Open Stack

> To be clear, they are able to communicate, and do, as long as you
> configure them to be able to do so. The long-term goal is that you don't
> have to configure them to be able to do so, so we're trying to design
> and work in that mode toward that goal.

No, the cell conductor doesn't have a way to communicate with the
scheduler. It's more than just a "it's not configured to" thing.

If you have multiple cells, then your conductors within a cell point to
the cell MQ as the default transport for all kinds of stuff. If they
call to compute to do a thing, they don't (can't, since it doesn't have
the ability to lookup the cell mapping) target, they just ask on their
default bus.

So, unless scheduler and compute are on the same bus, conductor *can't*
talk to both at the same time (for non-super conductor operations like
build that expect to target, but then they can't do the non-targeted
operations). If you do that, then you're not doing cellsv2.

>> [1] This really does not occur with any frequency for hypervisor virt
>> drivers, since the exceptions those hypervisors throw are caught by
>> the nova-compute worker and handled without raising a Reschedule.
> 
> Are you sure about that?
> 
> https://github.com/openstack/nova/blob/931c3f48188e57e71aa6518d5253e1a5bd9a27c0/nova/compute/manager.py#L2041-L2049

Sure, the diaper exception is rescheduled currently. That should
basically be things like misconfiguration type things. Rescheduling
papers over those issues, which I don't like, but in the room it surely
seemed like operators thought that they still needed to be handled.

--Dan