Linux-derived devices/daemons

[ipspace]

In #1002 and #1003 we identified two cases where it would be nice to have something that's derived from Linux but has additional functionality. The question is: how do we make that happen without having an explosion of devices?

Before going into the details:

• How are we going to call these thingies (aka "terminology is important"). Daemons? Any other ideas?
• Are we OK with having this stuff available only as containers (similar to tools)? The only drawback of this approach would be lack of Virtualbox integration, but then I wonder whether anyone is using that anyway.

Now for the technical stuff. Here are the requirements as I understand them today (subject to change ;)

Images

• These things (whatever they are) have to run a different container image than the linux device.
• They could run the same Ubuntu VM image we use for Linux (in case we can't get a good-enough image from whoever builds the software) and have extra software installed every time the VM is started.
• The user could build their own Vagrant box to bypass the "install the software" step.
• Initial device configuration would have to be extended to cope with "I need more software", but that could be built into the Linux initialization script.

Modules

This is the first hard problem. These thingies have to support additional modules (BGP, OSPF, DHCP...) or we wouldn't be able to use them. We need to build some inheritance mechanism into various netlab functions to cope with that. Ideally, we'd just add an abstraction layer in augment.devices and then make sure everyone else is using that.

Configurations

Daemons are usually configured with configuration files. Absolutely not a problem in containers, but we have no mechanism to push configuration files to Linux VMs at the moment, apart from building configurations in Ansible playbooks. That might work out-of-the-box (assuming we use correct variables to locate the desired task list) and have the added benefit of having a nice hook to restart the daemons once the config files have been updated. Alternatively, we could start with containers-only setup (see above).

Initial configuration playbooks

We don't need to "do stuff on the device" for container daemons configured with configuration files, which means that we have to have the ability to skip configuration steps. Maybe it's good enough to remove modules from the daemon containers at the very end of the configuration process.

cc: @jbemmel @ssasso @petercrocker @steffann

[ipspace]

Initial implementation in #1014