yahoo-eng-team team mailing list archive

[Thierry Carrez <thierry.carrez+lp@xxxxxxxxx>]

** Changed in: neutron
       Status: Fix Committed => 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/1168159

Title:
  Textual definition of "subnet" is not correct

Status in OpenStack Neutron (virtual network service):
  Fix Released

Bug description:
  The introduction section of the Quantum API states: "The v2.0 API does
  this by introducing a new entity, called a Subnet. Subnets can
  represent either a IPv4 or IPv6 address block, ..."

  This text should be corrected in the following way:
  The introduction section of the Quantum API states: "The v2.0 API does this by introducing a new entity, called a Subnet. Subnets can represent the binding of either a IPv4 or IPv6 address block to a previously created Quantum Network, ..."

  Proof Point: The High-Level flow is flawed, as it states that a subnet
  gets associated with a network, however, there is no API "associate
  Subnet", only an API "create Subnet, which associates (binds) a CIDR
  to a network. Therefore, the nature of the object "subnet" is not
  correctly reflected in the definitions. While this may sound like a
  minor negligence in the introductory text, this could lead to high
  cost as this object is so central in the data model. Some implementers
  may be mislead to believe, that a subnet can indeed exists without
  binding to a previsouly created network, i.e. that an address range
  already constitutes a subnet.

  Here is the current text describing  the high level flow

  •	Tenant creates a network (e.g., "net1")
  •	Tenant associates a subnet with that network (e.g., "10.0.0.0/24")

  Here is a proposal to correct this text and bring it inline with the
  API "create subnet":

  •	Tenant creates a network (e.g., "net1")
  •	Tenant creates a subnet (e.g., "10.0.0.0/24"), which implicitly associates the address space with that network.  This association creates a binding of the adress space to the previously created network. While it is common to say, that a subnet is represented by an IPv4 or IPv6 address range, the adress range alone is not a subnet. Rather it is the binding of the address space to the network, which creates the subnet.

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