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
