Deeper context/username support

[zdykstra]

First, I'd like to thank everybody involved with this project!

I'd like to use this on a hypervisor with multiple users. With use of the --context argument, this is generally possible. However, there are a few gotchas that I'd like to smooth over, if patches for these would be accepted.

• Allow context to be more easily set. If I create two project directories, with two different virt-lightning.yaml configs in them, they both end up in the same default context, unless I explicitly pass --context to all operations. This means that if I'm not careful some day, I'll vl down in the wrong place and nuke the wrong project. I'd like to add support to set context as a top-level key in virt-lightning.yaml, and use that to help limit the scope of operations more easily.

• Possibly update the output of vl status to show the context, since it can now be read from a config file.

• Add a config option to enable operating only on VMs that match our username, via vl:username. This way, even if I'm in the same context as another user, I won't be able to see their VMs. By default this would be disabled, but could be enabled via a config.ini flag.

Any additions would keep the current behavior as the default - you'd have to opt-in to these modifications via config.ini adjustments. Let me know your thoughts on this.

[goneri]

Hi @zdykstra!

First, I'd like to thank everybody involved with this project!

I'd like to use this on a hypervisor with multiple users. With use of the --context argument, this is generally possible. However, there are a few gotchas that I'd like to smooth over, if patches for these would be accepted.

* Allow _context_ to be more easily set. If I create two project directories, with two different virt-lightning.yaml configs in them, they both end up in the same `default` context, unless I explicitly pass --context to all operations. This means that if I'm not careful some day, I'll `vl down` in the wrong place and nuke the wrong project. I'd like to add support to set _context_ as a top-level key in virt-lightning.yaml, and use that to help limit the scope of operations more easily.

This was my plan since the beginning, so yes! The contribution would absolutely be welcome :-)

* Possibly update the output of `vl status` to show the context, since it can now be read from a config file.

Yes, same answer.

* Add a config option to enable operating only on VMs that match our username, via _vl:username_.  This way, even if I'm in the same context as another user, I won't be able to see their VMs. By default this would be disabled, but could be enabled via a config.ini flag.

Yes but I would prefer to use a new key, username is the name of the user of the VM. Something like created_by, or vm_owner.

Another option is to use an libvirt user session ( qemu:///session ) for that. But the network configuration is slightly more complicated. libvirt runs with the user privilege, and so cannot create bridge or change IP configuration. In addition, the feature is a bit miss-configured on Ubuntu, comparing to Fedora. I original started this way actually, see:
36a3b14

Any additions would keep the current behavior as the default - you'd have to opt-in to these modifications via config.ini adjustments. Let me know your thoughts on this.

It sounds totally reasonable to me. You may have to play a bit with the Unix permission to be able to have several users writing their VM at the same location. It may be nice to have dynamic image pool, one per user.

[zdykstra]

I've been playing with this just a bit, and the current structure of the virt-lightning.yaml file prevents me from making a trivial change to support this. The current format of a list of dictionaries means that I can't readily split top-level config options apart from the list of VMs to create.

- name: test-2
  distro: ubuntu-16.04
  memory: 2048
  vcpus: 2
  groups: ['test-ubuntu']
- name: test-3
  distro: centos-7 
  memory: 2048
  vcpus: 2
  groups: ['test-centos']

To keep full backwards compatibility with existing virt-lightning.yaml files, I'll have to do something like this:

- context: project1
- name: test-2
  distro: ubuntu-16.04
  memory: 2048
  vcpus: 2
  groups: ['test-ubuntu']
- name: test-3
  distro: centos-7 
  memory: 2048
  vcpus: 2
  groups: ['test-centos']

Then when the YAML is read in, look for specific configuration key names, extract the value and then remove them from the list.

Otherwise, maybe do something like:

config:
  context: project1
vms:
  - name: test1
  ...
  - name: test2
  ...

That route (for full backwards compatibility) would require being able to detect which YAML format is used and Do The Right Thing (tm) based on what was found.

[zdykstra]

#147 checks off one context use case for me