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.
afaik that is what we are doing (also as seen in code) but the discussion here is often using _ still:
Yes, all fields (input and output) will use - instead of _ if they’re multi-word names.
@pedronis are you ok with changing the input ‘name’ parameter to ‘snap-name’ (for consistency reasons mostly).
I’m not even 100% sure about “snap-name” in the output, seems a topic for when Gustavo is back
I would have left it alone… but let me know, I need to update the top post, giving that this is input
Epochs (stepped upgrades)
@pedronis let’s define the new API for getting details for a snap here or you will open a new thread? thanks!
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
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”…
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)
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?
So, we’ll leave snap_id and package_name out of internal fields, as it’s alredy in the mandatory data “outside”
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?
@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…
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.
started proposing PRs for this work:
and this for actually using the new API:
Support and switch to this is now on master.
Backport for 2.32.x has been prepared here:
support and use have landed in 2.32.4