Public bug reported: 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 ** Affects: neutron Importance: Undecided Status: New ** Tags: fullstack rfe ** Summary changed: - Fullstack infrastructure as a dev deployment tool + Fullstack infrastructure as a developer multi-node deployment tool -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1499864 Title: Fullstack infrastructure as a developer multi-node deployment tool Status in neutron: New Bug description: 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 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1499864/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
