A question but what filtering/scheduling would be done in which place; any thoughts on the breakup between nova and ironic?

If say ironic knows about all baremetal resources and nova doesn't know about them, then what kind of decisions can nova make during scheduling time? I guess the same question exists for other clustered drivers, what decision does nova really make for those types of drivers, is the decision beneficial?

I guess the same question connects into various/most filters and how they operate with clustered drivers:

For example if nova doesn't know about ironic baremetal resources, how does the concept of an availability zone or aggregate, or compute enabled/disabled filtering work (all these afaik are connected to nova-compute *service* and/or services table, but with this clustering model, which nova-compute proxies a request into ironic doesn't seem to mean that much).

Anyone compiled (or thought about compiling) a list of concepts from nova that *appear to* breakdown when a top level project (nova) doesn't know about the resources its child projects (ironic...) contain? (maybe an etherpad exists somewhere?)

Dan Smith wrote:
Thanks for summing this up, Deva. The planned solution still gets my
vote; we build that, deprecate the old single compute host model where
nova handles all scheduling, and in the meantime figure out the gaps
that operators need filled and the best way to fill them.

Mine as well, speaking only for myself. It's going to require some
deprecation and transition, but anyone with out-of-tree code (filters,
or otherwise) has to be prepared for that at any moment.

--Dan

__________________________________________________________________________
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

__________________________________________________________________________
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

Reply via email to