[openstack-dev] [Spam] [TripleO] UnderCloud & OverCloud

Clint Byrum clint at fewbar.com
Sat Dec 28 16:23:45 UTC 2013


Excerpts from LeslieWang's message of 2013-12-24 19:19:52 -0800:
> Dear All,
> Merry Christmas & Happy New Year!
> I'm new in TripleO. After some investigation, I have one question on UnderCloud & OverCloud. Per my understanding, UnderCloud will pre-install and set up all baremetal servers used for OverCloud. Seems like it assumes all baremetal server should be installed in advance. Then my question is from green and elasticity point of view. Initially OverCloud should have zero baremetal server. Per user demands, OverCloud Nova Scheduler should decide if I need more baremetal server, then talk to UnderCloud to allocate more baremetal servers, which will use Heat to orchestrate baremetal server starts. Does it make senses? Does it already plan in the roadmap?
> If UnderCloud resources are created/deleted elastically, why not OverCloud talks to Ironic to allocate resource directly? Seems like it can achieve same goal. What else features UnderCloud will provide? Thanks in advance.
> Best RegardsLeslie                           

Having the overcloud scheduler ask for new servers would be pretty
interesting. It takes most large scale servers several minutes just to
POST though, so I'm not sure it is going to work out well if you care
about latency for booting VMs.

What might work is to use an auto-scaler in the undercloud though, perhaps
having it informed by the overcloud in some way for more granular policy
possibilities, but even just knowing how much RAM and CPU are allocated
across the compute nodes would help to inform us when it is time for
more compute nodes.

Also the scale-up is fun, but scaling down is tougher. One can only scale
down off nodes that have no more compute workloads. If you have live
migration then you can kick off live migration before scale down, but
in a highly utilized cluster I think that will be a net loss over time
as the extra load caused by a large scale live migration will outweigh
the savings from turning off machines. The story might be different for
a system built on network based volumes like CEPH,  I'm not sure.

Anyway, this is really interesting to think about, but it is not
something we're quite ready for yet. We're just getting to the point
of being able to deploy software updates using images, and then I hope
to focus on improving usage of Heat with rolling updates and the new
software config capabilities. After that it may be that we can look at
how to scale down a compute cluster automatically. :)



More information about the OpenStack-dev mailing list