Juju Snap Changes
Those of you subscribed to a snap channel may have noticed some nice changes that happened with 2.1 release. The juju snap package now utilizes classic mode, and all channels (including stable) are now active. You should expect feature parity (including things like bash completion) with the debian package of juju. In addition, the juju snap also shares environments with the debian installed version. This means your current models and credentials are utilized. I would encourage those that haven't yet tried out the snap to do so and provide feedback. I think you'll find it a quick and easy way to get juju. snap install juju --classic Those of you who want to build your own snap to share will also find it much easier. By default, running snapcraft on the juju tree will build a snap using your local tree and will bundle the needed agent. The snapcraft.yaml also points out how easily you can grab a specific branch, commit or tag to snap up. Sharing your own version of the juju client with the world is as simple as "snapcraft, snapcraft release". You'll find the snap related things in the snap folder in the juju git tree. As always PRs welcome! Nicholas -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju Snap Changes
Thanks Nicholas, Sounds awesome. Tim On 01/03/17 08:52, Nicholas Skaggs wrote: Those of you subscribed to a snap channel may have noticed some nice changes that happened with 2.1 release. The juju snap package now utilizes classic mode, and all channels (including stable) are now active. You should expect feature parity (including things like bash completion) with the debian package of juju. In addition, the juju snap also shares environments with the debian installed version. This means your current models and credentials are utilized. I would encourage those that haven't yet tried out the snap to do so and provide feedback. I think you'll find it a quick and easy way to get juju. snap install juju --classic Those of you who want to build your own snap to share will also find it much easier. By default, running snapcraft on the juju tree will build a snap using your local tree and will bundle the needed agent. The snapcraft.yaml also points out how easily you can grab a specific branch, commit or tag to snap up. Sharing your own version of the juju client with the world is as simple as "snapcraft, snapcraft release". You'll find the snap related things in the snap folder in the juju git tree. As always PRs welcome! Nicholas -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju Snap Changes
Hi Nicholas I'm having a hard time wrapping my head around classic mode. Classic mode means unconfined, right? What are the reasons for this switch? Is the snap still cross-distro? Will the snap have some expectations about the system outside of the snap? What are the advantages of an unconfined snap over a deb package? This isn't strictly Juju related, but maybe you can shed some light on this. I don't follow the project close enough to understand this feature. Confinement was key to the goals of snaps, ever since the click days.. Why the 180 now? I would think that if an application like Juju can't work in a confined snap, then snaps have an inherent flaw that needs to be fixed instead of having the workaround of the classic mode. Paraphrasing the story I've heard so many times: Snaps enable devs to push code directly to users without having to go through the long review process of the distro. Security and stability concerns are countered with confinement. Snaps enable devs to package once, run anywhere. Confinement + frameworks makes this possible... Snaps without confinement just seems like someone just brought .debs into the 21 century, and that seems very underwhelming to me. What am I missing here? Kind regards Merlijn 2017-02-28 20:52 GMT+01:00 Nicholas Skaggs : > Those of you subscribed to a snap channel may have noticed some nice > changes that happened with 2.1 release. The juju snap package now utilizes > classic mode, and all channels (including stable) are now active. You > should expect feature parity (including things like bash completion) with > the debian package of juju. In addition, the juju snap also shares > environments with the debian installed version. This means your current > models and credentials are utilized. > > I would encourage those that haven't yet tried out the snap to do so and > provide feedback. I think you'll find it a quick and easy way to get juju. > > snap install juju --classic > > Those of you who want to build your own snap to share will also find it > much easier. By default, running snapcraft on the juju tree will build a > snap using your local tree and will bundle the needed agent. The > snapcraft.yaml also points out how easily you can grab a specific branch, > commit or tag to snap up. Sharing your own version of the juju client with > the world is as simple as "snapcraft, snapcraft release". > > You'll find the snap related things in the snap folder in the juju git > tree. As always PRs welcome! > > Nicholas > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/juju > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju Snap Changes
> > ... > > I'm having a hard time wrapping my head around classic mode. Classic mode > means unconfined, right? > > What are the reasons for this switch? Is the snap still cross-distro? Will > the snap have some expectations about the system outside of the snap? What > are the advantages of an unconfined snap over a deb package? > To get a deb package, you have to generally add something like a PPA, which means you now get anything they want to give you from that PPA. Core libraries, a new kernel, whatever. Once you've accepted the terms of a PPA, you're trusting that person not to hose you over. While classic snaps still have access to the rest of the filesystem, they 1) Still include their dependencies inside their containment, rather than producing other packages that you must also install. 2) Can't muck with things outside of that (so saying 'snap install juju --classic' won't be able to change package kernel) 3) Give you all the nice release cadence, etc of other snaps. Mainly things like "I'm willing to run beta", "I only want to run candidate+" etc. 4) Are definitely no-less secure than deb packages. 5) Can get your software into snaps immediately, and you can transition into more confinement as you can make it work. 6) Snaps apply transactionally. An update can't partially apply half of the update and then fail (if it does, the whole update is rolled back). > > This isn't strictly Juju related, but maybe you can shed some light on > this. I don't follow the project close enough to understand this feature. > Confinement was key to the goals of snaps, ever since the click days.. Why > the 180 now? > Confinement is great for a lot of things, but not everything. Vim confined to not be able to read your .bashrc file isn't a very good vim. Juju doesn't need access to everything, so there is still room to grow support in Snap confinement to limit you to the right subset (we do want to read .ssh/id_rsa* and .local/share/juju, we don't need to read .mozilla/firefox/...) > > I would think that if an application like Juju can't work in a confined > snap, then snaps have an inherent flaw that needs to be fixed instead of > having the workaround of the classic mode. Paraphrasing the story I've > heard so many times: Snaps enable devs to push code directly to users > without having to go through the long review process of the distro. > Security and stability concerns are countered with confinement. Snaps > enable devs to package once, run anywhere. Confinement + frameworks makes > this possible... > > Snaps without confinement just seems like someone just brought .debs into > the 21 century, and that seems very underwhelming to me. What am I missing > here? > > The distribution model and the dependency model are a lot nicer. Transactional updates to the packages is also *extremely* nice. John =:-> > > Kind regards > Merlijn > > 2017-02-28 20:52 GMT+01:00 Nicholas Skaggs > : > >> Those of you subscribed to a snap channel may have noticed some nice >> changes that happened with 2.1 release. The juju snap package now utilizes >> classic mode, and all channels (including stable) are now active. You >> should expect feature parity (including things like bash completion) with >> the debian package of juju. In addition, the juju snap also shares >> environments with the debian installed version. This means your current >> models and credentials are utilized. >> >> I would encourage those that haven't yet tried out the snap to do so and >> provide feedback. I think you'll find it a quick and easy way to get juju. >> >> snap install juju --classic >> >> Those of you who want to build your own snap to share will also find it >> much easier. By default, running snapcraft on the juju tree will build a >> snap using your local tree and will bundle the needed agent. The >> snapcraft.yaml also points out how easily you can grab a specific branch, >> commit or tag to snap up. Sharing your own version of the juju client with >> the world is as simple as "snapcraft, snapcraft release". >> >> You'll find the snap related things in the snap folder in the juju git >> tree. As always PRs welcome! >> >> Nicholas >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/juju >> > > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju > > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju Snap Changes
Thanks for the thorough explanation! 2017-03-01 7:07 GMT+01:00 John Meinel : > ... >> > > >> I'm having a hard time wrapping my head around classic mode. Classic mode >> means unconfined, right? >> >> What are the reasons for this switch? Is the snap still cross-distro? >> Will the snap have some expectations about the system outside of the snap? >> What are the advantages of an unconfined snap over a deb package? >> > > To get a deb package, you have to generally add something like a PPA, > which means you now get anything they want to give you from that PPA. Core > libraries, a new kernel, whatever. Once you've accepted the terms of a PPA, > you're trusting that person not to hose you over. > > While classic snaps still have access to the rest of the filesystem, they > 1) Still include their dependencies inside their containment, rather than > producing other packages that you must also install. > 2) Can't muck with things outside of that (so saying 'snap install juju > --classic' won't be able to change package kernel) > 3) Give you all the nice release cadence, etc of other snaps. Mainly > things like "I'm willing to run beta", "I only want to run candidate+" etc. > 4) Are definitely no-less secure than deb packages. > 5) Can get your software into snaps immediately, and you can transition > into more confinement as you can make it work. > 6) Snaps apply transactionally. An update can't partially apply half of > the update and then fail (if it does, the whole update is rolled back). > > >> >> This isn't strictly Juju related, but maybe you can shed some light on >> this. I don't follow the project close enough to understand this feature. >> Confinement was key to the goals of snaps, ever since the click days.. Why >> the 180 now? >> > > Confinement is great for a lot of things, but not everything. Vim confined > to not be able to read your .bashrc file isn't a very good vim. Juju > doesn't need access to everything, so there is still room to grow support > in Snap confinement to limit you to the right subset (we do want to read > .ssh/id_rsa* and .local/share/juju, we don't need to read > .mozilla/firefox/...) > > >> >> I would think that if an application like Juju can't work in a confined >> snap, then snaps have an inherent flaw that needs to be fixed instead of >> having the workaround of the classic mode. Paraphrasing the story I've >> heard so many times: Snaps enable devs to push code directly to users >> without having to go through the long review process of the distro. >> Security and stability concerns are countered with confinement. Snaps >> enable devs to package once, run anywhere. Confinement + frameworks makes >> this possible... >> >> Snaps without confinement just seems like someone just brought .debs into >> the 21 century, and that seems very underwhelming to me. What am I missing >> here? >> >> > The distribution model and the dependency model are a lot nicer. > Transactional updates to the packages is also *extremely* nice. > > John > =:-> > > >> >> Kind regards >> Merlijn >> >> 2017-02-28 20:52 GMT+01:00 Nicholas Skaggs > >: >> >>> Those of you subscribed to a snap channel may have noticed some nice >>> changes that happened with 2.1 release. The juju snap package now utilizes >>> classic mode, and all channels (including stable) are now active. You >>> should expect feature parity (including things like bash completion) with >>> the debian package of juju. In addition, the juju snap also shares >>> environments with the debian installed version. This means your current >>> models and credentials are utilized. >>> >>> I would encourage those that haven't yet tried out the snap to do so and >>> provide feedback. I think you'll find it a quick and easy way to get juju. >>> >>> snap install juju --classic >>> >>> Those of you who want to build your own snap to share will also find it >>> much easier. By default, running snapcraft on the juju tree will build a >>> snap using your local tree and will bundle the needed agent. The >>> snapcraft.yaml also points out how easily you can grab a specific branch, >>> commit or tag to snap up. Sharing your own version of the juju client with >>> the world is as simple as "snapcraft, snapcraft release". >>> >>> You'll find the snap related things in the snap folder in the juju git >>> tree. As always PRs welcome! >>> >>> Nicholas >>> >>> -- >>> Juju mailing list >>> Juju@lists.ubuntu.com >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/juju >>> >> >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/juju >> >> > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju Snap Changes
And thanks to Merlijn for bing blunt enough to ask the questions a lot of us were thinking about snaps! :) On Wed, Mar 1, 2017 at 9:27 AM, Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > Thanks for the thorough explanation! > > 2017-03-01 7:07 GMT+01:00 John Meinel : > >> ... >>> >> >> >>> I'm having a hard time wrapping my head around classic mode. Classic >>> mode means unconfined, right? >>> >>> What are the reasons for this switch? Is the snap still cross-distro? >>> Will the snap have some expectations about the system outside of the snap? >>> What are the advantages of an unconfined snap over a deb package? >>> >> >> To get a deb package, you have to generally add something like a PPA, >> which means you now get anything they want to give you from that PPA. Core >> libraries, a new kernel, whatever. Once you've accepted the terms of a PPA, >> you're trusting that person not to hose you over. >> >> While classic snaps still have access to the rest of the filesystem, they >> 1) Still include their dependencies inside their containment, rather than >> producing other packages that you must also install. >> 2) Can't muck with things outside of that (so saying 'snap install juju >> --classic' won't be able to change package kernel) >> 3) Give you all the nice release cadence, etc of other snaps. Mainly >> things like "I'm willing to run beta", "I only want to run candidate+" etc. >> 4) Are definitely no-less secure than deb packages. >> 5) Can get your software into snaps immediately, and you can transition >> into more confinement as you can make it work. >> 6) Snaps apply transactionally. An update can't partially apply half of >> the update and then fail (if it does, the whole update is rolled back). >> >> >>> >>> This isn't strictly Juju related, but maybe you can shed some light on >>> this. I don't follow the project close enough to understand this feature. >>> Confinement was key to the goals of snaps, ever since the click days.. Why >>> the 180 now? >>> >> >> Confinement is great for a lot of things, but not everything. Vim >> confined to not be able to read your .bashrc file isn't a very good vim. >> Juju doesn't need access to everything, so there is still room to grow >> support in Snap confinement to limit you to the right subset (we do want to >> read .ssh/id_rsa* and .local/share/juju, we don't need to read >> .mozilla/firefox/...) >> >> >>> >>> I would think that if an application like Juju can't work in a confined >>> snap, then snaps have an inherent flaw that needs to be fixed instead of >>> having the workaround of the classic mode. Paraphrasing the story I've >>> heard so many times: Snaps enable devs to push code directly to users >>> without having to go through the long review process of the distro. >>> Security and stability concerns are countered with confinement. Snaps >>> enable devs to package once, run anywhere. Confinement + frameworks makes >>> this possible... >>> >>> Snaps without confinement just seems like someone just brought .debs >>> into the 21 century, and that seems very underwhelming to me. What am I >>> missing here? >>> >>> >> The distribution model and the dependency model are a lot nicer. >> Transactional updates to the packages is also *extremely* nice. >> >> John >> =:-> >> >> >>> >>> Kind regards >>> Merlijn >>> >>> 2017-02-28 20:52 GMT+01:00 Nicholas Skaggs < >>> nicholas.ska...@canonical.com>: >>> Those of you subscribed to a snap channel may have noticed some nice changes that happened with 2.1 release. The juju snap package now utilizes classic mode, and all channels (including stable) are now active. You should expect feature parity (including things like bash completion) with the debian package of juju. In addition, the juju snap also shares environments with the debian installed version. This means your current models and credentials are utilized. I would encourage those that haven't yet tried out the snap to do so and provide feedback. I think you'll find it a quick and easy way to get juju. snap install juju --classic Those of you who want to build your own snap to share will also find it much easier. By default, running snapcraft on the juju tree will build a snap using your local tree and will bundle the needed agent. The snapcraft.yaml also points out how easily you can grab a specific branch, commit or tag to snap up. Sharing your own version of the juju client with the world is as simple as "snapcraft, snapcraft release". You'll find the snap related things in the snap folder in the juju git tree. As always PRs welcome! Nicholas -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm an/listinfo/juju >>> >>> >>> -- >>> Juju mailing list >>> Juju@lists.ubuntu.com >>> Modify settings or unsubscribe at: https://lists.ubuntu.c
Re: Juju Snap Changes
A 'classic' snap is OK in the cases where the tool in question really, really makes sense as part of a classic environment. Things like compilers, editors, file viewers, etc, all make sense. It's also a nice comfortable way to start out making a snap, but for things that can be confined, its best not to stop at 'classic' and keep going to 'strict' via 'devmode' :) The absence of confinement on classic snaps means we'll want to think carefully about how they end up on a user's system. At the moment our thinking is that they should ideally be: * built from upstream source * built on the same system that builds debs today If that's true, then we're really just cutting out a lot of work between upstream and distro users, not creating substantial new risks. To get a classic snap into the store you need to ask, and the folks there are expected to exercise judgment. Once we have a clear framework that works well, that will become policy. Its a lot of fun to make a snap, and upstreams that are not part of the Great Linux Tribal Theater are ime happy to see snapcraft.yaml land in their trunk so they get daily builds in edge channels for free from build.snapcraft.io. Those builds are created in the same trusted environment that debs are built. I would recommend it for places where you are working with upstreams that are fast moving (or where the 16.04 deb is out of date for other reasons). Mark -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju