[RFE] Allow automatic sub-port configuration on the per-trunk basis in the trunk API

[Baodong (Robert) Li]

The nova blueprint https://review.openstack.org/#/c/471815/7/specs/queens/approved/expose-vlan-trunking.rst adds support of automatic sub interfaces configuration in the guest instance by exposing trunk details in the config drive. However, some deployment requires such auto configuration be disabled. This RFE will allow a user to specify the intent to enable/disable sub interface auto configuration in the trunk create API. It also allows the deployer to specify the default setting of enabling/disabling sub interface auto configuration, which can be overwritten by that specified in the trunk API.

[Armando Migliaccio (armando-migliaccio)]

Can you elaborate what do you mean by 'auto configuration', and why a deployer may want to disable that on a per-subport basis?

[Armando Migliaccio (armando-migliaccio)]

Another thing that is not clear is whether you mean to provide this capability on a per-trunk or per-subport basis. Perhaps a few steps that describe the use case you have can help us understand what exactly you have in mind.

[Baodong (Robert) Li (baoli)]

By auto configuration, I mean that after the guest instance is up, sub interfaces are automatically configured and brought up in the guest by means of, for example, cloud-init or glean. Sub interfaces information is built into the network_data.json file that is part of the config-drive.

Refer to https://review.openstack.org/#/c/471815/3/specs/pike/approved/expose-vlan-trunking.rst about the comments that Sean Mooney made about making a per-trunk option to enable/disable this feature. Basically, for some NFV instances, this feature must be turned off.

Supposedly we call the option as auto-sub-intf. A trunk can be created with the option being True or False. If the option is not present, then its default value is taken from a neutron config option default-auto-sub-intf.

A basic work flow would look like this:
   -- create a neutron port.
   -- create a trunk with the above neutron port as parent port.
   -- if the trunk's auto-sub-intf value is False, then the existing behavior as it is today remains.
   -- if the trunk's auto-sub-intf value is True, then the trunk details will be used to populate the network_data.json file with the trunk's sub interface information.
   -- suppose the guest instance has cloud-init with config-drive datasource turned on. Cloud-init will load the network_data.json file, configure the sub interfaces, and bring them up.

[Armando Migliaccio (armando-migliaccio)]

What if some VNFs connecting to the same trunk (not at the same time obviously) do want the auto-configuration and some do not? You'll have to go and toggle this flag on the trunk. This smells like we're polluting the trunk API with details, such as guest config management, that do not really belong there. To me this sound like something a user would specify on a per-boot basis.

[Armando Migliaccio (armando-migliaccio)]

Let's see what the overall opinion on this proposal is.

[Baodong (Robert) Li (baoli)]

That's a really good question.
So far, the requirement of configuring/not configuring interfaces in the guest seems to be specific to trunk interfaces. If your specific scenario were a common use case, then the decision of configuring/not configuring sub interfaces would need to be made at boot time as you indicated. However, introducing an option at boot time seems to be overkill.

One option is to use the Virtual guest device role tagging https://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/virt-device-role-tagging.html. The nic corresponding to the trunk may be specified at boot as --nic port-id=12345,tag=auto-subif. However, this either means the specific tag has a meaning in nova (to determine whether or not subinterfaces should be generated in network_data.json. But According to the tagging spec, tags should be opaque to nova.). Or otherwise, cloud-init/glean needs to be enhanced to support the tag so that when the tag is present, sub interfaces will be configured in the guest.

Another way of thinking about it is that a trunk may be created with a specific VNF guest in mind that either support or doesn't support auto configuration. A trunk is created accordingly, then used to boot the instance. When the instance is done, the trunk may be destroyed. In other words, a trunk (a logical entity) doesn't have to be long-lived.

[Armando Migliaccio (armando-migliaccio)]

To me this fundamentally boils down to where we believe the property of configuring a guest really belongs to. I can't seem to justify why this belongs to Neutron and to a trunk. The property for a VNF to be auto-configured has nothing to do with the logical wiring that a trunk represents.

[YAMAMOTO Takashi (yamamoto)]

my impression is that this doesn't belong to neutron. probably nova.

otoh i can understand implementation-wise it's convenient to put this into neutron.
maybe we can use some generic mechanisms like tags as a hint for nova?

[Miguel Lavalle (minsel)]

This RFE was reviewed in the latest drivers meeting. Team consensus was that this functionality doesn't belong in Neutron: http://eavesdrop.openstack.org/meetings/neutron_drivers/2017/neutron_drivers.2017-10-27-14.00.log.html#l-94