Lxd: Allow all lxd init questions to be pre-seeded

[ajd394]

while the interactive version of lxd init allows you to create a lxd bridge, the non-interactive, using --auto, does not accept the arguments to perform the creation of the lxd bridge.

[davidfavor]

Was looking for the ticket where Stephan answered this for me. Can't find the ticket.

My notes show...

lxd init --auto --storage-backend dir 
lxc network create lxdbr0
lxc network attach-profile lxdbr0 default eth0

[stgraber]

Right, you can indeed do it through "lxc network".

In general, I'd like to rework "lxd init" to allow for a .yaml preseed file to be passed as constantly adding new command line options makes parsing it and testing it much harder than it should.

I expect we'll keep the current ones as they are for backward compatibility but will add a way to pass a .yaml with everything else in the near future.

[ajd394]

@stgraber Sounds great!

[stgraber]

So just dumping some notes in here since we've been pointing to this quite a bit lately.
The expectation as far as pre-seeding so far is:

• Have "lxd init" read a yaml document from stdin when --auto is passed.
• Keep the other command line arguments around but print a deprecation warning to stderr, pointing to the yaml pre-seeding format as preferred.
• Document LXD daemon configuration preseeding in doc/
• Allow pre-seeding of:
  
  
  
  • Daemon configuration
  
  
  • Storage pools
  
  
  • Networks
  
  
  • Profiles
  
  
  • Initial image set
  
  
• Re-work the interactive mode to match those new options, possibly moving some of the more advanced options behind a --advanced flag.

[brauner]

@stgraber, I've assigned @freeekanayaka to this for now so that he can take a stab at it. What we need to discuss is the format of the yaml file. My idea was basically to support the various post api struct in shared/api/* that are supported by lxd init already. So for storage and networks the section of the yaml file could look like:

pool:
- config:
    size: 57GB
    source: /var/lib/lxd/disks/default.img
    zfs.pool_name: default
  name: default
  driver: zfs
  used_by: []
- config:
    lvm.thinpool_name: LXDThinpool
    lvm.vg_name: lvmpool
    size: 57GB
    source: /var/lib/lxd/disks/lvmpool.img
  name: lvmpool
  driver: lvm
- config:
    size: 57GB
    source: /var/lib/lxd/disks/pool1.img
  name: pool1
  driver: btrfs
network:
- config:
    ipv4.address: 10.48.159.1/24
    ipv4.nat: "true"
    ipv6.address: fd42:f3fc:def8:af88::1/64
    ipv6.nat: "true"
  name: lxdbr0
  type: bridge
- config:
    ipv4.address: 10.44.93.1/24
    ipv4.nat: "true"
    ipv6.address: fd42:347f:b637:1ddc::1/64
    ipv6.nat: "true"
  name: lxdbr1

[brauner]

And I wouldn't necessarily deprecate the old lxd init --auto options since some users might just want a quick and dirty way of setting up lxd. We certainly don't need to add more options to it and leave any advanced configuration via the yaml file. It will likely be most useful in automatic deployment environments anyway.

[stgraber]

Right, we can't deprecate the existing arguments just yet, we'll add the yaml preseeding as a new option. Won't be adding new stuff to the command line arguments and we can drop them when we release LXD 3.0.

As for the layout you proposed, that seems fine to me, though I'd argue for plural form for the top levels ("networks" instead of "network").

I suspect we'll also want to add some helpers later, for example letting you easily specific a default network and storage pool without having to list a "default" profile in there, which would then conflict with your existing default profile.

We also probably should check whether any of the listed stuff already exists and bail before applying any of those changes. We can then provide some way to explicitly request an update of the existing config (when possible).

[freeekanayaka]

@stgraber just to be clear, do you mean that if ANY of the value passed via the stdin yaml text is already present in the database (or whatever persistence storage is used to a particular setting), then "lxd init" should return 1?

I was thinking to start with all daemon-level config values already supported by the --auto cmd line and proceed gradually to more advanced things like pools and networks. So the initial yaml snippet I would implement support for could look like:

daemon:
- config:
    core.https_address: 127.0.0.1:9999
    core.trust_password: sekret

# pools:
# - config:
#     <THIS WILL COME LATER>

The name of the keys match the ones returned by the /1.0 root API GET. This would be equivalent to:

lxd init --auto --network-address 127.0.0.1 --network-port 9999 --trust-password sekret

Does it sound reasonable?

[freeekanayaka]

Stéphane Graber [e-mail] writes:

Right, we can't deprecate the existing arguments just yet, we'll add
the yaml preseeding as a new option. Won't be adding new stuff to the
command line arguments and we can drop them when we release LXD 3.0.

Just to be clear, would you add a brand new command line flag
(e.g. --preseed) that triggers the new behavior (reading yaml from
stdin), and that is incompatible with --auto and interactive?
>

As for the layout you proposed, that seems fine to me, though I'd
argue for plural form for the top levels ("networks" instead of
"network").

I suspect we'll also want to add some helpers later, for example
letting you easily specific a default network and storage pool without
having to list a "default" profile in there, which would then conflict
with your existing default profile.

These helpers seem pretty important, otherwise I guess you'd be left
with e.g. no root device in your default profile (e.g. when you run "lxd
init" for the very first time).

In absence of such explicit helpers, and of an explicit default profile,
do we want to force some "reasonable" defaults? e.g. the first storage
device listed gets to be the root device of the default profile.

Also, if no storage or network is specified in the yaml, should we still
create one (probably based on the same defaults as the interactive mode)?

We also probably should check whether any of the listed stuff already
exists and bail before applying any of those changes. We can then
provide some way to explicitly request an update of the existing
config (when possible).

I guess we don't want this to be too much fine-grained/complicated?
E.g. we should just check if the name of an entity already exists and
bail if it does, regardless of the YAML content (e.g. it could be that
the YAML content is "compatible" with the existing entity, and it just
adds new stuff, but we'd still bail out).

[freeekanayaka]

@stgraber I've discussed with Christian the questions above, and we decided that it's reasonable for preseed to allow modification of existing entities as long as the underlying API code is happy with that (for instance the API will refuse to change a root disk device in a profile that is currently used by some containers).

The relevant IRC conversation is here http://paste.ubuntu.com/24510168/

In this sense the behavior of --preseed would be a bit more liberal than interactive mode or --auto, since the latter two need to implement some more opinionated logic because the have a more narrow context.

[MarkusTeufelberger]

Just linking https://github.com/lxc/lxc/issues/1267 here, since I found both issues via Google after trying to debug why lxdbr0 wasn't created.

[stgraber]

Not sure why this one is still open, the feature was merged.

[ksaikiranr]

Hello,
When i do lxc network it throws error called network cmd unknown. Can anyone point me to right direction?

[stgraber]

Sounds like you're using lxd 2.0 then, that command exists since 2.1

[ksaikiranr]

@stgraber actually I installed using apt-get but snap install fixed it. Thanks.