charms need to be able to declare if they can run in a container

[Scott Moser]

Juju recently gained the ability to put charms inside a lxc container. Among other methods, with something like this:
  juju deploy --to=existing_machine:lxc charm

Some services (charms) are not able to run inside a container, or at least running them inside a container would require giving them access to un-containerized resources which would defeat the purpose.

Some examples to think about:
 * maas-cluster-controller (at the moment) requires ability to 'mount -o loop' (bug 1257389)
 * nova-compute requires access to loop devices (and likely always will), and also cinder configured with iscsi.
 * openstack neutron requires access to openvswitch kernel module. It may even depend on a specific version of the module or a set of functionality.

While my list is limited to openstack components, reality is that any application developed may use linux resources that are not yet namespaced.

The short path to "supporting" those is to just allow the charm to declare a boolean defining whether or not it will run in a container. A more flexible approach might allow the charm to declare a set of resources that it would need access to inside a container. Ie, it expects that 'openvswitch' kernel module is loaded, or that it can interact with /dev/loopX and /dev/loopctl.

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2013-12-05 23:33, Curtis Hovey wrote:
> ** Changed in: juju-core Status: New => Triaged
>
> ** Changed in: juju-core Importance: Undecided => High
>
> ** Tags added: charms local-provider
>

Seeing this, I remember we talked about putting the charm "needs foo"
into the bundle containing that charm, rather than in the charm itself.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKlptQACgkQJdeBCYSNAAPSfQCfcPDBezvRQIkUMUCvM0sUIvW2
R0AAoJvgL4UH+izBn79EaizTLs7WU3EU
=jQCX
-----END PGP SIGNATURE-----

[Kapil Thangavelu (hazmat)]

This is more inherently a property of the charm then the bundle. The bundle
can do declarative placement as a deployment consideration, but the charm
needs the ability to specify container support so that the actual
deployments and bundles only use valid placement forms.

On Mon, Dec 9, 2013 at 3:17 AM, John A Meinel <email address hidden>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2013-12-05 23:33, Curtis Hovey wrote:
> > ** Changed in: juju-core Status: New => Triaged
> >
> > ** Changed in: juju-core Importance: Undecided => High
> >
> > ** Tags added: charms local-provider
> >
>
> Seeing this, I remember we talked about putting the charm "needs foo"
> into the bundle containing that charm, rather than in the charm itself.
>
> John
> =:->
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (Cygwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlKlptQACgkQJdeBCYSNAAPSfQCfcPDBezvRQIkUMUCvM0sUIvW2
> R0AAoJvgL4UH+izBn79EaizTLs7WU3EU
> =jQCX
> -----END PGP SIGNATURE-----
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1257729
>
> Title:
> charms need to be able to declare if they can run in a container
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1257729/+subscriptions
>

[Anastasia (anastasia-macmood)]

Re-targeting to Juju 2.x

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 5 years, so we're marking it Expired. If you believe this is incorrect, please update the status.