Re: Juju Snap Changes

[Mark Shuttleworth]

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

Re: Juju Snap Changes

[Tom Barber]

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 

Re: Juju Snap Changes

[Merlijn Sebrechts]

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

[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/
> 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

[Merlijn Sebrechts]

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

Juju Snap Changes

[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/mailman/listinfo/juju