I don't dabble in the RequestSpec code much, but in trying to fix bug
1712008 [1] I'm venturing in there and have some questions. This is
mostly an email to Sylvain for when he gets back from vacation but I
wanted to dump it before moving forward.
Mainly, what is the difference between
RequestSpec.force_hosts/force_nodes and RequestSpec.requested_destination?
When should one be used over the other? I take it that
requested_destination is the newest and coolest thing and we should
always use that first, and that's what the nova-api code is using, but I
also see the scheduler code checking force_hosts/force_nodes.
Is that all legacy compatibility code? And if so, then why don't we
handle requested_destination in RequestSpec routines like
reset_forced_destinations() and to_legacy_filter_properties_dict(), i.e.
for the latter, if it's a new style RequestSpec with
requested_destination set, but we have to backport and call
to_legacy_filter_properties_dict(), shouldn't requested_destination be
used to set force_hosts/force_nodes on the old style filter properties?
Since RequestSpec.requested_destination is the thing that restricts a
move operation to a single cell, it seems pretty important to always be
using that field when forcing where an instance is moving to. But I'm
confused about whether or not both requested_destination *and*
force_hosts/force_nodes should be set since the compat code doesn't seem
to transform the former into the latter.
If this is all transitional code, we should really document the hell out
of this in the RequestSpec class itself for anyone trying to write new
client side code with it, like me.
[1] https://bugs.launchpad.net/nova/+bug/1712008
--
Thanks,
Matt
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
