<p dir="ltr"><br>
On 25 Jan 2014 15:11, "Clint Byrum" <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>> wrote:<br>
><br>
> Excerpts from Devananda van der Veen's message of 2014-01-22 16:44:01 -0800:<br>
><br>
> What Tuskar wants to do is layer workloads on top of logical and physical<br>
> groupings. So it would pass to Nova "Boot 4 machines with (flavor)<br>
> and distinct(failure_domain_id)"</p>
<p dir="ltr">Maybe. Maybe it would ask for a reservation and then ask for machines within that reservation.... Until it is unopened we are speculating :-)<br></p>
<p dir="ltr">> However, in looking at how Ironic works and interacts with Nova, it<br>
> doesn't seem like there is any distinction of data per-compute-node<br>
> inside Ironic.  So for this to work, I'd have to run a whole bunch of<br>
> ironic instances, one per compute node. That seems like something we<br>
> don't want to do.</p>
<p dir="ltr">Huh?</p>
<p dir="ltr">> So perhaps if ironic can just model _a single_ logical grouping per node,<br>
> it can defer any further distinctions up to Nova where it will benefit<br>
> all workloads, not just Ironic.</p>
<p dir="ltr">Agreed with this.</p>
<p dir="ltr"> be deterministic. If Heat does not<br>
> > inform Ironic of this grouping, but Ironic infers it (eg, from timing of<br>
> > requests for similar actions) then optimization is possible but<br>
> > non-deterministic, and may be much harder to reason about or debug.<br>
> ><br>
><br>
> I'm wary of trying to get too deep on optimization this early. There<br>
> are some blanket optimizations that you allude to here that I think will<br>
> likely work o-k with even the most minimal of clues.</p>
<p dir="ltr">+1 premature optimisation and the root of all evil...</p>
<p dir="ltr">> > 3: APIs<br>
r the same operation, but this would<br>
> > be non-deterministic.<br>
><br>
> Agreed, I think Ironic needs _some_ level of grouping to be efficient.</p>
<p dir="ltr">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?</p>

<p dir="ltr">> > - Moving group-awareness or group-operations into the lower layers (eg,<br>
> > Ironic) looks like it will require non-trivial changes to Heat and Nova,<br>
> > and, in my opinion, violates a layer-constraint that I would like to<br>
> > maintain. On the other hand, we could avoid the challenges around<br>
> > coalescing. This might be necessary to support physically-grouped hardware<br>
> > anyway, too.<br>
> ><br>
><br>
> I actually think that the changes to Heat and Nova are trivial. Nova<br>
> needs to have groups for compute nodes and the API needs to accept those<br>
> groups. Heat needs to take advantage of them via the API.</p>
<p dir="ltr">The changes to Nova would be massive and invasive as they would be redefining the driver api....and all the logic around it.</p>
<p dir="ltr">> There is a non-trivial follow-on which is a "wholistic" scheduler which<br>
> would further extend these groups into other physical resources like<br>
> networks and block devices. These all feel like logical evolutions of the<br>
> idea of making somewhat arbitrary and overlapping groups of compute nodes.</p>
<p dir="ltr">The holistic scheduler can also be a holistic reserver plus reservation aware scheduler -this avoids a lot of pain imo<br>
</p>