[lxc-devel] lxd: Initial design specifications

[Dwight Engen]

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 :)

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?

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)?

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?

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

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?

> 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.
>