Open Stack

On 10/23/2014 07:57 PM, Elzur, Uri wrote:
> Today, OpenStack makes placement decision mainly based on Compute
> demands (Scheduler is part of Nova). It also uses some info provided
> about platform’s Compute capabilities. But for a given application
> (consists of some VMs, some Network appliances, some storage etc),
> Nova/Scheduler has no way to figure out relative placement of Network
> devices (virtual appliances, SFC) and/or Storage devices (which is also
> network born in many cases) in reference to the Compute elements. This
> makes it harder to provide SLA, support certain policies (e.g. HA or
> keeping all of these elements within a physical boundary of your choice,
> or within a given network physical boundary and guarantee storage
> proximity, for example. It also makes it harder to optimize resource
> utilization level, which increases the cost and may cause Openstack to
> be less competitive on TCO.
>
> Another aspect of the issue, is that in order, to lower the cost per
> unit of compute (or said better per unit of Application), it is
> essential to pack tighter. This increases infrastructure utilization but
> also makes interference a more important phenomenon (aka Nosy neighbor).
> SLA requests, SLA guarantees and placement based on ability to provide
> desired SLA are required.
>
> We’d like to suggest moving a bit faster on making OpenStack a more
> compelling stack for Compute/Network/Storage, capable of supporting
> Telco/NFV and other usage models, and creating the foundation for
> providing very low cost platform, more competitive with large cloud
> deployment.

How do you suggest moving faster?

Also, when you say things like "more competitive with large cloud 
deployment" you need to tell us what you are comparing OpenStack to, and 
what cost factors you are using. Otherwise, it's just a statement with 
no context.

> The concern is that any scheduler change will take long time. Folks
> closer to the Scheduler work, have already pointed out we first need to
> stabilize the API between Nova and the Scheduler, before we can talk
> about a split (e.g. Gantt). So it may take till  late in 2016 (best
> case?), to get this kind of broader Application level functionality in
> the OpenStack scheduler .

I'm not entirely sure where late in 2016 comes from? Could you elaborate?

> We’d like to bring it up in the coming design summit. Where do you think
> it needs to be discussed: cross project tack? Scheduler discussion? Other?
>
> I’ve just added a proposed item 17.1 to the
> https://etherpad.openstack.org/p/kilo-crossproject-summit-topics
>
> 1.
>
> 2.“present Application’s Network and Storage requirements, coupled with
> infrastructure capabilities and status (e.g. up/dn

This is the kind of thing that was nixed as an idea last go around with 
the "nic-state-aware-scheduler":

https://review.openstack.org/#/c/87978/

You are coupling service state monitoring with placement decisions, and 
by doing so, you will limit the scale of the system considerably. We 
need improvements to our service state monitoring, for sure, including 
the ability to have much more fine-grained definition of what a service 
is. But I am 100% against adding the concept of checking service state 
*during* placement decisions.

Service state monitoring (it's called the servicegroup API in Nova) can 
and should notify the scheduler of important changes to the state of 
resource providers, but I'm opposed to making changes to the scheduler 
that would essentially make a placement decision and then immediately go 
and check a link for UP/DOWN state before "finalizing" the claim of 
resources on the resource provider.

> , utilization levels) and placement policy (e.g. proximity, HA)

I understand proximity (affinity/anti-affinity), but what does HA have 
to do with placement policy? Could you elaborate a bit more on that?

 > to get optimized placement
> decisions accounting for all application elements (VMs, virt Network
> appliances, Storage) vs. Compute only”

Yep. These are all simply inputs to the scheduler's placement decision 
engine. We need:

  a) A way of providing these inputs to the launch request without 
polluting a cloud user's view of the cloud -- remember we do NOT want 
users of the Nova API to essentially need to understand the exact layout 
of the cloud provider's datacenter. That's definitively anti-cloudy :) 
So, we need a way of providing generic inputs to the scheduler that the 
scheduler can translate into specific inputs because the scheduler would 
know the layout of the datacenter...

  b) Simple condition engine that would be able to understand the inputs 
(requested proximity to a storage cluster used by applications running 
in the instance, for example) with information the scheduler can query 
for about the topology of the datacenter's network and storage.

Work on b) involves the following foundational blueprints:

https://review.openstack.org/#/c/127609/
https://review.openstack.org/#/c/127610/
https://review.openstack.org/#/c/127612/

Looking forward to a cross-project or Nova session at the summit. Either 
would work for me, and I encourage you and others to response to this ML 
thread with thoughts about the scheduler and resource tracker space so I 
may summarize the thoughts on an etherpad before the summit.

All the best,
-jay