Using the fakestore


#1

Hi,

As some of you know, I am working on a feature where subiquity will offer the user a change to refresh to a newer version of subiquity during the install if one is available. To test this I need to be able to easily create a situation where snapd in a vm thinks there is an update available.

The fake store (tests/lib/fakestore) in the snapd source is the tool for this, but I can’t quite make it work. I’ve got a snapd in a vm, built with -tags withtestkeys and configured to talk to the store running on my host system but whenever I try to do anything store related, snapd says “error: cannot get nonce from store: store server returned status 418”. I think this means that I am hitting an endpoint the fakestore does not support – looking at the logs, it seems to be “/api/v1/snaps/auth/nonces”, which certainly the fakestore doesn’t seem to support.

Help?

It also looks like the fakestore only implements a pretty small set of store apis. Would it be possible to generically forward other requests to the fallback store?


#2

Ah I can get somewhere by doing some other store operation before reconfiguring snapd to talk to the fake store. That works but is a bit inconvenient. The next thing was that passing --addr=0.0.0.0:11028 to fakestore --run caused the fake store to tell snapd to download the snap from http://0.0.0.0:11028/download/… which was a bit confusing :slight_smile:

Finally, is there a simple way to create an assertion for a snap signed by the test key? My current script for injecting a snap into an ISO inserts it unasserted, which means that snapd needs some prodding to consider refreshing it.


#3

Oh one more question: it seems one can only make the fakestore refresh to a snap you have installed on the machine the fake store is running on. That’s definitely less than ideal for me, would it be possible to pass it a locally made .snap file (and possibly a locally generated assertion for that snap file, per the previous question)?


#4

there is fakestore new-snap-revision, takes a .snap, --dir to put things in, and optionally a --snap-rev-json <.json> to override its naive defaults about what to put in the assertion headers.

Code is here: https://github.com/snapcore/snapd/blob/master/tests/lib/fakestore/cmd/fakestore/cmd_new_snap_rev.go

Sticking .snap in --dir <dir> for run and assertions in <dir>/asserts should work afaik


#5

Thanks, that pointed in the right direction.

I’ve made things work a bit. My rough notes are here http://paste.ubuntu.com/p/93kvGwBc3D/

If I do all this, then snap refresh --list shows an available upgrade for subiquity as I want, but when I try to actually refresh I hit the si.Revision != snapRev.SnapID() failure in CrossCheck (si.Revision is the old revno). Help?


#6

here:

echo '{"snap-revision": "123456"}' > rev1.json

you should set also the original "snap-id" and "developer-id" for subiquity. AFAICT they are:

"snap-id":  "ba2aj8guta0zSRlT3QM5aJNAUXPlBtf9"
"developer-id": "canonical"