
Snap install openstackclients - elopio
https://javacruft.wordpress.com/2017/02/03/snap-install-openstackclients/
======
alsadi
I belive doing typical oci-standard docker image suites portability and
servers and sysadmin more than canonical's non-standard vendor lockins

~~~
timthelion
What kind of image format does snap use? Is packaging complicated? I've noted
that flatpak is a nightmare to package for.

I created subuser <subuser.org> which runs on top of Docker, and of course,
packaging is as simple as it is with Docker... The big problem is that when
you want to update something, it is hard to do so without making everyone have
to download a huge image all over again. Of course, you can try to prevent
this with layers, but usually updates don't just touch the top layer :( ... So
what I really want in the future is to be able to use IPFS or some kind of
bittorrent-like download interface for images, so that when you update an
image, you only have to download the parts that changed. There is a GREAT demo
by a guy named Mathias Buus on this very topic here
[https://www.youtube.com/watch?v=2Sc6_XgNXyk](https://www.youtube.com/watch?v=2Sc6_XgNXyk)
which really gives you a feel for the awsome that would be deduplicated
content addressed Docker.

Flatpak has something sorta similar, they use OSTree under the hood.
[https://github.com/ostreedev/ostree](https://github.com/ostreedev/ostree)
which is basically git annex for people who like incompatible
redhat/freedesktop specific implementations of generic algorithms. It also
does dedup, but at the file level not the block level, and so flatpak should
be better at handling updates than subuser/Docker. Then again, who wants to
repackage everything with their weird "standard" overcomplicated image format
when you can just use Docker and throw anything you like into the image,
however you like to throw it....

~~~
coreycb
You can just use a base Ubuntu 16.04 image or greater. Creating a snap is very
simple. Here's the source for snap-openstackclients:
[https://github.com/openstack/snap-
openstackclients](https://github.com/openstack/snap-openstackclients)

~~~
timthelion
Thanks for the link. I'm not going to provide an opinion in a HN/while-on-the-
front-page timescale, because I'd like to actually study the system that you
use and come to an educated conclusion.

~~~
coreycb
No problem. If you have questions/comments later #openstack-snaps on freenode
is a good place.

------
Daviey
James, it would be great you could provide some feedback on _why_ this snap is
better than using a docker image.

Ie, Why is it better than:

    
    
      alias openstackclient='docker run --rm -ti -v ~/.config/openstack:/etc/openstack gbraad/openstack-client:ubuntu openstack "$@"'

~~~
elopio
I'm not James, but I have opinions! :D

A docker image runs a full operating system. There are some light OSs for
docker, but that's still heavier than a snap.

The snap runs directly on your host, with a different kind of isolation to
make it secure. So it also makes easy other kinds of communication between
apps, like unix sockets or dbus.

Then there's the great feature of autoupdates. If the openstack developers
push a new version, it will reach all the users within 4 hours. On a docker
container you can have the same problems you have in classic distros. You'll
get an old version by default, and you have to apply hacks or accept other
risks if you want to get a newer.

What would be awesome is to be able to run snaps inside docker containers.
That will be a mix of both worlds, docker for replication and adding or
removing new machines as the load changes; snaps for getting the software into
those machines. We can currently do that with linux containers, maybe at some
point docker will support them too.

And we have snaps for docker and lxd, make sure to give them a try:

$ sudo snap install docker $ sudo snap install lxd

~~~
timthelion
To what extent is snap a new package manager and to what extent is it a
security mechanism? Does it actually prevent the application from getting full
access to the user's home directory?

~~~
elopio
It's a new package manager that implements existing linux security mechanisms.
It will use apparmor to confine the snap to the directories that it is allowed
to read and write. By default, $HOME/snap/snap-name/

Then the snap can use interfaces to go out of its confinement and access
things that the user has agreed to allow:
[https://github.com/snapcore/snapd/wiki/Interfaces](https://github.com/snapcore/snapd/wiki/Interfaces)

~~~
timthelion
Cool, though it seems to be "insecure by defualt". I presume that there will
be some clear way to say "I don't trust this snap, dissable everything like
gsettings, pulseaudio microphone support, ect. that I wouldn't want some
random untrusted code to access..."

I didn't know that DBUS supported selectively allowing access to selected
services. I thought that was a new feature in the non-accepted kdbus. That was
certainly what the redhat folks wrote. They wrote that it isn't possible to
secure dbus without kdbus...

~~~
mhall119
This works:

> snap disconnect <snap>:<plug>

Then you can reconnect with:

> snap connect <snap>:<plug>

dbus mediation is something that Canonical developers added, IIRC.

~~~
timthelion
I saw it in the docs, but my question was how did they do it when this is a
missing feature in DBus... So Canonical added this feature to dbus but it
hasn't made its way upstream or redhat chooses to ignore the new feature so
that they have a reason to promote kdbus. OK.

