local provider should use cloud images

[Nick Barcet]

Update: The underlying issue here is that the local provider/lxc should be using cloud images instead of the minimal debootstrap we're getting with lxc.

juju on oneiric with lxc provider

Any time I invoke a command that uses perl in a unit, I receive the following errors:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

[Clint Byrum (clint-fewbar)]

Seems like this is a documentation bug. We should make it clear what the user can and cannot expect from the environment. I'd rather do that than get heavy handed about the container creation.

The other option is to make an LXC template that uses the Ubuntu cloud images. But that would then put bare metal installs as the second class citizen to LXC and EC2, so I think its better to simply document this and fix bugs as they come up. If you need a locale, you probably need a package which provides one, or a config option to configure it.

[Scott Moser (smoser)]

On Mon, 23 Jan 2012, Clint Byrum wrote:

> The other option is to make an LXC template that uses the Ubuntu cloud
> images. But that would then put bare metal installs as the second class
> citizen to LXC and EC2, so I think its better to simply document this
> and fix bugs as they come up. If you need a locale, you probably need a
> package which provides one, or a config option to configure it.

I don't follow that statement.
At the moment, LXC would be the "second class citizen". bare metal (via
cobbler/orchestra) and EC2 will have a sane locale set. So setting one in
lxc would put it on equal footing.

[Clint Byrum (clint-fewbar)]

Excerpts from Scott Moser's message of Mon Jan 23 18:37:49 UTC 2012:
> On Mon, 23 Jan 2012, Clint Byrum wrote:
>
> > The other option is to make an LXC template that uses the Ubuntu cloud
> > images. But that would then put bare metal installs as the second class
> > citizen to LXC and EC2, so I think its better to simply document this
> > and fix bugs as they come up. If you need a locale, you probably need a
> > package which provides one, or a config option to configure it.
>
> I don't follow that statement.
> At the moment, LXC would be the "second class citizen". bare metal (via
> cobbler/orchestra) and EC2 will have a sane locale set. So setting one in
> lxc would put it on equal footing.
>

I mean in a broader sense, not in this particular bug.

If we fix *this* in LXC by using the cloud images, then EC2 and Orchestra
are using the same source, which is great, but it also means that
providers that can't use the cloud images become more prone to problems.

In many ways, using the minimal install of Ubuntu will help to make the
charms more robust to changes in the default seeds of the cloud images
because people will need to document *everything* they need, since they
can really only count on having juju and the minimal Ubuntu install.

[Scott Moser (smoser)]

On Mon, 23 Jan 2012, Clint Byrum wrote:

> In many ways, using the minimal install of Ubuntu will help to make the
> charms more robust to changes in the default seeds of the cloud images
> because people will need to document *everything* they need, since they
> can really only count on having juju and the minimal Ubuntu install.

This is true, but assuming a sane set of packages is reasonable and
desirable. Such a simplification is made all over ubuntu.
Having an absolute minimal install is just going to result in fighting
random issues that are fixed if you take the more common path.

my personal feeling is that the 'lxc create -t ubuntu' is unreasonably
small, which will only cause long term loss of developer time chasing "it
doesn't work on lxc" bugs.

One should at least be able to assume anything in server^ task set.
Can a charm even expect 'essential' packages?

[Patrick Hetu (patrick-hetu)]

I really think this would be a great feature. Using Ubuntu's qcow2 images mounted via nbd devices would make instances creation
extremely fast and will use a lot less disk space.

[Kapil Thangavelu (hazmat)]

is there a way for us to install the server task set into the container? we're primarily cloning a template container when creating units, so the amortized cost is fairly small albeit at the cost of more time waiting for the first unit (while the template container is created).

[Kapil Thangavelu (hazmat)]

This appears to do the trick..

sudo apt-get install tasksel && tasksel --task-packages cloud-image | xargs sudo apt-get install

[Kapil Thangavelu (hazmat)]

from smoser on juju ml ->

  For what its worth, there is now:
     lxc-create -t ubuntu-cloud
  which should do most of your work for you.

  You can pass '--userdata' to get your juju cloud-init user data run.

  This will only work for precise and oneiric systems, but I think thats
  probably enough for you.

[Kapil Thangavelu (hazmat)]

switching out to the cloud template appears like it will be too disruptive at this point, although a useful change. It would drop our custom shell scripts and libvirt usage as the it would standardize on cloud-init and builtin lxc capabilities, but it would also entail breakage for existing local environments and require some additional testing time.. fwiw.. there's a wip lp:~hazmat/juju/local-cloud-img but i think its post precise atm.

[Clint Byrum (clint-fewbar)]

Agreed Kapil.. seems like this will require some refactoring to make work right, and would be a good thing to target at the "galapagos" series, so I've moved it to that.