> 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 _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators