> > 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. > I agree with Robert. I think that nova RPC is fairly enough for the new scheduler right now. Most of the scheduler works focus on nova anyway, so starting from there is reasonable and rather easy for the transition. We can think of enhancing API later (even creating REST API perhaps).
> > 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 > > If by "2. Statistics update" you mean the database issue for scheduler then yes, it is a big issue, especially during the transition period when nova still holds the host state data. Should scheduler get access to nova's DB for the time being, and later fork out the DB to scheduler? According to Boris, Merantis has already studied the separation of host state from nova's DB. I think we can benefit from their experience. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev