On Mon, Jul 7, 2014 at 8:02 AM, Daniel P. Berrange <berra...@redhat.com> wrote:
> On Mon, Jul 07, 2014 at 02:38:57PM +0000, Dugger, Donald D wrote: > > Well, my main thought is that I would prefer to see the gantt split > > done sooner rather than later. The reality is that we've been trying > > to split out the scheduler for months and we're still not there. Until > > we bite the bullet and actually do the split I'm afraid we'll still be > > here discussing the `best` way to do the split at the K & L summits > > (there's a little bit of `the perfect is the enemy of the good' happening > > here). With the creation of the client library we've created a good > > seam to split out the scheduler, let's do the split and fix the remaining > > problems (aggregates and instance group references). > > > To address some specific points: > > > 2) We won't get around to creating parity between gantt and nova. Gantt > > will never be the default scheduler until it has complete parity with the > > nova scheduler, that should give us sufficient incentive to make sure we > > achieve parity as soon as possible. > > Although it isn't exactly the same situation, we do have history with > Neutron/nova-network showing that kind of incentive to be insufficient > to make the work actually happen. If Gantt remained a subset of features > of the Nova scheduler, this might leave incentive to address the gaps, > but I fear that other unrelated features will be added to Gantt that > are not in Nova, and then we'll be back in the Neutron situation pretty > quickly where both options have some features the other option lacks. > > > 3) The split should be done at the beginning of the cycle. I don't > > see a need for that, we should do the split whenever we are ready. > > Since gantt will be optional it shouldn't affect release issues with > > nova and the sooner we have a separate tree the sooner people can test > > and develop on the gantt tree. > > If we're saying Gantt is optional, this implies the existing Nova code > is remaining. This seems to leave us with the neutron/nova-network > situation again of maintaining two code bases again, and likely the > people who were formerly fixing the bugs in nova scheduler codebase > would be focused on gantt leaving the nova code to slowly bitrot. > I agree with Daniel, we should not make Gantt optional otherwise we risk ending up in a neutron/nova-network scenario. IMHO the workflow from the consumers point of view should be something along the lines of: * In release X, nova-scheduler is deprecated and will be removed in N cycles with Gantt as the default scheduler (along with a robust migration strategy) * In release X+N we delete nova-scheduler > > Regards, > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ > :| > |: http://libvirt.org -o- http://virt-manager.org > :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ > :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc > :| > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
