Open Stack

On 11/28/13 11:34 PM, "Robert Collins" <robertc at robertcollins.net> wrote:

>On 29 November 2013 09:44, Gary Kotton <gkotton at vmware.com> wrote:
>>
>>
>> The first stage is technical - move Nova scheduling code from A to be.
>> What do we achieve - not much - we actually complicate things - there is
>> always churn in Nova and we will have duplicate code bases. In addition
>>to
>> this the only service that can actually make use of they is Nova
>>
>> The second stage is defining an API that other modules can use (we have
>> yet to decide if this will be RPC based or have a interface like Glance,
>> Cinder etc.)
>> We have yet to even talk about the API's.
>> The third stage is adding shiny new features and trying to not have a
>> community tar and feather us.
>
>Yup; I look forward to our tar and feathering overlords. :)
>
>> Prior to copying code we really need to discuss the API's.
>
>I don't think we do: it's clear that we need to come up with them -
>it's necessary, and noone has expressed any doubt about the ability to
>do that. RPC API evolution is fairly well understood - we add a new
>method, and have it do the necessary, then we go to the users and get
>them using it, then we delete the old one.
>
>> This can even
>> be done in parallel if your concern is time and resources. But the point
>> is we need a API to interface with the service. For a start we can just
>> address the Nova use case. We need to at least address:
>> 1. Scheduling interface
>> 2. Statistics updates
>> 3. API's for configuring the scheduling policies
>>
>> Later these will all need to bode well with all of the existing modules
>> that we want to support - Nova, Cinder and Neutron (if I missed on then
>> feel free to kick me whilst I am down)
>
>Ironic perhaps.
>
>> I do not think that we should focus on failure modes, we should plan it
>> and break it up so that it will be usable and functional and most
>> importantly useful in the near future.
>>
>> How about next week we sit together and draw up a wiki of the flows,
>>data
>> structures and interfaces. Lets go from there.
>
>While I disagree about us needing to do it right now, I'm very happy
>to spend some time on it - I don't want to stop folk doing work that
>needs to be done!

I do not think that discussion will prevent any of the work getting done
or not done. It may actually save us a ton of time. I really think that
defining the API and interfaces can save us a lot in the short and long
run. The V1 API should really be very simple and we should not get bogged
down but if we can define an interface that could work with Nova and be
extensible to work with the rest then we will be in a very good state. I
am thinking of have a notion of a 'scheduling domain' and that will be
used with the scheduling request. This could be a host aggregate, a AZ,
the feature that Phil is working on - private hosts. If we can define an
interface around this and have the Nova <-> scheduling interface down then
we are on the wayŠ.

Hosts scan be added to the domain and the scheduling will be able to get
the stats etc. For the first phase this will be completely RPC bases so
not to get bogged down.

Can we talk about this next week?

>
>-Rob
>
>
>
>-- 
>Robert Collins <rbtcollins at hp.com>
>Distinguished Technologist
>HP Converged Cloud
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
>bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=e
>H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=m8Unw2sBiRyQsd6ADjYCH
>CpcxAKBG1Gb3R58ehl3wIw%3D%0A&s=6c2d9b2f3b884693094cffc0392402f24b50ddac3d9
>d956472d26c726c84a2a6