canonical-ci-engineering team mailing list archive

[Evan Dandrea <evan.dandrea@xxxxxxxxxxxxx>]

On 14 October 2013 06:23, Vincent Ladeuil <vila+ci@xxxxxxxxxxxxx> wrote:
> The primary benefits would be that:
>
> - we separate the move from the IP redeployment,
>
> - we prepare the move to prodstack by taking a snapshot of our existing
>   infrastructure (I'm talking about using juju yet ! But knowing that
>   everything runs inside lxcs is already a significant step in the right
>   direction).
>
> That gives us:
>
> - more time to switch to name-only services (we can start before and
>   finish after the move instead on requiring a big switch at move time),
>
> - we can swap an lxc from one physical host to another if one is broken
>   or lost or doesn't came up after the move,
>
> - we ensure we've collected all configurations before the move (a kind
>   of snapshot) and have even (optimistic target) tested them.

Thanks for raising this, Vincent. I think it's brought up some
important things we need to be aware of as we migrate to 1SS, namely
how are we going to ensure that we're tracking changes to the
configuration, packaging, and kernel.

I raised the LXC idea with James Troup in IS and he warned strongly
against it from his own experience. They did something similar a while
back and he showed me the pile of firewall rules they've had to carry
around because they still haven't quite unwrapped the container
environment. Once you build something like this, you're largely stuck
with it.

He also pointed out that we'll have issues access devices from within LXC.

I think the recent plan to use an IS-provided DNS service rooted at
.ubuntu-ci solves the networking concerns we had:
https://rt.admin.canonical.com/Ticket/Display.html?id=65278

What it doesn't help us with is co-locating services or easily
migrating them to a new machine if the hardware fails. I think
charming services is a better investment of time to address this
problem, though I wholly admit we will not get there prior to the 1SS
move. The reasons for my preference of charming are twofold:

- Encapsulating services in LXC wouldn't guarantee that they come back
up when deployed on new hardware. There are going to be assumptions
built into the contained environment that are likely to break. In
Juju, we're building with the expectation that services will move.

- Moving to LXC up to Juju isn't any easier a path than starting with
Juju. As James put it, "it's clever and well-intentioned, but it's
ultimately moving in a direction that's veering off of cloud."

Now, if we built Juju charms and deployed them using the LXC provider,
that's another matter (and how the new Juju "null" provider [1]
works).

Happy to continue to have a discussion around this, if you feel
strongly that LXC remains the right approach.

Thanks!

1: "[Canonical-tech] Manual provisioning in Juju now available, testers wanted"