yahoo-eng-team team mailing list archive

[Assaf Muller <amuller@xxxxxxxxxx>]

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