On 11/28/13 8:12 PM, "Robert Collins" <robe...@robertcollins.net> wrote:
>On 29 November 2013 04:50, Gary Kotton <gkot...@vmware.com> wrote: > >> I am not really sure how we can have a client tree without even having >> discussed the API's and interfaces. From the initial round of emails the >> intention was to make use of the RPC mechanism to speak with the >>scheduler. > >It still is. We have an existing RPC API in the nova/scheduler tree. > >> One option worth thinking about is to introduce a new scheduling driver >>to >> nova - this driver will interface with the external scheduler. This will >> let us define the scheduling API, model etc, without being in the >>current >> confines of Nova. This will also enable all of the other modules, for >> example Cinder to hook into it. > >The problem is that that is the boil-the-ocean approach that hasn't >succeeded for several cycles. We have interest in trying something new >- there are three failure modes I can see: >A - we fail to split it out enough, and noone else uses it. >B - we introduce a performance / correctness problem during the split out >C - we stall and don't do anything 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. Prior to copying code we really need to discuss the API's. 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) 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. Thanks Gary > >Right now, I am mainly worried about B. Getting good APIs is step two >after getting a solid split out scheduler. > >-Rob > > >-- >Robert Collins <rbtcoll...@hp.com> >Distinguished Technologist >HP Converged Cloud > >_______________________________________________ >OpenStack-dev mailing list >OpenStack-dev@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=1c2juHtCdurF15wlASmHX >Xy7sW%2FYrZ1iUwZVFKhfDGs%3D%0A&s=061da913e6d2a1ea705e44dc0523f8be2b56d4245 >d34d8aed35bc95dca402064 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
