Open Stack

On 25 Jan 2014 15:11, "Clint Byrum" <clint at fewbar.com> wrote:
>
> Excerpts from Devananda van der Veen's message of 2014-01-22 16:44:01
-0800:
>
> What Tuskar wants to do is layer workloads on top of logical and physical
> groupings. So it would pass to Nova "Boot 4 machines with (flavor)
> and distinct(failure_domain_id)"

Maybe. Maybe it would ask for a reservation and then ask for machines
within that reservation.... Until it is unopened we are speculating :-)

> However, in looking at how Ironic works and interacts with Nova, it
> doesn't seem like there is any distinction of data per-compute-node
> inside Ironic.  So for this to work, I'd have to run a whole bunch of
> ironic instances, one per compute node. That seems like something we
> don't want to do.

Huh?

> So perhaps if ironic can just model _a single_ logical grouping per node,
> it can defer any further distinctions up to Nova where it will benefit
> all workloads, not just Ironic.

Agreed with this.

be deterministic. If Heat does not
> > inform Ironic of this grouping, but Ironic infers it (eg, from timing of
> > requests for similar actions) then optimization is possible but
> > non-deterministic, and may be much harder to reason about or debug.
> >
>
> I'm wary of trying to get too deep on optimization this early. There
> are some blanket optimizations that you allude to here that I think will
> likely work o-k with even the most minimal of clues.

+1 premature optimisation and the root of all evil...

> > 3: APIs
r the same operation, but this would
> > be non-deterministic.
>
> Agreed, I think Ironic needs _some_ level of grouping to be efficient.

What makes you think this? Ironic runs in the same data centre as Nova...
It it takes 20000 Api calls to boot 10000 physical machines is that really
a performance problem? When other that first power on would you do that
anyway?

> > - Moving group-awareness or group-operations into the lower layers (eg,
> > Ironic) looks like it will require non-trivial changes to Heat and Nova,
> > and, in my opinion, violates a layer-constraint that I would like to
> > maintain. On the other hand, we could avoid the challenges around
> > coalescing. This might be necessary to support physically-grouped
hardware
> > anyway, too.
> >
>
> I actually think that the changes to Heat and Nova are trivial. Nova
> needs to have groups for compute nodes and the API needs to accept those
> groups. Heat needs to take advantage of them via the API.

The changes to Nova would be massive and invasive as they would be
redefining the driver api....and all the logic around it.

> There is a non-trivial follow-on which is a "wholistic" scheduler which
> would further extend these groups into other physical resources like
> networks and block devices. These all feel like logical evolutions of the
> idea of making somewhat arbitrary and overlapping groups of compute nodes.

The holistic scheduler can also be a holistic reserver plus reservation
aware scheduler -this avoids a lot of pain imo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140125/2d95ef1a/attachment.html>