preserve subnet-create behavior in presence of subnet pools

[Armando Migliaccio]

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>

[Armando Migliaccio (armando-migliaccio)]

https://review.openstack.org/#/c/279378/

[OpenStack Infra (hudson-openstack)]

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 <email address hidden>
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

[OpenStack Infra (hudson-openstack)]

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

commit 26e268db7923c4deb4c0de32066874b44d441042
Author: Carl Baldwin <email address hidden>
Date: Thu Feb 18 19:27:30 2016 +0000

    Add use_default_subnetpool to subnet create requests

    This follows up [1] by adding an extension to allow requesting the
    default subnet pool explicitly through the API thus restoring the
    convenience that was lost by removing the automatic default subnetpool
    fallback behavior.

    ApiImpact

    [1] https://review.openstack.org/#/c/279378/

    Change-Id: Ifff57c0485e4727f352b2cc2bd1bdaabd0f1606b
    Related-Bug: #1545199
    Closes-Bug: #1547705