[lxc-devel] lxd: Initial design specifications

Thu Nov 6 21:51:42 UTC 2014

On Thu, Nov 06, 2014 at 04:03:18PM -0500, Dwight Engen wrote:
> On Wed, 5 Nov 2014 20:13:53 -0500
> Stéphane Graber <stgraber at ubuntu.com> wrote:
> 
> > Hey,
> > 
> > So as of earlier today, we have a working repository for lxd at
> > github.com/lxc/lxd with the usual paperwork (license, contribution
> > guidelines, ...) and Serge just reviewed and merged the first design
> > specification.
> > 
> > Those are published in the specs/ folder in that branch:
> > https://github.com/lxc/lxd/blob/master/specs
> > 
> > The one I sent earlier is the command line user experience which
> > documents all the commands we want to support and how the whole thing
> > will end up feeling to the user.
> > 
> > I'm now working on a smaller one about some of the details of the
> > image system which very much ressembles what we've been doing with the
> > download template until now but pushing it a bit further here and
> > there. I expect this one to be potentially more controversial and
> > raise more questions.
> > 
> > 
> > Those specifications are mostly there to ensure we do things in a
> > consistent manner and will likely be re-used as documentation at a
> > later point. They are not set in stone and changes are welcome.
> > 
> > If something looks wrong, missing or incomplete in those, feel free to
> > bring it up for discussion on the list or just send a pull request to
> > change it.
>  
> Hi, first off, this looks great! I read through the specs and had a
> couple of questions/comments:
> 
> "added by the plugins. Remote operations"... followed by nothing :)

Remote operations was meant to be a title but I forgot the # in front of
it to mark it as such... Fixed in master now.

> Should there be a way to provision a container without actually
> starting it? (ie. an analogue to what lxc-create does today)? Maybe an
> argument to start? I can see that it might be useful to remotely
> provision a set of containers before starting them up. Upon reading
> further, it looks like "copy" is to be used for this purpose, but it
> doesn't seem to support --profile, maybe it should?

So the problem I see with adding --profile to copy is that it won't be
clear whether intend to replace an existing profile defintion. It also
means that any option we add to start which affects the permanent
container configuration, we have to add to copy too.

Re-reading the examples, except for that specific one, there's nothing
that copy can do which start doesn't do too.

So I see two options there and I'm not completely sure which I prefer to
be honnest:
1) We drop copy and we add a --later option to the start command.
2) We drop copy and we introduce a create command which is identical to
   start except that it doesn't start the container and doesn't accept any
   runtime-specific argument.

My problem with 1) is the obvious conceptual issue that start in that
mode won't actually start anything.

My problem with 2) is the addition of a new command just for what may
well end up being a corner case.

> I assume the behavior of stop being different from lxc-stop is
> intentional (ie. that after the timeout it gives an error instead
> of falling back to hard-kill)?

Yeah, it's intentional. The idea is to do the safe thing there. Some
workloads realistically won't shut down in 30s if they have a lot of
data to flush to disk so setting an arbitrary timeout is difficult.
Instead we offer something closer to what you get with a VM where you
can send a shutdown signal or force kill the whole thing.

> Does "config set" set the key in the config file, or in cgroup of
> <resource> if its currently running? It seems like the former, if so
> will there be a way to do the latter?

I didn't actually think of that but I think the right answer there is
"both".

That is, if you set a cgroup limit, it should apply immediately and be
save in the config.

Any key which requires a reboot to be effective
(lxc.* minus the cgroup ones) should print a message saying as much.

> IMO "config set-profile" would would be more consistent with the
> existing commands if it was named "config profile apply".

+1

Can you send a pull request?

> Given the command: "lxc file push -R c1/test c2/test" how do we
> disambiguate c1 from being a local relative directory name vs a
> container named c1?

I think my plan was simply not to allow cross-container copies, so only
the last argument of push is a URI, all the others are local fs paths.
For pull, it's the reverse, they all are URIs execept for the last one
which is a local fs path.

If you think it'd be useful to support direct container to container
copies, then indeed we'd have to rethink things a bit...

> 
> > As a rule, we'll always make sure that code submissions follow the
> > specification, so radical changes should first update the
> > specification, have that discussed and merged and only then change
> > the code.
> > 
> 
> _______________________________________________
> lxc-devel mailing list
> lxc-devel at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20141106/ae1e4eab/attachment-0001.sig>