yahoo-eng-team team mailing list archive

[Armando Migliaccio <1631371@xxxxxxxxxxxxxxxxxx>]

There are a couple of issues right now:

a) If a trunk dynamically changes after a consumer of the Neutron API
access trunk-details, the consumer won't know unless it polls.

b) From within the guest there is no good way of knowing whether a trunk
is dynamically changing after boot. Mind you, it's doable but it's not
clean.

While I think a) may be worth addressing in the form of a os-external
notification (which should not require an RFE), I don't see how Neutron
should be in the business of dealing with b). Shortcutting components
together is usually a manifestation of tight coupling, and no-one wants
that.


** Changed in: neutron
       Status: Incomplete => Won't Fix

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

Title:
  [RFE] Expose trunk details over metadata API

Status in neutron:
  Won't Fix

Bug description:
  Enable bringup of subports via exposing trunk/subport details over
  the metadata API

  With the completion of the trunk port feature in Newton (Neutron
  bp/vlan-aware-vms [1]), trunk and subports are now available. But the
  bringup of the subports' VLAN interfaces inside an instance is not
  automatic. In Newton there's no easy way to pass information about
  the subports to the guest operating system. But using the metadata
  API we can change this.

  Problem Description
  -------------------

  To bring up (and/or tear down) a subport the guest OS

  (a) must know the segmentation-type and segmentation-id of a subport
      as set in 'openstack network trunk create/set --subport'

  (b) must know the MAC address of a subport
      as set in 'openstack port create'

  (c) must know which vNIC the subport belongs to

  (d) may need to know when were subports added or removed
      (if they are added or removed during the lifetime of an instance)

  Since subports do not have a corresponding vNIC, the approach used
  for regular ports (with a vNIC) cannot work.

  This write-up addresses problems (a), (b) and (c), but not (d).

  Proposed Change
  ---------------

  Here we propose a change involving both Nova and Neutron to expose
  the information needed via the metadata API.

  Information covering (a) and (b) is already available (read-only)
  in the 'trunk_details' attribute of the trunk parent port (ie. the
  port which the instance was booted with). [2]

  We propose to use the MAC address of the trunk parent port to cover
  (c). We recognize this may occasionally be problematic, because MAC
  addresses (of ports belonging to different neutron networks) are not
  guaranteed to be unique, therefore collision may happen. But this seems
  to be a small price for avoiding the complexity of other solutions.

  The mechanism would be the following. Let's suppose we have port0
  which is a trunk parent port and instance0 was booted with '--nic
  port-id=port0'. On every update of port0's trunk_details Neutron
  constructs the following JSON structure:

  PORT0-DETAILS = {
      "mac_address": PORT0-MAC-ADDRESS, "trunk_details":
      PORT0-TRUNK-DETAILS
  }

  Then Neutron sets a metadata key-value pair of instance0, equivalent
  to the following nova command:

  nova meta set instance0 trunk_details::PORT0-MAC-ADDRESS=PORT0-DETAILS

  Nova in Newton limits meta values to <= 255 characters, this limit
  must be raised. Assuming the current format of trunk_details roughly
  150 characters/subport are needed. Alternatively meta values could
  have unlimited length - at least for the service tenant used by
  Neutron. (Though tenant-specific API validators may not be a good
  idea.) The 'values' column of the the 'instance_metadata' table should
  be altered from VARCHAR(255) to TEXT() in a Nova DB migration.
  (A slightly related bug report: [3])

  A program could read
  http://169.254.169.254/openstack/2016-06-30/meta_data.json and
  bring up the subport VLAN interfaces accordingly. This program is
  not covered here, however it is worth pointing out that it could be
  called by cloud-init.

  Alternatives
  ------------

  (1) The MAC address of a parent port can be reused for all its child
  ports (when creating the child ports). Then VLAN subinterfaces
  of a network interface will have the correct MAC address by
  default. Segmentation type and ID can be shared in other ways, for
  example as a VLAN plan embedded into a golden image. This approach
  could even partially solve problem (d), however it cannot solve problem
  (a) in the dynamic case. Use of this approach is currently blocked
  by an openvswitch firewall driver bug. [4][5]

  (2) Generate and inject a subport bringup script into the instance
  as user data. Cannot handle subports added or removed after VM boot.

  (3) An alternative solution to problem (c) could rely on the
  preservation of ordering between NICs passed to nova boot and NICs
  inside an instance. However this would turn the update of trunk_details
  into an instance-level operation instead of the port-level operation
  proposed here. Plus it would fail if this ordering is ever lost.

  References
  ----------

  [1] https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
  [2] https://review.openstack.org/#q,Id23ce8fc16c6ea6a405cb8febf8470a5bf3bcb43,n,z
  [3] https://bugs.launchpad.net/nova/+bug/1117923
  [4] https://bugs.launchpad.net/neutron/+bug/1626010
  [5] https://bugs.launchpad.net/neutron/+bug/1593760

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