yahoo-eng-team team mailing list archive

[Armando Migliaccio <1547271@xxxxxxxxxxxxxxxxxx>]

We'll have to provide user facing documentation on how to use
subnetpools and how they blend in with subnets.

** Changed in: neutron
       Status: New => Confirmed

** Changed in: neutron
   Importance: Undecided => Low

** Also affects: openstack-api-site
   Importance: Undecided
       Status: New

** Also affects: openstack-manuals
   Importance: Undecided
       Status: New

** Changed in: neutron
       Status: Confirmed => Invalid

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

Title:
      Preserve subnet_create behavior in presence of subnet pools

Status in neutron:
  Invalid
Status in openstack-api-site:
  Confirmed
Status in openstack-manuals:
  Confirmed

Bug description:
  https://review.openstack.org/279378
  Dear bug triager. This bug was created since a commit was marked with DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to.

  commit d38aeade9db7169955b4524a5fc8d814067dec15
  Author: Armando Migliaccio <armamig@xxxxxxxxx>
  Date:   Thu Feb 11 20:56:20 2016 -0800

      Preserve subnet_create behavior in presence of subnet pools
      
      The development of the auto_allocate extension, which relies on subnet
      pools, revealed some discrepancies in the behavior of the subnet_create
      API: if a user specifies a cidr on subnet_create like he/she is used
      to, the API outcome changes in presence of default subnetpools. For
      instance the command 'neutron subnet-create network <cidr>' returns a
      subnet associated to a pool, if a default pool exists, but it does not
      otherwise. At the same time, attempting to create a subnet without
      passing any detail but the ip version also behaves unexpectedly
      depending on the state of the system.
      
      Whilst this could be considered convenient in some circumstances,
      it is problematic for a couple of reasons: a) it breaks a well defined
      contract (backward compat of the subnet-create command), and b) it
      leads to ambiguity of the API.
      
      This patch restores the semantic of the subnet_create API where it is
      mandatory to specify CIDR/IP version regardless of the conditions
      under which the request is issued. On the other hand, associating
      subnets to subnet pools will have to be more prescriptive, and
      require the user to explicitly state his/her intentions when creating
      the subnet: if a user does want a subnet (CIDR) to belong to a subnet
      pool, he/she will have to state so, either by specifying a subnetpool
      name/uuid, or by asking for a default one.
      
      This will be tackled as a follow-up, especially in order to address the
      needs of prefix delegation which currently rely on the ambiguous
      behavior that this patch is fixing.
      
      Closes-bug: 1545199
      
      DocImpact: subnetpools can be used to simplify IPAM, and can be specified
      during subnet creation.
      
      Change-Id: Idf516ed9db24d779742cdff0584b48182a8502d6

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