<div dir="ltr">Robert, <div><br></div><div><br></div><div>Btw,  I would like to be a volunteer too=)</div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div><div><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sun, Nov 24, 2013 at 10:43 PM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 22 November 2013 23:55, Gary Kotton <<a href="mailto:gkotton@vmware.com">gkotton@vmware.com</a>> wrote:<br>
><br>
><br>
<br>
>>> I'm looking for 4-5 folk who have:<br>
>>>  - modest Nova skills<br>
>>>  - time to follow a fairly mechanical (but careful and detailed work<br>
>>> needed) plan to break the status quo around scheduler extraction<br>
><br>
> I would be happy to take part. But prior I think that we need to iron out<br>
> a number of issues:<br>
<br>
</div>Cool! Added your name to the list of volunteers, which brings us to 4,<br>
the minimum I wanted before starting things happening.<br>
<div class="im"><br>
> 1. Will this be a new service that has an API, for example will Nova be<br>
</div>> able to register a host and provide the host statistics.<br>
<br>
This will be an RPC api initially, because we know the performance<br>
characteristics of the current RPC API, and doing anything different<br>
to that is unnecessary risk. Once the new structure is:<br>
* stable<br>
* gated with unit and tempest tests<br>
* with a straightforward and well documented migration path for deployers<br>
<br>
Then adding a RESTful API could take place.<br>
<div class="im"><br>
> 2. How will the various components interact with the scheduler - same as<br>
> today - that is RPC? Or a REST API? The latter is a real concern due to<br>
> problems we have seen with the interactions of nova and other services<br>
<br>
</div>RPC initially. REST *only* once we've avoided second system syndrome.<br>
<div class="im"><br>
> 3. How will current developments fit into this model?<br>
<br>
</div>Code sync - take a forklift copy of the code, and apply patches to<br>
both for the one cycle.<br>
<div class="im"><br>
> All in all I think that it is a very good and healthy idea. I have a<br>
> number of reservations - these are mainly regarding the implementation and<br>
> the service definition.<br>
><br>
> Basically I like the approach of just getting heads down and doing it, but<br>
> prior to that I think that we just need to understand the scope and mainly<br>
> define the interfaces and how they can used/abused and consumed. It may be<br>
> a very good topic to discuss at the up and coming scheduler meeting - this<br>
> may be in the middle of the night for Robert. If so then maybe we can<br>
> schedule another time.<br>
<br>
</div>Tuesdays at 1500 UTC - I'm in UTC+13 at the moment, so thats 0400<br>
local. A leeeetle early for me :) I'll ping you on IRC about resolving<br>
the concerns you raise, and you can proxy my answers to the sub group<br>
meeting?<br>
<div class="im"><br>
> Please note that this is scheduling and not orchestration. That is also<br>
> something that we need to resolve.<br>
<br>
</div>Yup, sure is.<br>
<br>
-Rob<br>
<div class="im"><br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
</div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>