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
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
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.
. 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
? 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
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
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
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
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
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
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
://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
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
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
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
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
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
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
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
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
.
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
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
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:
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
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
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
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
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.
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
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
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
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
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
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
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.
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
36 matches
Mail list logo
