Juju with btrfs

[Kapil Thangavelu]

On Mon, May 13, 2013 at 10:41 PM, Scott Moser <smoser at ubuntu.com> wrote:

> On Mon, 13 May 2013, Kapil Thangavelu wrote:
>
> > Lxc-clone isn't used atm, so the integration with btrfs isn't present.
> The
> > clone support in pyjuju is a historical artifact for current versions.
> The
> > original lxc support utilized clone to allow for fast unit creation, at
> the
> > cost of post container modification scripts. A subsequent refactoring
> late
> > last year, unified juju installation for all instances around cloud-init
> > and cloud-images, and the lxc-clone support wasn't kept. Hopefully that
> can
> > be revisited in the juju-core implementation when local provider is
> > reimplemented via re-running cloud-init on the cloned container with new
> > user data (after resetting cloud-init state).
>
> fwiw, I've suggested to Serge that lxc should have a 'clone script', so
> that container specific code could be run on each clone.
>
> This will allow in the future something like this:
>  $ lxc-create -t ubuntu-cloud --name=precise-amd64-source --arch=amd64
>  $ lxc-clone --orig=precise-amd64-source --new=precise-amd64-01 \
>      --userdata=my-user-data
>  $ lxc-start --name=precise-amd64-source
>
> That is equivalent to EC2 doing:
>  $ ec2-upload-image precise-amd64-source
>  $ ec2-run-instances precise-amd64-source --userdata
>
> And, pair that function with btrfs clone integration, or optionally
> overlayfs clone, and you have instant "start" with customized user-data.
>
> That may or may not be usable from juju, but it makes for really nice lxc
> usage.
>

That sounds pretty idea for juju usage as well.

thanks,
Kapil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130514/582374f1/attachment.html>