Re: [openstack-dev] [Congress] [Delegation] Meeting scheduling

2015-03-20 Thread Yathiraj Udupi (yudupi)
Hi Tim,

I think what you are saying is a reasonable goal in terms of high-level 
Congress policies not having to depend on the domain-specific solver / policy 
engines.  As long as there are Congress adapters to transform the user’s 
policies to something that domain-specific solver understands it will be fine.

With respect to delegation to solver scheduler, I agree that we need a 
combination of options (1) and (2).
For option (2), in order to leverage the pre-defined constraint classes in 
Solver Scheduler,  it is more like the Congress adapter notifying the Solver 
Scheduler to include that constraint as part of the current placement decision. 
  Also we have to take it to account that it is not just the user-defined 
Congress policies that define the placement choices,  the already existing 
infrastructure-specific constraints, in terms of Host capacities, or any other 
provider specific constraints will have to be included in the placement 
decision calculation by the solver.   The pre-configured scheduler/placement 
constraints will always have to be included.  But some additional policies from 
Congress can introduce additional constraints.

For option (1), new custom constraint class -  Solver Scheduler already has an 
interface BaseLinearConstraint - 
https://github.com/stackforge/nova-solver-scheduler/blob/master/nova/scheduler/solvers/linearconstraints/__init__.py
with methods -  get_coefficient_vectors, get_variable_vectors, and 
get_operations that will be invoked by the main solver class to feed in the 
variables, and the host metrics, along with some input parameters that used to 
get additional metadata that can be used to build matrices.  Eventually the 
main solver class builds the LP program by invoking all the classes.  So for 
the Congress delegation scenario, it will be along these lines, where the 
Congress adapter will have to populate these matrices based on the Datalog 
policy.   So as part of the solver scheduler’s workflow this special 
CongressConstraint class will have to call the Congress adapter with the 
variables already known, and get the necessary values.
For reference, an example implementation of this constraint class is here - 
https://github.com/stackforge/nova-solver-scheduler/blob/master/nova/scheduler/solvers/linearconstraints/max_disk_allocation_constraint.py

Will need some more thoughts, but the approach seems reasonable.

Thanks,
Yathi.



On 3/18/15, 8:34 AM, Tim Hinrichs 
thinri...@vmware.commailto:thinri...@vmware.com wrote:

I responded in the gdoc.  Here’s a copy.

One of my goals for delegation is to avoid asking people to write policy 
statements specific to any particular domain-specific solver.  People ought to 
encode policy however they like, and the system ought to figure out how best to 
enforce that policy  (delegation being one option).

Assuming that's a reasonable goal, I see two options for delegation to  
solverScheduler

(1) SolverScheduler exposes a custom constraint class.  Congress generates the 
LP program from the Datalog, similar to what is described in this doc, and 
gives that LP program as custom constraints to the  SolverScheduler.  
SolverScheduler is then responsible for enforcing that policy both during 
provisioning of new servers and for monitoring/migrating servers once 
provisioning is finished.

(2) The Congress adapter for SolverScheduler understands the semantics of 
MemoryCapacityConstraint, identifies when the user has asked for that 
constraint, and replaces that part of the LP program with the 
MemoryCapacityConstraint.

We probably want a combination of (1) and (2) so that we handle any gaps in the 
pre-defined constraints that SolverScheduler has, while at the same time 
leveraging the pre-defined constraints when possible.

Tim


On Mar 17, 2015, at 6:09 PM, Yathiraj Udupi (yudupi) 
yud...@cisco.commailto:yud...@cisco.com wrote:

Hi Tim,

I posted this comment on the doc.  I am still pondering over a possibility of 
have a policy-driven scheduler workflow via the Solver Scheduler placement 
engine, which is also LP based like you describe in your doc.
I know in your initial meeting, you plan to go over your proposal of building a 
VM placement engine that subscribes to the Congress DSE,  I probably will 
understand the Congress workflows better and see how I could incorporate this 
proposal to talk to the Solver Scheduler to make the placement decisions.

The example you provide in the doc, is a very good scenario, where a VM 
placement engine should continuously monitor and trigger VM migrations.

I am also interested in the case of a policy-driven scheduling for the initial 
creation of VMs. This is where say people will call Nova APIs and create a new 
set of VMs. Here the scheduler workflow should address the constraints as 
imposed from the user's policies.

Say the simple policy is  Host's free RAM = 0.25 * Memory_Capacity
I would like the scheduler to use this policy as defined from Congress, and 
apply

Re: [openstack-dev] [Congress] [Delegation] Meeting scheduling

2015-03-17 Thread Yathiraj Udupi (yudupi)
Hi Tim,

I posted this comment on the doc.  I am still pondering over a possibility of 
have a policy-driven scheduler workflow via the Solver Scheduler placement 
engine, which is also LP based like you describe in your doc.
I know in your initial meeting, you plan to go over your proposal of building a 
VM placement engine that subscribes to the Congress DSE,  I probably will 
understand the Congress workflows better and see how I could incorporate this 
proposal to talk to the Solver Scheduler to make the placement decisions.

The example you provide in the doc, is a very good scenario, where a VM 
placement engine should continuously monitor and trigger VM migrations.

I am also interested in the case of a policy-driven scheduling for the initial 
creation of VMs. This is where say people will call Nova APIs and create a new 
set of VMs. Here the scheduler workflow should address the constraints as 
imposed from the user's policies.

Say the simple policy is  Host's free RAM = 0.25 * Memory_Capacity
I would like the scheduler to use this policy as defined from Congress, and 
apply it during the scheduling as part of the Nova boot call.

I am really interested in and need help in coming up with a solution 
integrating Solver Scheduler, so say if I have an implementation of a 
MemoryCapacityConstraint, which takes a hint value free_memory_limit (0.25 
in this example),
could we have a policy in Datalog

placement_requirement(id) :-
nova:host(id),
solver_scheduler:applicable_constraints(id, [MemoryCapacityConstraint, ]),
applicable_metadata(id, {free_memory_limit: 0.25, })

This policy could be set and delegated by Congress to solver scheduler via the 
set_policy API. or the Solver Scheduler can query Congress via a get_policy 
API to get this policy, and incorporate it as part of the solver scheduler 
workflow ?

Does this sound doable ?

Thanks,
Yathi.



On 3/16/15, 11:05 AM, Tim Hinrichs 
thinri...@vmware.commailto:thinri...@vmware.com wrote:

Hi all,

The feedback on the POC delegation proposal has been mostly positive.  Several 
people have asked for a meeting to discuss further.  Given time zone 
constraints, it will likely be 8a or 9a Pacific.  Let me know in the next 2 
days if you want to participate, and we will try to find a day that everyone 
can attend.

https://docs.google.com/document/d/1ksDilJYXV-5AXWON8PLMedDKr9NpS8VbT0jIy_MIEtI/edit

Thanks!
Tim
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Congress] [Delegation] Meeting scheduling

2015-03-17 Thread Yathiraj Udupi (yudupi)
I will like to participate in the discussions.

Thanks,
Yathi.


On 3/16/15, 11:05 AM, Tim Hinrichs 
thinri...@vmware.commailto:thinri...@vmware.com wrote:

Hi all,

The feedback on the POC delegation proposal has been mostly positive.  Several 
people have asked for a meeting to discuss further.  Given time zone 
constraints, it will likely be 8a or 9a Pacific.  Let me know in the next 2 
days if you want to participate, and we will try to find a day that everyone 
can attend.

https://docs.google.com/document/d/1ksDilJYXV-5AXWON8PLMedDKr9NpS8VbT0jIy_MIEtI/edit

Thanks!
Tim
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Congress][Delegation] Initial workflow design

2015-02-27 Thread Yathiraj Udupi (yudupi)
) is :

Reading “host utilization” state from the data bases and DB (nova:host table) 
updates and overhead of maintaining in-memory state uptodate.

ð  This is expensive and current nova-scheduler does face this issue (many 
blogs/discussions).

  While the first goal is a PoC, this will likely become a concern in terms 
of adoption.



So you’re saying we won’t have fresh enough data to make policy decisions?  If 
the data changes so frequently that we can’t get an accurate view, then I’m 
guessing we shouldn’t be migrating based on that data anyway.

Could you point me to some of these discussions?


7)  While in this document you have changed the “example” policy, could we 
drill down the set of policies for the PoC (the server under utilization ?)


ð  As a reference

Sure.  The only reason I chose this policy was because it doesn’t have 
aggregation.  I’m guessing we’ll want to avoid aggregation for the POC because 
we don’t yet have it in Congress, and it complicates the problem of translating 
Datalog to LP substantially.

Tim

Ruby

De : Yathiraj Udupi (yudupi) [mailto:yud...@cisco.com]
Envoyé : mardi 24 février 2015 20:01
À : OpenStack Development Mailing List (not for usage questions); Tim Hinrichs
Cc : Debo Dutta (dedutta)
Objet : Re: [openstack-dev] [Congress][Delegation] Initial workflow design

Hi Tim,

Thanks for your updated doc on Delegation from Congress to a domain-specific 
policy engine, in this case, you are planning to build a LP-based VM-Placement 
engine to be the domain specific policy engine.
I agree your main goal is to first get the delegation interface sorted out.  It 
will be good so that external services (like Solver-Scheduler) can also easily 
integrate to the delegation model.

From the Solver-Scheduler point of view,  we would actually want to start 
working on a PoC effort to start integrating Congress and the Solver-Scheduler.
We believe rather than pushing this effort to a long-term,  it would add value 
to both the Solver Scheduler effort, as well as the Congress effort to try some 
early integration now, as most of the LP solver work for VM placements is ready 
available now in Solver scheduler, and we need to spend some time thinking 
about translating your domain-agnostic policy to constraints that the Solver 
scheduler can use.

I would definitely need your help from the Congress interfaces and I hope you 
will share your early interfaces for the delegation, so I can start the effort 
from the Solver scheduler side for integration.
I will reach out to you to get some initial help for integration w.r.t. 
Congress, and also keep you posted about the progress from our side.

Thanks,
Yathi.



On 2/23/15, 11:28 AM, Tim Hinrichs 
thinri...@vmware.commailto:thinri...@vmware.com wrote:


Hi all,



I made a heavy editing pass of the Delegation google doc, incorporating many of 
your comments and my latest investigations into VM-placement.  I left the old 
stuff in place at the end of the doc and put the new stuff at the top.



My goal was to propose an end-to-end workflow for a PoC that we could put 
together quickly to help us explore the delegation interface.  We should 
iterate on this design until we have something that we think is workable.   And 
by all means pipe up if you think we need a totally different starting point to 
begin the iteration.



(BTW I'm thinking of the integration with solver-scheduler as a long-term 
solution to VM-placement, once we get the delegation interface sorted out.)



https://docs.google.com/document/d/1ksDilJYXV-5AXWON8PLMedDKr9NpS8VbT0jIy_MIEtI/edit#https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1ksDilJYXV-2D5AXWON8PLMedDKr9NpS8VbT0jIy-5FMIEtI_editd=AwMFAwc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=B6BWd4kFfgOzAREgThxkmTZKy7dDXE2-eBAmL0PBK7sm=kF8jMOpogOhk8MJWvNMKJC3PiNImxWpZeD2o642YM2ss=8PV5EW-kz8Q9aP9riFbIjJXJNZXchx2NsL-Z3Y7E5Vge=



Tim

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you

Re: [openstack-dev] [Congress][Delegation] Google doc for working notes

2015-02-13 Thread Yathiraj Udupi (yudupi)
Hi Tim,

Glad to collaborate and work towards nailing down the details.  Yeah in terms 
of policy enforcement from Congress, it makes sense to delegate to  
domain-specific policy engines.  It will be good to go through this PoC and to 
start thinking about the integration points of Congress with Solver scheduler, 
with a good set of APIs supported from both sides.

Some more comments inline to your questions:

On 2/13/15, 9:35 AM, Tim Hinrichs 
thinri...@vmware.commailto:thinri...@vmware.com wrote:

Hi Debo and Yathi,

We’re completely on the same page here.  We’ve known about the solver-scheduler 
for a while now (I even attended your Atlanta talk), and I always expected 
Congress would integrate with it.  As you say, now it’s a matter of getting 
down to the details.

A bit on the context…  The current problem we’re working on in Congress is how 
we might delegate responsibility for policy enforcement to domain-specific 
policy engines, and a number of people were interested in integrating with a 
VM-placement engine.  We started looking at the solver-scheduler (the obvious 
first choice), hence this dialog.  The notes in the google doc are just me 
trying to understand the problem of delegation to a VM-placement engine by 
working through the problem end-to-end.  (I’ve not worked with LP or 
VM-placement much, so my notes are there to help me grapple a bit with the 
domain for the first time.)  How we build a PoC is something we haven’t started 
to discuss.  So you’re joining the discussion at the right time.  The more of 
that PoC we can build by leveraging solver-scheduler, the better.

More detailed comments inline.


On Feb 13, 2015, at 5:05 AM, Debojyoti Dutta 
ddu...@gmail.commailto:ddu...@gmail.com wrote:

Tim

Wanted to clarify a bit. As I have mentioned before: Solver scheduler is work 
done before this work (Datalog-constraints) but we had kept it very 
generic to be integrated with something like congress. In fact Ramki (who was 
one of the members of the original thread when you reached out to us) joined us 
to in talk in Atlanta where we described some of the same use cases using PULP 
 congress was still ramping up then. We were not aware of the 
Datalog-constraints work that you guys were doing, else we would have joined 
hands before.

The question is this: going forward, how do build this cool stuff together in 
the community? I am hoping the scheduler folks will be very excited too!

debo

On Thu, Feb 12, 2015 at 11:27 AM, Yathiraj Udupi (yudupi) 
yud...@cisco.commailto:yud...@cisco.com wrote:
Hi Tim,

Thanks for your response.  Excited too to extend the collaboration and ensure 
there is no need to duplicate effort in the open source community.
 My responses inline.

1)  Choice of LP solver.

I see solver-scheduler uses Pulp, which was on the Congress short list as well. 
 So we’re highly aligned on the choice of underlying solver.

YATHI - This makes me wonder why can’t we easily adapt the solver-scheduler to 
your needs, rather than duplicating the effort!


My primary goal is to build an architecture that makes it easy to integrate 
with domain-specific policy engines (like compute or networking).

What I’m also hearing is that people are interested in building *new* 
domain-specific policy engines within the Congress framework and/or expanding 
the functionality of the Congress policy engine itself to include optimization 
technology.  In both cases, we would need a library for solving optimization 
problems.  Oliver (CC’ed) has proposed adding such a library to Congress.  
Solver-scheduler already has such a library, so it would be great if we could 
all brainstorm about how to make optimization technology easy to use for people 
writing domain-specific policy engines, without reinventing the wheel.

https://blueprints.launchpad.net/congress/+spec/rule-x

YATHI: It is an interesting thought in this direction.  However it is good to 
build an architecture with easy integration of Congress to separate 
domain-specific engines in compute, networking, and storage.I feel some of 
these policy validation/enforcement workflows are sometimes best within the 
domain-specific engines like VM placement/scheduling for example.   But 
definitely optimization technology is a good choice for this kind of problems.



2) User control over VM-placement.


To choose the criteria for VM-placement, the solver-scheduler user picks from a 
list of predefined options, e.g. ActiveHostConstraint, 
MaxRamAllocationPerHostConstraint.

We’re investigating a slightly different approach, where the user defines the 
criteria for VM-placement by writing any policy they like in Datalog.  Under 
the hood we then convert that Datalog to an LP problem.  From the developer’s 
perspective, with the Congress approach we don’t attempt to anticipate the 
different policies the user might want and write code for each policy; instead, 
we as developers write a translator from Datalog to LP.  From the user’s

Re: [openstack-dev] [Congress][Delegation] Google doc for working notes

2015-02-12 Thread Yathiraj Udupi (yudupi)
 at the solver-scheduler docs and code with your comments in 
mind.  A few things jumped out.





2) User control over VM-placement.

Tim


On Feb 11, 2015, at 4:50 PM, Debojyoti Dutta 
ddu...@gmail.commailto:ddu...@gmail.com wrote:

Hi Tim: moving our thread to the mailer. Excited to collaborate!



From: Debo~ Dutta dedu...@cisco.commailto:dedu...@cisco.com
Date: Wednesday, February 11, 2015 at 4:48 PM
To: Tim Hinrichs thinri...@vmware.commailto:thinri...@vmware.com
Cc: Yathiraj Udupi (yudupi) yud...@cisco.commailto:yud...@cisco.com, 
Gokul B Kandiraju go...@us.ibm.commailto:go...@us.ibm.com, Prabhakar Kudva 
ku...@us.ibm.commailto:ku...@us.ibm.com, 
ruby.krishnasw...@orange.commailto:ruby.krishnasw...@orange.com 
ruby.krishnasw...@orange.commailto:ruby.krishnasw...@orange.com, 
dilik...@in.ibm.commailto:dilik...@in.ibm.com 
dilik...@in.ibm.commailto:dilik...@in.ibm.com, Norival Figueira 
nfigu...@brocade.commailto:nfigu...@brocade.com, Ramki Krishnan 
r...@brocade.commailto:r...@brocade.com, Xinyuan Huang (xinyuahu) 
xinyu...@cisco.commailto:xinyu...@cisco.com, Rishabh Jain -X (rishabja - 
AAP3 INC at Cisco) risha...@cisco.commailto:risha...@cisco.com
Subject: Re: Nova solver scheduler and Congress

Hi Tim

To address your particular questions:

  1.  translate some policy language into constraints for the LP/CVP and we had 
left that to congress hoping to integrate when the policy efforts in openstack 
were ready (our initial effort was pre congress)
  2.  For migrations: we are currently doing that – its about incremental 
constraints into the same solver. Hence its a small deal ….

Joining forces is a terrific idea. Would love to join the IRC call and see how 
we can build cool stuff in the community together. I hope we don’t have to 
replicate the vm placement engine while the work that was done in the community 
does something very similar (and be adapted)

debo

From: Tim Hinrichs thinri...@vmware.commailto:thinri...@vmware.com
Date: Wednesday, February 11, 2015 at 4:43 PM
To: Debo~ Dutta dedu...@cisco.commailto:dedu...@cisco.com
Cc: Yathiraj Udupi (yudupi) yud...@cisco.commailto:yud...@cisco.com, 
Gokul B Kandiraju go...@us.ibm.commailto:go...@us.ibm.com, Prabhakar Kudva 
ku...@us.ibm.commailto:ku...@us.ibm.com, 
ruby.krishnasw...@orange.commailto:ruby.krishnasw...@orange.com 
ruby.krishnasw...@orange.commailto:ruby.krishnasw...@orange.com, 
dilik...@in.ibm.commailto:dilik...@in.ibm.com 
dilik...@in.ibm.commailto:dilik...@in.ibm.com, Norival Figueira 
nfigu...@brocade.commailto:nfigu...@brocade.com, Ramki Krishnan 
r...@brocade.commailto:r...@brocade.com, Xinyuan Huang (xinyuahu) 
xinyu...@cisco.commailto:xinyu...@cisco.com, Rishabh Jain -X (rishabja - 
AAP3 INC at Cisco) risha...@cisco.commailto:risha...@cisco.com
Subject: Re: Nova solver scheduler and Congress

Hi Debo,

The 2 efforts share great similarities, which was why we investigated the state 
of solver-scheduler.  From what I understand, (i) solver-scheduler doesn’t 
currently have a policy language and (ii) it doesn’t do migrations.  (I realize 
these are both in the works.)  We needed both and wanted to make progress 
before those were complete.

In the long run, it may make perfect sense to replace our vm-placement engine 
with yours.  So joining forces sounds like a good idea.  At the very *least* we 
ought to keep up to date with each other’s progress.

I’m starting to wonder if we ought to schedule a (bi-) weekly IRC for this 
topic.

Tim

On Feb 11, 2015, at 4:35 PM, Debo Dutta (dedutta) 
dedu...@cisco.commailto:dedu...@cisco.com wrote:

Hi Tim

This looks awesome. Trying to figure out how this approach is different from 
the solver scheduler effort we did? We would be happy to fold our solver 
scheduler effort into this (that way you also get code up and running)

Will also respond on the thread.

thx
debo

From: Tim Hinrichs thinri...@vmware.commailto:thinri...@vmware.com
Date: Wednesday, February 11, 2015 at 4:11 PM
To: Yathiraj Udupi (yudupi) yud...@cisco.commailto:yud...@cisco.com
Cc: Gokul B Kandiraju go...@us.ibm.commailto:go...@us.ibm.com, Prabhakar 
Kudva ku...@us.ibm.commailto:ku...@us.ibm.com, 
ruby.krishnasw...@orange.commailto:ruby.krishnasw...@orange.com 
ruby.krishnasw...@orange.commailto:ruby.krishnasw...@orange.com, 
dilik...@in.ibm.commailto:dilik...@in.ibm.com 
dilik...@in.ibm.commailto:dilik...@in.ibm.com, Norival Figueira 
nfigu...@brocade.commailto:nfigu...@brocade.com, Ramki Krishnan 
r...@brocade.commailto:r...@brocade.com, Xinyuan Huang (xinyuahu) 
xinyu...@cisco.commailto:xinyu...@cisco.com, Rishabh Jain -X (rishabja - 
AAP3 INC at Cisco) risha...@cisco.commailto:risha...@cisco.com, Debo~ 
Dutta dedu...@cisco.commailto:dedu...@cisco.com
Subject: Re: Nova solver scheduler and Congress

Hi Yathiraj,

The group is getting big enough that we’ve decided to move the entire 
discussion to the openstack-dev mailing list.  I sent a note today with the 
google doc we’re working on.  We’re trying to include [Congress

Re: [openstack-dev] [Congress] Re: Placement and Scheduling via Policy

2014-12-16 Thread Yathiraj Udupi (yudupi)
Tim,

I read the conversation thread below and this got me interested as it relates 
to our discussion we had in the Policy Summit (mid cycle meet up) held in Palo 
Alto a few months ago.

This relates to our project – Nova Solver Scheduler, which I had talked about 
at the Policy summit.   Please see this - 
https://github.com/stackforge/nova-solver-scheduler

We already have a working constraints-based solver framework/engine that 
handles Nova placement, and we are currently active in Stackforge, and aim to 
get this integrated into the Gantt project 
(https://blueprints.launchpad.net/nova/+spec/solver-scheduler), based on our 
discussions in the Nova scheduler sub group.

When I saw discussions around using Linear programming (LP) solvers, PULP, etc, 
 I thought of pitching in here to say, we already have demonstrated integrating 
a LP based solver for Nova compute placements.   Please see: 
https://www.youtube.com/watch?v=7QzDbhkk-BI#t=942 for a demo of this (from our 
talk at the Atlanta Openstack summit).
 Based on this email thread,  I believe Ramki, one of our early collaborators 
is driving a similar solution in the NFV ETSI research group.  Glad to know our 
Solver scheduler project is getting interest now.

As part of Congress integration,  at the policy summit, I had suggested, we can 
try to translate a Congress policy into our Solver Scheduler’s constraints,  
and use this to enforce Nova placement policies.
We can already demonstrate policy-driven nova placements using our pluggable 
constraints model.  So it should be easy to integrate with Congress.

The Nova solver scheduler team would be glad to help with any efforts wrt to 
trying out a Congress integration for Nova placements.

Thanks,
Yathi.



On 12/16/14, 10:24 AM, Tim Hinrichs 
thinri...@vmware.commailto:thinri...@vmware.com wrote:

[Adding openstack-dev to this thread.  For those of you just joining… We 
started kicking around ideas for how we might integrate a special-purpose VM 
placement engine into Congress.]

Kudva: responses inline.


On Dec 16, 2014, at 6:25 AM, Prabhakar Kudva 
ku...@us.ibm.commailto:ku...@us.ibm.com wrote:

Hi,

I am very interested in this.

So, it looks like there are two parts to this:
1. Policy analysis when there are a significant mix of logical and builtin 
predicates (i.e.,
runtime should identify a solution space when there are arithmetic operators). 
This will
require linear programming/ILP type solvers.  There might be a need to have a 
function
in runtime.py that specifically deals with this (Tim?)


I think it’s right that we expect there to be a mix of builtins and standard 
predicates.  But what we’re considering here is having the linear solver be 
treated as if it were a domain-specific policy engine.  So that solver wouldn’t 
be embedded into the runtime.py necessarily.  Rather, we’d delegate part of the 
policy to that domain-specific policy engine.

2. Enforcement. That is with a large number of constraints in place for 
placement and
scheduling, how does the policy engine communicate and enforce the placement
constraints to nova scheduler.


I would imagine that we could delegate either enforcement or monitoring or 
both.  Eventually we want enforcement here, but monitoring could be useful too.

And yes you’re asking the right questions.  I was trying to break the problem 
down into pieces in my bullet (1) below.  But I think there is significant 
overlap in the questions we need to answer whether we’re delegating monitoring 
or enforcement.

Both of these require some form of mathematical analysis.

Would be happy and interested to discuss more on these lines.


Maybe take a look at how I tried to breakdown the problem into separate 
questions in bullet (1) below and see if that makes sense.

Tim

Prabhakar






From:Tim Hinrichs thinri...@vmware.commailto:thinri...@vmware.com
To:ruby.krishnasw...@orange.commailto:ruby.krishnasw...@orange.com 
ruby.krishnasw...@orange.commailto:ruby.krishnasw...@orange.com
Cc:Ramki Krishnan (r...@brocade.commailto:r...@brocade.com) 
r...@brocade.commailto:r...@brocade.com, Gokul B 
Kandiraju/Watson/IBM@IBMUS, Prabhakar Kudva/Watson/IBM@IBMUS
Date:12/15/2014 12:09 PM
Subject:Re: Placement and Scheduling via Policy




[Adding Prabhakar and Gokul, in case they are interested.]

1) Ruby, thinking about the solver as taking 1 matrix of [vm, server] and 
returning another matrix helps me understand what we’re talking about—thanks.  
I think you’re right that once we move from placement to optimization problems 
in general we’ll need to figure out how to deal with actions.  But if it’s a 
placement-specific policy engine, then we can build VM-migration into it.

It seems to me that the only part left is figuring out how to take an arbitrary 
policy, carve off the placement-relevant portion, and create the inputs the 
solver needs to generate that new matrix.  Some thoughts...

- My 

Re: [openstack-dev] [Congress] Re: Placement and Scheduling via Policy

2014-12-16 Thread Yathiraj Udupi (yudupi)
To add to what I mentioned below… We from the Solver Scheduler team are a small 
team here at Cisco, trying to drive this project and slowly adding more complex 
use cases for scheduling and policy–driven placements.We would really love 
to have some real contributions from everyone in the community and build this 
the right way.
If it may interest – some interesting scheduler use cases are here based on one 
of our community meetings in IRC - 
https://etherpad.openstack.org/p/SchedulerUseCases  This could apply to 
Congress driving some of this too.

I am leading the effort for the  Solver Scheduler project ( 
https://github.com/stackforge/nova-solver-scheduler ) , and if any of you are 
willing to contribute code, API, benchmarks, and also work on integration, my 
team and I can help you guide through this.   We would be following the same 
processes under Stackforge at the moment.

Thanks,
Yathi.





On 12/16/14, 11:14 AM, Yathiraj Udupi (yudupi) 
yud...@cisco.commailto:yud...@cisco.com wrote:

Tim,

I read the conversation thread below and this got me interested as it relates 
to our discussion we had in the Policy Summit (mid cycle meet up) held in Palo 
Alto a few months ago.

This relates to our project – Nova Solver Scheduler, which I had talked about 
at the Policy summit.   Please see this - 
https://github.com/stackforge/nova-solver-scheduler

We already have a working constraints-based solver framework/engine that 
handles Nova placement, and we are currently active in Stackforge, and aim to 
get this integrated into the Gantt project 
(https://blueprints.launchpad.net/nova/+spec/solver-scheduler), based on our 
discussions in the Nova scheduler sub group.

When I saw discussions around using Linear programming (LP) solvers, PULP, etc, 
 I thought of pitching in here to say, we already have demonstrated integrating 
a LP based solver for Nova compute placements.   Please see: 
https://www.youtube.com/watch?v=7QzDbhkk-BI#t=942 for a demo of this (from our 
talk at the Atlanta Openstack summit).
 Based on this email thread,  I believe Ramki, one of our early collaborators 
is driving a similar solution in the NFV ETSI research group.  Glad to know our 
Solver scheduler project is getting interest now.

As part of Congress integration,  at the policy summit, I had suggested, we can 
try to translate a Congress policy into our Solver Scheduler’s constraints,  
and use this to enforce Nova placement policies.
We can already demonstrate policy-driven nova placements using our pluggable 
constraints model.  So it should be easy to integrate with Congress.

The Nova solver scheduler team would be glad to help with any efforts wrt to 
trying out a Congress integration for Nova placements.

Thanks,
Yathi.



On 12/16/14, 10:24 AM, Tim Hinrichs 
thinri...@vmware.commailto:thinri...@vmware.com wrote:

[Adding openstack-dev to this thread.  For those of you just joining… We 
started kicking around ideas for how we might integrate a special-purpose VM 
placement engine into Congress.]

Kudva: responses inline.


On Dec 16, 2014, at 6:25 AM, Prabhakar Kudva 
ku...@us.ibm.commailto:ku...@us.ibm.com wrote:

Hi,

I am very interested in this.

So, it looks like there are two parts to this:
1. Policy analysis when there are a significant mix of logical and builtin 
predicates (i.e.,
runtime should identify a solution space when there are arithmetic operators). 
This will
require linear programming/ILP type solvers.  There might be a need to have a 
function
in runtime.py that specifically deals with this (Tim?)


I think it’s right that we expect there to be a mix of builtins and standard 
predicates.  But what we’re considering here is having the linear solver be 
treated as if it were a domain-specific policy engine.  So that solver wouldn’t 
be embedded into the runtime.py necessarily.  Rather, we’d delegate part of the 
policy to that domain-specific policy engine.

2. Enforcement. That is with a large number of constraints in place for 
placement and
scheduling, how does the policy engine communicate and enforce the placement
constraints to nova scheduler.


I would imagine that we could delegate either enforcement or monitoring or 
both.  Eventually we want enforcement here, but monitoring could be useful too.

And yes you’re asking the right questions.  I was trying to break the problem 
down into pieces in my bullet (1) below.  But I think there is significant 
overlap in the questions we need to answer whether we’re delegating monitoring 
or enforcement.

Both of these require some form of mathematical analysis.

Would be happy and interested to discuss more on these lines.


Maybe take a look at how I tried to breakdown the problem into separate 
questions in bullet (1) below and see if that makes sense.

Tim

Prabhakar






From:Tim Hinrichs thinri...@vmware.commailto:thinri...@vmware.com
To:ruby.krishnasw...@orange.commailto:ruby.krishnasw...@orange.com 
ruby.krishnasw

[openstack-dev] [Nova][Spec freeze exception] Solver Scheduler spec

2014-07-18 Thread Yathiraj Udupi (yudupi)
Hi Nova cores,

I would like to request a spec proposal extension for Solver Scheduler 
described here in this spec:  https://review.openstack.org/#/c/96543/.
This blueprint:  https://blueprints.launchpad.net/nova/+spec/solver-scheduler 
has been discussed for a long time now since HKG summit, where it was demoed 
first and got the initial interest from core sponsors such as Joe Gordon.
Several patches were submitted as part of Icehouse time frame, when it was an 
approved blueprint, but had missed the feature freeze deadline.  Now for Juno, 
we had to re-submit this as a spec.

Now the NFV community has also expressed interest in this, as there are several 
NFV related use cases, which might benefit from having this constraint-based 
scheduling framework for addressing complex and cross-service scenarios.

I hope this spec can get merged in Juno at least, so that we can merge the 
basic pluggable scheduler driver, and a pluggable solver module.  The 
additional pluggable modules can be added and merged later on to address the 
various constraint scenarios, if it is going to be hard to get reviewed and 
merged in Juno.

This being a pluggable driver, will be non-disruptive to Nova, and can easily 
fit within Gantt as well.

I would like to request the attention of cores Joe Gordon, and Johnthetubaguy 
to for being sponsors, as they have initially shared their interest and 
feedback on this blueprint in the Icehouse timeframe.

Thanks,
Yathi.

On 7/16/14, 4:52 PM, Yathiraj Udupi (yudupi) 
yud...@cisco.commailto:yud...@cisco.com wrote:

Hi Nova cores,

I would like to request a spec freeze exception for our spec on Solver 
Scheduler – a constraint based scheduler framework.
Please see the spec here: https://review.openstack.org/#/c/96543/   -  
https://review.openstack.org/#/c/96543/10/specs/juno/solver-scheduler.rst

This is for the blueprint: 
https://blueprints.launchpad.net/nova/+spec/solver-scheduler.

Our working and tested code is currently available at this project repository:  
https://github.com/CiscoSystems/nova-solver-scheduler
This feature would integrate easily with Nova or the split out scheduler Gantt. 
 This would be non-disruptive as it is a pluggable scheduler driver.

This blueprint was approved for Icehouse, and a lot of code patches were 
submitted as part of the Icehouse time frame.  It had missed the feature freeze 
deadline then.  And now for Juno we have had to re-submit it here as a 
nova-spec for review.

The first code patch with the basic framework, the SolverScheduler driver  - 
https://review.openstack.org/#/c/46588/ has already gone through several 
iterations of code reviews as part of Icehouse, and will need minimal changes 
now.  The other dependent  patches that are already submitted add additional 
features in terms of a pluggable Solver that supports pluggable constraints and 
costs.

We had demoed a few use cases already in HongKong using our constraint-based 
scheduling framework addressing the cross-service constraint scenarios:
  - Compute – Storage affinity,  where we can schedule a VM on or close to a 
Volume node.

We have also seen a lot of interest from the NFV community, in terms of 
addressing the complex NFV related use cases using our constraints solving 
framework for making optimal placement decisions
Please see our NFV talk and demo in the Atlanta summit:   
https://www.youtube.com/watch?v=7QzDbhkk-BI Slides: 
http://www.slideshare.net/ybudupi/optimized-nfv-placement-in-openstack-clouds

Hope you will honor this request, and help us take this effort forward.

Thanks,
Yathi.









___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Nova][Scheduler] Requesting spec freeze exception: Smart (Solver) Scheduler spec

2014-07-16 Thread Yathiraj Udupi (yudupi)
Hi Nova cores,

I would like to request a spec freeze exception for our spec on Solver 
Scheduler – a constraint based scheduler framework.
Please see the spec here: https://review.openstack.org/#/c/96543/   -  
https://review.openstack.org/#/c/96543/10/specs/juno/solver-scheduler.rst

This is for the blueprint: 
https://blueprints.launchpad.net/nova/+spec/solver-scheduler.

Our working and tested code is currently available at this project repository:  
https://github.com/CiscoSystems/nova-solver-scheduler
This feature would integrate easily with Nova or the split out scheduler Gantt. 
 This would be non-disruptive as it is a pluggable scheduler driver.

This blueprint was approved for Icehouse, and a lot of code patches were 
submitted as part of the Icehouse time frame.  It had missed the feature freeze 
deadline then.  And now for Juno we have had to re-submit it here as a 
nova-spec for review.

The first code patch with the basic framework, the SolverScheduler driver  - 
https://review.openstack.org/#/c/46588/ has already gone through several 
iterations of code reviews as part of Icehouse, and will need minimal changes 
now.  The other dependent  patches that are already submitted add additional 
features in terms of a pluggable Solver that supports pluggable constraints and 
costs.

We had demoed a few use cases already in HongKong using our constraint-based 
scheduling framework addressing the cross-service constraint scenarios:
  - Compute – Storage affinity,  where we can schedule a VM on or close to a 
Volume node.

We have also seen a lot of interest from the NFV community, in terms of 
addressing the complex NFV related use cases using our constraints solving 
framework for making optimal placement decisions
Please see our NFV talk and demo in the Atlanta summit:   
https://www.youtube.com/watch?v=7QzDbhkk-BI Slides: 
http://www.slideshare.net/ybudupi/optimized-nfv-placement-in-openstack-clouds

Hope you will honor this request, and help us take this effort forward.

Thanks,
Yathi.









___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Nova] [Gantt][Scheduler-split] Why we need a Smart Placement Engine as a Service! (was: Scheduler split status (updated))

2014-07-14 Thread Yathiraj Udupi (yudupi)
Hi all,

Adding to the interesting discussion thread regarding the scheduler split and 
its importance, I would like to pitch in a couple of thoughts in favor of 
Gantt.  It was in the Icehouse summit in HKG in one of the scheduler design 
sessions, I along with a few others (cc’d) pitched a session on Smart Resource 
Placement 
(https://etherpad.openstack.org/p/NovaIcehouse-Smart-Resource-Placement), where 
we pitched for a  Smart Placement Decision Engine  as a Service , addressing 
cross-service scheduling as one of the use cases.  We pitched the idea as to 
how a stand-alone service can act as a  smart resource placement engine, (see 
figure: 
https://docs.google.com/drawings/d/1BgK1q7gl5nkKWy3zLkP1t_SNmjl6nh66S0jHdP0-zbY/edit?pli=1)
 that can use state data from all the services, and make a unified placement 
decision.   We even have proposed a separate blueprint 
(https://blueprints.launchpad.net/nova/+spec/solver-scheduler with working code 
now here: https://github.com/CiscoSystems/nova-solver-scheduler) called Smart 
Scheduler (Solver Scheduler), which has the goals of being able to do smart 
resource placement taking into account complex constraints incorporating 
compute(nova), storage(cinder), and network constraints.   The existing Filter 
Scheduler or the projects like Smart (Solver) Scheduler (for covering the 
complex constraints scenarios) could easily fulfill the decision making aspects 
of the placement engine.

I believe the Gantt project is the right direction in terms of separating out 
the placement decision concern, and creating a separate scheduler as a service, 
so that it can freely talk to any of the other services, or use a unified 
global state repository and make the unified decision.  Projects like 
Smart(Solver) Scheduler can easily fit into the Gantt Project as pluggable 
drivers to add the additional smarts required.

To make our Smart Scheduler as a service, we currently have prototyped this 
Scheduler as a service providing a RESTful interface to the smart scheduler, 
that is detached from Nova (loosely connected):
For example a RESTful request like this (where I am requests for 2 Vms, with a 
requirement of 1 GB disk, and another request for 1 Vm of flavor ‘m1.tiny’, but 
also has a special requirement that it should be close to the volume with uuid: 
“ef6348300bc511e4bc4cc03fd564d1bc (Compute-Volume affinity constraint)) :


curl -i -H Content-Type: application/json -X POST -d '{instance_requests: 
[{num_instances: 2, request_properties: {instance_type: {root_gb: 1}}}, 
{num_instances: 1, request_properties: {flavor: m1.tiny”, 
“volume_affinity: ef6348300bc511e4bc4cc03fd564d1bc}}]}' 
http://x.x.x.x/smart-scheduler-as-a-service/v1.0/placement


provides a placement decision something like this:

{

  result: [

[

  {

host: {

  host: Host1,

  nodename: Node1

},

instance_uuid: VM_ID_0_0

  },

  {

host: {

  host: Host2,

  nodename: Node2

},

instance_uuid: VM_ID_0_1

  }

],

[

  {

host: {

  host: Host1,

  nodename: Node1

},

instance_uuid: VM_ID_1_0

  }

]

  ]

}


This placement result can be used by Nova to proceed and complete the 
scheduling.


This is where I see the potential for Gantt, which will be a stand alone 
placement decision engine, and can easily accommodate different pluggable 
engines (such as Smart Scheduler 
(https://blueprints.launchpad.net/nova/+spec/solver-scheduler))  to do smart 
placement decisions.


Pointers:
Smart Resource Placement overview: 
https://docs.google.com/document/d/1IiPI0sfaWb1bdYiMWzAAx0HYR6UqzOan_Utgml5W1HI/edit?pli=1
Figure: 
https://docs.google.com/drawings/d/1BgK1q7gl5nkKWy3zLkP1t_SNmjl6nh66S0jHdP0-zbY/edit?pli=1
Nova Design Session Etherpad: 
https://etherpad.openstack.org/p/NovaIcehouse-Smart-Resource-Placement
https://etherpad.openstack.org/p/IceHouse-Nova-Scheduler-Sessions
Smart Scheduler Blueprint: 
https://blueprints.launchpad.net/nova/+spec/solver-scheduler
Working code: https://github.com/CiscoSystems/nova-solver-scheduler



Thanks,

Yathi.





On 7/14/14, 1:40 PM, Murray, Paul (HP Cloud) 
pmur...@hp.commailto:pmur...@hp.com wrote:

Hi All,

I’m sorry I am so late to this lively discussion – it looks a good one! Jay has 
been driving the debate a bit so most of this is in response to his comments. 
But please, anyone should chip in.

On extensible resource tracking

Jay, I am surprised to hear you say no one has explained to you why there is an 
extensible resource tracking blueprint. It’s simple, there was a succession of 
blueprints wanting to add data about this and that to the resource tracker and 
the scheduler and the database tables used to communicate. These included 
capabilities, all the stuff in the stats, rxtx_factor, the equivalent for cpu 
(which only works on one hypervisor I think), pci_stats and more were coming 

Re: [openstack-dev] NFV in OpenStack use cases and context

2014-06-16 Thread Yathiraj Udupi (yudupi)
Hi Sylvain, 

The Smart Scheduler work should work along withGantt easily, as it is just
another scheduler driver, instead of using the Filters, it will have a
separate mechanism of solving the placement problem all at once.
So just like how it currently works along with Nova scheduler, it should
easily be integrated into Gantt, is what I would imagine. I have not
looked very closely at the Gantt work, but I assume if you claim, no
behavior changes in Gantt, and if you are continuing to use
FilterScheduler, SmartScheduler should fit in too.

I will try to update the nova-spec ([1]
https://review.openstack.org/#/c/96543/) for Smart Scheduler, and let the
review continue sometime soon.

Thanks,
Yathi. 



On 6/13/14, 12:37 AM, Sylvain Bauza sba...@redhat.com wrote:

Hi Yathi,

Le 12/06/2014 20:53, Yathiraj Udupi (yudupi) a écrit :
 Hi Alan, 

 Our Smart (Solver) Scheduler blueprint
 (https://blueprints.launchpad.net/nova/+spec/solver-scheduler ) has been
 in the works in the Nova community since late 2013.  We have demoed at
the
 Hong Kong summit, as well as the Atlanta summit,  use cases using this
 smart scheduler for better, optimized resource placement with complex
 constrained scenarios.  So to let you know this work was started as a
 smart way of doing scheduling, applicable in general and not limited to
 NFV.  Currently we feel NFV is a killer app for driving this blueprint
and
 work ahead, however is applicable for all kinds of resource placement
 scenarios. 

 We will be very interested in finding out more about your blueprints
that
 you are referring to here, and see how it can be integrated as part of
our
 future roadmap. 

Indeed, Smart Scheduler is something that could help NFV use-cases. My
only concern is about the necessary steps for providing such a feature,
with regards to the scheduler breakout that is coming.

Could you please make sure the current nova-spec [1] is taking in
account all other efforts about the scheduler, like scheduler forklift
[2], on-demand resource reporting [3] or others ? It also seems the spec
is not following the defined template, could you please fix it ? It
would be easier to review your proposal.

Gantt and Nova scheduler teams are attending a weekly meeting every
Tuesday at 3pm UTC. Would you have a chance to join, it would be great
to discuss about your proposal and how we can identify all the
milestones for this and potentially track progress on it.

Thanks,
-Sylvain

[1] https://review.openstack.org/#/c/96543/
[2] https://review.openstack.org/82133 and
https://review.openstack.org/89893
[3] https://review.openstack.org/97903



 Thanks,
 Yathi. 


 On 6/12/14, 10:55 AM, Alan Kavanagh alan.kavan...@ericsson.com
wrote:

 Hi Ramki

 Really like the smart scheduler idea, we made a couple of blueprints
that
 are related to ensuring you have the right information to build a
 constrained based scheduler. I do however want to point out that this
is
 not NFV specific but is useful for all applications and services of
which
 NFV is one. 

 /Alan

 -Original Message-
 From: ramki Krishnan [mailto:r...@brocade.com]
 Sent: June-10-14 6:06 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Cc: Chris Wright; Nicolas Lemieux; Norival Figueira
 Subject: Re: [openstack-dev] NFV in OpenStack use cases and context

 Hi Steve,

 Forgot to mention, the Smart Scheduler (Solver Scheduler) enhancements
 for NFV: Use Cases, Constraints etc. is a good example of an NFV use
 case deep dive for OpenStack.

 
https://urldefense.proofpoint.com/v1/url?u=https://docs.google.com/docum
en
 
t/d/1k60BQXOMkZS0SIxpFOppGgYp416uXcJVkAFep3Oeju8/edit%23heading%3Dh.wlbc
la
 
gujw8ck=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=%2FZ35AkRhp2kCW4Q3MPeE%2BxY
2b
 
qaf%2FKm29ZfiqAKXxeo%3D%0Am=vTulCeloS8Hc59%2FeAOd32Ri4eqbNqVE%2FeMgNRzG
Zn
 
z4%3D%0As=836991d6daab66b519de3b670db8af001144ddb20e636665b395597aa1185
38
 f

 Thanks,
 Ramki

 -Original Message-
 From: ramki Krishnan
 Sent: Tuesday, June 10, 2014 3:01 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Cc: Chris Wright; Nicolas Lemieux; Norival Figueira
 Subject: RE: NFV in OpenStack use cases and context

 Hi Steve,

 We are have OpenStack gap analysis documents in ETSI NFV under member
 only access. I can work on getting public version of the documents (at
 least a draft) to fuel the kick start.

 Thanks,
 Ramki

 -Original Message-
 From: Steve Gordon [mailto:sgor...@redhat.com]
 Sent: Tuesday, June 10, 2014 12:06 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Cc: Chris Wright; Nicolas Lemieux
 Subject: Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and
 context

 - Original Message -
 From: Steve Gordon sgor...@redhat.com
 To: Stephen Wong stephen.kf.w...@gmail.com

 - Original Message -
 From: Stephen Wong stephen.kf.w...@gmail.com
 To: ITAI MENDELSOHN (ITAI) itai.mendels...@alcatel-lucent.com,
 OpenStack Development Mailing List

Re: [openstack-dev] [NFV] - follow up on scheduling discussion

2014-06-10 Thread Yathiraj Udupi (yudupi)
Hi Tim,



In our current implementation of Smart (Solver) Scheduler,  the constraints are 
defined as pluggable modules (just like filter definitions in the filter 
scheduler) and are pulled in together when necessary to solve the scheduling 
decision. And regarding the data that we get from different services in storage 
(cinder)  , network and so on, we are currently using their clients to directly 
get the data to use along with the constraints.



I believe a policy implementation can specify which constraints to use and 
which data. So the data can potentially be saved in the individual services.



The Gantt project is also planning to have internal DB which will be used for 
scheduling. That is another option where the unified data can be, when we want 
to do unified scheduling that we describe in our Smart scheduler project.



I will open to explore options as to where Congress will fit in here,  but 
currently I feel it is one layer above this.



Thanks,

Yathi.







Sent from my LG G2, an ATT 4G LTE smartphone





-- Original message--

From: Tim Hinrichs

Date: Tue, Jun 10, 2014 8:27 AM

To: OpenStack Development Mailing List (not for usage questions);

Cc: Norival Figueira;Debo Dutta (dedutta);

Subject:Re: [openstack-dev] [NFV] - follow up on scheduling discussion



Hi all,

I see that many of the use cases require information from different OS 
components, e.g. networking, compute, and storage.  One thing to think about is 
where those constraints are written/stored and how the data the constraints 
depend on is pulled together.  The Congress project might be helpful here, and 
I’m happy to help explore options.  Let me know if you’re interested.

https://wiki.openstack.org/wiki/Congress

Tim



On Jun 4, 2014, at 11:25 AM, ramki Krishnan r...@brocade.com wrote:

 All,

 Thanks for the interest in the NFV scheduling topic. Please find a proposal 
 on Smart Scheduler (Solver Scheduler) enhancements for NFV: Use Cases, 
 Constraints etc.. 
 https://urldefense.proofpoint.com/v1/url?u=https://docs.google.com/document/d/1k60BQXOMkZS0SIxpFOppGgYp416uXcJVkAFep3Oeju8/edit%23heading%3Dh.wlbclagujw8ck=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0Am=vTulCeloS8Hc59%2FeAOd32Ri4eqbNqVE%2FeMgNRzGZnz4%3D%0As=836991d6daab66b519de3b670db8af001144ddb20e636665b395597aa118538f

 Based on this proposal, we are planning to enhance the existing 
 solver-scheduler blueprint 
 https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.net/nova/%2Bspec/solver-schedulerk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0Am=vTulCeloS8Hc59%2FeAOd32Ri4eqbNqVE%2FeMgNRzGZnz4%3D%0As=d1883d82f8d09081b35986987b5f2f9f1d7731f16b2a5251fdbf26c1b26b294d.

 Would love to hear your comments and thoughts. Would be glad to arrange a 
 conference call if needed.

 Thanks,
 Ramki


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0Am=vTulCeloS8Hc59%2FeAOd32Ri4eqbNqVE%2FeMgNRzGZnz4%3D%0As=7df001977efa968a09f3fae30b16ae35f4278a7bc82fcb3cdbbc9639cc505503


___
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


Re: [openstack-dev] [OpenStack GSoC] Chenchong Ask for Mentoring on Implement a cross-services scheduler Project

2014-03-05 Thread Yathiraj Udupi (yudupi)
Hi Chenchong, Fang,

I am glad that you have expressed interested in this project for GSoC.  It is a 
big project I agree in terms of its scope. But it is good to start with smaller 
goals.
It will be interesting to see what incremental  things can be added to the 
current Nova scheduler to achieve cross-services scheduling.
Solver Scheduler (https://blueprints.launchpad.net/nova/+spec/solver-scheduler) 
 has been pushed to Juno, and that BP has a goal of providing a generic 
framework for expressing scheduling problem as a constraint optimization 
problem, and hence can take different forms of constraints and cost metrics 
including the cross-services aspects.
So it is good to not limit your ideas with respect to Solver Scheduler BP, but 
in general also think of what additional stuff can be added to the current 
Filter Scheduler as well.

For GSoC, I don’t think you should worry about the feature freeze for now.  You 
can propose ideas in this theme for GSoC, and we can eventually get it upstream 
to be merged with Nova/ Gantt.

The cross service scheduling BP for Filter Scheduler enhancements  is here - 
https://blueprints.launchpad.net/nova/+spec/cross-service-filter-scheduling  We 
can probably use this for additional filter scheduler enhancements.

Thanks,
Yathi.




On 3/5/14, 10:33 AM, Chenchong Qin 
qinchench...@gmail.commailto:qinchench...@gmail.com wrote:

Hi

Sorry for not cc openstack-dev at first (haven't got familiar with OpenStack's 
GSoC
custom... but it's quite a different flavor compared with my last mentoring 
org). I just
sent it to the possible mentors. But it turns out that openstack-dev gives lots 
of
benefit. :)

I noticed that Fang also has interests towards this idea. It's strengthened my 
thought
that it's a great idea/project.

Russell and dims showed their concerns that the project described it is far too 
large
to be able to implement in one GSoC term. In fact, I hold the same concern, so I
asked the possible mentors about it at the end of my last mail.

This project appear to have a big name. But when we dig into detail of the 
project
description, it seems that the project is about implementing a nova scheduler 
that
can take information from storage and network components into consideration and
can make decisions based on global information. Besides, Sylvain also mentioned
that it's now in FeatureFreeze period. So, I think maybe we can move this 
project
from Gantt section to Nova section (with the consent of original project 
proposers),
and further specify the contents of the project to make it a enhancement or a 
new
feature/option to nova's current scheduler.

Thanks all your help and Sylvain's reminder on #openstack-meeting!

Regards!

Chenchong


-- Forwarded message --
From: Chenchong Qin qinchench...@gmail.commailto:qinchench...@gmail.com
Date: Wed, Mar 5, 2014 at 10:28 PM
Subject: [OpenStack GSoC] Chenchong Ask for Mentoring on Implement a 
cross-services scheduler Project
To: yud...@cisco.commailto:yud...@cisco.com, 
dedu...@cisco.commailto:dedu...@cisco.com


Hi, Yathi and Debo

I'm a master student from China who got a great interest in the Implement a 
cross-services scheduler
project you put in the Gantt section of OpenStack's GSoC 2014 idea list. I'm 
taking the liberty of asking
you as my mentor for applying this project.

My name is Chenchong Qin. I'm now in my second year as a master student of 
Computer Science at
University of Chinese Academy of Sciences. My research interests mainly focus 
on Computer Network
and Cloud Computing. I participated in GSoC 2013 to develop a rate control API 
that is 802.11n features
aware for FreeBSD (project 
homepagehttps://wiki.freebsd.org/SummerOfCode2013/80211RateControl80211nExtensions).
 I've been following closely with OpenStack since last year and
have done some work related to network policy migration. I'm familiar with 
C/C++ and Python, and have
also write some little tools and simulation programs with python.

When I first saw your idea of implementing a cross-services scheduler, I 
determined that it's a necessary
and meaningful proposal. I participated in a research project on channel 
scheduling in a distributed MIMO
system last year. From that project, I learned that without global information, 
any scheduling mechanisms
seemed feeble. I‘ve read the blueprints you wrote and I highly agree with you 
that the scheduler should be
able to leverage global information from multiple components like Nova, Cinder, 
and Neutron to make the
placement decisions. I'm willing to help with the SolverScheduler blueprint 
both during this GSoC project
and after.

And, I also got a question here. According to the project description, This 
project will help to build a
cross-services scheduler that can interact with storage and network services to 
make decisions. So, our
cross-services scheduler is now just a nova scheduler that can interact with 
storage and network component
to make decisions, but not a 

[openstack-dev] [Nova] FFE Request: Solver Scheduler: Complex constraint based resource placement

2014-03-05 Thread Yathiraj Udupi (yudupi)
Hi,

We would like to make a request for FFE for the Solver Scheduler work.  A lot 
of work has gone into it since Sep’13, and the first patch has gone through 
several iteration after some reviews.   The first patch - 
https://review.openstack.org/#/c/46588/ introduces the main solver scheduler 
driver, and a reference solver implementation, and the subsequent patches that 
are already added provide the pluggable solver, and individual support for 
adding constraints, costs, etc.

First Patch: https://review.openstack.org/#/c/46588/
Second patch with enhanced support for pluggable constraints and costs: -  
https://review.openstack.org/#/c/70654/
Subsequent patches add the constraints and the costs.
BP: https://blueprints.launchpad.net/nova/+spec/solver-scheduler
Core sponsor:  Joe Gordon

John Garbutt expressed concerns in Blueprint whiteboard regarding the 
configuration values, existing filters,etc and I noticed that you have 
un-approved this BP.
John, I will discuss with you in detail over IRC.
But briefly,  the plan is not many new configuration values will be added, just 
the ones to specify the solver to use, and the pluggable constraints, and costs 
to use, with the weights for the costs. (these are mainly part of the second 
patch -
 https://review.openstack.org/#/c/70654/ )

The plan is to gradually support the concepts for the existing filters as the 
constraints that are accepted by our Solver Scheduler.   Depending on the 
constraints and the costs chosen, the final scheduling will be done by solving 
the problem as an optimization problem.

Please reconsider this blueprint, and allow a FFE.

Thanks,
Yathi.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] FFE Request: Solver Scheduler: Complex constraint based resource placement

2014-03-05 Thread Yathiraj Udupi (yudupi)
Sorry,  This is request for FFE.
I meant Approver of the BP was Joe Gordon below.. not sponsor, probably the 
wrong word.

Thanks
Yathi.



On 3/5/14, 12:40 PM, Yathiraj Udupi (yudupi) 
yud...@cisco.commailto:yud...@cisco.com wrote:

Hi,

We would like to make a request for FFE for the Solver Scheduler work.  A lot 
of work has gone into it since Sep’13, and the first patch has gone through 
several iteration after some reviews.   The first patch - 
https://review.openstack.org/#/c/46588/ introduces the main solver scheduler 
driver, and a reference solver implementation, and the subsequent patches that 
are already added provide the pluggable solver, and individual support for 
adding constraints, costs, etc.

First Patch: https://review.openstack.org/#/c/46588/
Second patch with enhanced support for pluggable constraints and costs: -  
https://review.openstack.org/#/c/70654/
Subsequent patches add the constraints and the costs.
BP: https://blueprints.launchpad.net/nova/+spec/solver-scheduler
Core sponsor:  Joe Gordon

John Garbutt expressed concerns in Blueprint whiteboard regarding the 
configuration values, existing filters,etc and I noticed that you have 
un-approved this BP.
John, I will discuss with you in detail over IRC.
But briefly,  the plan is not many new configuration values will be added, just 
the ones to specify the solver to use, and the pluggable constraints, and costs 
to use, with the weights for the costs. (these are mainly part of the second 
patch -
 https://review.openstack.org/#/c/70654/ )

The plan is to gradually support the concepts for the existing filters as the 
constraints that are accepted by our Solver Scheduler.   Depending on the 
constraints and the costs chosen, the final scheduling will be done by solving 
the problem as an optimization problem.

Please reconsider this blueprint, and allow a FFE.

Thanks,
Yathi.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Nova] Regarding the icehouse release roadmap tracking page

2014-03-03 Thread Yathiraj Udupi (yudupi)
Hi,

I was looking at the Icehouse release roadmap tracking page here - 
http://status.openstack.org/release/

How is the list generated?
I couldn’t see the Nova Solver Scheduler blueprint here in this list - 
https://blueprints.launchpad.net/nova/+spec/solver-scheduler which is approved 
for icehouse-3.
Whoever knows or handles this release tracking page, can you please update this 
to include the above blueprint?

Thanks,
Yathi.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [OpenStack][Runtime Policy] A proposal for OpenStack run time policy to manage compute/storage resource

2014-02-26 Thread Yathiraj Udupi (yudupi)
Hi Jay, Tim, Sylvain,

It is an important topic of run time monitoring and policies for management of 
compute/storage resources.  I agree this is the kind of solution that we should 
learn from Vmware DRS.
Regarding how the Solver Scheduler fits in, we initiated this effort to address 
complex constraint and policy scenarios, and the kinds of policies and 
constraints that become relevant for Load balancing, HA, energy saving, etc are 
all relevant constraints that we care about addressing and solving using the 
Solver scheduler.   However you should consider the solver scheduler as a pure 
placement decision engine, whether it is used for the initial placement, or if 
it is used for automatically triggering any action (such as a migration etc.) 
at runtime based on the constraints/policy checking.

As of now, the Solver Scheduler effort has been started to address the initial 
Nova placement decision, as a new scheduler driver.  But eventually with the 
Gantt efforts, of having scheduler as a separate service, and the resulting new 
apis, it is heading towards being a true decision engine, that can be triggered 
at any point of time, to figure out the ideal placements given the current 
state of the resource capacities.

But the kinds of policies you have mentioned here,  appear as a true fit for 
being addressed as the complex constraints and cost metrics that can be used to 
be solved the Solver Scheduler’s intelligent constraints-based optimization 
solver.

We (the solver scheduler sub-team) will be very happy to work with you to 
address some of these scenarios, and we can have a session at the upcoming 
summit regarding this kind of run-time policies.

Thanks,
Yathi.

—



On 2/26/14, 6:30 PM, Jay Lau 
jay.lau@gmail.commailto:jay.lau@gmail.com wrote:

Hi Tim,

I'm not sure if we can put resource monitor and adjust to solver-scheduler 
(Gantt), but I have proposed this to Gantt design [1], you can refer to [1] and 
search jay-lau-513.

IMHO, Congress does monitoring and also take actions, but the actions seems 
mainly for adjusting single VM network or storage. It did not consider 
migrating VM according to hypervisor load.

Not sure if this topic deserved to be a design session for the coming summit, 
but I will try to propose.

[1] https://etherpad.openstack.org/p/icehouse-external-scheduler

Thanks,

Jay

2014-02-27 1:48 GMT+08:00 Tim Hinrichs 
thinri...@vmware.commailto:thinri...@vmware.com:
Hi Jay and Sylvain,

The solver-scheduler sounds like a good fit to me as well.  It clearly 
provisions resources in accordance with policy.  Does it monitor those 
resources and adjust them if the system falls out of compliance with the policy?

I mentioned Congress for two reasons. (i) It does monitoring.  (ii) There was 
mention of compute, networking, and storage, and I couldn't tell if the idea 
was for policy that spans OS components or not.  Congress was designed for 
policies spanning OS components.

Tim

- Original Message -
| From: Jay Lau jay.lau@gmail.commailto:jay.lau@gmail.com
| To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
| Sent: Tuesday, February 25, 2014 10:13:14 PM
| Subject: Re: [openstack-dev] [OpenStack][Runtime Policy] A proposal for 
OpenStack run time policy to manage
| compute/storage resource
|
|
|
|
|
| Thanks Sylvain and Tim for the great sharing.
|
| @Tim, I also go through with Congress and have the same feeling with
| Sylvai, it is likely that Congress is doing something simliar with
| Gantt providing a holistic way for deploying. What I want to do is
| to provide some functions which is very similar with VMWare DRS that
| can do some adaptive scheduling automatically.
|
| @Sylvain, can you please show more detail for what Pets vs. Cattles
| analogy means?
|
|
|
|
| 2014-02-26 9:11 GMT+08:00 Sylvain Bauza  
sylvain.ba...@gmail.commailto:sylvain.ba...@gmail.com  :
|
|
|
| Hi Tim,
|
|
| As per I'm reading your design document, it sounds more likely
| related to something like Solver Scheduler subteam is trying to
| focus on, ie. intelligent agnostic resources placement on an
| holistic way [1]
| IIRC, Jay is more likely talking about adaptive scheduling decisions
| based on feedback with potential counter-measures that can be done
| for decreasing load and preserving QoS of nodes.
|
|
| That said, maybe I'm wrong ?
|
|
| [1] https://blueprints.launchpad.net/nova/+spec/solver-scheduler
|
|
|
| 2014-02-26 1:09 GMT+01:00 Tim Hinrichs  
thinri...@vmware.commailto:thinri...@vmware.com  :
|
|
|
|
| Hi Jay,
|
| The Congress project aims to handle something similar to your use
| cases. I just sent a note to the ML with a Congress status update
| with the tag [Congress]. It includes links to our design docs. Let
| me know if you have trouble finding it or want to follow up.
|
| Tim
|
|
|
| - Original Message -
| | From: Sylvain Bauza  

Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

2014-02-11 Thread Yathiraj Udupi (yudupi)
I thought of adding some more points about the Solver Scheduler to this
conversation.
Think of SolverScheduler as a placement decision engine, which gives an
optimal solution for the specified request based on the current
information available at a specific time.  The request could potentially
be a set of instances of the same flavor or different flavors (assuming we
eventually support scheduler APIs that can provide this).
Once the optimal placement decision is known, then we need to allocate the
resources. Currently Nova supports the final allocation of resources
(resource provisioning) one at a time.  I definitely agree there will be
more success in allocating all the requested instances, if there is a
support for reserving the spots as soon as a placement decision is taken
by the SolverScheduler. This is something to explore to add in Nova, using
a local service or external service (need to explore Climate).

If the required set of instances is known, irrespective of whether it is
part of one instance group, or multiple instance groups, you always get a
more optimal solution, if all of this is requested in one shot to the
solver scheduler, as the constraint solving happens in one shot, letting
you know if the entire set of instances is feasible to be placed given the
existing resource capacity.
If it is okay to support partial instantiation of subset of instances,
then it makes sense to provide support to retry one instance group at a
time, when the entire request is not feasible.
To add another point about instance group api implementation for icehouse,
it was decided in the HongKong summit to initially support only flat
instance groups without nesting. Hence if an application requires a big
topology of instances, they can easily belong to multiple instance groups,
and hence if you want the entire application requirement to be satisfied,
the entire set of instances from multiple flat instance groups should be
requested as a single shot to the solver scheduler.  Also, there is
additional work required to add new scheduler APIs to support requesting
instance groups of multiple flavors.

I think I have reiterated some of the points what Chris has mentioned
below.  But Yes, like I had stated earlier in this thread, we need to
separate the decision making phase from the initial request making, and
the final allocation provisioning (or orchestration).  In these phases, a
reservation phase, after the decision making,  will add additional
guarantees to allocate the placed instances.

Thanks,
Yathi. 



On 2/11/14, 7:09 AM, Chris Friesen chris.frie...@windriver.com wrote:

On 02/11/2014 03:21 AM, Khanh-Toan Tran wrote:
 Second, there is nothing wrong with booting the instances (or
 instantiating other
 resources) as separate commands as long as we support some kind of
 reservation token.

 I'm not sure what reservation token would do, is it some kind of
informing
 the scheduler that the resources would not be initiated until later ?

Like a restaurant reservation, it would claim the resources for use by
someone at a later date.  That way nobody else can use them.

That way the scheduler would be responsible for determining where the
resource should be allocated from, and getting a reservation for that
resource.  It would not have anything to do with actually instantiating
the instance/volume/etc.

 Let's consider a following example:

 A user wants to create 2 VMs, a small one with 20 GB RAM, and a big one
 with 40 GB RAM in a datacenter consisted of 2 hosts: one with 50 GB RAM
 left, and another with 30 GB RAM left, using Filter Scheduler's default
 RamWeigher.

 If we pass the demand as two commands, there is a chance that the small
VM
 arrives first. RamWeigher will put it in the 50 GB RAM host, which will
be
 reduced to 30 GB RAM. Then, when the big VM request arrives, there will
be
 no space left to host it. As a result, the whole demand is failed.

 Now if we can pass the two VMs in a command, SolverScheduler can put
their
 constraints all together into one big LP as follow (x_uv = 1 if VM u is
 hosted in host v, 0 if not):

Yes.  So what I'm suggesting is that we schedule the two VMs as one call
to the SolverScheduler.  The scheduler then gets reservations for the
necessary resources and returns them to the caller.  This would be sort
of like the existing Claim object in nova/compute/claims.py but
generalized somewhat to other resources as well.

The caller could then boot each instance separately (passing the
appropriate reservation/claim along with the boot request).  Because the
caller has a reservation the core code would know it doesn't need to
schedule or allocate resources, that's already been done.

The advantage of this is that the scheduling and resource allocation is
done separately from the instantiation.  The instantiation API could
remain basically as-is except for supporting an optional reservation
token.

 That responses to your first point, too. If we don't mind that some VMs
 are 

Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

2014-02-11 Thread Yathiraj Udupi (yudupi)
Hi Dina,

Thanks for note about Climate logic.  This is something that will be very 
useful, when we will have to schedule from Nova multiple instances (of 
potentially different flavors) as a single request.  If the Solver Scheduler, 
can make a request to the Climate service to reserve the resources soon after 
the placement decision has been made, then the nova provisioning logic can 
handle the resource provisioning using the climate reserved leases.  Regarding 
Solver Scheduler for your reference, just sent another email about this with 
some pointers about it.  Otherwise this is the blueprint - 
https://blueprints.launchpad.net/nova/+spec/solver-scheduler
I guess this is something to explore more and see how Nova provisioning logic 
to work with Climate leases. Or this is something that already works.  I need 
to find out more about Climate.

Thanks,
Yathi.


On 2/11/14, 7:44 AM, Dina Belova 
dbel...@mirantis.commailto:dbel...@mirantis.com wrote:

Like a restaurant reservation, it would claim the resources for use by 
someone at a later date.  That way nobody else can use them.
That way the scheduler would be responsible for determining where the resource 
should be allocated from, and getting a reservation for that resource.  It 
would not have anything to do with actually instantiating the 
instance/volume/etc.

Although I'm quite new to topic of Solver Scheduler, it seems to me that in 
that case you need to look on Climate project. It aims to provide resource 
reservation to OS clouds (and by resource I mean here instance/compute 
host/volume/etc.)

And Climate logic is like: create lease - get resources from common pool - do 
smth with them when lease start time will come.

I'll say one more time - I'm not really common with this discussion, but it 
looks like Climate might help here.

Thanks
Dina


On Tue, Feb 11, 2014 at 7:09 PM, Chris Friesen 
chris.frie...@windriver.commailto:chris.frie...@windriver.com wrote:
On 02/11/2014 03:21 AM, Khanh-Toan Tran wrote:
Second, there is nothing wrong with booting the instances (or
instantiating other
resources) as separate commands as long as we support some kind of
reservation token.

I'm not sure what reservation token would do, is it some kind of informing
the scheduler that the resources would not be initiated until later ?

Like a restaurant reservation, it would claim the resources for use by 
someone at a later date.  That way nobody else can use them.

That way the scheduler would be responsible for determining where the resource 
should be allocated from, and getting a reservation for that resource.  It 
would not have anything to do with actually instantiating the 
instance/volume/etc.


Let's consider a following example:

A user wants to create 2 VMs, a small one with 20 GB RAM, and a big one
with 40 GB RAM in a datacenter consisted of 2 hosts: one with 50 GB RAM
left, and another with 30 GB RAM left, using Filter Scheduler's default
RamWeigher.

If we pass the demand as two commands, there is a chance that the small VM
arrives first. RamWeigher will put it in the 50 GB RAM host, which will be
reduced to 30 GB RAM. Then, when the big VM request arrives, there will be
no space left to host it. As a result, the whole demand is failed.

Now if we can pass the two VMs in a command, SolverScheduler can put their
constraints all together into one big LP as follow (x_uv = 1 if VM u is
hosted in host v, 0 if not):

Yes.  So what I'm suggesting is that we schedule the two VMs as one call to the 
SolverScheduler.  The scheduler then gets reservations for the necessary 
resources and returns them to the caller.  This would be sort of like the 
existing Claim object in nova/compute/claims.py but generalized somewhat to 
other resources as well.

The caller could then boot each instance separately (passing the appropriate 
reservation/claim along with the boot request).  Because the caller has a 
reservation the core code would know it doesn't need to schedule or allocate 
resources, that's already been done.

The advantage of this is that the scheduling and resource allocation is done 
separately from the instantiation.  The instantiation API could remain 
basically as-is except for supporting an optional reservation token.


That responses to your first point, too. If we don't mind that some VMs
are placed and some are not (e.g. they belong to different apps), then
it's OK to pass them to the scheduler without Instance Group. However, if
the VMs are together (belong to an app), then we have to put them into an
Instance Group.

When I think of an Instance Group, I think of 
https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension;.   
Fundamentally Instance Groups describes a runtime relationship between 
different instances.

The scheduler doesn't necessarily care about a runtime relationship, it's just 
trying to allocate resources efficiently.

In the above example, there is no need for those two instances to necessarily 
be part of an 

Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

2014-02-11 Thread Yathiraj Udupi (yudupi)
hi Sylvain and Dina,

Thanks for your pointers about Climate.  I will take a closer look at it and 
try it out.  So after a reservation lease for a VM is made by Climate, who acts 
on it to finally instantiate the VM ? Is it Climate or Nova should act on the 
lease to finally provision the VM.

Thanks,
Yathi.

On 2/11/14, 8:42 AM, Sylvain Bauza 
sylvain.ba...@bull.netmailto:sylvain.ba...@bull.net wrote:

Le 11/02/2014 17:23, Yathiraj Udupi (yudupi) a écrit :
Hi Dina,

Thanks for note about Climate logic.  This is something that will be very 
useful, when we will have to schedule from Nova multiple instances (of 
potentially different flavors) as a single request.  If the Solver Scheduler, 
can make a request to the Climate service to reserve the resources soon after 
the placement decision has been made, then the nova provisioning logic can 
handle the resource provisioning using the climate reserved leases.  Regarding 
Solver Scheduler for your reference, just sent another email about this with 
some pointers about it.  Otherwise this is the blueprint - 
https://blueprints.launchpad.net/nova/+spec/solver-scheduler
I guess this is something to explore more and see how Nova provisioning logic 
to work with Climate leases. Or this is something that already works.  I need 
to find out more about Climate.

Thanks,
Yathi.



There are possibly 2 ways for creating a lease : either thru the CLI or by the 
python binding.

We implemented these 2 possibilities within the current Climate 0.1 release :
 - a Nova extension plugin is responsible for creating the lease if a VM should 
be reserved (using the Climate pythonclient binding)
 - an user can request for reserving a compute host using the Climate python 
client directly

Both logics (VM and compute host) are actually referring to 2 distinct plugins 
in the Climate manager, so the actions are completely different.

Based on your use-case, you could imagine a call from the SolverScheduler to 
Climate for creating a lease containing multiple VM reservations, and either 
you would use the Climate VM plugin or you would use a dedicated plugin if your 
need is different.

I don't think that's a huge volume of work, as Climate already defines and 
implements the main features that you need.

-Sylvain
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

2014-02-03 Thread Yathiraj Udupi (yudupi)
The solver-scheduler is designed to solve for an arbitrary list of instances of 
different flavors. We need to have some updated apis in the scheduler to be 
able to pass on such requests. Instance group api is an initial effort to 
specify such groups.



Even now the existing solver scheduler patch,  works for a group request,  only 
that it is a group of a single flavor. It still solves once for the entire 
group based on the constraints on available capacity.



With updates to the api that call the solver scheduler we can easily 
demonstrate how an arbitrary group of VM request can be satisfied and solved 
together in a single constraint solver run. (LP based solver for now in the 
current patch, But can be any constraint solver)



Thanks,

Yathi.





-- Original message--

From: Chris Friesen

Date: Mon, 2/3/2014 11:24 AM

To: openstack-dev@lists.openstack.org;

Subject:Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver 
Scheduler



On 02/03/2014 12:28 PM, Khanh-Toan Tran wrote:

 Another though would be the need for Instance Group API [1].
 Currently users can only request multiple instances of the same
 flavors. These requests do not need LP to solve, just placing
 instances one by one is sufficient. Therefore we need this API so
 that users can request instances of different flavors, with some
 relations (constraints) among them. The advantage is that this logic
 and API will help us add Cinder volumes with ease (not sure how the
 Cinder-stackers think about it, though).

I don't think that the instance group API actually helps here.  (I think
it's a good idea, just not directly related to this.)

I think what we really want is the ability to specify an arbitrary list
of instances (or other things) that you want to schedule, each of which
may have different image/flavor, each of which may be part of an
instance group, a specific network, have metadata which associates with
a host aggregate, desire specific PCI passthrough devices, etc.

An immediate user of something like this would be heat, since it would
let them pass the whole stack to the scheduler in one API call.  The
scheduler could then take a more holistic view, possibly doing a better
fitting job than if the instances are scheduled one-at-a-time.

Chris

___
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


Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

2014-01-30 Thread Yathiraj Udupi (yudupi)
It is really good we are reviving the conversation we started during the last 
summit in Hongkong during one of the scheduler sessions called “Smart resource 
placement”.   This is the document we used to discuss during the session.  
Probably you may have seen this before:
https://docs.google.com/document/d/1IiPI0sfaWb1bdYiMWzAAx0HYR6UqzOan_Utgml5W1HI/edit

The idea is to separate out the logic for the placement decision engine from 
the actual request and the final provisioning  phase.   The placement engine 
itself can be pluggable, and as we show in the solver scheduler blueprint,  we 
show how it fits inside of Nova.

The discussions at the summit and in our weekly scheduler meetings led to us 
starting the “Smart resource placement” idea inside of Nova, and then take it 
to a unified global level spanning cross services such as cinder and neutron.

Like you point out, I do agree the two entities of placement advisor, and the 
placement engine, but I think there should be a third one – the provisioning 
engine, which should be responsible for whatever it takes to finally create the 
instances, after the placement decision has been taken.
It is good to take incremental approaches, hence we should try to get patches 
like these  get accepted first within nova, and then slowly split up the logic 
into separate entities.

Thanks,
Yathi.





On 1/30/14, 7:14 AM, Gil Rapaport g...@il.ibm.commailto:g...@il.ibm.com 
wrote:

Hi all,

Excellent definition of the issue at hand.
The recent blueprints of policy-based-scheduler and solver-scheduler indeed 
highlight a possible weakness in the current design, as despite their 
completely independent contributions (i.e. which filters to apply per request 
vs. how to compute a valid placement) their implementation as drivers makes 
combining them non-trivial.

As Alex Glikson hinted a couple of weekly meetings ago, our approach to this is 
to think of the driver's work as split between two entities:
-- A Placement Advisor, that constructs placement problems for scheduling 
requests (filter-scheduler and policy-based-scheduler)
-- A Placement Engine, that solves placement problems (HostManager in 
get_filtered_hosts() and solver-scheduler with its LP engine).

Such modularity should allow developing independent mechanisms that can be 
combined seamlessly through a unified  well-defined protocol based on 
constructing placement problem objects by the placement advisor and then 
passing them to the placement engine, which returns the solution. The protocol 
can be orchestrated by the scheduler manager.

As can be seen at this point already, the policy-based-scheduler blueprint can 
now be positioned as an improvement of the placement advisor. Similarly, the 
solver-scheduler blueprint can be positioned as an improvement of the placement 
engine.

I'm working on a wiki page that will get into the details.
Would appreciate your initial thoughts on this approach.

Regards,
Gil



From:Khanh-Toan Tran 
khanh-toan.t...@cloudwatt.commailto:khanh-toan.t...@cloudwatt.com
To:OpenStack Development Mailing List \(not for usage questions\) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org,
Date:01/30/2014 01:43 PM
Subject:Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler 
andSolver Scheduler




Hi Sylvain,

1) Some Filters such as AggregateCoreFilter, AggregateRAMFilter can change its 
parameters for aggregates. But what if admin wants to change for all hosts in 
an availability-zone? Does he have to rewrite all the parameters in all 
aggregates? Or should we create a new AvailabilityZoneCoreFilter?

The Policy Based Scheduler (PBS)  blueprint separates the effect (filter 
according to Core) from its target (all hosts in an aggregate, or in an 
availability-zone). It will benefit all filters, not just CoreFilter or 
RAMFilter, so that we can avoid creating for each filter XFilter the 
AggregateXFilter and AvailabilityZoneWFilter from now on. Beside, if admin 
wants to apply the a filter to some aggregates (or availability-zone) and not 
the other (don’t call filters at all, not just modify parameters), he can do 
it. It help us avoid running all filters on all hosts.

2) In fact, we also prepare for a separated scheduler in which PBS is a very 
first step of it, that’s why we purposely separate the Policy Based Scheduler 
from Policy Based Scheduling Module (PBSM) [1] which is the core of our 
architecture. If you look at our code, you will see that 
Policy_Based_Scheduler.py is only slightly different from Filter Scheduler. 
That is because we just want a link from Nova-scheduler to PBSM. We’re trying 
to push some more management into scheduler without causing too much 
modification, as you can see in the patch .

Thus I’m very happy when Gantt is proposed. As I see it, Gantt is based on 
Nova-scheduler code, with the planning on replacing nova-scheduler in J. The 

[openstack-dev] [Nova][Scheduler] Solver Scheduler code is now ready for review, with a reference solver implementation

2014-01-29 Thread Yathiraj Udupi (yudupi)
Hi,

The Solver scheduler code is committed with the new solver_scheduler driver, 
and a reference implementation of a PULP based solver – hosts_pulp_solver.   
The code is ready now for further review, now that the JENKINS build has 
succeeded.

This is an initial commit and there will be future enhancements in the pipeline 
as separate patches.

Please review.

Thanks,
Yathi.




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova][Scheduler] Solver Scheduler code is now ready for review, with a reference solver implementation

2014-01-29 Thread Yathiraj Udupi (yudupi)
Sorry I forgot to include the review link - 
https://review.openstack.org/#/c/46588/

—Yathi.

On 1/29/14, 3:52 PM, Yathiraj Udupi (yudupi) 
yud...@cisco.commailto:yud...@cisco.com wrote:

Hi,

The Solver scheduler code is committed with the new solver_scheduler driver, 
and a reference implementation of a PULP based solver – hosts_pulp_solver.   
The code is ready now for further review, now that the JENKINS build has 
succeeded.

This is an initial commit and there will be future enhancements in the pipeline 
as separate patches.

Please review.

Thanks,
Yathi.




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime

2013-12-03 Thread Yathiraj Udupi (yudupi)
I totally agree on this meta level scheduler aspect. This should separate the 
placement decision making logic (for resources of any type, but can start on 
Nova resources) from their actual creation, say VM creation.



This way the placement decisions can be relayed to the individual components 
allocator component or whatever component that handles this after the 
separation.



So in this effort of separating the scheduler I hope some clean interfaces will 
be created that separate these logics.  At least we should attempt to make the 
effort follow some  global meta scheduling clean interfaces that should be 
designed.



Yathi.





-- Original message--

From: Debojyoti Dutta

Date: Tue, 12/3/2013 10:50 AM

To: OpenStack Development Mailing List (not for usage questions);

Cc: Boris Pavlovic;

Subject:Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest 
proposal for an external scheduler in our lifetime



I agree with RussellB on this … if the forklift's goal is to just separate the 
scheduler, there should be no new features etc till the forklift is done and it 
should work as is with very minor config changes.

A scheduler has several features like place resources correctly, for example. 
Ideally, this should be a simple service that can allocate any resources to any 
available bucket - balls in bins, VMs in host, blocks/blobs on disk/SSD etc. 
Maybe the scheduler should operate on meta level resource maps for each type 
and delegate the precise decisions to the allocator for that type.

debo


On Tue, Dec 3, 2013 at 9:58 AM, Russell Bryant 
rbry...@redhat.commailto:rbry...@redhat.com wrote:
On 12/03/2013 07:22 AM, Boris Pavlovic wrote:
 Hi all,


 Finally found a bit time to write my thoughts.

 There are few blockers that make really complex to build scheduler as a
 services or even to move main part of scheduler code to separated lib.
 We already have one unsuccessfully effort
 https://blueprints.launchpad.net/oslo/+spec/oslo-scheduler .

 Major problems that we faced were next:
 1) Hard connection with project db api layer (e.g. nova.db.api,
 cinder.db.api)
 2) Hard connection between db.models and host_states
 3) Hardcoded host states objects structure
 4) There is no namespace support in host states (so we are not able to
 keep all filters for all projects in the same place)
 5) Different API methods, that can't be effectively generalized.


 Main goals of no-db-scheduler effort are:
 1) Make scheduling much faster, storing data locally on each scheduler
 and just syncing states of them
 2) Remove connections between project.db.api and scheduler.db
 3) Make host_states just JSON like objects
 4) Add namespace support in host_states

 When this part will be finished, we will have actually only 1 problem
 what to do with DB API methods, and business logic of each project. What
 I see is that there are 2 different ways:

If the new project is just a forklift of the existing code that still
imports nova's db API and accesses Nova's DB, I don't think the initial
forklift necessarily has to be blocked on completing no-db-scheduler.
That can happen after just as easily (depending on which effort is ready
first).

 1) Make scheduler as a big lib, then implement RPC methods + bit of
 business logic in each project
 2) Move all RPC calls from nova,cinder,ironic,... and business logic in
 1 scheduler as a service

Right now I think #2 is the approach we should take.  This is mainly
because there is common information that is needed for the scheduling
logic for resources in multiple projects.

--
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
-Debo~
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime

2013-11-22 Thread Yathiraj Udupi (yudupi)
I would definitely like to take part in this discussion and also
contribute where I can.  I was part of the scheduler sessions in the
recent summit along with Debo Dutta, Gary Kotton, and Mike Spreitzer and
we had proposed sessions on smart resource placement, and also the
instance group API work for nova.  We have been discussing this at our
weekly scheduler meetings as well.
I am also in the process of contributing a Solver Scheduler - a
constraints-solver based way of finding optimal resource placements in
openstack. 
In our smart resource placement proposal, we discussed a high level
overview of scheduling considering cross services, and it hints at how the
scheduler should sit outside as a separate service.  But we decided to
start within Nova first.

This work of separating the scheduler is very promising, and I definitely
would like to be involved in this effort.

Thanks,
Yathi. 

‹

On 11/21/13, 12:58 PM, Robert Collins robe...@robertcollins.net wrote:

https://etherpad.openstack.org/p/icehouse-external-scheduler

I'm looking for 4-5 folk who have:
 - modest Nova skills
 - time to follow a fairly mechanical (but careful and detailed work
needed) plan to break the status quo around scheduler extraction

And of course, discussion galore about the idea :)

Cheers,
Rob

-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

___
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


[openstack-dev] [nova][scheduler] Instance Group Model and APIs - Updated document with an example request payload

2013-10-29 Thread Yathiraj Udupi (yudupi)
The Instance Group API document is now updated with a simple example request 
payload of a nested group, and some description of how the API implementation 
should handle the registration of the components of a nested instance group.
https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit

Hope we will have a good API design session at the summit, and also continue 
the discussion face-to-face over there.

Thanks,
Yathi.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][scheduler] Instance Group Model and APIs - Updated document with an example request payload

2013-10-29 Thread Yathiraj Udupi (yudupi)
Thanks Khanh for your questions and Mike for adding your inputs.  Some more 
inline comments.

On 10/29/13, 1:23 PM, Mike Spreitzer 
mspre...@us.ibm.commailto:mspre...@us.ibm.com wrote:

Khanh-Toan Tran 
khanh-toan.t...@cloudwatt.commailto:khanh-toan.t...@cloudwatt.com wrote on 
10/29/2013 09:10:00 AM:
 ...
 1) Member of a group is recursive. A member can be group or an
 instance. In this case there are two different declaration formats
 for members, as with http-server-group-1 (name, policy, edge)
 and Http-Server-1 (name, request_spec, type). Would it be
 better if group-typed member also have type field to better
 interpret the member? Like policy which has type field to declare
 that's a egde-typed policy or group-typed policy.

I have no strong opinion on this.

Yeah some of this might have missed in my example, the purpose here was to 
provide an example to express it.  type field for group-type member will be 
included in the request payload


 2) The edge is not clear to me. It seems to me that edge is just
 a place holder for the edge policy. Does it have some particular
 configuration like group members (e.g. group-typed member is
 described by its member,edge and policy, while instance-typed
 member is described by its request_spec) ?

Yes, an edge is just a way to apply a policy to an ordered pair of groups.

If you read earlier in the doc – an edge represents the 
InstanceGroupMemberConnection, which describes the edge connecting two instance 
group members.  This is used to apply a policy on this edge.   This is also 
used to represent complex topologies where members could be different groups.
Again, the request payload is based on what all data can be provided to 
instantiate the objects in DB based on the model class diagram provided in the 
document.  This is just an example spec, so some fields may be missing in this 
example.



 3) Members  groups have policy declaration nested in them. Why is
 edge-policy is declared outside of edge's declaration?

I agree, it would be more natural to write an edge's policy references inside 
the edge object itself.

Like we discussed earlier and also mentioned in the document,  the policy has a 
lifecycle of its own and defined outside with all the required parameters.  
InstanceGroupPolicy is a reference to that policy object.



Thanks,
Mike


Thanks,
Yathi.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [scheduler] APIs for Smart Resource Placement - Updated Instance Group Model and API extension model - WIP Draft

2013-10-15 Thread Yathiraj Udupi (yudupi)
I have made some edits to the document: 
https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit?pli=1#
by updating the Instance Group Model and APIs based on the recent mailing list 
discussion below and also about the Policy Model in another email thread.  An 
action item is to provide some examples of request and response to the REST 
apis.  But they will be based on enhancements and reuse of some examples 
already provided here: https://review.openstack.org/#/c/30028/22

This API proposal is still under discussion and work-in-progress,  and will 
definitely be a good session topic to finalize this proposal.

Regards,
Yathi.


From: Yathiraj Udupi yud...@cisco.commailto:yud...@cisco.com
Date: Monday, October 14, 2013 10:17 AM
To: Mike Spreitzer mspre...@us.ibm.commailto:mspre...@us.ibm.com, Debojyoti 
Dutta ddu...@gmail.commailto:ddu...@gmail.com, garyk 
gkot...@vmware.commailto:gkot...@vmware.com
Cc: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [scheduler] APIs for Smart Resource Placement - 
Updated Instance Group Model and API extension model - WIP Draft

Hi Mike,

I read your email where you expressed concerns regarding create-time 
dependencies, and I agree they are valid concerns to be addressed.  But like we 
all agree, as a starting point, we are just focusing on the APIs for now, and 
will leave that aside as implementation details to be addressed later.
Thanks for sharing your suggestions on how we can simplify the APIs.  I think 
we are getting closer to finalizing this one.

Let us start at the model proposed here -
[1] 
https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit?usp=sharing
(Ignore the white diamonds - they will be black, when I edit the doc)

The InstanceGroup represents all the information necessary to capture the group 
- nodes, edges, policies, and metadata

InstanceGroupMember - is a reference to an Instance, which is saved separately, 
using the existing Instance Model in Nova.

InstanceGroupMemberConnection - represents the edge

InstanceGroupPolicy is a reference to a Policy, which will also be saved 
separately, (currently not existing in the model, but has to be created). Here 
in the Policy model, I don't mind adding any number of additional fields, and 
key-value pairs to be able to fully define a policy.  I guess a Policy-metadata 
dictionary is sufficient to capture all the required arguments.
The InstanceGroupPolicy will be associated to a group as a whole or an edge.

InstanceGroupMetadata - represents key-value dictionary for any additional 
metadata for the instance group.

I think this should fully support what we care about - nodes, edges, policies 
and metadata.

Do we all agree ?


Now going to the APIs,

Register GROUP API (from my doc [1]):


POST


/v3.0/{tenant_id}/groups


Register a group


I think the confusion is only about when the member (all nested members) and 
policy about when they are saved in the DB (registered, but not CREATED 
actually), such that we can associate a UUID.  This led to my original thinking 
that it is a 3-phase operation where we have to register (save in DB) the 
nested members first, then register the group as a whole.  But this is not 
client friendly.

Like I had suggested earlier, as an implementation detail of the Group 
registration API (CREATE part 1 in your terminology), we can support this: as 
part of the group registration transaction,  complete the registration of the 
nested members, get their UUIDs,  create the InstanceGroupMemberConnections, 
and then complete saving the group - resulting in a UUID for the group,  all in 
a single transaction-scope.  While you start the transaction, you can start 
with a UUID for the group, so that you can add the group_id pointers to the 
individual members,  and then finally complete the transaction.
This means,  you provide as an input to the REST API - the complete nested 
tree, including all the details about the nested members and policies, and the 
register API, will handle the saving of all the individual objects required.

But I think it does help to also add additional APIs to just register an 
InstanceGroupMember and  an InstanceGroupPolicy separately.  This might help 
the client while creating a group, rather than giving the entire nested tree.   
(his makes it a 3-phase) This API will support adding members and policies to 
an instance group that is created.  (you can start with an empty group)


POST


/v3.0/{tenant_id}/groups/instance


Register an instance belonging to an instancegroup



POST


/v3.0/{tenant_id}/groups/policy


Register a policy belonging to an instance group



Are we okay with this ?


The next API - is the actual creation of the resources.  (CREATE part 2  in 
your terminology).   This is was my create API in the doc-


POST


/v3.0/{tenant_id}/groups/{id}/create


Create and schedule 

Re: [openstack-dev] [scheduler] APIs for Smart Resource Placement - Updated Instance Group Model and API extension model - WIP Draft

2013-10-14 Thread Yathiraj Udupi (yudupi)
Hi Mike,

I read your email where you expressed concerns regarding create-time 
dependencies, and I agree they are valid concerns to be addressed.  But like we 
all agree, as a starting point, we are just focusing on the APIs for now, and 
will leave that aside as implementation details to be addressed later.
Thanks for sharing your suggestions on how we can simplify the APIs.  I think 
we are getting closer to finalizing this one.

Let us start at the model proposed here -
[1] 
https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit?usp=sharing
(Ignore the white diamonds - they will be black, when I edit the doc)

The InstanceGroup represents all the information necessary to capture the group 
- nodes, edges, policies, and metadata

InstanceGroupMember - is a reference to an Instance, which is saved separately, 
using the existing Instance Model in Nova.

InstanceGroupMemberConnection - represents the edge

InstanceGroupPolicy is a reference to a Policy, which will also be saved 
separately, (currently not existing in the model, but has to be created). Here 
in the Policy model, I don't mind adding any number of additional fields, and 
key-value pairs to be able to fully define a policy.  I guess a Policy-metadata 
dictionary is sufficient to capture all the required arguments.
The InstanceGroupPolicy will be associated to a group as a whole or an edge.

InstanceGroupMetadata - represents key-value dictionary for any additional 
metadata for the instance group.

I think this should fully support what we care about - nodes, edges, policies 
and metadata.

Do we all agree ?


Now going to the APIs,

Register GROUP API (from my doc [1]):


POST


/v3.0/{tenant_id}/groups


Register a group


I think the confusion is only about when the member (all nested members) and 
policy about when they are saved in the DB (registered, but not CREATED 
actually), such that we can associate a UUID.  This led to my original thinking 
that it is a 3-phase operation where we have to register (save in DB) the 
nested members first, then register the group as a whole.  But this is not 
client friendly.

Like I had suggested earlier, as an implementation detail of the Group 
registration API (CREATE part 1 in your terminology), we can support this: as 
part of the group registration transaction,  complete the registration of the 
nested members, get their UUIDs,  create the InstanceGroupMemberConnections, 
and then complete saving the group - resulting in a UUID for the group,  all in 
a single transaction-scope.  While you start the transaction, you can start 
with a UUID for the group, so that you can add the group_id pointers to the 
individual members,  and then finally complete the transaction.
This means,  you provide as an input to the REST API - the complete nested 
tree, including all the details about the nested members and policies, and the 
register API, will handle the saving of all the individual objects required.

But I think it does help to also add additional APIs to just register an 
InstanceGroupMember and  an InstanceGroupPolicy separately.  This might help 
the client while creating a group, rather than giving the entire nested tree.   
(his makes it a 3-phase) This API will support adding members and policies to 
an instance group that is created.  (you can start with an empty group)


POST


/v3.0/{tenant_id}/groups/instance


Register an instance belonging to an instancegroup



POST


/v3.0/{tenant_id}/groups/policy


Register a policy belonging to an instance group



Are we okay with this ?


The next API - is the actual creation of the resources.  (CREATE part 2  in 
your terminology).   This is was my create API in the doc-


POST


/v3.0/{tenant_id}/groups/{id}/create


Create and schedule an Instance group


This is just the API proposal, the underlying implementation details will 
involve all the required logic to ensure the creation of all the group members. 
 Here like you also suggest, as a starting point,  we can try to first use 
existing Nova mechanisms to create the members of this group.  Eventually we 
will need to get to the discussions for scheduling this entire group as a 
whole, which covers cross-services support like I discuss in the unified 
resource placement document - 
https://docs.google.com/document/d/1IiPI0sfaWb1bdYiMWzAAx0HYR6UqzOan_Utgml5W1HI/edit?pli=1

Let me know your thoughts on this.

Thanks,
Yathi.



























___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [scheduler] Policy Model

2013-10-14 Thread Yathiraj Udupi (yudupi)
Mike,

Like I proposed in my previous email about the model and the APIs,

About the InstanceGroupPolicy, why not leave it as is, and introduce a new 
abstract model class called Policy.
The InstanceGroupPolicy will be a reference to a Policy object saved separately.
and the policy field will point to the saved Policy object's unique name or 
id.

The new class Policy – can have the usual fields – id, name, uuid, and a 
dictionary of key-value pairs for any additional arguments about the policy.

This is in alignment with the model for InstanceGroupMember, which is a 
reference to an actual Instance Object saved in the DB.

I will color all the diamonds black to make it a composition I the UML diagram.

Thanks,
Yathi.







From: Mike Spreitzer mspre...@us.ibm.commailto:mspre...@us.ibm.com
Date: Monday, October 14, 2013 7:14 AM
To: Yathiraj Udupi yud...@cisco.commailto:yud...@cisco.com
Cc: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [scheduler] Policy Model

Could we agree on the following small changes to the model you posted last week?

1.  Rename InstanceGroupPolicy to InstanceGroupPolicyUse

2.  In InstanceGroupPolicy[Use], rename the policy field to policy_type

3.  Add an InstanceGroupPolicyUseProperty table, holding key/value pairs (two 
strings) giving the properties of the policy uses

4.  Color all the diamonds black

Thanks,
Mike
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [scheduler] APIs for Smart Resource Placement - Updated Instance Group Model and API extension model - WIP Draft

2013-10-08 Thread Yathiraj Udupi (yudupi)
Hi Sylvain,

Thanks for your comments.  I can see that Climate is aiming to provide a 
reservation service for physical and now virtual resources also like you 
mention.

The Instance-group [a][b] effort   (proposed during the last summit,  and good 
progress has been made so far)  attempts to address the tenant facing API 
aspects in the bigger Smart Resource Placement puzzle [c].
The idea is to be able to represent an entire topology (a group of resources) 
that is requested by the tenant, that contains members or sub-groups , their 
connections,  their associated policies and other metadata.

The first part is to be able to persist this group, and use the group to 
create/schedule the resources together as a whole group, so that intelligent 
decisions can be made together considering all the requirements and constraints 
(policies).

In the ongoing discussions in the Nova scheduler sub-team, we do agree that we 
need additional support to achieve the creation of the group as a whole.   It 
will involve reservation too to achieve this.

Once the Instance group is registered and persisted,  we can trigger the 
creation/boot up of the instances, which will involve arriving at the resource 
placement decisions and then the actual creation.  So one of the idea is to 
provide clear apis such an external component (such as climate, heat, or some 
other module) can take the placement decision results and do the actual 
creation of resource.

As described in [c], we will also need the support of a global state repository 
to make all the resource states from across services available to smart 
placement decision engine.

As part of the plan for [c],  the first step is to tackle the representation 
and API for these InstanceGroups, and that is this ongoing effort within the 
Nova Scheduler sub-team.

Our idea to separate the phases of this grand scale scheduling of resources, 
and keep the interfaces clean.  If we have to interface with Climate for the 
final creation (I.e., once the smart placement decisions have been made), we 
should be able to do that, at least that is the vision.


References
[a]Instance Group Model and API extension doc -  
https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit?usp=sharinghttps://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit?usp=sharing
[b] Instance group blueprint - 
https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension
[c] Smart Resource Placement  
https://docs.google.com/document/d/1IiPI0sfaWb1bdYiMWzAAx0HYR6UqzOan_Utgml5W1HI/edit

Thanks,
Yathi.





From: Sylvain Bauza sylvain.ba...@bull.netmailto:sylvain.ba...@bull.net
Date: Tuesday, October 8, 2013 12:40 AM
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Cc: Yathiraj Udupi yud...@cisco.commailto:yud...@cisco.com
Subject: Re: [openstack-dev] [scheduler] APIs for Smart Resource Placement - 
Updated Instance Group Model and API extension model - WIP Draft

Hi Yathi,

Le 08/10/2013 05:10, Yathiraj Udupi (yudupi) a écrit :
Hi,

Based on the discussions we have had in the past few scheduler sub-team 
meetings,  I am sharing a document that proposes an updated Instance Group 
Model and API extension model.
This is a work-in-progress draft version, but sharing it for early feedback.
https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit?usp=sharing

This model support generic instance types, where an instance can represent a 
virtual node of any resource type.  But in the context of Nova, an instance 
refers to the VM instance.

This builds on the existing proposal for Instance Group Extension as documented 
here in this blueprint:  
https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension

Thanks,
Yathi.



Well, I actually read the design document, and I'm strongly interested in 
jumping to the project.
We started a few months ago a Stackforge project, called Climate [0], aiming to 
reserve both physical and virtual resources. Initially, the project came from a 
blueprint targeting only physical reservations [1], and then Mirantis folks 
joined us having a new usecase for virtual reservations (potentially 
implementing deferred starts, as said above).

Basically, the physical host reservation is not about deferred starts of 
instances, it's about grouping for a single tenant a list of hosts, in other 
words a whole host allocation (see [2]).

We'll provide to end-users a Reservation API allowing to define policies for 
selecting hosts based on their capabilities [3] and then create host aggregates 
(or Pclouds if we implement [2]). Actually, we could define some policies in 
the Climate host aggregate for affinity and network-proximity policies, so that 
any VM to boot from one of these hosts would be applied these host aggregate 
policies.

As you maybe see, there are some concerns which are close in between your BP 
[4] and our

Re: [openstack-dev] [scheduler] APIs for Smart Resource Placement - Updated Instance Group Model and API extension model - WIP Draft

2013-10-08 Thread Yathiraj Udupi (yudupi)
 
with scheduling, then activate the resources in an acceptable order?

I can't answer for it, but as far as I can understand the draft, there is no 
clear understanding that we have to postpone the VM boot *after* creating the 
Groups.
As stated in the document, there is a strong prereq which is that all the 
resources mapped to the Group must have their own uuids, but there is no clear 
outstanding that it should prevent the VMs to actually boot.

At the moment, deferring a bootable state in Nova is not yet implemented and 
that's part of Climate folks to implement it, so I can't get your point.

-Sylvain


FYI: my group is using Weaver as the software orchestration technique, so there 
are no runtime dependencies that are mediated directly by the client.  The 
client sees a very simple API: the client presents a definition of all the 
groups and resources, and the service first schedules it all then activates in 
an acceptable order.  (We already have something in OpenStack that can do 
resource invocations in an acceptable order, right?)  Weaver is not the only 
software orchestration technique with this property.  The simplicity of this 
API is one reason I recommend software orchestration techniques that take 
dependency mediation out of the client's hands.  I hope that with coming work 
on HOT we can get OpenStack to this level of API simplicity.  But that struggle 
lies farther down the roadmap...

I was wondering if you could explain why you included all those integer IDs; 
aren't the UUIDs sufficient?  Do you intend that clients will see/manipulate 
the integer IDs?

If I understand your UML correctly, an InstanceGroup owns its metadata but none 
of the other subsidiary objects introduced.  Why not?  If an InstanceGroup is 
deleted, shouldn't all those other subsidiary objects be deleted too?

Thanks,
Mike

Yathiraj Udupi (yudupi) yud...@cisco.commailto:yud...@cisco.com wrote on 
10/07/2013 11:10:20 PM:
 Hi,

 Based on the discussions we have had in the past few scheduler sub-
 team meetings,  I am sharing a document that proposes an updated
 Instance Group Model and API extension model.
 This is a work-in-progress draft version, but sharing it for early feedback.
 https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit?usp=sharing

 This model support generic instance types, where an instance can
 represent a virtual node of any resource type.  But in the context
 of Nova, an instance refers to the VM instance.

 This builds on the existing proposal for Instance Group Extension as
 documented here in this blueprint:  https://
 blueprints.launchpad.net/nova/+spec/instance-group-api-extension

 Thanks,
 Yathi.




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.orghttp://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


[openstack-dev] [scheduler] APIs for Smart Resource Placement - Updated Instance Group Model and API extension model - WIP Draft

2013-10-07 Thread Yathiraj Udupi (yudupi)
Hi,

Based on the discussions we have had in the past few scheduler sub-team 
meetings,  I am sharing a document that proposes an updated Instance Group 
Model and API extension model.
This is a work-in-progress draft version, but sharing it for early feedback.
https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit?usp=sharing

This model support generic instance types, where an instance can represent a 
virtual node of any resource type.  But in the context of Nova, an instance 
refers to the VM instance.

This builds on the existing proposal for Instance Group Extension as documented 
here in this blueprint:  
https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension

Thanks,
Yathi.






___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [scheduler] Smart Resource Placement Vision - high level overview document

2013-09-23 Thread Yathiraj Udupi (yudupi)
Hi,

We have written a high-level vision document for Smart Resource Placement in 
Openstack.  This covers all the required solutions, and how it relates to some 
of the proposed blueprints.
So this is an attempt to bring the bits together, so that we can collaborate 
and work towards bringing all of this together.

Please review: 
https://docs.google.com/document/d/1IiPI0sfaWb1bdYiMWzAAx0HYR6UqzOan_Utgml5W1HI/edit?usp=sharing

Provides additional details for our proposal of a unified constraints-based 
resource placement engine.

Thanks,
Yathi.



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev