Icehouse Design Summit

This will be a split session to discuss extensions for drivers.

This session will include the following subject(s):

ML2: How to support driver-specific extensions:

In this topics, how to support driver-specific features will be discussed. Various ML2 mechanism drivers are implemented and proposed, and features provided by them may be different. It is one of good topics how to support such extensions in ML2 plugin/drivers.

It is also important from the point of migrating from monolithic plugin to ML2 driver. In the existing monolithic core plugins, support of extensions are different across plugins and some plugins have plugin-specific extensions. They would like to continue to support their extensions even after migrating ML2 plugin.

If an extension introduces a new resource, service plugin is an option. Is it a direction we have service plugins per extension? Generally speaking it seems not a good idea to me. If an extension add a new attribute to an existing resource, what can we do? Should we allow mechanism drivers to define additional extensions list?

ML2 plugin has several merits (potentially support multiple backend, avoiding code duplication across core plugins, ...), so I believe it is worth discussed.

I am now looking ML2 plugin code and looking for possible ways.

(Session proposed by Akihiro Motoki)

Extensible API: deal with growing services:

Neutron has added 3 new services in addition to LBaaS during Havana cycle: FWaaS, VPNaaS, Metering.
More services to follow (possibly).

All these services are implemented as API extensions at this point, but as amount of features and diversity will grow, it will create a need for 'extensions for extensions'.

We need to decide how/what to make part of Core API and propose a way to extend Core Service API with vendor-specific features

(Session proposed by Eugene Nikanorov)