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.
@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.
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?
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.
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?
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.
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.