Please note: This schedule is for OpenStack Active Technical Contributors participating in the Icehouse Design Summit sessions in Hong Kong. These are working sessions to determine the roadmap of the Icehouse release and make decisions across the project. To see the full OpenStack Summit schedule, including presentations, panels and workshops, go to http://openstacksummitnovember2013.sched.org.
Back To Schedule
Tuesday, November 5 • 5:30pm - 6:10pm
API Extensions for Drivers

Sign up or log in to save this to your schedule, view media, leave feedback and see who's attending!

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)

Tuesday November 5, 2013 5:30pm - 6:10pm HKT
AWE Level 2, Room 201C

Attendees (0)