<tt><font size=2>Boris Pavlovic <bpavlovic@mirantis.com> wrote on
18/11/2013 08:31:20 AM:<br>
<br>
> Actually schedulers in nova and cinder are almost the same. </font></tt>
<br>
<br><tt><font size=2>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).</font></tt>
<br>
<br><tt><font size=2>> >> So, Cinder (as well as Neutron, and
potentially others) would <br>
> need to be hooked to Nova rpc? </font></tt>
<br><tt><font size=2>> <br>
> As a first step, to prove approach yes, but I hope that we won't <br>
> have "nova" or "cinder" scheduler at all. We will
have just <br>
> scheduler that works well. </font></tt>
<br>
<br><tt><font size=2>So, do you envision this code being merged in Nova
first, and then move out? Start as a new "thing" from the beginning?
</font></tt>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>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).</font></tt>
<br>
<br><tt><font size=2>> >> Instances of memcached. In an environment
with multiple <br>
> schedulers. I think you mentioned that if we have, say, 10 <br>
> schedulers, we will also have 10 instances of memcached. </font></tt>
<br><tt><font size=2>> <br>
> Actually we are going to make implementation based on sqlalchemy as
<br>
> well. In case of memcached I just say one of arch, that you could
<br>
> run on each server with scheduler service memcahced instance. But
it<br>
> is not required, you can have even just one memcached instance for
<br>
> all scheulers (but it is not HA).</font></tt>
<br>
<br><tt><font size=2>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).</font></tt>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Alex</font></tt>
<br>
<br><tt><font size=2>> Best regards,<br>
> Boris Pavlovic </font></tt>
<br><tt><font size=2>> ---</font></tt>
<br><tt><font size=2>> Mirantis Inc. </font></tt>
<br>