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 <arma...@gmail.com> 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 -- 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