Hi Clint,
Thanks for your reply. Please see inline.
Best RegardsLeslie
From: cl...@fewbar.com
To: openstack-dev@lists.openstack.org
Date: Sat, 28 Dec 2013 08:23:45 -0800
Subject: Re: [openstack-dev] [Spam] [TripleO] UnderCloud OverCloud
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.
Leslie - Nova API can add one option (latency sensitive or not) to aid
scheduler decision. If client is sensitive about latency for booting VM, it can
pass one parameter to specify booting VM immediately. Then scheduler can start
VM from running baremetal server. Otherwise, if client doesn't create latency,
scheduler can start new servers, then start VM on top.
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.
Leslie - agree.
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. :)
Leslie - understand. Roma is not build in the one day.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
