yahoo-eng-team team mailing list archive

[Brian Haley <1475792@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

As part of the "get me a network" work outlined in
https://review.openstack.org/#/c/196803/ we need to be able to auto-
allocate Neutron networks for tenants.  This is an RFE for those
changes.

The current Neutron v2 api calls that Nova makes to neutron live in
nova/network/neutronv2/api.py - specifically in
_get_available_networks().  In the 'nova boot' case where no network has
been specified, it makes two calls to neutron:

            # (1) Retrieve non-public network list owned by the tenant.
            search_opts = {'tenant_id': project_id, 'shared': False}
            nets = neutron.list_networks(**search_opts).get('networks', [])
            # (2) Retrieve public network list.
            search_opts = {'shared': True}
            nets += neutron.list_networks(**search_opts).get('networks', []) 

The first will get any existing networks with this tenant_id, the second
any shared networks the admin as pre-configured.  If nothing exists the
boot will error out and fail.

I'm proposing a new API, tentatively called "retrieve_networks", that
while similar to "list_networks", can also be given additional
information such as a flag parameter, that can signal neutron to auto-
allocate a network and return it to the caller.  This will be created as
an extension, such that a caller could determine if it is supported
before calling it (or falling-back to the old method).

The arguments to it can either be similar to "list_networks", or
something like { ids: [], tenant_id: None, flags: [] }, where flags can
be one or more values such as:

SHARED - return any shared networks
ALLOCATE - if no network exists, auto-allocate one based on config settings

This new API call would only need to be used from the call to
_get_available_networks() in allocate_for_instance(), and not from the
others.

This could either be a single-step process, where a single POST is done,
or a two-step process, such that a GET is used first.  We need to ask
the API working group what the current recommendation would be.  An
alternative approach would be to put this logic in a library that Nova
can call, rather than baking it into Nova.

The neutron configuration will be done in a new database table, such
that updating config files and restarting services are not required.
Initially, this will be just a few variables:

 - network name to use (private_network)
 - subnet name to use (private_subnet)
 - subnet cidr to use (10.0.0.0/24)
 - router name to use (private_router)
 - external network to attach router to (must be a UUID ?)

This information - names and CIDR range for the initial subnet, can be
the same for every tenant since they are private networks and over-
lapping IPs are allowed in this case.  The recommendation would be to
use an address range in the RFC 1918 space unless otherwise specified.

A future enhancement could be to use subnet_pools for this.

In order to eliminate duplicate default networks being created, the
database layer MUST use some sort of distributed locking (based on
tenant_id) such that simultaneous calls to different neutron API servers
for this new resource do not both succeed.  The preferred outcome is for
the second (and subsequent) calls to block, and return the network
allocated by the first.

So it's in one place, the details that still need some ironing are:

1) Get recommendation from API working group
2) DB schema
3) DB locking
4) Buy-in from Nova, as this affects the nova-neutron API
5) Type of beer desired for first landed patch :)  It's Friday here people!

Please feel free to comment!

** Affects: neutron
     Importance: Undecided
     Assignee: Brian Haley (brian-haley)
         Status: New


** Tags: get-me-a-network rfe

** Changed in: neutron
     Assignee: (unassigned) => Brian Haley (brian-haley)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1475792

Title:
  Change Neutron so that it can auto-allocate networks

Status in neutron:
  New

Bug description:
  As part of the "get me a network" work outlined in
  https://review.openstack.org/#/c/196803/ we need to be able to auto-
  allocate Neutron networks for tenants.  This is an RFE for those
  changes.

  The current Neutron v2 api calls that Nova makes to neutron live in
  nova/network/neutronv2/api.py - specifically in
  _get_available_networks().  In the 'nova boot' case where no network
  has been specified, it makes two calls to neutron:

              # (1) Retrieve non-public network list owned by the tenant.
              search_opts = {'tenant_id': project_id, 'shared': False}
              nets = neutron.list_networks(**search_opts).get('networks', [])
              # (2) Retrieve public network list.
              search_opts = {'shared': True}
              nets += neutron.list_networks(**search_opts).get('networks', []) 

  The first will get any existing networks with this tenant_id, the
  second any shared networks the admin as pre-configured.  If nothing
  exists the boot will error out and fail.

  I'm proposing a new API, tentatively called "retrieve_networks", that
  while similar to "list_networks", can also be given additional
  information such as a flag parameter, that can signal neutron to auto-
  allocate a network and return it to the caller.  This will be created
  as an extension, such that a caller could determine if it is supported
  before calling it (or falling-back to the old method).

  The arguments to it can either be similar to "list_networks", or
  something like { ids: [], tenant_id: None, flags: [] }, where flags
  can be one or more values such as:

  SHARED - return any shared networks
  ALLOCATE - if no network exists, auto-allocate one based on config settings

  This new API call would only need to be used from the call to
  _get_available_networks() in allocate_for_instance(), and not from the
  others.

  This could either be a single-step process, where a single POST is
  done, or a two-step process, such that a GET is used first.  We need
  to ask the API working group what the current recommendation would be.
  An alternative approach would be to put this logic in a library that
  Nova can call, rather than baking it into Nova.

  The neutron configuration will be done in a new database table, such
  that updating config files and restarting services are not required.
  Initially, this will be just a few variables:

   - network name to use (private_network)
   - subnet name to use (private_subnet)
   - subnet cidr to use (10.0.0.0/24)
   - router name to use (private_router)
   - external network to attach router to (must be a UUID ?)

  This information - names and CIDR range for the initial subnet, can be
  the same for every tenant since they are private networks and over-
  lapping IPs are allowed in this case.  The recommendation would be to
  use an address range in the RFC 1918 space unless otherwise specified.

  A future enhancement could be to use subnet_pools for this.

  In order to eliminate duplicate default networks being created, the
  database layer MUST use some sort of distributed locking (based on
  tenant_id) such that simultaneous calls to different neutron API
  servers for this new resource do not both succeed.  The preferred
  outcome is for the second (and subsequent) calls to block, and return
  the network allocated by the first.

  So it's in one place, the details that still need some ironing are:

  1) Get recommendation from API working group
  2) DB schema
  3) DB locking
  4) Buy-in from Nova, as this affects the nova-neutron API
  5) Type of beer desired for first landed patch :)  It's Friday here people!

  Please feel free to comment!

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1475792/+subscriptions