[openstack-dev] [Magnum] COE drivers spec

Jamie Hannaford jamie.hannaford at rackspace.com
Thu Mar 17 11:22:53 UTC 2016


Hi all,


I'm writing the spec for the COE drivers, and I wanted some feedback about what it should include. I'm trying to reconstruct some of the discussion that was had at the mid-cycle meet-up, but since I wasn't there I need to rely on people who were :)


>From my perspective, the spec should recommend the following:


1. Change the BayModel `coe` attribute to `bay_driver`, the value of which will correspond to the name of the directory where the COE code will reside, i.e. drivers/{driver_name}


2. Introduce a base Driver class that each COE driver extends. This would reside in the drivers dir too. This base driver will specify the interface for interacting with a Bay. The following operations would need to be defined by each COE driver: Get, Create, List, List detailed, Update, Delete. Each COE driver would implement each operation differently depending on their needs, but would satisfy the base interface. The base class would also contain common logic to avoid code duplication. Any operations that fall outside this interface would not exist in the COE driver class, but rather an extension situated elsewhere. The JSON payloads for requests would differ from COE to COE.


Cinder already uses this approach to great effect for volume drivers:


https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/lvm.py

https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py


Question: Is this base class a feasible idea for Magnum? If so, do we need any other operations in the base class that I haven't mentioned?


3. Each COE driver would have its own Heat template for creating a bay node. It would also have a template definition that lists the JSON parameters which are fed into the Heat template.


Question: From a very top-level POV, what logic or codebase changes would Magnum need Heat templates in the above way?


4. Removal of all old code that does not fit the above paradigm.


?---


Any custom COE operations that are not common Bay operations (i.e. the six listed in #2) would reside in a COE extension. This is outside of the scope of the COE drivers spec and would require an entirely different spec that utilizes a common paradigm for extensions in OpenStack. Such a spec would also need to cover how the conductor would link off to each COE. Is this summary correct?


Does Magnum already have a scale manager? If not, should this be introduced as a separate BP/spec?


Is there anything else that a COE drivers spec need to cover which I have not mentioned??


Jamie


________________________________
Rackspace International GmbH a company registered in the Canton of Zurich, Switzerland (company identification number CH-020.4.047.077-1) whose registered office is at Pfingstweidstrasse 60, 8005 Zurich, Switzerland. Rackspace International GmbH privacy policy can be viewed at www.rackspace.co.uk/legal/swiss-privacy-policy - This e-mail message may contain confidential or privileged information intended for the recipient. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com and delete the original message. Your cooperation is appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160317/44939981/attachment.html>


More information about the OpenStack-dev mailing list