New install/refresh API with the store

noise · November 1, 2017, 10:55pm

We had discussed during the Rally to consider changing our json field names to using dashes instead of underscores to align with how things are presented in snapd and assertions.

pedronis · November 2, 2017, 6:49am

afaik that is what we are doing (also as seen in code) but the discussion here is often using _ still:

ricardokirkner · November 2, 2017, 2:31pm

Yes, all fields (input and output) will use - instead of _ if they’re multi-word names.

ricardokirkner · November 2, 2017, 2:32pm

@pedronis are you ok with changing the input ‘name’ parameter to ‘snap-name’ (for consistency reasons mostly).

pedronis · November 2, 2017, 3:18pm

I’m not even 100% sure about “snap-name” in the output, seems a topic for when Gustavo is back

ricardokirkner · November 2, 2017, 3:33pm

@pedronis ok… I will pre-emptively change the input field to snap-name (for consistency reasons) and we can review this (globally) when @niemeyer comes back.

pedronis · November 2, 2017, 3:43pm

I would have left it alone… but let me know, I need to update the top post, giving that this is input

facundobatista · November 6, 2017, 8:13pm

@pedronis let’s define the new API for getting details for a snap here or you will open a new thread? thanks!

niemeyer · November 9, 2017, 6:02pm

The consistent version of this in the snap world is actually “name”.

That’s true in more places than I can count, but just of the top of my mind:

snapd API
snap info command output
snap list command output
snapd code, all of it
client library
snap.yaml
snapcraft.yaml
…

facundobatista · November 21, 2017, 4:08pm

@pedronis @chipaca , do we need pagination on this endpoint?

Furthermore, is pagination possible? (I’m in doubt, because that would mean that after considering all the context and all proper validations, returning “only the first N” responses it would mean that the client would apply part of the “resulting state”…

pedronis · November 22, 2017, 12:38pm

I don’t think pagination makes sense for this API (if we really reach payload size issues in a while will need to think, but don’t think pagination alone would be an answer)

facundobatista · November 22, 2017, 1:14pm

Maybe we should remove the snap id and name from here, as those already are part of the mandatory external information where these fields will be included… what do you think?

facundobatista · November 27, 2017, 12:31pm

So, we’ll leave snap_id and package_name out of internal fields, as it’s alredy in the mandatory data “outside”

facundobatista · December 15, 2017, 8:07pm

@pedronis @chipaca Question…

If revision is specified (in the “install” and/or “refresh” sections), the Store should try to answer that revision if that revision is currently released or was released at some point in the past in the specified channel? Or ‘channel’ becomes irrelevant if ‘revision’ is specified?

Thanks!!

facundobatista · January 25, 2018, 8:49pm

@pedronis @niemeyer question… if the revision is specified in the “install” or “refresh” request, all the “controls” apply? I mean if even if the client specify a revision X, the server needs to check “if that revision is validated because it’s a gated snap” or “if the revision complies with the stepped updates rules”…

Or if a revision is specified we should just return it and that’s all?

One detail to consider in this case is what would happen if we just return the requested revision, and then an auto-refresh happens and the revision is changed…

For the record, for the Stepped Updates (Epoch) analysis we took the decision of returning 404 if a revision is requested but it “breaks” the rules to get to that revision…

Thanks!

pedronis · January 29, 2018, 2:46pm

We can live with either behavior I think, because at least for “refresh” snapd will check the refresh-control constraints and also epoch (once we have them). Checking unless ignore-validation is sent would be more consistent though.