"Create your own Core image" tutorial doesn't cover --extra-snaps

kyrofa 2017-03-29 19:41:41 UTC #1

Hey all. I recently finished a soon-to-be-published blog series walking the reader through taking a ROS prototype to production with Ubuntu Core. Part of this series is creating a custom gadget snap to expose serial ports to the ROS snap, and creating a custom image with this gadget and ROS snap pre-installed.

This effort ultimately ended in success, but I wanted to provide some feedback about some of the rough edges I encountered while going through this process. This is one of those rough edges.

There’s a super-handy Ubuntu Core image-creation tutorial that taught me most of the ubuntu-image usage necessary for creating the image. However, I wanted to be able to test my gadget snap without needing to put it in the store first (as gadget snaps still require manual review). The tutorial says that the gadget in the model definition “can be a file on disk,” but that made me think I could provide a file path in the definition, which isn’t correct. This requires the usage of --extra-snaps, which is not mentioned in the tutorial. I’ve logged a bug to discuss this.

JamieBennett 2017-03-30 07:50:28 UTC #2

Great feedback @kyrofa, thanks.

niemeyer 2017-03-30 21:03:04 UTC #3

niemeyer 2017-03-30 21:13:26 UTC #4

@kyrofa I’ve broken your topic down into several individual topics with proper titles and filed in the proper places, otherwise we can’t tell what the content is about out of the title, and will have an interleaved conversation discussing completely independent issues.

About --extra-snaps, which is your first point and what this topic is now about, let’s please not have that option in the tutorial. This option is most likely going away at some point, because we cannot accept extra snaps in an image that are not in the model signed by the image publisher. If you want extra snaps in an image, you need a new model that specifies them.

niemeyer 2017-03-30 21:13:32 UTC #5

kyrofa 2017-03-30 22:26:54 UTC #6

Sure, though the fact that you can open new topics as me is slightly disconcerting .

Does that mean the ability to install local (unpublished) snaps into an image will be going away entirely? I assume not… testing gadgets by pushing to the store (which still requires manual approval) before being able to generate an image with them sounds painful, no?

niemeyer 2017-03-30 22:30:06 UTC #7

If you don’t trust me you have much larger problems to worry about.

No, it means that the publisher must sign the fact it wants an image published like that. It’s their image. If you want to change that, you can just sign your own image.

kyrofa 2017-03-30 22:33:10 UTC #8

Isn’t that what I was doing? I created a model assertion (is that “signing the image?”), but that only contains snap names. I needed to use --extra-snaps to satisfy those names with local snaps. I’m not quite clear on how that workflow will change with what you describe.

niemeyer 2017-03-30 22:36:15 UTC #9

Last I checked --extra-snaps was doing that even if it wasn’t in the model. This will eventually stop working altogether. If it is in the model, then all good.

By the way, note that the change in ownership is visible via the pencil in top-right corner. The admin can hide those revisions too, but I wouldn’t do that in this case.

kyrofa 2017-03-30 22:38:46 UTC #10

Ah yes, that makes sense. So are you saying that --extra-snaps will simply be replaced by a similar option that only works if the snap name in question is given in the model assertion? Or just that --extra-snaps will stop installing snaps not contained in the model assertion?

kyrofa 2017-03-30 22:48:49 UTC #11

Sure. For what it’s worth, I would have been happy to split them myself had you asked.

niemeyer 2017-03-30 22:50:21 UTC #12

The model will always be able to specify what goes installed into the image by default. Those snaps must be there, and no other snaps. Otherwise it’s not the same model anymore.

Command line options should enable one to set up details such as which specific revision of the snap, or which channel, or even which local file to take it from. But not “extra snaps” that were not defined to be in the model in the first place.

kyrofa 2017-03-30 22:52:09 UTC #13

That sounds perfect, thanks!

niemeyer 2017-03-30 22:54:36 UTC #14

Speaking of forum best practices, there’s no need to use quoting at all times when you’re just replying to what was said above anyway. Quoting is useful mainly when you want to reply to particular points that will get unclear unless quoted.

retrocausal 2017-08-30 08:28:16 UTC #15

I have been following the guide at creating a core snap

When it comes to gadget and kernel snaps, for the model assertion, the guide says,

gadget: name of the gadget snap as published on the store. Note that this snap can be a file on disk.
kernel: name of the gadget snap as published on the store. Similarly to the gadget snap, it can be a file on disk.

Now I am trying to find the store that lists available gadget and kernel snaps, but I can not find one.

Is there a store where I can find existing kernel and gadget snaps? as in, does canonical itself list official kernel and gadget snaps?

ogra 2017-08-30 09:46:46 UTC #16

Note that any snap used with ubuntu-image can be a file on disk …

you could even “snap download core” (as long as you are on the same architecture as the image targets at least) and use --extra-snaps /path/to/core …

the store will only search for your current arch, and has no way to serach by snap type, so all you can find on a PC will be the pc gadget (with prior knowledge that it has “pc” in the name):

ogra@anubis:~$ snap find pc|grep gadget
pc-turtlebot-kyrofa  16.04-0.8     kyrofa        gadget  AMD64 gadget for the Turtlebot 2
pc                   16.04-0.8     canonical     gadget  AMD64 generic package

There is a third party store frontend that is not that strict try:

https://uappexplorer.com/snaps?type=gadget