Open Stack

Mike Spreitzer <mspreitz at us.ibm.com> wrote on 01/10/2013 06:58:10 AM:
> Alex Glikson <GLIKSON at il.ibm.com> wrote on 09/29/2013 03:30:35 PM:
> > Mike Spreitzer <mspreitz at us.ibm.com> wrote on 29/09/2013 08:02:00 PM:
> > 
> > > Another reason to prefer host is that we have other resources to 
> > > locate besides compute. 
> > 
> > Good point. Another approach (not necessarily contradicting) could 
> > be to specify the location as a property of host aggregate rather 
> > than individual hosts (and introduce similar notion in Cinder, and 
> > maybe Neutron). This could be an evolution/generalization of the 
> > existing 'availability zone' attribute, which would specify a more 
> > fine-grained location path (e.g., 
> > 'az_A:rack_R1:chassis_C2:node_N3'). We briefly discussed this 
> > approach at the previous summit (see 'simple implementation' under 
> > https://etherpad.openstack.org/HavanaTopologyAwarePlacement) -- but 
> > unfortunately I don't think we made much progress with the actual 
> > implementation in Havana (would be good to fix this in Icehouse). 
> 
> Thanks for the background.  I can still see the etherpad, but the 
> old summit proposal to which it points is gone. 

The proposal didn't have much details -- the main tool used at summit 
sessions is the etherpad.

> 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.

IMO, it does make sense to have a service which maintains the physical 
topology. Tuskar sounds like a good candidate. Then it can 'feed' 
Nova/Cinder/Neutron with the relevant aggregation entities (like host 
aggregates in Nova) and their attributes, to be used by the scheduler 
within each of them. Alternatively, this could be done by the 
administrator (manually, or using other tools).

Regards,
Alex

> 
> Thanks, 
> Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131001/e4b540b0/attachment.html>