<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">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.<div><br></div><div>[1] <a href="https://blueprints.launchpad.net/nova/+spec/dynamic-server-groups">https://blueprints.launchpad.net/nova/+spec/dynamic-server-groups</a></div><div><br></div><div>- Joe<br><div><div>On Sep 11, 2014, at 2:11 AM, Sylvain Bauza <<a href="mailto:sbauza@redhat.com">sbauza@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>Le 11/09/2014 01:10, Joe Cropper a écrit :<br><blockquote type="cite">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.<br></blockquote><br>Count me on it, I'm interested in discussing the next stage.<br><br>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.<br>I proposed accordingly a patch for moving the logic to the conductor instead, see the proposal here :<br><a href="https://review.openstack.org/110043">https://review.openstack.org/110043</a><br><br>Reviews are welcome of course.<br><br>-Sylvain<br><br><br><blockquote type="cite">- Joe<br>On Sep 10, 2014, at 6:00 PM, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote:<br><br><blockquote type="cite">On 09/10/2014 06:46 PM, Joe Cropper wrote:<br><blockquote type="cite">Hmm, not sure I follow the concern, Russell. How is that any different<br>from putting a VM into the group when it’s booted as is done today?<br>This simply defers the ‘group insertion time’ to some time after<br>initial the VM’s been spawned, so I’m not sure this creates anymore race<br>conditions than what’s already there [1].<br><br>[1] Sure, the to-be-added VM could be in the midst of a migration or<br>something, but that would be pretty simple to check make sure its task<br>state is None or some such.<br></blockquote>The way this works at boot is already a nasty hack. It does policy<br>checking in the scheduler, and then has to re-do some policy checking at<br>launch time on the compute node. I'm afraid of making this any worse.<br>In any case, it's probably better to discuss this in the context of a<br>more detailed design proposal.<br><br>--<span class="Apple-converted-space"> </span><br>Russell Bryant<br><br>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote><br>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></blockquote><br><br>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div></blockquote></div><br></div></body></html>