I have heard that the system in use to package and install apps in sandboxes on ubuntu is the click package on the desktopNext and phone/tablet.

If I have understood well, a snappy ubuntu core apps, is packaged the same way as a click apps (both using apparmor), It might be tagged "snappy" to be sure they target a server, not a client device.

I also know there are some charms on the Ubuntu server's Juju tool to install apps on a server.

Are those those click/snappy apps same as a Charm ?

I am right if I say charms are like containers that can install .deb or snappy apps and also add some metadata to allow the Juju tool to know (for example) how to configure the apps, or how to connect apps together so it will be easier to a human to configure his environement full of techi server apps ; And those charm are just made to work on Juju, to be deployed at scale, not necessarily on only 1 device ?

| improve this question | | | | |

Charms aren't packages, charms are code and metadata that deploy services across multiple machines; so they consume debian packages. People have made analogies that charms are like "cloud packages" or "apt-get for the cloud", but it's not a packaging system as more as it is a collection of code.

A typical charm install hook might contain apt-get commands to install software from a repository, or they might grab tarballs, or they might even contain the binaries themselves. It's really up to the charm author how a charm installs the software.

I would expect as snappy becomes more popular that many charms will choose to use snappy packages for installation, or at least offer it as an option. It should be noted that currently you can't deploy a charm to a snappy system, but there's no reason this wouldn't be an option for people in the future.

| improve this answer | | | | |

A Charm is more similar to a Puppet Module or a Chief Recipe. Charms, Modules, and Recipes are mechanisms for orchestration which is different than package management. Orchestration involves the installation and management of the installed resources. The orchestration software can dynamically configure the installed software customized for the user. It can manage that configuration over time as well. Take for instance an web certificate. Certificates expire after some time. Orchestration software can install the certificate. When the certificate needs to be replaced, the orchestration software can managed the update (automatically).

Its my personal opinion that Puppet is the best orchestration software. Its the oldest, has the most support, is Free Source, has a great community, has multitudes of documentation, has its own programming language, is actively developing and evolving. The latest version of puppet has defined types!!!

I know that one can write puppet code to create a charm, but you are losing out of the other benefits of running a puppet system. When using puppet, its best to leverage the puppet server for managing the entire lifecycle of the software and systems.

I'm not terribly familiar with charms, but I think they do not manage system resources like Puppet. The important bit is change management. IE, puppet ensures that the resources it knows about are in the correct state. Meaning, if an admin ssh's into the box and changes a configuration file manually (maybe he is debugging), puppet will revert the changes back to what's specified in the puppet code. I don't think charms have this capability. Please correct me if I am wrong.

| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.