<tt><font size=2>Alex Glikson <GLIKSON@il.ibm.com> wrote on 09/29/2013
03:30:35 PM:<br>
<br>
> Mike Spreitzer <mspreitz@us.ibm.com> wrote on 29/09/2013 08:02:00
PM:<br>
> <br>
> > Another reason to prefer host is that we have other resources
to <br>
> > locate besides compute. <br>
> <br>
> Good point. Another approach (not necessarily contradicting) could
<br>
> be to specify the location as a property of host aggregate rather
<br>
> than individual hosts (and introduce similar notion in Cinder, and
<br>
> maybe Neutron). This could be an evolution/generalization of the <br>
> existing 'availability zone' attribute, which would specify a more
<br>
> fine-grained location path (e.g., <br>
> 'az_A:rack_R1:chassis_C2:node_N3'). We briefly discussed this <br>
> approach at the previous summit (see 'simple implementation' under
<br>
> </font></tt><a href=https://etherpad.openstack.org/HavanaTopologyAwarePlacement><tt><font size=2>https://etherpad.openstack.org/HavanaTopologyAwarePlacement</font></tt></a><tt><font size=2>)
-- but <br>
> unfortunately I don't think we made much progress with the actual
<br>
> implementation in Havana (would be good to fix this in Icehouse).
<br>
</font></tt>
<br><tt><font size=2>Thanks for the background.  I can still see the
etherpad, but the old summit proposal to which it points is gone.</font></tt>
<br>
<br><tt><font size=2>The etherpad proposes an API, and leaves open the
question of whether it backs onto a common service.  I think that
is a key question.  In my own group's work, this sort of information
is maintained in a shared database.  I'm not sure what is the right
approach for OpenStack.</font></tt>
<br>
<br><tt><font size=2>Thanks,</font></tt>
<br><tt><font size=2>Mike</font></tt>