Hi All,
Last couple of month Mirantis team was working on new scalable scheduler
architecture. The main concept was proposed by Boris Pavlovic in the
following blue print
https://blueprints.launchpad.net/nova/+spec/no-db-scheduler and Alexey
Ovchinnikov prepared a bunch of patches
Excerpts from Herman Narkaytis's message of 2013-12-09 08:18:17 -0800:
Hi All,
Last couple of month Mirantis team was working on new scalable scheduler
architecture. The main concept was proposed by Boris Pavlovic in the
following blue print
The team size was a minimum, not a maximum - please add your names.
We're currently waiting on the prerequisite blueprint to land before
work starts in earnest; and for the blueprint to be approved (he says,
without having checked to see if it has been now:))
-Rob
On 3 December 2013 20:48,
Hi all
More volunteers for you - myself (Calum Loudon) and Colin Tregenza Dancer from
Metaswitch (http://metaswitch.com).
We're new to OpenStack development, so a bit of context: we develop software
for the telecoms space, ranging from low-level network stacks to voice
applications. We see
Russell Bryant wrote:
On 12/02/2013 11:41 AM, Thierry Carrez wrote:
I don't really care that much about deprecation in that case, but I care
about which release the new project is made part of. Would you make it
part of the Icehouse common release ? That means fast-tracking through
incubation
We are also interested in the proposal and would like to contribute
whatever we can.
Currently we're working on nova-scheduler we think that an independent
scheduler
is a need for Openstack. We've been engaging in several discussions on
this topic in
the ML as well as in Nova meeting, thus we were
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
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
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
On 12/03/2013 03:17 AM, Robert Collins wrote:
The team size was a minimum, not a maximum - please add your names.
We're currently waiting on the prerequisite blueprint to land before
work starts in earnest; and for the blueprint to be approved (he says,
without having checked to see if it
On 11/29/2013 10:01 AM, Thierry Carrez wrote:
Robert Collins wrote:
https://etherpad.openstack.org/p/icehouse-external-scheduler
Just looked into it with release management / TC hat on and I have a
(possibly minor) concern on the deprecation path/timing.
Assuming everything goes well, the
On 12/02/2013 09:13 AM, Russell Bryant wrote:
On 11/29/2013 10:01 AM, Thierry Carrez wrote:
Robert Collins wrote:
https://etherpad.openstack.org/p/icehouse-external-scheduler
Just looked into it with release management / TC hat on and I have a
(possibly minor) concern on the deprecation
On 12/02/2013 10:33 AM, Monty Taylor wrote:
Just because I'd like to argue - if what we do here is an actual
forklift, do we really need a cycle of deprecation?
The reason I ask is that this is, on first stab, not intended to be a
service that has user-facing API differences. It's a
On 12/2/13 5:39 PM, Russell Bryant rbry...@redhat.com wrote:
On 12/02/2013 10:33 AM, Monty Taylor wrote:
Just because I'd like to argue - if what we do here is an actual
forklift, do we really need a cycle of deprecation?
The reason I ask is that this is, on first stab, not intended to be
On 12/02/2013 10:53 AM, Gary Kotton wrote:
On 12/2/13 5:39 PM, Russell Bryant rbry...@redhat.com wrote:
On 12/02/2013 10:33 AM, Monty Taylor wrote:
Just because I'd like to argue - if what we do here is an actual
forklift, do we really need a cycle of deprecation?
The reason I ask is
On 12/2/13 5:33 PM, Monty Taylor mord...@inaugust.com wrote:
On 12/02/2013 09:13 AM, Russell Bryant wrote:
On 11/29/2013 10:01 AM, Thierry Carrez wrote:
Robert Collins wrote:
https://urldefense.proofpoint.com/v1/url?u=https://etherpad.openstack.o
Monty Taylor wrote:
On 12/02/2013 09:13 AM, Russell Bryant wrote:
On 11/29/2013 10:01 AM, Thierry Carrez wrote:
Robert Collins wrote:
https://etherpad.openstack.org/p/icehouse-external-scheduler
Just looked into it with release management / TC hat on and I have a
(possibly minor) concern on
On 12/02/2013 11:41 AM, Thierry Carrez wrote:
I don't really care that much about deprecation in that case, but I care
about which release the new project is made part of. Would you make it
part of the Icehouse common release ? That means fast-tracking through
incubation *and* integration in
On 12/02/2013 10:59 AM, Gary Kotton wrote:
I think that this is certainly different. It is something that we we want
and need a user facing API.
Examples:
- aggregates
- per host scheduling
- instance groups
Etc.
That is just taking the nova options into account and not the other
Le 02/12/2013 18:12, Russell Bryant a écrit :
On 12/02/2013 10:59 AM, Gary Kotton wrote:
I think that this is certainly different. It is something that we we want
and need a user facing API.
Examples:
- aggregates
- per host scheduling
- instance groups
Etc.
That is just taking the nova
On Dec 2, 2013, at 9:12 AM, Russell Bryant rbry...@redhat.com wrote:
On 12/02/2013 10:59 AM, Gary Kotton wrote:
I think that this is certainly different. It is something that we we want
and need a user facing API.
Examples:
- aggregates
- per host scheduling
- instance groups
Etc.
On 12/02/2013 03:31 PM, Vishvananda Ishaya wrote:
On Dec 2, 2013, at 9:12 AM, Russell Bryant rbry...@redhat.com
wrote:
On 12/02/2013 10:59 AM, Gary Kotton wrote:
I think that this is certainly different. It is something that
we we want and need a user facing API. Examples: - aggregates -
On 12/02/2013 02:31 PM, Vishvananda Ishaya wrote:
I'm going to reopen a can of worms, though. I think the most difficult part of
the forklift will be moving stuff out of the existing databases into
a new database.
Do we really need to move it to a new database for the forklift?
Chris
On Dec 2, 2013, at 12:38 PM, Russell Bryant rbry...@redhat.com wrote:
On 12/02/2013 03:31 PM, Vishvananda Ishaya wrote:
On Dec 2, 2013, at 9:12 AM, Russell Bryant rbry...@redhat.com
wrote:
On 12/02/2013 10:59 AM, Gary Kotton wrote:
I think that this is certainly different. It is
On 12/02/2013 04:49 PM, Vishvananda Ishaya wrote:
That is a good point. If the forklift is still talking to nova's
db then it would be significantly less duplication and i could see
doing it in the reverse order. The no-db-stuff should be done
before trying to implement cinder support so we
Lianhao Lu, Shuangtai Tian and I are also willing to join the team to
contribute because we are also changing scheduler, but it seems the team is
full. You can put us to the backup list.
Thanks.
--
Shane
-Original Message-
From: Robert Collins [mailto:robe...@robertcollins.net]
Sent:
The first stage is technical - move Nova scheduling code from A to be.
What do we achieve - not much - we actually complicate things - there
is always churn in Nova and we will have duplicate code bases. In
addition to this the only service that can actually make use of they
is Nova
On 11/28/13 11:34 PM, Robert Collins robe...@robertcollins.net wrote:
On 29 November 2013 09:44, Gary Kotton gkot...@vmware.com wrote:
The first stage is technical - move Nova scheduling code from A to be.
What do we achieve - not much - we actually complicate things - there is
always
Robert Collins wrote:
https://etherpad.openstack.org/p/icehouse-external-scheduler
Just looked into it with release management / TC hat on and I have a
(possibly minor) concern on the deprecation path/timing.
Assuming everything goes well, the separate scheduler will be
fast-tracked through
On 11/28/13 12:10 AM, Robert Collins robe...@robertcollins.net wrote:
On 25 November 2013 21:51, Sylvain Bauza sylvain.ba...@bull.net wrote:
As said earlier, I also would love to join the team, triggering a few
blueprints or so.
By the way, I'm currently reviewing the Scheduler code. Do you
On 11/28/2013 09:50 AM, Gary Kotton wrote:
One option worth thinking about is to introduce a new scheduling driver to
nova - this driver will interface with the external scheduler. This will
let us define the scheduling API, model etc, without being in the current
confines of Nova. This will
Le 28/11/2013 17:04, Chris Friesen a écrit :
On 11/28/2013 09:50 AM, Gary Kotton wrote:
One option worth thinking about is to introduce a new scheduling
driver to
nova - this driver will interface with the external scheduler. This will
let us define the scheduling API, model etc, without
On 29 November 2013 04:50, Gary Kotton gkot...@vmware.com wrote:
I am not really sure how we can have a client tree without even having
discussed the API's and interfaces. From the initial round of emails the
intention was to make use of the RPC mechanism to speak with the scheduler.
It still
On 29 November 2013 09:44, Gary Kotton gkot...@vmware.com wrote:
The first stage is technical - move Nova scheduling code from A to be.
What do we achieve - not much - we actually complicate things - there is
always churn in Nova and we will have duplicate code bases. In addition to
this the
On 25 November 2013 21:51, Sylvain Bauza sylvain.ba...@bull.net wrote:
As said earlier, I also would love to join the team, triggering a few
blueprints or so.
By the way, I'm currently reviewing the Scheduler code. Do you began to
design the API queries or do you need help for that ?
As said earlier, I also would love to join the team, triggering a few
blueprints or so.
By the way, I'm currently reviewing the Scheduler code. Do you began to
design the API queries or do you need help for that ?
-Sylvain
Le 25/11/2013 08:24, Haefliger, Juerg a écrit :
Hi Robert,
I see
I think everyone agrees we need a unified scheduler. Boris' approach
is to move the storage to memcache so the DB is no longer part of the
picture, and then move the scheduler out of Nova, rinse and repeat for
Cinder etc.
My approach is to move the scheduler out of Nova, and then let folk do
Robert,
Btw, I would like to be a volunteer too=)
Best regards,
Boris Pavlovic
On Sun, Nov 24, 2013 at 10:43 PM, Robert Collins
robe...@robertcollins.netwrote:
On 22 November 2013 23:55, Gary Kotton gkot...@vmware.com wrote:
I'm looking for 4-5 folk who have:
- modest Nova
On 25 November 2013 08:08, Boris Pavlovic bpavlo...@mirantis.com wrote:
Robert,
Btw, I would like to be a volunteer too=)
Best regards,
Boris Pavlovic
Awesome, added to the etherpad!
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
Hi Robert,
I see you have enough volunteers. You can put me on the backup list in case
somebody drops out or you need additional bodies.
Regards
...Juerg
From: Boris Pavlovic [mailto:bpavlo...@mirantis.com]
Sent: Sunday, November 24, 2013 8:09 PM
To: OpenStack Development Mailing List (not
Great initiative!
I would certainly be interested taking part in this -- although I wouldn't
necessary claim to be among people with the know-how to design and
implement it well. For sure this is going to be a painful but exciting
process.
Regards,
Alex
From: Robert Collins
I'd very much like to take part in the discussions. Depending on the
outcome of said discussion, I may or may not want to participate in
the implementation :)
Soren Hansen | http://linux2go.dk/
Ubuntu Developer | http://www.ubuntu.com/
OpenStack Developer |
I'm still a newbie here, so can not claim my Nova skills are even
modest. But I'd like to track this, if nothing more.
Thanks,
Mike___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
Dear all,
I'm very interested in this subject as well. Actually there is also a
discussion of the possibility of an independent scheduler in the mailisg list:
http://lists.openstack.org/pipermail/openstack-dev/2013-November/019518.html
Would it be possible to discuss about this subject in the
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
De : Robert Collins [robe...@robertcollins.net]
Date d'envoi : jeudi 21 novembre 2013 21:58
À : OpenStack Development Mailing List
Objet : [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest
proposal for an external scheduler in our
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
Robert,
It is nice that community like idea of making one scheduler as a service.
But I saw in https://etherpad.openstack.org/p/icehouse-external-schedulersome
misleading about
https://blueprints.launchpad.net/nova/+spec/no-db-scheduler
Approach no-db-scheduler is actually base step that
On 22 November 2013 15:57, Boris Pavlovic bpavlo...@mirantis.com wrote:
Robert,
It is nice that community like idea of making one scheduler as a service.
But I saw in https://etherpad.openstack.org/p/icehouse-external-scheduler
some misleading about
49 matches
Mail list logo
