Fullstack infrastructure as a developer multi-node deployment tool

[Assaf Muller]

The fullstack testing infrastructure today is used purely in a testing context. This RFE suggests that it could be useful to have fullstack support another use case, which is a quick deployment tool for developers that want to manually test something they're working on, or if they want to learn about Neutron or a specific feature.

Neutron would expose a script that would accept a deployment topology document that will describe what is currently here:
https://github.com/openstack/neutron/blob/master/neutron/tests/fullstack/test_l3_agent.py#L61

For example, a .yaml file with:
How many OVS, L3, DHCP agents
Global configuration such as the segmentation type, l2pop={True,False}, OVS arp responder etc.

The script would then deploy the requested topology and spit out a credentials file to interact with the API server, information about the agents it deployed (Their host names, state paths, path to configuration files etc), and perhaps also a plotnetcfg [1] output of the resulting deployment (An image that shows how the OVS bridges are connected, namespaces, what devices are connected to what bridges).

After deployment is finished, the script would also allow the creation of fake VMs (Identical to the fake VMs we already create during fullstack testing). Reminder: These VMs are backed by a Neutron port, a namespace, and a device with the appropriate IP address connected to the correct bridge. They can sufficiently simulate VMs, and resources on external networks (To enable testing floating IPs and SNAT).

So, for example:
neutron-fullstack deploy dvr_ha_dhcp.yaml # Spits out information about the topology

source <credentials_file_output_from_deploy command>
neutron net-create 1
neutron net-create 2
neutron-fullstack create_vm --net_id=1, --binding:host_id=xyz
neutron-fullstack create_vm --net_id=2, --binding:host_id=abc
neutron router-create, attach it to both networks
Test ping from VM 1 to VM 2

neutron-fullstack destroy # Possibly accepting a topology ID if we were to support deploying more than a single topology at any given time, I need to think about this further

[1] https://github.com/jbenc/plotnetcfg

[Assaf Muller (amuller)]

NOTE: I don't currently intend to work on this myself. If anyone wants to pick this up (With my assistance and reviews), I'd be really glad.

[Miguel Angel Ajo (mangelajo)]

This looks really useful to simplify how we develop/test. Partly reminds me of mininet (from which I only know the high level).

[Armando Migliaccio (armando-migliaccio)]

I wonder if this is overlapping with something that Fuel or other deployment tools do. I personally like the idea, but I wonder if we should really go full-blown here. I fear we might end up creating a monster?

[Armando Migliaccio (armando-migliaccio)]

To be discussed at the drivers meeting.

[Armando Migliaccio (armando-migliaccio)]

As discussed during the drivers meeting, if someone shows active interest, we can revisit, otherwise out of scope for now.

[Assaf Muller (amuller)]

So, is it out of scope or not? Why would the lack of an assignee determine scope? Changing the status to won't fix also removes this RFE bug from many search results, further killing the chance of an assignee.

[Cedric Brandily (cbrandily)]

I agree with Assaf: i remembered this rfe but lost some times to find it because of its status. The status wishlist(?) would let "the door open".

I am potentially interested in implementing it but i need to evaluate first the cost of such feature and how we will maintain it

[Armando Migliaccio (armando-migliaccio)]

@Assaf: your concern is valid, but the lack of assignee/approver is only partially justifying the bug status. Btw, I didn't realize that 'won't fix' makes the bug invisible.

That said, I am dubious whether this belongs here or into some other initiative like rally, or kolla. I see lots of potential duplication/overlap, and I'd rather have us focus time and energy to the other stuff in our laundry list of testing activities.