Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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