yahoo-eng-team team mailing list archive

[OpenStack Infra <1545199@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/279378
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=d38aeade9db7169955b4524a5fc8d814067dec15
Submitter: Jenkins
Branch:    master

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


** Changed in: neutron
       Status: In Progress => Fix Released

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

Title:
  preserve subnet-create behavior in presence of subnet pools

Status in neutron:
  Fix Released

Bug description:
  The subnet create command [1] creates a subnet that does not belong to
  a subnet pool. When a default subnet pool is present, however, the
  subnet is implicitly assigned to the default pool, and hence the
  command triggers prefix validation.

  [1] neutron subnet-create <net> <cidr> <name>

  It's probably better to preserve the semantic of the message
  irrespective of the presence of the (default) pool.

  If a user does want the association, he/she can either be explicit (by
  passing --subnetpool/-id) or simply specify the family of the subnet,
  like in [2] (by default the client chooses v4).

  This happens in master.

  [2] neutron subnet-create <net> --ip-version <name>

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