On Dec 2, 2013, at 12:38 PM, Russell Bryant <rbry...@redhat.com> wrote:
> On 12/02/2013 03:31 PM, Vishvananda Ishaya wrote: >> >> On Dec 2, 2013, at 9:12 AM, Russell Bryant <rbry...@redhat.com> >> wrote: >> >>> On 12/02/2013 10:59 AM, Gary Kotton wrote: >>>> I think that this is certainly different. It is something that >>>> we we want and need a user facing API. Examples: - aggregates - >>>> per host scheduling - instance groups >>>> >>>> Etc. >>>> >>>> That is just taking the nova options into account and not the >>>> other modules. How doul one configure that we would like to >>>> have storage proximity for a VM? This is where things start to >>>> get very interesting and enable the cross service scheduling >>>> (which is the goal of this no?). >>> >>> An explicit part of this plan is that all of the things you're >>> talking about are *not* in scope until the forklift is complete >>> and the new thing is a functional replacement for the existing >>> nova-scheduler. We want to get the project established and going >>> so that it is a place where this work can take place. We do >>> *not* want to slow down the work of getting the project >>> established by making these things a prerequisite. >> >> >> I'm all for the forklift approach since I don't think we will make >> any progress if we stall going back into REST api design. >> >> I'm going to reopen a can of worms, though. I think the most >> difficult part of the forklift will be moving stuff out of the >> existing databases into a new database. We had to deal with this in >> cinder and having a db export and import strategy is annoying to >> say the least. Managing the db-related code was the majority of the >> work during the cinder split. >> >> I think this forklift will be way easier if we merge the >> no-db-scheduler[1] patches first before separating the scheduler >> out into its own project: >> >> https://blueprints.launchpad.net/nova/+spec/no-db-scheduler >> >> I think the effort to get this finished is smaller than the effort >> to write db migrations and syncing scripts for the new project. > > Agreed that this should make it easier. > > My thought was that the split out scheduler could just import nova's > db API and use it against nova's database directly until this work > gets done. If the forklift goes that route instead of any sort of > work to migrate data from one db to another, they could really happen > in any order, I think. That is a good point. If the forklift is still talking to nova's db then it would be significantly less duplication and i could see doing it in the reverse order. The no-db-stuff should be done before trying to implement cinder support so we don't have the messiness of the scheduler talking to multiple db apis. Vish > > -- > Russell Bryant > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev