Open Stack

Hi Mike

We understand your point, and, academically, we agree to a large
extent. We aware of the optimization results for holistic placement
etc (and how any realistic formulation is hard). When we look at the
scheduler today, it does one thing at a time because it was meant to
be pragmatic when it was built.

Where we want to go is to move gradually to a point where some entity
knows 1) what to place where and 2) what order to place holistically
so we are saying the same thing!

Now how do we go there 'gradually'? A few of us decided that we can
1st do scheduling for a group of instance and then gradually extend it
to the kind of things you are mentioning.

My $0.02: A possible next step is to 1st tackle the problem of
intelligent placement as in 1) and leave 2) for later or the heat guys
since 1) is independent of 1). Since Openstack is a framework, it
might be useful to define a simple extensible API (least common
denominator) since everyone will have their opinion on how to do
define this (and extend it). We can use the scheduler subgroup to do
this.

We would ideally like to define the API that is cross services
compliant but works with the current Nova so that we can incrementally
build this out. In the final version, the API needs to specify
compute, network, storage, policies etc. I think templates might be
more heat or heat-like service specific.

Debo


On Wed, Sep 25, 2013 at 12:57 PM, Mike Spreitzer <mspreitz at us.ibm.com> wrote:
> Debo, Yathi: I have read
> https://docs.google.com/document/d/1IiPI0sfaWb1bdYiMWzAAx0HYR6UqzOan_Utgml5W1HI/edit?pli=1
> and most of the referenced materials, and I have a couple of big-picture
> questions.  That document talks about making Nova call out to something that
> makes the sort of smart decisions you and I favor.  As far as I know, Nova
> is still scheduling one thing at a time.  How does that smart decision maker
> get a look at the whole pattern/termplate/topology as soon as it is needed?
> I think you intend the smart guy gets it first, before Nova starts getting
> individual VM calls, right?  How does this picture grow to the point where
> the smart guy is making joint decisions about compute, storage, and network?
> I think the key idea has to be that the smart guy gets a look at the whole
> problem first, and makes its decisions, before any individual resources are
> requested from nova/cinder/neutron/etc.  I think your point about
> "non-disruptive, works with the current nova architecture" is about solving
> the problem of how the smart guy's decisions get into nova.  Presumably this
> problem will occur for cinder and so on, too.  Have I got this right?
>
> There is another way, right?  Today Nova accepts an 'availability zone'
> argument whose value can specify a particular host.  I am not sure about
> Cinder, but you can abuse volume types to get this job done.
>
> Thanks,
> Mike
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
-Debo~