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

2013-12-09 Thread Herman Narkaytis
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
https://review.openstack.org/#/c/45867/9
  This patch set was intensively reviewed by community and there was a call
for some kind of documentation that describes overall architecture and
details of implementation. Here is an etherpad document
https://etherpad.openstack.org/p/scheduler-design-proposal (a copy in
google doc
https://docs.google.com/a/mirantis.com/document/d/1irmDDYWWKWAGWECX8bozu8AAmzgQxMCAAdjhk53L9aM/edit
).
  Comments and critics are highly welcome.

HHN.



On Wed, Dec 4, 2013 at 12:12 AM, Russell Bryant rbry...@redhat.com wrote:

 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 has been now:))

 I approved it.

 https://blueprints.launchpad.net/nova/+spec/forklift-scheduler-breakout

 Once this is moving, please keep me in the loop on progress.

 --
 Russell Bryant

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




-- 
Herman Narkaytis
DoO Ru, PhD
Tel.: +7 (8452) 674-555, +7 (8452) 431-555
Tel.: +7 (495) 640-4904
Tel.: +7 (812) 640-5904
Tel.: +38(057)728-4215
Tel.: +1 (408) 715-7897
ext 2002
http://www.mirantis.com

This email (including any attachments) is confidential. If you are not the
intended recipient you must not copy, use, disclose, distribute or rely on
the information contained in it. If you have received this email in error,
please notify the sender immediately by reply email and delete the email
from your system. Confidentiality and legal privilege attached to this
communication are not waived or lost by reason of mistaken delivery to you.
Mirantis does not guarantee (that this email or the attachment's) are
unaffected by computer virus, corruption or other defects. Mirantis may
monitor incoming and outgoing emails for compliance with its Email Policy.
Please note that our servers may not be located in your country.
___
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-09 Thread Clint Byrum
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
 https://blueprints.launchpad.net/nova/+spec/no-db-scheduler and Alexey
 Ovchinnikov prepared a bunch of patches
 https://review.openstack.org/#/c/45867/9
   This patch set was intensively reviewed by community and there was a call
 for some kind of documentation that describes overall architecture and
 details of implementation. Here is an etherpad document
 https://etherpad.openstack.org/p/scheduler-design-proposal (a copy in
 google doc
 https://docs.google.com/a/mirantis.com/document/d/1irmDDYWWKWAGWECX8bozu8AAmzgQxMCAAdjhk53L9aM/edit
 ).
   Comments and critics are highly welcome.
 

Looks great. I think I would post this message as new rather than a
reply. It it isn't really related to the original thread. Many people
who are interested in scheduler improvements may have already killed this
thread in their mail reader and thus may miss your excellent message. :)

___
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 Robert Collins
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, Wang, Shane shane.w...@intel.com wrote:
 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: Friday, November 22, 2013 4:59 AM
 To: OpenStack Development Mailing List
 Subject: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest 
 proposal for an external scheduler in our lifetime

 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



-- 
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


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

2013-12-03 Thread Calum Loudon
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 enormous interest in the idea of the software Telco, 
with telecoms providers now really understanding cloud and wanting to move to 
it; you may have heard of Network Functions Virtualisation (NFV), a big push by 
the telecoms industry to define how this will work, and which implicitly 
assumes OpenStack as the underlying cloud platform.

NFV needs a few things OpenStack doesn't currently provide, mainly due to the 
extremely high reliability  bandwidth/latency requirements of Telco-grade apps 
compared to typical Enterprise-grade data apps, and we want to contribute code 
to help close those gaps.  From what I learnt in Hong Kong, I think that 
initially means richer placement policies (e.g. more advanced (anti)affinity 
rules; locating VMs close to storage or networks; globally-optimal placement) 
and if I'm following this list correctly then I think this activity is the 
first step towards that goal, enabling in future phases Yathi's vision of 
instance groups with smart resource placement [1] which closely resembles our 
own.

So we'd love to help in whatever way is needed - please count us in.

cheers

Calum

[1] 
https://docs.google.com/document/d/1IiPI0sfaWb1bdYiMWzAAx0HYR6UqzOan_Utgml5W1HI/edit


Calum Loudon
Director of Architecture
Metaswitch Networks
 
P   +44 (0)208 366 1177
E   calum.lou...@metaswitch.com


-Original Message-
From: Robert Collins [mailto:robe...@robertcollins.net] 
Sent: Friday, November 22, 2013 4:59 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest 
proposal for an external scheduler in our lifetime

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 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 Thierry Carrez
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 *and* integration in less than one cycle... I'm not sure we
 want that.

 I agree it's the same code (at least at the beginning), but the idea
 behind forcing all projects to undergo a full cycle before being made
 part of the release is not really about code stability, it's about
 integration with the other projects and all the various programs. We
 want them to go through a whole cycle to avoid putting unnecessary
 stress on packagers, QA, docs, infrastructure and release management.

 So while I agree that we could play tricks around deprecation, I'm not
 sure we should go from forklifted to part of the common release in less
 than 3 months.

 I'm not sure it would buy us anything, either. Having the scheduler
 usable by the end of the Icehouse cycle and integrated in the J cycle
 lets you have one release where both options are available, remove it
 first thing in J and then anyone running J (be it tracking trunk or
 using the final release) is using the external scheduler. That makes
 more sense to me and technically, you still have the option to use it
 with Icehouse.
 
 Not having to maintain code in 2 places is what it buys us.  However,
 this particular point is a bit moot until we actually had it done and
 working.  Perhaps we should just revisit the deprecation plan once we
 actually have the thing split out and running.

Agreed. My position on this would probably be different if the forklift
had been completed one month ago and we had 5 months of 'integration'.
With the current timing however, I think we'll have to have the code in
two places by the icehouse release.

That said, if we mark the nova-scheduler Icehouse code deprecated and
remove it early in J, the dual-maintenance burden is limited. The only
obligation we'd have would be security backports, and the scheduler has
been relatively vulnerability-free so far.

-- 
Thierry Carrez (ttx)

___
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 Khanh-Toan Tran
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 thrilled to hear your
proposal.

PS: I've written in a mail expressing our interest in this topic earlier ,
but I feel it's better
to have an more official submission to join the team :)

Best regards,

Jerome Gallard  Khanh-Toan Tran

 -Message d'origine-
 De : Robert Collins [mailto:robe...@robertcollins.net]
 Envoyé : mardi 3 décembre 2013 09:18
 À : OpenStack Development Mailing List (not for usage questions)
 Objet : Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a
modest
 proposal for an external scheduler in our lifetime

 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


___
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 Boris Pavlovic
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:

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


Best regards,
Boris Pavlovic



On Tue, Dec 3, 2013 at 1:11 PM, Khanh-Toan Tran 
khanh-toan.t...@cloudwatt.com wrote:

 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 thrilled to hear your
 proposal.

 PS: I've written in a mail expressing our interest in this topic earlier ,
 but I feel it's better
 to have an more official submission to join the team :)

 Best regards,

 Jerome Gallard  Khanh-Toan Tran

  -Message d'origine-
  De : Robert Collins [mailto:robe...@robertcollins.net]
  Envoyé : mardi 3 décembre 2013 09:18
  À : OpenStack Development Mailing List (not for usage questions)
  Objet : Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a
 modest
  proposal for an external scheduler in our lifetime
 
  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
 

 ___
 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][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime

2013-12-03 Thread Russell Bryant
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.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-12-03 Thread Russell Bryant
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 has been now:))

I approved it.

https://blueprints.launchpad.net/nova/+spec/forklift-scheduler-breakout

Once this is moving, please keep me in the loop on progress.

-- 
Russell Bryant

___
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-02 Thread Russell Bryant
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 separate scheduler will be
 fast-tracked through incubation in I, graduate at the end of the I cycle
 to be made a fully-integrated project in the J release.
 
 Your deprecation path description mentions that the internal scheduler
 will be deprecated in I, although there is no released (or
 security-supported) alternative to switch to at that point. It's not
 until the J release that such an alternative will be made available.
 
 So IMHO for the release/security-oriented users, the switch point is
 when they start upgrading to J, and not the final step of their upgrade
 to I (as suggested by the deploy the external scheduler and switch over
 before you consider your migration to I complete wording in the
 Etherpad). As the first step towards *switching to J* you would install
 the new scheduler before upgrading Nova itself. That works whether
 you're a CD user (and start deploying pre-J stuff just after the I
 release), or a release user (and wait until J final release to switch to
 it).
 
 Maybe we are talking about the same thing (the migration to the separate
 scheduler must happen after the I release and, at the latest, when you
 switch to the J release) -- but I wanted to make sure we were on the
 same page.

Sounds good to me.

 I also assume that all the other scheduler-consuming projects would
 develop the capability to talk to the external scheduler during the J
 cycle, so that their own schedulers would be deprecated in J release and
 removed at the start of H. That would be, to me, the condition to
 considering the external scheduler as integrated with (even if not
 mandatory for) the rest of the common release components.
 
 Does that work for you ?

I would change all the other to at least one other here.  I think
once we prove that a second project can be integrated into it, the
project is ready to be integrated.  Adding support for even more
projects is something that will continue to happen over a longer period
of time, I suspect, especially since new projects are coming in every cycle.

-- 
Russell Bryant

___
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-02 Thread Monty Taylor


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 path/timing.

 Assuming everything goes well, the separate scheduler will be
 fast-tracked through incubation in I, graduate at the end of the I cycle
 to be made a fully-integrated project in the J release.

 Your deprecation path description mentions that the internal scheduler
 will be deprecated in I, although there is no released (or
 security-supported) alternative to switch to at that point. It's not
 until the J release that such an alternative will be made available.

 So IMHO for the release/security-oriented users, the switch point is
 when they start upgrading to J, and not the final step of their upgrade
 to I (as suggested by the deploy the external scheduler and switch over
 before you consider your migration to I complete wording in the
 Etherpad). As the first step towards *switching to J* you would install
 the new scheduler before upgrading Nova itself. That works whether
 you're a CD user (and start deploying pre-J stuff just after the I
 release), or a release user (and wait until J final release to switch to
 it).

 Maybe we are talking about the same thing (the migration to the separate
 scheduler must happen after the I release and, at the latest, when you
 switch to the J release) -- but I wanted to make sure we were on the
 same page.
 
 Sounds good to me.
 
 I also assume that all the other scheduler-consuming projects would
 develop the capability to talk to the external scheduler during the J
 cycle, so that their own schedulers would be deprecated in J release and
 removed at the start of H. That would be, to me, the condition to
 considering the external scheduler as integrated with (even if not
 mandatory for) the rest of the common release components.

 Does that work for you ?
 
 I would change all the other to at least one other here.  I think
 once we prove that a second project can be integrated into it, the
 project is ready to be integrated.  Adding support for even more
 projects is something that will continue to happen over a longer period
 of time, I suspect, especially since new projects are coming in every cycle.

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 reorganization of
code from one repo into a different one. It's very strongly designed to
not be different. It's not even adding a new service like conductor was
- it's simply moving the repo where the existing service is held.

Why would we need/want to deprecate? I say that if we get the code
ectomied and working before nova feature freeze, that we elevate the new
nova repo and delete the code from nova. Process for process sake here
I'm not sure gets us anywhere.

Monty

___
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-02 Thread Russell Bryant
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 reorganization of
 code from one repo into a different one. It's very strongly designed to
 not be different. It's not even adding a new service like conductor was
 - it's simply moving the repo where the existing service is held.
 
 Why would we need/want to deprecate? I say that if we get the code
 ectomied and working before nova feature freeze, that we elevate the new
 nova repo and delete the code from nova. Process for process sake here
 I'm not sure gets us anywhere.

That makes sense to me, actually.

I suppose part of the issue is that we're not positive how much work
will happen to the code *after* the forklift.  Will we have other
services integrated?  Will it have its own database?  How different is
different enough to warrant needing a deprecation cycle?

-- 
Russell Bryant

___
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-02 Thread Gary Kotton


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 a
 service that has user-facing API differences. It's a reorganization of
 code from one repo into a different one. It's very strongly designed to
 not be different. It's not even adding a new service like conductor was
 - it's simply moving the repo where the existing service is held.
 
 Why would we need/want to deprecate? I say that if we get the code
 ectomied and working before nova feature freeze, that we elevate the new
 nova repo and delete the code from nova. Process for process sake here
 I'm not sure gets us anywhere.

That makes sense to me, actually.

I suppose part of the issue is that we're not positive how much work
will happen to the code *after* the forklift.  Will we have other
services integrated?  Will it have its own database?  How different is
different enough to warrant needing a deprecation cycle?

I have concerns with the forklift. There are at least 1 or 2 changes a
week to the scheduling code (and the is is not taking into account new
features being added). Will these need to be updated in 2 separate code
bases? How do we ensure that both are in sync for the interim period. I am
really sorry for playing devils advocate but I really think that there are
too many issues and we have yet to iron them out. This should not prevent
us from doing it but lets at least be aware of what is waiting ahead.


-- 
Russell Bryant

___
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=e
H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=D6xsP98tUQhdMCSQYclCv
Bu6a28phHWronAJfm0sZwE%3D%0As=d306716b35d97764ffdf5a1b54427a6167c32ae1cef
fc3b41a7525e684d48d2d


___
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-02 Thread Russell Bryant
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 that this is, on first stab, not intended to be a
 service that has user-facing API differences. It's a reorganization of
 code from one repo into a different one. It's very strongly designed to
 not be different. It's not even adding a new service like conductor was
 - it's simply moving the repo where the existing service is held.

 Why would we need/want to deprecate? I say that if we get the code
 ectomied and working before nova feature freeze, that we elevate the new
 nova repo and delete the code from nova. Process for process sake here
 I'm not sure gets us anywhere.

 That makes sense to me, actually.

 I suppose part of the issue is that we're not positive how much work
 will happen to the code *after* the forklift.  Will we have other
 services integrated?  Will it have its own database?  How different is
 different enough to warrant needing a deprecation cycle?
 
 I have concerns with the forklift. There are at least 1 or 2 changes a
 week to the scheduling code (and the is is not taking into account new
 features being added). Will these need to be updated in 2 separate code
 bases? How do we ensure that both are in sync for the interim period. I am
 really sorry for playing devils advocate but I really think that there are
 too many issues and we have yet to iron them out. This should not prevent
 us from doing it but lets at least be aware of what is waiting ahead.

This is one of the reasons that I think the forklift is a *good* idea.
It's what will enable us to do it as fast as possible and minimize the
time we're dealing with 2 code bases.  It could be just 1 deprecation
cycle, or just a matter of a few weeks if we settle on what Monty is
suggesting.

What we *don't* want is something like Neutron and nova-network, where
we end up maintaining two implementations of a thing for a long, long time.

-- 
Russell Bryant

___
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-02 Thread Gary Kotton


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
rg/p/icehouse-external-schedulerk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=
eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=nlm44OzEwIEFTzGCf
k6Dx1Lc0g7KHrY0h78JGykLd0s%3D%0As=0b234ac4dbe29b80b61b0d53be18362c3743
299f908abc97941bfdb6f4c0c9da

 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 incubation in I, graduate at the end of the I
cycle
 to be made a fully-integrated project in the J release.

 Your deprecation path description mentions that the internal scheduler
 will be deprecated in I, although there is no released (or
 security-supported) alternative to switch to at that point. It's not
 until the J release that such an alternative will be made available.

 So IMHO for the release/security-oriented users, the switch point is
 when they start upgrading to J, and not the final step of their upgrade
 to I (as suggested by the deploy the external scheduler and switch
over
 before you consider your migration to I complete wording in the
 Etherpad). As the first step towards *switching to J* you would install
 the new scheduler before upgrading Nova itself. That works whether
 you're a CD user (and start deploying pre-J stuff just after the I
 release), or a release user (and wait until J final release to switch
to
 it).

 Maybe we are talking about the same thing (the migration to the
separate
 scheduler must happen after the I release and, at the latest, when you
 switch to the J release) -- but I wanted to make sure we were on the
 same page.
 
 Sounds good to me.
 
 I also assume that all the other scheduler-consuming projects would
 develop the capability to talk to the external scheduler during the J
 cycle, so that their own schedulers would be deprecated in J release
and
 removed at the start of H. That would be, to me, the condition to
 considering the external scheduler as integrated with (even if not
 mandatory for) the rest of the common release components.

 Does that work for you ?
 
 I would change all the other to at least one other here.  I think
 once we prove that a second project can be integrated into it, the
 project is ready to be integrated.  Adding support for even more
 projects is something that will continue to happen over a longer period
 of time, I suspect, especially since new projects are coming in every
cycle.

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 reorganization of
code from one repo into a different one. It's very strongly designed to
not be different. It's not even adding a new service like conductor was
- it's simply moving the repo where the existing service is held.

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
modules. How doul one configure that we would like to have storage
proximity for a VM? This is where things start to get very interesting and
enable the cross service scheduling (which is the goal of this no?).

Thanks
Gary


Why would we need/want to deprecate? I say that if we get the code
ectomied and working before nova feature freeze, that we elevate the new
nova repo and delete the code from nova. Process for process sake here
I'm not sure gets us anywhere.

Monty

___
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=e
H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=nlm44OzEwIEFTzGCfk6Dx
1Lc0g7KHrY0h78JGykLd0s%3D%0As=e39dbfa0d3ca06da0fe8785a05a337a7c046c1634b3
7b24f9822e686596e4265


___
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-02 Thread Thierry Carrez
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 the deprecation path/timing.

 Assuming everything goes well, the separate scheduler will be
 fast-tracked through incubation in I, graduate at the end of the I cycle
 to be made a fully-integrated project in the J release.

 Your deprecation path description mentions that the internal scheduler
 will be deprecated in I, although there is no released (or
 security-supported) alternative to switch to at that point. It's not
 until the J release that such an alternative will be made available.

 So IMHO for the release/security-oriented users, the switch point is
 when they start upgrading to J, and not the final step of their upgrade
 to I (as suggested by the deploy the external scheduler and switch over
 before you consider your migration to I complete wording in the
 Etherpad). As the first step towards *switching to J* you would install
 the new scheduler before upgrading Nova itself. That works whether
 you're a CD user (and start deploying pre-J stuff just after the I
 release), or a release user (and wait until J final release to switch to
 it).

 Maybe we are talking about the same thing (the migration to the separate
 scheduler must happen after the I release and, at the latest, when you
 switch to the J release) -- but I wanted to make sure we were on the
 same page.

 Sounds good to me.

 I also assume that all the other scheduler-consuming projects would
 develop the capability to talk to the external scheduler during the J
 cycle, so that their own schedulers would be deprecated in J release and
 removed at the start of H. That would be, to me, the condition to
 considering the external scheduler as integrated with (even if not
 mandatory for) the rest of the common release components.

 Does that work for you ?

 I would change all the other to at least one other here.  I think
 once we prove that a second project can be integrated into it, the
 project is ready to be integrated.  Adding support for even more
 projects is something that will continue to happen over a longer period
 of time, I suspect, especially since new projects are coming in every cycle.
 
 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 reorganization of
 code from one repo into a different one. It's very strongly designed to
 not be different. It's not even adding a new service like conductor was
 - it's simply moving the repo where the existing service is held.
 
 Why would we need/want to deprecate? I say that if we get the code
 ectomied and working before nova feature freeze, that we elevate the new
 nova repo and delete the code from nova. Process for process sake here
 I'm not sure gets us anywhere.

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 less than one cycle... I'm not sure we
want that.

I agree it's the same code (at least at the beginning), but the idea
behind forcing all projects to undergo a full cycle before being made
part of the release is not really about code stability, it's about
integration with the other projects and all the various programs. We
want them to go through a whole cycle to avoid putting unnecessary
stress on packagers, QA, docs, infrastructure and release management.

So while I agree that we could play tricks around deprecation, I'm not
sure we should go from forklifted to part of the common release in less
than 3 months.

I'm not sure it would buy us anything, either. Having the scheduler
usable by the end of the Icehouse cycle and integrated in the J cycle
lets you have one release where both options are available, remove it
first thing in J and then anyone running J (be it tracking trunk or
using the final release) is using the external scheduler. That makes
more sense to me and technically, you still have the option to use it
with Icehouse.

-- 
Thierry Carrez (ttx)

___
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-02 Thread Russell Bryant
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 less than one cycle... I'm not sure we
 want that.
 
 I agree it's the same code (at least at the beginning), but the idea
 behind forcing all projects to undergo a full cycle before being made
 part of the release is not really about code stability, it's about
 integration with the other projects and all the various programs. We
 want them to go through a whole cycle to avoid putting unnecessary
 stress on packagers, QA, docs, infrastructure and release management.
 
 So while I agree that we could play tricks around deprecation, I'm not
 sure we should go from forklifted to part of the common release in less
 than 3 months.
 
 I'm not sure it would buy us anything, either. Having the scheduler
 usable by the end of the Icehouse cycle and integrated in the J cycle
 lets you have one release where both options are available, remove it
 first thing in J and then anyone running J (be it tracking trunk or
 using the final release) is using the external scheduler. That makes
 more sense to me and technically, you still have the option to use it
 with Icehouse.
 

Not having to maintain code in 2 places is what it buys us.  However,
this particular point is a bit moot until we actually had it done and
working.  Perhaps we should just revisit the deprecation plan once we
actually have the thing split out and running.

-- 
Russell Bryant

___
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-02 Thread Russell Bryant
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
 modules. How doul one configure that we would like to have storage
 proximity for a VM? This is where things start to get very interesting and
 enable the cross service scheduling (which is the goal of this no?).

An explicit part of this plan is that all of the things you're talking
about are *not* in scope until the forklift is complete and the new
thing is a functional replacement for the existing nova-scheduler.  We
want to get the project established and going so that it is a place
where this work can take place.  We do *not* want to slow down the work
of getting the project established by making these things a prerequisite.

-- 
Russell Bryant

___
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-02 Thread Sylvain Bauza

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 options into account and not the other
modules. How doul one configure that we would like to have storage
proximity for a VM? This is where things start to get very interesting and
enable the cross service scheduling (which is the goal of this no?).

An explicit part of this plan is that all of the things you're talking
about are *not* in scope until the forklift is complete and the new
thing is a functional replacement for the existing nova-scheduler.  We
want to get the project established and going so that it is a place
where this work can take place.  We do *not* want to slow down the work
of getting the project established by making these things a prerequisite.

While I can understand we need to secure the forklift, I also think it 
would be a good thing to step up defining what would be the 
scheduling-as-a-service in the next steps even if they are not planned yet.


There is already an RPC interface defining what *is* the scheduler, my 
concern is just to make sure this API (RPC or REST anyway) wouldn't it 
be too sticked to Nova instances so that planning to deliver for Cinder 
volumes or Nova hosts would be hard.
In other terms, having the RPC methods enough generic to say add this 
entity to this group or elect entities from this group would be fine.


-Sylvain


___
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-02 Thread Vishvananda Ishaya

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.
 
 That is just taking the nova options into account and not the other
 modules. How doul one configure that we would like to have storage
 proximity for a VM? This is where things start to get very interesting and
 enable the cross service scheduling (which is the goal of this no?).
 
 An explicit part of this plan is that all of the things you're talking
 about are *not* in scope until the forklift is complete and the new
 thing is a functional replacement for the existing nova-scheduler.  We
 want to get the project established and going so that it is a place
 where this work can take place.  We do *not* want to slow down the work
 of getting the project established by making these things a prerequisite.


I'm all for the forklift approach since I don't think we will make any progress
if we stall going back into REST api design.

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. We had to deal with this in cinder and having a db export
and import strategy is annoying to say the least. Managing the db-related
code was the majority of the work during the cinder split.

I think this forklift will be way easier if we merge the no-db-scheduler[1]
patches first before separating the scheduler out into its own project:

https://blueprints.launchpad.net/nova/+spec/no-db-scheduler

I think the effort to get this finished is smaller than the effort to write
db migrations and syncing scripts for the new project.

Vish


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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-02 Thread Russell Bryant
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 -
 per host scheduling - instance groups
 
 Etc.
 
 That is just taking the nova options into account and not the
 other modules. How doul one configure that we would like to
 have storage proximity for a VM? This is where things start to
 get very interesting and enable the cross service scheduling
 (which is the goal of this no?).
 
 An explicit part of this plan is that all of the things you're
 talking about are *not* in scope until the forklift is complete
 and the new thing is a functional replacement for the existing
 nova-scheduler.  We want to get the project established and going
 so that it is a place where this work can take place.  We do
 *not* want to slow down the work of getting the project
 established by making these things a prerequisite.
 
 
 I'm all for the forklift approach since I don't think we will make
 any progress if we stall going back into REST api design.
 
 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. We had to deal with this in
 cinder and having a db export and import strategy is annoying to
 say the least. Managing the db-related code was the majority of the
 work during the cinder split.
 
 I think this forklift will be way easier if we merge the
 no-db-scheduler[1] patches first before separating the scheduler
 out into its own project:
 
 https://blueprints.launchpad.net/nova/+spec/no-db-scheduler
 
 I think the effort to get this finished is smaller than the effort
 to write db migrations and syncing scripts for the new project.

Agreed that this should make it easier.

My thought was that the split out scheduler could just import nova's
db API and use it against nova's database directly until this work
gets done.  If the forklift goes that route instead of any sort of
work to migrate data from one db to another, they could really happen
in any order, I think.

-- 
Russell Bryant

___
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-02 Thread Chris Friesen

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

___
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-02 Thread Vishvananda Ishaya

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 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 modules. How doul one configure that we would like to
 have storage proximity for a VM? This is where things start to
 get very interesting and enable the cross service scheduling
 (which is the goal of this no?).
 
 An explicit part of this plan is that all of the things you're
 talking about are *not* in scope until the forklift is complete
 and the new thing is a functional replacement for the existing
 nova-scheduler.  We want to get the project established and going
 so that it is a place where this work can take place.  We do
 *not* want to slow down the work of getting the project
 established by making these things a prerequisite.
 
 
 I'm all for the forklift approach since I don't think we will make
 any progress if we stall going back into REST api design.
 
 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. We had to deal with this in
 cinder and having a db export and import strategy is annoying to
 say the least. Managing the db-related code was the majority of the
 work during the cinder split.
 
 I think this forklift will be way easier if we merge the
 no-db-scheduler[1] patches first before separating the scheduler
 out into its own project:
 
 https://blueprints.launchpad.net/nova/+spec/no-db-scheduler
 
 I think the effort to get this finished is smaller than the effort
 to write db migrations and syncing scripts for the new project.
 
 Agreed that this should make it easier.
 
 My thought was that the split out scheduler could just import nova's
 db API and use it against nova's database directly until this work
 gets done.  If the forklift goes that route instead of any sort of
 work to migrate data from one db to another, they could really happen
 in any order, I think.


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 don't have the messiness of the
scheduler talking to multiple db apis.

Vish

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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-02 Thread Russell Bryant
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 don't have the
 messiness of the scheduler talking to multiple db apis.

+1

-- 
Russell Bryant

___
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-02 Thread Wang, Shane
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: Friday, November 22, 2013 4:59 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest 
proposal for an external scheduler in our lifetime

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


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

2013-11-29 Thread Khanh-Toan Tran
  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
 
  The second stage is defining an API that other modules can use (we
  have yet to decide if this will be RPC based or have a interface like
  Glance, Cinder etc.) We have yet to even talk about the API's.
  The third stage is adding shiny new features and trying to not have a
  community tar and feather us.
 
 Yup; I look forward to our tar and feathering overlords. :)
 
  Prior to copying code we really need to discuss the API's.
 
 I don't think we do: it's clear that we need to come up with them - it's
necessary,
 and noone has expressed any doubt about the ability to do that. RPC API
 evolution is fairly well understood - we add a new method, and have it
do the
 necessary, then we go to the users and get them using it, then we delete
the old
 one.
 
I agree with Robert. I think that nova RPC is fairly enough for the new
scheduler 
right now. Most of the scheduler works focus on nova anyway, so starting
from there 
is reasonable and rather easy for the transition. We can think of
enhancing API later 
(even creating REST API perhaps).

  This can even
  be done in parallel if your concern is time and resources. But the
  point is we need a API to interface with the service. For a start we
  can just address the Nova use case. We need to at least address:
  1. Scheduling interface
  2. Statistics updates
  3. API's for configuring the scheduling policies
 
If by 2. Statistics update you mean the database issue for scheduler
then yes, it
is a  big issue, especially during the transition period when nova still
holds the host state
data. Should scheduler get access to nova's DB for the time being, and
later fork out the
DB to scheduler? According to Boris, Merantis has already studied the
separation of host state
from nova's DB. I think we can benefit from their experience.

___
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-29 Thread Gary Kotton


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 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

 The second stage is defining an API that other modules can use (we have
 yet to decide if this will be RPC based or have a interface like Glance,
 Cinder etc.)
 We have yet to even talk about the API's.
 The third stage is adding shiny new features and trying to not have a
 community tar and feather us.

Yup; I look forward to our tar and feathering overlords. :)

 Prior to copying code we really need to discuss the API's.

I don't think we do: it's clear that we need to come up with them -
it's necessary, and noone has expressed any doubt about the ability to
do that. RPC API evolution is fairly well understood - we add a new
method, and have it do the necessary, then we go to the users and get
them using it, then we delete the old one.

 This can even
 be done in parallel if your concern is time and resources. But the point
 is we need a API to interface with the service. For a start we can just
 address the Nova use case. We need to at least address:
 1. Scheduling interface
 2. Statistics updates
 3. API's for configuring the scheduling policies

 Later these will all need to bode well with all of the existing modules
 that we want to support - Nova, Cinder and Neutron (if I missed on then
 feel free to kick me whilst I am down)

Ironic perhaps.

 I do not think that we should focus on failure modes, we should plan it
 and break it up so that it will be usable and functional and most
 importantly useful in the near future.

 How about next week we sit together and draw up a wiki of the flows,
data
 structures and interfaces. Lets go from there.

While I disagree about us needing to do it right now, I'm very happy
to spend some time on it - I don't want to stop folk doing work that
needs to be done!

I do not think that discussion will prevent any of the work getting done
or not done. It may actually save us a ton of time. I really think that
defining the API and interfaces can save us a lot in the short and long
run. The V1 API should really be very simple and we should not get bogged
down but if we can define an interface that could work with Nova and be
extensible to work with the rest then we will be in a very good state. I
am thinking of have a notion of a 'scheduling domain' and that will be
used with the scheduling request. This could be a host aggregate, a AZ,
the feature that Phil is working on - private hosts. If we can define an
interface around this and have the Nova - scheduling interface down then
we are on the wayŠ.

Hosts scan be added to the domain and the scheduling will be able to get
the stats etc. For the first phase this will be completely RPC bases so
not to get bogged down.

Can we talk about this next week?


-Rob



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

___
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=e
H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=m8Unw2sBiRyQsd6ADjYCH
CpcxAKBG1Gb3R58ehl3wIw%3D%0As=6c2d9b2f3b884693094cffc0392402f24b50ddac3d9
d956472d26c726c84a2a6


___
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-29 Thread Thierry Carrez
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 incubation in I, graduate at the end of the I cycle
to be made a fully-integrated project in the J release.

Your deprecation path description mentions that the internal scheduler
will be deprecated in I, although there is no released (or
security-supported) alternative to switch to at that point. It's not
until the J release that such an alternative will be made available.

So IMHO for the release/security-oriented users, the switch point is
when they start upgrading to J, and not the final step of their upgrade
to I (as suggested by the deploy the external scheduler and switch over
before you consider your migration to I complete wording in the
Etherpad). As the first step towards *switching to J* you would install
the new scheduler before upgrading Nova itself. That works whether
you're a CD user (and start deploying pre-J stuff just after the I
release), or a release user (and wait until J final release to switch to
it).

Maybe we are talking about the same thing (the migration to the separate
scheduler must happen after the I release and, at the latest, when you
switch to the J release) -- but I wanted to make sure we were on the
same page.

I also assume that all the other scheduler-consuming projects would
develop the capability to talk to the external scheduler during the J
cycle, so that their own schedulers would be deprecated in J release and
removed at the start of H. That would be, to me, the condition to
considering the external scheduler as integrated with (even if not
mandatory for) the rest of the common release components.

Does that work for you ?

-- 
Thierry Carrez (ttx)

___
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-28 Thread Gary Kotton


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 began to
 design the API queries or do you need help for that ?

 -Sylvain

https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.ne
t/nova/%2Bspec/remove-cast-to-schedule-run-instancek=oIvRg1%2BdGAgOoM1BIl
LLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=m51N
cC8%2Byhvmtv%2FnrCQvfmoJK0QyJo5pl7iShl2bmck%3D%0As=bf6f26da40ba9acedc20fe
3f1f84d4d3eb1a215282db3e59ff7088225da7e6f1
is a pre-requisite for nova to use the split out scheduler, but I
think we can begin before that is complete, by doing the work on the
new trees:

 - setting up the basic trees we'll need (a service tree and a client
tree) as openstack-infra/config changes

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.

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 also enable all of the other modules, for
example Cinder to hook into it.

To be honest I think that that is a lot cleaner way of going about it.
Once the driver is working then we can speak about deprecating the
existing drivers.

My thoughts are:
1. Lets start to define the external scheduler API's - say V1 - support
all existing Nova, Cinder, Neutron etc - that is have parity with these
2. Start to think of the new and shiny scheduling features

How about we draw up a plan for #1 and then see how we can divide up the
work and set milestones etc.

The API's can evolve, but we need to get the initial engine (which will be
based on nova code) up and runningŠ.

Happy holidays

 - picking an interim name (e.g. external-scheduler and
python-external-schedulerclient)

However, lets get russelb to approve the blueprint
https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.ne
t/nova/%2Bspec/forklift-scheduler-breakoutk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3
D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=m51NcC8%2Byhv
mtv%2FnrCQvfmoJK0QyJo5pl7iShl2bmck%3D%0As=5b89f2239e66793a9d62e7a1249b60a
bda511694a43ddb28c5e8109cc5f43ac1
first.

Cheers,
Rob

___
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=e
H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=m51NcC8%2Byhvmtv%2Fnr
CQvfmoJK0QyJo5pl7iShl2bmck%3D%0As=4e696767b9510069b282cad72b0e37841731a66
3c904fdf41fb7f94b4cc1b9dc


___
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-28 Thread Chris Friesen

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 also enable all of the other modules, for
example Cinder to hook into it.


I see a couple nice things about this proposal:

1) Going this route means that we're free to mess with the APIs to some 
extent since they're not really public yet.


2) Once we have API parity with the current schedulers all in one place 
then we'll be able to more easily start extracting common stuff.


Chris

___
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-28 Thread Sylvain Bauza

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 being in the 
current

confines of Nova. This will also enable all of the other modules, for
example Cinder to hook into it.


I see a couple nice things about this proposal:

1) Going this route means that we're free to mess with the APIs to 
some extent since they're not really public yet.


2) Once we have API parity with the current schedulers all in one 
place then we'll be able to more easily start extracting common stuff.


I agree with Gary. From my POV, I think it's really important to define 
what the interfaces are, what is passed to the scheduler and what is 
given by the scheduler.
Of course, Nova is the first starting point for knowing what to define, 
but we need to make sure the I/Os are enough modular to support any type 
of things to schedule (Cinder backends, Manila FSes, Climate 
compute-hosts and so far...)


-Sylvain

___
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-28 Thread Robert Collins
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 is. We have an existing RPC API in the nova/scheduler tree.

 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 also enable all of the other modules, for
 example Cinder to hook into it.

The problem is that that is the boil-the-ocean approach that hasn't
succeeded for several cycles. We have interest in trying something new
- there are three failure modes I can see:
A - we fail to split it out enough, and noone else uses it.
B - we introduce a performance / correctness problem during the split out
C - we stall and don't do anything

Right now, I am mainly worried about B. Getting good APIs is step two
after getting a solid split out scheduler.

-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


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

2013-11-28 Thread Robert Collins
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 only service that can actually make use of they is Nova

 The second stage is defining an API that other modules can use (we have
 yet to decide if this will be RPC based or have a interface like Glance,
 Cinder etc.)
 We have yet to even talk about the API's.
 The third stage is adding shiny new features and trying to not have a
 community tar and feather us.

Yup; I look forward to our tar and feathering overlords. :)

 Prior to copying code we really need to discuss the API's.

I don't think we do: it's clear that we need to come up with them -
it's necessary, and noone has expressed any doubt about the ability to
do that. RPC API evolution is fairly well understood - we add a new
method, and have it do the necessary, then we go to the users and get
them using it, then we delete the old one.

 This can even
 be done in parallel if your concern is time and resources. But the point
 is we need a API to interface with the service. For a start we can just
 address the Nova use case. We need to at least address:
 1. Scheduling interface
 2. Statistics updates
 3. API's for configuring the scheduling policies

 Later these will all need to bode well with all of the existing modules
 that we want to support - Nova, Cinder and Neutron (if I missed on then
 feel free to kick me whilst I am down)

Ironic perhaps.

 I do not think that we should focus on failure modes, we should plan it
 and break it up so that it will be usable and functional and most
 importantly useful in the near future.

 How about next week we sit together and draw up a wiki of the flows, data
 structures and interfaces. Lets go from there.

While I disagree about us needing to do it right now, I'm very happy
to spend some time on it - I don't want to stop folk doing work that
needs to be done!

-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


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

2013-11-27 Thread Robert Collins
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 ?

 -Sylvain

https://blueprints.launchpad.net/nova/+spec/remove-cast-to-schedule-run-instance
is a pre-requisite for nova to use the split out scheduler, but I
think we can begin before that is complete, by doing the work on the
new trees:

 - setting up the basic trees we'll need (a service tree and a client
tree) as openstack-infra/config changes
 - picking an interim name (e.g. external-scheduler and
python-external-schedulerclient)

However, lets get russelb to approve the blueprint
https://blueprints.launchpad.net/nova/+spec/forklift-scheduler-breakout
first.

Cheers,
Rob

___
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-25 Thread Sylvain Bauza
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 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 for usage questions)
*Subject:* Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for 
a modest proposal for an external scheduler in our lifetime


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.net mailto:robe...@robertcollins.net wrote:


On 22 November 2013 23:55, Gary Kotton gkot...@vmware.com 
mailto:gkot...@vmware.com wrote:




 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

 I would be happy to take part. But prior I think that we need to 
iron out

 a number of issues:

Cool! Added your name to the list of volunteers, which brings us to 4,
the minimum I wanted before starting things happening.


 1. Will this be a new service that has an API, for example will Nova be

 able to register a host and provide the host statistics.

This will be an RPC api initially, because we know the performance
characteristics of the current RPC API, and doing anything different
to that is unnecessary risk. Once the new structure is:
* stable
* gated with unit and tempest tests
* with a straightforward and well documented migration path for deployers

Then adding a RESTful API could take place.


 2. How will the various components interact with the scheduler - same as
 today - that is RPC? Or a REST API? The latter is a real concern due to
 problems we have seen with the interactions of nova and other services

RPC initially. REST *only* once we've avoided second system syndrome.


 3. How will current developments fit into this model?

Code sync - take a forklift copy of the code, and apply patches to
both for the one cycle.


 All in all I think that it is a very good and healthy idea. I have a
 number of reservations - these are mainly regarding the 
implementation and

 the service definition.

 Basically I like the approach of just getting heads down and doing 
it, but
 prior to that I think that we just need to understand the scope and 
mainly
 define the interfaces and how they can used/abused and consumed. It 
may be
 a very good topic to discuss at the up and coming scheduler meeting 
- this

 may be in the middle of the night for Robert. If so then maybe we can
 schedule another time.

Tuesdays at 1500 UTC - I'm in UTC+13 at the moment, so thats 0400
local. A ltle early for me :) I'll ping you on IRC about resolving
the concerns you raise, and you can proxy my answers to the sub group
meeting?


 Please note that this is scheduling and not orchestration. That is also
 something that we need to resolve.

Yup, sure is.

-Rob


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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org 
mailto: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 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-24 Thread Robert Collins
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
whatever they need/want to do to the now separate scheduler - and
refine the interface subsequently as well.

I think both approaches are doable, and can even be done in parallel
(just keep the code that moves synced). My concern about moving the
data store /first/ is that that is secondary to the key goal of moving
it out of tree, and we work on a fast time scale here :).

-Rob


On 23 November 2013 06:01, Khanh-Toan Tran
khanh-toan.t...@cloudwatt.com wrote:
 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 next Scheduler 
 meeting Nov 26th?

 Best regards,

 Toan

 - Original Message -
 From: Mike Spreitzer mspre...@us.ibm.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Friday, November 22, 2013 4:58:46 PM
 Subject: Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest 
 proposal for an external scheduler in our lifetime

 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
 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



-- 
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


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

2013-11-24 Thread Boris Pavlovic
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 skills
   - time to follow a fairly mechanical (but careful and detailed work
  needed) plan to break the status quo around scheduler extraction
 
  I would be happy to take part. But prior I think that we need to iron out
  a number of issues:

 Cool! Added your name to the list of volunteers, which brings us to 4,
 the minimum I wanted before starting things happening.

  1. Will this be a new service that has an API, for example will Nova be
  able to register a host and provide the host statistics.

 This will be an RPC api initially, because we know the performance
 characteristics of the current RPC API, and doing anything different
 to that is unnecessary risk. Once the new structure is:
 * stable
 * gated with unit and tempest tests
 * with a straightforward and well documented migration path for deployers

 Then adding a RESTful API could take place.

  2. How will the various components interact with the scheduler - same as
  today - that is RPC? Or a REST API? The latter is a real concern due to
  problems we have seen with the interactions of nova and other services

 RPC initially. REST *only* once we've avoided second system syndrome.

  3. How will current developments fit into this model?

 Code sync - take a forklift copy of the code, and apply patches to
 both for the one cycle.

  All in all I think that it is a very good and healthy idea. I have a
  number of reservations - these are mainly regarding the implementation
 and
  the service definition.
 
  Basically I like the approach of just getting heads down and doing it,
 but
  prior to that I think that we just need to understand the scope and
 mainly
  define the interfaces and how they can used/abused and consumed. It may
 be
  a very good topic to discuss at the up and coming scheduler meeting -
 this
  may be in the middle of the night for Robert. If so then maybe we can
  schedule another time.

 Tuesdays at 1500 UTC - I'm in UTC+13 at the moment, so thats 0400
 local. A ltle early for me :) I'll ping you on IRC about resolving
 the concerns you raise, and you can proxy my answers to the sub group
 meeting?

  Please note that this is scheduling and not orchestration. That is also
  something that we need to resolve.

 Yup, sure is.

 -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


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

2013-11-24 Thread Robert Collins
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

___
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-24 Thread Haefliger, Juerg
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 for usage questions)
Subject: Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest 
proposal for an external scheduler in our lifetime

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.netmailto:robe...@robertcollins.net wrote:
On 22 November 2013 23:55, Gary Kotton 
gkot...@vmware.commailto:gkot...@vmware.com wrote:



 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

 I would be happy to take part. But prior I think that we need to iron out
 a number of issues:
Cool! Added your name to the list of volunteers, which brings us to 4,
the minimum I wanted before starting things happening.

 1. Will this be a new service that has an API, for example will Nova be
 able to register a host and provide the host statistics.

This will be an RPC api initially, because we know the performance
characteristics of the current RPC API, and doing anything different
to that is unnecessary risk. Once the new structure is:
* stable
* gated with unit and tempest tests
* with a straightforward and well documented migration path for deployers

Then adding a RESTful API could take place.

 2. How will the various components interact with the scheduler - same as
 today - that is RPC? Or a REST API? The latter is a real concern due to
 problems we have seen with the interactions of nova and other services
RPC initially. REST *only* once we've avoided second system syndrome.

 3. How will current developments fit into this model?
Code sync - take a forklift copy of the code, and apply patches to
both for the one cycle.

 All in all I think that it is a very good and healthy idea. I have a
 number of reservations - these are mainly regarding the implementation and
 the service definition.

 Basically I like the approach of just getting heads down and doing it, but
 prior to that I think that we just need to understand the scope and mainly
 define the interfaces and how they can used/abused and consumed. It may be
 a very good topic to discuss at the up and coming scheduler meeting - this
 may be in the middle of the night for Robert. If so then maybe we can
 schedule another time.
Tuesdays at 1500 UTC - I'm in UTC+13 at the moment, so thats 0400
local. A ltle early for me :) I'll ping you on IRC about resolving
the concerns you raise, and you can proxy my answers to the sub group
meeting?

 Please note that this is scheduling and not orchestration. That is also
 something that we need to resolve.
Yup, sure is.

-Rob

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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime

2013-11-22 Thread Alex Glikson
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 robe...@robertcollins.net
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.org, 
Date:   21/11/2013 11:00 PM
Subject:[openstack-dev] [Nova][Schduler] Volunteers wanted for a 
modest proposal for an external scheduler in our lifetime



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


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

2013-11-22 Thread Soren Hansen
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  | http://www.openstack.org/


2013/11/21 Robert Collins robe...@robertcollins.net:
 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


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

2013-11-22 Thread Mike Spreitzer
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
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 Khanh-Toan Tran
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 next Scheduler 
meeting Nov 26th?

Best regards,

Toan

- Original Message - 
From: Mike Spreitzer mspre...@us.ibm.com 
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org 
Sent: Friday, November 22, 2013 4:58:46 PM 
Subject: Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest 
proposal for an external scheduler in our lifetime 

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 
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][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


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

2013-11-22 Thread Sylvain Bauza
 
 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 lifetime

 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


Hi Rob,

I can also add Climate as a separate Stackforge project which could get
benefits from querying a scheduler service for electing some compute-hosts
based on what we call a 'reservation request' [1]
By the way, you mentioned the original BP for Climate [2] in the etherpad,
which does let me thinking we are on the same page.

That said, I would really love joining the team for delivering the new
service, but unfortunately, I will only be able to commit myself on my
personal spare time.

Anyway, I'm following the discussion, whatever the outcome is.

-Sylvain

[1] https://etherpad.openstack.org/p/NovaIcehouse-ClimateInteractions
[2]
https://wiki.openstack.org/wiki/Blueprint-nova-planned-resource-reservation-api
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-11-21 Thread Robert Collins
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


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

2013-11-21 Thread Boris Pavlovic
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 allows us to make
scalable scheduler as a service without huge pain of changing too much in
current architecture: As I mention on HK summit, there are just few steps,
that should be implemented:

1) Scheduler should store all data by self:
1.1) Keep all data locally + mechanism that effectively sync all
schedulers
1.2) new scheduler RPC method: update_host(host_name, namespace,
values)
 e.g. in this patchset https://review.openstack.org/#/c/45867/
 It is still WIP:
   During this week we are going to make final version:
 a) Garbage collector for sync mechanism
 b) Support of name spaces
 c) Support of sqlaclhemy backends (not only memcached)

2) Cleanup Nova scheduler
2.1) Remove compute_node tables
2.2) Remove from db.api methods that returns state of hosts, and use
Scheduler

3.a) Make Nova Scheduler as a separated service

3.b) Call from cinder in cinder namespace  Scheduler Service
 update_host() method
4) Move cinder scheduler rpc method to  scheduler service
5) Remove Cinder Scheduler

3.c) Call from malina in malina namespace  Scheduler Service
update_host() method
4) Move malina scheduler rpc method to scheduler service
5) Remove Malina Scheduler


I don't think that it is step backward as it was mentioned in etherpad..



Best regards,
Boris Pavlovic



On Fri, Nov 22, 2013 at 12:58 AM, Robert Collins
robe...@robertcollins.netwrote:

 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


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

2013-11-21 Thread Robert Collins
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
 https://blueprints.launchpad.net/nova/+spec/no-db-scheduler

Ok, lets fix that up.

 Approach no-db-scheduler is actually base step that allows us to make
 scalable scheduler as a service without huge pain of changing too much in
 current architecture: As I mention on HK summit, there are just few steps,
 that should be implemented:
..
 3.a) Make Nova Scheduler as a separated service

This is the bit that all previous efforts on the scheduler have failed
to deliver - and it's just the bit that my proposal tackles.
...

 I don't think that it is step backward as it was mentioned in etherpad..

I don't see any mention of a step backwards.

-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