Snap install openstackclients | Hacker News Reader

Snap install openstackclients

javacruft.wordpress.com

52 pointselopio22 comments

I belive doing typical oci-standard docker image suites portability and servers and sysadmin more than canonical's non-standard vendor lockins

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

A snap is a squashfs of a directory with a metadata file in ./meta/snap.yaml

We can also provide binary delta downloads of snaps.

We use ansible to generate small inremental updates of docker images. The ansible takes any base image and put it into desired state. We feed it a milestone image to generate a small layer over it.

http://engineering.opensooq.com/manage-your-docker-image-lay...

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

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.

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

Docker != OCI. Please don't confuse the two.

Docker inc. is a key member of oci which is under linux foundation

https://www.opencontainers.org/faq

Docker Inc is one of many members of the OCI and is by no means the most major contributor.

[I'm one of the maintainers of runC and am very involved in the OCI.]

thank you.

Snaps aren't limited to Ubuntu. I'm not sure the extent of support but just to note that there is support for other distros: https://snapcraft.io/

They're a much easier way to package applications vs traditional packaging (ie apt, rpm).

Your meaning of everywhere is by having 3rd party non official repos that ship small copy of ubuntu core.

Remind me why do steam do have to ship ubuntu's version of heavily patched libraries instead of using system upstrean version shipped by archlinux for example?

If snap is not a vendor lockin trap what is the vendor lockin trap?

Here's the status of support everywhere: https://github.com/snapcore/snapd/wiki/Distributions

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 "$@"'

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

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?

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

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

This works:

> snap disconnect <snap>:<plug>

Then you can reconnect with:

> snap connect <snap>:<plug>

dbus mediation is something that Canonical developers added, IIRC.

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.

Your example runs 'openstack' in a container. The snap runs 'openstack' without a container. The question really is what does the container do for you to justify adding it to the stack?

Reply on news.ycombinator.com