Open Stack

On Mon, Jul 7, 2014 at 8:02 AM, Daniel P. Berrange <berrange at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140707/93c55d73/attachment.html>