Great to hear. I started a blueprint for this [1]. More detail can be added once the kilo nova-specs directory is created… for now, I’ve tried to put some fairly detailed notes on the blueprint’s description.
[1] https://blueprints.launchpad.net/nova/+spec/dynamic-server-groups - Joe On Sep 11, 2014, at 2:11 AM, Sylvain Bauza <sba...@redhat.com> wrote: > > Le 11/09/2014 01:10, Joe Cropper a écrit : >> Agreed - I’ll draft up a formal proposal in the next week or two and we can >> focus the discussion there. Thanks for the feedback - this provides a good >> framework for implementation considerations. > > Count me on it, I'm interested in discussing the next stage. > > When preparing the scheduler split, I just discovered it was unnecessary to > keep the instance groups setup in the scheduler, because it was creating > dependencies to other Nova objects that the Scheduler doesn't necessarly need > to handle. > I proposed accordingly a patch for moving the logic to the conductor instead, > see the proposal here : > https://review.openstack.org/110043 > > Reviews are welcome of course. > > -Sylvain > > >> - Joe >> On Sep 10, 2014, at 6:00 PM, Russell Bryant <rbry...@redhat.com> wrote: >> >>> On 09/10/2014 06:46 PM, Joe Cropper wrote: >>>> Hmm, not sure I follow the concern, Russell. How is that any different >>>> from putting a VM into the group when it’s booted as is done today? >>>> This simply defers the ‘group insertion time’ to some time after >>>> initial the VM’s been spawned, so I’m not sure this creates anymore race >>>> conditions than what’s already there [1]. >>>> >>>> [1] Sure, the to-be-added VM could be in the midst of a migration or >>>> something, but that would be pretty simple to check make sure its task >>>> state is None or some such. >>> The way this works at boot is already a nasty hack. It does policy >>> checking in the scheduler, and then has to re-do some policy checking at >>> launch time on the compute node. I'm afraid of making this any worse. >>> In any case, it's probably better to discuss this in the context of a >>> more detailed design proposal. >>> >>> -- >>> Russell Bryant >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > 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
