<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<style type="text/css" style="display:none"><!-- p { margin-top: 0px; margin-bottom: 0px; }--></style>
</head>
<body dir="ltr" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>Hi Kai,<br>
</p>
<p><br>
</p>
<p>Does Magnum already have drivers for networks and volumes, or are you suggesting this is what needs to be handled by a new COE driver structure?<br>
</p>
<p><br>
</p>
<p>I think having a directory per COE is a good idea, if the driver handles multiple responsibilities. So far we haven't really identified what the responsibility of a COE driver is - that's what I'm currently trying to identify. What type of classes would
be in the default/ and contrib/ directories?<br>
</p>
<p><br>
</p>
<p>I'm assuming the scale manager would need to be specced alongside the COE drivers, since each COE has a different way of handling scaling. If that's the case, how would a scale manager integrate into the COE driver model we've already touched upon? Would
each COE class implement various scaling methods from a base class, or would there be a manager class per COE?<br>
</p>
<p><br>
</p>
<p>Jamie<br>
</p>
<p><br>
</p>
<div style="color: rgb(33, 33, 33);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Kai Qiang Wu <wkqwu@cn.ibm.com><br>
<b>Sent:</b> 17 March 2016 15:44<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Magnum] COE drivers spec</font>
<div> </div>
</div>
<div>
<p>Here are some of my raw points,<br>
<br>
<br>
1. For the driver mentioned, I think we not necessary use bay-driver here, as have network-driver, volume-driver, maybe it is not needed to introduce driver in bay level.(bay is higher level than network or volume)<br>
<br>
maybe like<br>
<br>
coes/<br>
swarm/<br>
mesos/<br>
kubernetes<br>
<br>
Each coes include, take swarm as example,<br>
<br>
coes/<br>
swarm/<br>
default/<br>
contrib/<br>
Or we not use contrib here, just like (one is support by default, others are contributed by more contributors and tested in jenkins pipeline)<br>
coes/<br>
swarm/<br>
atomic/<br>
ubuntu/<br>
<br>
<br>
We have BaseCoE, other specific CoE inherit from that, Each CoE have related life management operations, like Create, Update, Get, Delete life cycle management.<br>
<br>
<br>
<br>
2. We need to think more about scale manager, which involves scale cluster up and down, Maybe a related auto-scale and manual scale ways.<br>
<br>
<br>
The user cases, like as a Cloud Administrator, I could easily use OpenStack to provide CoEs cluster, and manage CoE life cycle. and scale CoEs.<br>
CoEs could do its best to use OpenStack network, and volume services to provide CoE related network, volume support.<br>
<br>
<br>
Others interesting case(not required), if user just want to deploy one container in Magnum, we schedule it to the right CoE, (if user manual specify, it would schedule to the specific CoE)<br>
<br>
<br>
Or more user cases .....<br>
<br>
<br>
<br>
Thanks<br>
<br>
Best Wishes,<br>
--------------------------------------------------------------------------------<br>
Kai Qiang Wu (Î⿪ǿ Kennan£©<br>
IBM China System and Technology Lab, Beijing<br>
<br>
E-mail: wkqwu@cn.ibm.com<br>
Tel: 86-10-82451647<br>
Address: Building 28(Ring Building), ZhongGuanCun Software Park, <br>
No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193<br>
--------------------------------------------------------------------------------<br>
Follow your heart. You are miracle! <br>
<br>
<img width="16" height="16" border="0" alt="Inactive hide details for Jamie Hannaford ---17/03/2016 07:24:41 pm---Hi all, I'm writing the spec for the COE drivers, and I w" src="cid:1__=8FBBF5EADFDE40548f9e8a93df938690918c8FB@"><font color="#424282">Jamie Hannaford
---17/03/2016 07:24:41 pm---Hi all, I'm writing the spec for the COE drivers, and I wanted some feedback about what it should in</font><br>
<br>
<font size="2" color="#5F5F5F">From: </font><font size="2">Jamie Hannaford <jamie.hannaford@rackspace.com></font><br>
<font size="2" color="#5F5F5F">To: </font><font size="2">"openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org></font><br>
<font size="2" color="#5F5F5F">Date: </font><font size="2">17/03/2016 07:24 pm</font><br>
<font size="2" color="#5F5F5F">Subject: </font><font size="2">[openstack-dev] [Magnum] COE drivers spec</font><br>
</p>
<hr width="100%" size="2" align="left" noshade="" style="color:#8091A5">
<br>
<br>
<br>
<font size="4" face="Calibri">Hi all,</font><br>
<br>
<font size="4" face="Calibri">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 :)</font><br>
<br>
<font size="4" face="Calibri">From my perspective, the spec should recommend the following:</font><br>
<br>
<font size="4" face="Calibri">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}</font><br>
<br>
<font size="4" face="Calibri">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.</font><br>
<br>
<font size="4" face="Calibri">Cinder already uses this approach to great effect for volume drivers:</font><br>
<br>
<a href="https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/lvm.py"><u><font size="4" color="#0000FF" face="Calibri">https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/lvm.py</font></u></a><br>
<a href="https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py"><u><font size="4" color="#0000FF" face="Calibri">https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py</font></u></a><font size="4" face="Calibri">
</font><br>
<br>
<font size="4" face="Calibri">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?</font><br>
<br>
<font size="4" face="Calibri">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.</font><br>
<br>
<font size="4" face="Calibri">Question: From a very top-level POV, what logic or codebase changes would Magnum need Heat templates in the above way?</font><br>
<br>
<font size="4" face="Calibri">4. Removal of all old code that does not fit the above paradigm.</font><br>
<br>
<font size="4" face="Calibri">---</font><br>
<br>
<font size="4" face="Calibri">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?</font><br>
<br>
<font size="4" face="Calibri">Does Magnum already have a scale manager? If not, should this be introduced as a separate BP/spec?</font><br>
<br>
<font size="4" face="Calibri">Is there anything else that a COE drivers spec need to cover which I have not mentioned?</font><br>
<br>
<font size="4" face="Calibri">Jamie</font>
<p><font size="4" face="Calibri"></font></p>
<hr width="100%" size="2" align="left">
<font size="4" face="Calibri">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 </font><font size="4" face="Calibri">www.rackspace.co.uk/legal/swiss-privacy-policy</font><font size="4" face="Calibri"> - 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@rackspace.com and delete the original message. Your cooperation is
appreciated. </font><tt>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
</tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br>
</tt>
<p></p>
<p><br>
</p>
</div>
</div>
</body>
</html>