<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=iso-8859-1"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
tt
{mso-style-priority:99;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=FR link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Boris,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.5pt;font-family:"Calibri","sans-serif";color:#1F497D'>>>> Is it really OK to drop these tables? Could Nova can work without them (e.g. rollback)? And if Ceilometer is about to ask nova for host state metrics ?<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.5pt;font-family:"Calibri","sans-serif";color:#1F497D'>></span><span lang=EN-US>>> Yes it is OK, because now ceilometer and other projects could ask scheduler about host state. (I don't see any problems)<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>IMO, since the scheduler doesn’t communicate directly to hypervisors, that’s the role of computes, thus we should not rely on it for collecting the host state data. I think that it should be inversed, i.e. scheduler relies on others, s.a. Ceilometer for that matter. But this means we have to deal with data synchronization.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Alex,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>></span><tt><span lang=EN-US style='font-size:10.0pt'>By the way, since the relationships between resources are likely to reside in Heat DB, it could make sense to have this "thing" as a new Engine under Heat umbrella (as discussed in couple of other threads, you are also likely to need orchestration, when dealing with groups of resources).<o:p></o:p></span></tt></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I’m not so sure that this “scheduler” should fall into Heat. Heat does not “know” *<b>every</b>* compute, it communicates with Nova-API and that’s all it knows. Scheduler has the complete knowledge of the infrastructure, and responses to question which compute hosts which VM. Thus whoever the scheduler responds to should be able to communicate with *<b>every</b>* computes. For instance, the scheduler can directly initiate VM like in the old days, or have some conductor for this task, or some orchestration like you said. Of course, Heat can call this scheduler which will initiate the VMs is a sound scenario. But otherwise for Heat to have this scheduler integrated is too much intrusive into the infra.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Best regards,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Toan<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>De :</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Alex Glikson [mailto:GLIKSON@il.ibm.com] <br><b>Envoyé :</b> lundi 18 novembre 2013 09:29<br><b>À :</b> OpenStack Development Mailing List (not for usage questions)<br><b>Objet :</b> Re: [openstack-dev] [nova][cinder][oslo][scheduler] How to leverage oslo schduler/filters for nova and cinder<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><tt><span lang=EN-US style='font-size:10.0pt'>Boris Pavlovic <</span></tt><tt><span style='font-size:10.0pt'><a href="mailto:bpavlovic@mirantis.com"><span lang=EN-US>bpavlovic@mirantis.com</span></a></span></tt><tt><span lang=EN-US style='font-size:10.0pt'>> wrote on 18/11/2013 08:31:20 AM:</span></tt><span lang=EN-US style='font-size:10.0pt;font-family:"Courier New"'><br><br><tt>> Actually schedulers in nova and cinder are almost the same. </tt></span><span lang=EN-US><br><br></span><tt><span style='font-size:10.0pt'>Well, this is kind of expected, since Cinder scheduler started as a copy-paste of the Nova scheduler :-) But they already started diverging (not sure whether this is necessarily a bad thing or not).</span></tt> <br><br><tt><span style='font-size:10.0pt'>> >> So, Cinder (as well as Neutron, and potentially others) would </span></tt><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>> need to be hooked to Nova rpc? </tt></span> <br><tt><span style='font-size:10.0pt'>> </span></tt><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>> As a first step, to prove approach yes, but I hope that we won't </tt><br><tt>> have "nova" or "cinder" scheduler at all. We will have just </tt><br><tt>> scheduler that works well. </tt></span> <br><br><tt><span style='font-size:10.0pt'>So, do you envision this code being merged in Nova first, and then move out? Start as a new "thing" from the beginning? </span></tt><br><tt><span style='font-size:10.0pt'>Also, when it will be separate (probably not in icehouse?), will the communication continue being over RPC, or would we need to switch to REST? This could be conceptually similar to the communicate between cells today, via a separate RPC.</span></tt> <br><br><tt><span style='font-size:10.0pt'>By the way, since the relationships between resources are likely to reside in Heat DB, it could make sense to have this "thing" as a new Engine under Heat umbrella (as discussed in couple of other threads, you are also likely to need orchestration, when dealing with groups of resources).</span></tt> <br><br><tt><span style='font-size:10.0pt'>> >> Instances of memcached. In an environment with multiple </span></tt><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>> schedulers. I think you mentioned that if we have, say, 10 </tt><br><tt>> schedulers, we will also have 10 instances of memcached. </tt></span> <br><tt><span style='font-size:10.0pt'>> </span></tt><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>> Actually we are going to make implementation based on sqlalchemy as </tt><br><tt>> well. In case of memcached I just say one of arch, that you could </tt><br><tt>> run on each server with scheduler service memcahced instance. But it</tt><br><tt>> is not required, you can have even just one memcached instance for </tt><br><tt>> all scheulers (but it is not HA).</tt></span> <br><br><tt><span style='font-size:10.0pt'>I am not saying that having multiple instances of memcached is wrong - just that it would require some work.. It seems that one possible approach could be partitioning -- each scheduler will take care of a subset of the environment (availability zone?). This way data will be naturally partitioned too, and the data in memcached's will not need to be synchronized. Of course, making this HA would also require some effort (something like ZooKeeper could be really useful to manage all of this - configuration of each scheduler, ownership of underlying 'zones', leader election, etc).</span></tt> <br><br><tt><span style='font-size:10.0pt'>Regards,</span></tt> <br><tt><span style='font-size:10.0pt'>Alex</span></tt> <br><br><tt><span style='font-size:10.0pt'>> Best regards,</span></tt><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>> Boris Pavlovic </tt></span> <br><tt><span style='font-size:10.0pt'>> ---</span></tt> <br><tt><span style='font-size:10.0pt'>> Mirantis Inc. </span></tt> <o:p></o:p></p><div class=MsoNormal align=center style='text-align:center'><hr size=1 width="100%" noshade style='color:#A0A0A0' align=center></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Aucun virus trouvé dans ce message.<br>Analyse effectuée par AVG - <a href="http://www.avg.fr">www.avg.fr</a><br>Version: 2014.0.4158 / Base de données virale: 3629/6844 - Date: 17/11/2013<o:p></o:p></p></div></body></html>