Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev