Re: [openstack-dev] The state of nova-network to neutron migration
On 01/10/2015 05:57 AM, Armando M. wrote: If we were standing at a place with a detailed manual upgrade document that explained how to do minimal VM downtime, that a few ops had gone through and proved out, that would be one thing. And we could figure out which parts made sense to put tooling around to make this easier for everyone. But we seem far from there. My suggestion is to start with a detailed document, figure out that it works, and build automation around that process. The problem is that whatever documented solution we can come up with is going to be so opinionated to be hardly of any use on general terms, let alone worth automating. Furthermore, its lifespan is going to be reasonably limited which to me doesn't seem to justify enough the engineering cost, and it's not like we haven't been trying... I am not suggesting we give up entirely, but perhaps we should look at the operator cases (for those who cannot afford cold migrations, or more simply stand up a new cloud to run side-by-side with old cloud, and leave the old one running until it drains), individually. This means having someone technical who has a deep insight into these operator's environments lead the development effort required to adjust the open source components to accommodate whatever migration process makes sense to them. Having someone championing a general effort from the 'outside' does not sound like an efficient use of anyone's time. So this goes back to the question: who can effectively lead the technical effort? I personally don't think we can have Neutron cores or Nova cores lead this effort and be effective, if they don't have direct access/knowledge to these cloud platforms, and everything that pertains to them. Armando You have a good point Armando, the ideal person to lead this effort is someone with deep technical knowledge in this area. I think we can all agree that I don't have deep technical knowledge in this area (whether I have deep technical knowledge in any area can be a beer conversation). I do have one ability, and folks can decide for themselves if that ability has value or not to them (I don't expect to have any consensus here). I do have the ability to wade into an area that everyone else deems too painful to bother with and share my perspective. Exercising that ability seems to stir up dormant feelings and either be looked on favourably or unfavourably depending on what someone's role in the history has been. Contrary to popular opinion I don't do what I do to hurt people, I do what I do from the motivation of trying to keep things flowing so all folks benefit (including folks who are affected by this decision and have never heard of OpenStack, let alone found this mailing list). In the absence of some person who actually has the abilities you outline, Armando, (and I do agree with your assessment, those qualities would be ideal) lets try to create a situation to perhaps attract such a person to either come forward or grow those abilities (or come forward _and_ grow those abilities), as we continue to move in the direction of putting ourselves (ourselves meaning OpenStack here) in the situation of deprecating Nova-Network. Thanks, Anita. -Sean -- Sean Dague http://dague.net ___ 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 Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] The state of nova-network to neutron migration
Maru Newby wrote: On Jan 8, 2015, at 3:54 PM, Sean Dague s...@dague.net wrote: The crux of it comes from the fact that the operator voice (especially those folks with large nova-network deploys) wasn't represented there. Once we got back from the mid-cycle and brought it to the list, there was some very understandable push back on deprecating without a migration plan. I think it’s clear that a migration plan is required. An automated migration, not so much. The solution is not black or white. Yes, operators would generally prefer an instant, automated, no-downtime hot migration that magically moves them to the new world order. Yes, developers would generally prefer to just document a general cold procedure that operators could follow to migrate, warning that their mileage may vary. The trade-off solution we came up with last cycle is to have developers and operators converge on a clear procedure with reasonable/acceptable downtime, potentially assisted by new features and tools. It's really not a us vs. them thing. It's a collaborative effort where operators agree on what level of pain they can absorb and developers help to reduce that pain wherever reasonably possible. This convergence effort is currently rebooted because it has stalled. We still need to agree on the reasonable trade-off procedure. We still need to investigate if there is any tool or simple feature we can add to Neutron or Nova to make some parts of that procedure easier and less painful. So we are not bringing back the magic upgrade pony requirement on the table. We are just rebooting the effort to come to a reasonable solution for everyone. -- 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] The state of nova-network to neutron migration
On 9 January 2015 at 02:57, Tom Fifield t...@openstack.org wrote: On 09/01/15 08:06, Maru Newby wrote: The fact that operators running nova-network would like the upstream community to pay for implementing an automated migration solution for them is hardly surprising. It is less clear to me that implementing such a solution, with all the attendant cost and risks, should take priority over efforts that benefit a broader swath of the community. Are the operators in question so strapped for resources that they are not able to automate their migrations themselves, provided a sufficiently detailed plan to do so? This effort does benefit a broad swath of the community. Also, as I recall, CERN and others who you may consider more along the lines of ops, rather than devs, are committing resources to this. It's just that those resources are not core devs in either nova or neutron - that's why Anita was seeking champions in those two areas to assist with moving things along and with their knowledge of the code-base. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] The state of nova-network to neutron migration
If we were standing at a place with a detailed manual upgrade document that explained how to do minimal VM downtime, that a few ops had gone through and proved out, that would be one thing. And we could figure out which parts made sense to put tooling around to make this easier for everyone. But we seem far from there. My suggestion is to start with a detailed document, figure out that it works, and build automation around that process. The problem is that whatever documented solution we can come up with is going to be so opinionated to be hardly of any use on general terms, let alone worth automating. Furthermore, its lifespan is going to be reasonably limited which to me doesn't seem to justify enough the engineering cost, and it's not like we haven't been trying... I am not suggesting we give up entirely, but perhaps we should look at the operator cases (for those who cannot afford cold migrations, or more simply stand up a new cloud to run side-by-side with old cloud, and leave the old one running until it drains), individually. This means having someone technical who has a deep insight into these operator's environments lead the development effort required to adjust the open source components to accommodate whatever migration process makes sense to them. Having someone championing a general effort from the 'outside' does not sound like an efficient use of anyone's time. So this goes back to the question: who can effectively lead the technical effort? I personally don't think we can have Neutron cores or Nova cores lead this effort and be effective, if they don't have direct access/knowledge to these cloud platforms, and everything that pertains to them. Armando -Sean -- Sean Dague http://dague.net ___ 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] The state of nova-network to neutron migration
On 01/09/2015 05:04 AM, Thierry Carrez wrote: Maru Newby wrote: On Jan 8, 2015, at 3:54 PM, Sean Dague s...@dague.net wrote: The crux of it comes from the fact that the operator voice (especially those folks with large nova-network deploys) wasn't represented there. Once we got back from the mid-cycle and brought it to the list, there was some very understandable push back on deprecating without a migration plan. I think it’s clear that a migration plan is required. An automated migration, not so much. The solution is not black or white. Yes, operators would generally prefer an instant, automated, no-downtime hot migration that magically moves them to the new world order. Yes, developers would generally prefer to just document a general cold procedure that operators could follow to migrate, warning that their mileage may vary. The trade-off solution we came up with last cycle is to have developers and operators converge on a clear procedure with reasonable/acceptable downtime, potentially assisted by new features and tools. It's really not a us vs. them thing. It's a collaborative effort where operators agree on what level of pain they can absorb and developers help to reduce that pain wherever reasonably possible. This convergence effort is currently rebooted because it has stalled. We still need to agree on the reasonable trade-off procedure. We still need to investigate if there is any tool or simple feature we can add to Neutron or Nova to make some parts of that procedure easier and less painful. So we are not bringing back the magic upgrade pony requirement on the table. We are just rebooting the effort to come to a reasonable solution for everyone. If we were standing at a place with a detailed manual upgrade document that explained how to do minimal VM downtime, that a few ops had gone through and proved out, that would be one thing. And we could figure out which parts made sense to put tooling around to make this easier for everyone. But we seem far from there. My suggestion is to start with a detailed document, figure out that it works, and build automation around that process. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] The state of nova-network to neutron migration
On 09/01/15 08:06, Maru Newby wrote: On Jan 8, 2015, at 3:54 PM, Sean Dague s...@dague.net wrote: On 01/08/2015 06:41 PM, Maru Newby wrote: As per a recent exchange on #openstack-neutron, I’ve been asked to present my views on this effort. What follows is in no way intended to detract from the hard work and dedication of those undertaking it, but I think that their energy could be better spent. At nova’s juno mid-cycle in July, there was a discussion about deprecating nova-network. Most of the work-items on the TC’s gap analysis [1] had been covered off, with one notable exception: Gap 6, the requirement to provide a migration plan between nova-network and neutron, had stalled over questions of implementation strategy. In my recollection of the conversation that followed, broad consensus was reached that the costs of automating a reliable and fault-tolerant migration strategy would be considerable. The technical complexity of targeting a fixed deployment scenario would be challenging enough, and targeting heterogenous scenarios would magnify that complexity many-fold. Given the cost and high risks associated with implementing an automated solution, everyone seemed to agree that it was not worth pursuing. Our understanding was that not pursuing an automated solution could still be in keeping with the TC’s requirements for deprecation, which required that a migration plan be formulated but not that it be automated. Documentation was deemed sufficient, and that was to be the path forward in covering Gap 6. The documentation would allow deployers and operators to devise migration strategies to suit their individual requirements. Then, when the Kilo summit schedule was announced, there was a session scheduled in the nova track for discussing how to implement an automated migration. I only managed to catch the tail end of the session, but the etherpad [2] makes no mention of the rationale for requiring an automated migration in the first place. It was like the discussion at the mid-cycle, and all the talk of the risks outweighing the potential benefits of such an effort, had simply not occurred. So, in the interests of a full and open discussion on this matter, can someone please explain to me why the risks discussed at the mid-cycle were suddenly deemed justifiable, seemingly against all technical rationale? Criticism has been leveled at the neutron project for our supposed inaction in implementing an automated solution, and I don’t think I’m the only one who is concerned that this is an unreasonable requirement imposed without due consideration to the risks involved. Yes, most of us want to see nova-network deprecated, but why is the lack of migration automation blocking that? An automated migration was not a requirement in the TC’s original assessment of the preconditions for deprecation. I think that if neutron is deemed to be of sufficiently high quality that it can serve as an effective replacement for nova-network, and we can document a migration plan between them, then deprecation should proceed. Maru The crux of it comes from the fact that the operator voice (especially those folks with large nova-network deploys) wasn't represented there. Once we got back from the mid-cycle and brought it to the list, there was some very understandable push back on deprecating without a migration plan. I think it’s clear that a migration plan is required. An automated migration, not so much. I believe we landed at the need for the common case, flat multi host networking, to be migrated to something equivalent in neutron land (dvr?). And it needs to be something that Metacloud and CERN can get behind, as they represent 2 very large nova-network deploys (and have reasonably well defined down time allowances for this). This doesn't have to be automation for all cases, but we need to support a happy path from one to the other that's repeatable, reasonably automatic (as much as possible), and provides minimum down time for guests running on the environment. The fact that operators running nova-network would like the upstream community to pay for implementing an automated migration solution for them is hardly surprising. It is less clear to me that implementing such a solution, with all the attendant cost and risks, should take priority over efforts that benefit a broader swath of the community. Are the operators in question so strapped for resources that they are not able to automate their migrations themselves, provided a sufficiently detailed plan to do so? Maru, This effort does benefit a broad swath of the community. Regards, Tom ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] The state of nova-network to neutron migration
On 01/08/2015 06:41 PM, Maru Newby wrote: As per a recent exchange on #openstack-neutron, I’ve been asked to present my views on this effort. What follows is in no way intended to detract from the hard work and dedication of those undertaking it, but I think that their energy could be better spent. At nova’s juno mid-cycle in July, there was a discussion about deprecating nova-network. Most of the work-items on the TC’s gap analysis [1] had been covered off, with one notable exception: Gap 6, the requirement to provide a migration plan between nova-network and neutron, had stalled over questions of implementation strategy. In my recollection of the conversation that followed, broad consensus was reached that the costs of automating a reliable and fault-tolerant migration strategy would be considerable. The technical complexity of targeting a fixed deployment scenario would be challenging enough, and targeting heterogenous scenarios would magnify that complexity many-fold. Given the cost and high risks associated with implementing an automated solution, everyone seemed to agree that it was not worth pursuing. Our understanding was that not pursuing an automated solution could still be in keeping with the TC’s requirements for deprecation, which required that a migration plan be formulated but not that it be automated. Documentation was deemed sufficient, and that was to be the path forward in covering Gap 6. The documentation would allow deployers and operators to devise migration strategies to suit their individual requirements. Then, when the Kilo summit schedule was announced, there was a session scheduled in the nova track for discussing how to implement an automated migration. I only managed to catch the tail end of the session, but the etherpad [2] makes no mention of the rationale for requiring an automated migration in the first place. It was like the discussion at the mid-cycle, and all the talk of the risks outweighing the potential benefits of such an effort, had simply not occurred. So, in the interests of a full and open discussion on this matter, can someone please explain to me why the risks discussed at the mid-cycle were suddenly deemed justifiable, seemingly against all technical rationale? Criticism has been leveled at the neutron project for our supposed inaction in implementing an automated solution, and I don’t think I’m the only one who is concerned that this is an unreasonable requirement imposed without due consideration to the risks involved. Yes, most of us want to see nova-network deprecated, but why is the lack of migration automation blocking that? An automated migration was not a requirement in the TC’s original assessment of the preconditions for deprecation. I think that if neutron is deemed to be of sufficiently high quality that it can serve as an effective replacement for nova-network, and we can document a migration plan between them, then deprecation should proceed. Maru The crux of it comes from the fact that the operator voice (especially those folks with large nova-network deploys) wasn't represented there. Once we got back from the mid-cycle and brought it to the list, there was some very understandable push back on deprecating without a migration plan. I believe we landed at the need for the common case, flat multi host networking, to be migrated to something equivalent in neutron land (dvr?). And it needs to be something that Metacloud and CERN can get behind, as they represent 2 very large nova-network deploys (and have reasonably well defined down time allowances for this). This doesn't have to be automation for all cases, but we need to support a happy path from one to the other that's repeatable, reasonably automatic (as much as possible), and provides minimum down time for guests running on the environment. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] The state of nova-network to neutron migration
As per a recent exchange on #openstack-neutron, I’ve been asked to present my views on this effort. What follows is in no way intended to detract from the hard work and dedication of those undertaking it, but I think that their energy could be better spent. At nova’s juno mid-cycle in July, there was a discussion about deprecating nova-network. Most of the work-items on the TC’s gap analysis [1] had been covered off, with one notable exception: Gap 6, the requirement to provide a migration plan between nova-network and neutron, had stalled over questions of implementation strategy. In my recollection of the conversation that followed, broad consensus was reached that the costs of automating a reliable and fault-tolerant migration strategy would be considerable. The technical complexity of targeting a fixed deployment scenario would be challenging enough, and targeting heterogenous scenarios would magnify that complexity many-fold. Given the cost and high risks associated with implementing an automated solution, everyone seemed to agree that it was not worth pursuing. Our understanding was that not pursuing an automated solution could still be in keeping with the TC’s requirements for deprecation, which required that a migration plan be formulated but not that it be automated. Documentation was deemed sufficient, and that was to be the path forward in covering Gap 6. The documentation would allow deployers and operators to devise migration strategies to suit their individual requirements. Then, when the Kilo summit schedule was announced, there was a session scheduled in the nova track for discussing how to implement an automated migration. I only managed to catch the tail end of the session, but the etherpad [2] makes no mention of the rationale for requiring an automated migration in the first place. It was like the discussion at the mid-cycle, and all the talk of the risks outweighing the potential benefits of such an effort, had simply not occurred. So, in the interests of a full and open discussion on this matter, can someone please explain to me why the risks discussed at the mid-cycle were suddenly deemed justifiable, seemingly against all technical rationale? Criticism has been leveled at the neutron project for our supposed inaction in implementing an automated solution, and I don’t think I’m the only one who is concerned that this is an unreasonable requirement imposed without due consideration to the risks involved. Yes, most of us want to see nova-network deprecated, but why is the lack of migration automation blocking that? An automated migration was not a requirement in the TC’s original assessment of the preconditions for deprecation. I think that if neutron is deemed to be of sufficiently high quality that it can serve as an effective replacement for nova-network, and we can document a migration plan between them, then deprecation should proceed. Maru 1: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee/Neutron_Gap_Coverage 2: https://etherpad.openstack.org/p/kilo-nova-nova-network-to-neutron On Dec 19, 2014, at 8:59 AM, Anita Kuno ante...@anteaya.info wrote: Rather than waste your time making excuses let me state where we are and where I would like to get to, also sharing my thoughts about how you can get involved if you want to see this happen as badly as I have been told you do. Where we are: * a great deal of foundation work has been accomplished to achieve parity with nova-network and neutron to the extent that those involved are ready for migration plans to be formulated and be put in place * a summit session happened with notes and intentions[0] * people took responsibility and promptly got swamped with other responsibilities * spec deadlines arose and in neutron's case have passed * currently a neutron spec [1] is a work in progress (and it needs significant work still) and a nova spec is required and doesn't have a first draft or a champion Where I would like to get to: * I need people in addition to Oleg Bondarev to be available to help come up with ideas and words to describe them to create the specs in a very short amount of time (Oleg is doing great work and is a fabulous person, yay Oleg, he just can't do this alone) * specifically I need a contact on the nova side of this complex problem, similar to Oleg on the neutron side * we need to have a way for people involved with this effort to find each other, talk to each other and track progress * we need to have representation at both nova and neutron weekly meetings to communicate status and needs We are at K-2 and our current status is insufficient to expect this work will be accomplished by the end of K-3. I will be championing this work, in whatever state, so at least it doesn't fall off the map. If you would like to help this effort please get in contact. I will be thinking of ways to
Re: [openstack-dev] The state of nova-network to neutron migration
On Jan 8, 2015, at 3:54 PM, Sean Dague s...@dague.net wrote: On 01/08/2015 06:41 PM, Maru Newby wrote: As per a recent exchange on #openstack-neutron, I’ve been asked to present my views on this effort. What follows is in no way intended to detract from the hard work and dedication of those undertaking it, but I think that their energy could be better spent. At nova’s juno mid-cycle in July, there was a discussion about deprecating nova-network. Most of the work-items on the TC’s gap analysis [1] had been covered off, with one notable exception: Gap 6, the requirement to provide a migration plan between nova-network and neutron, had stalled over questions of implementation strategy. In my recollection of the conversation that followed, broad consensus was reached that the costs of automating a reliable and fault-tolerant migration strategy would be considerable. The technical complexity of targeting a fixed deployment scenario would be challenging enough, and targeting heterogenous scenarios would magnify that complexity many-fold. Given the cost and high risks associated with implementing an automated solution, everyone seemed to agree that it was not worth pursuing. Our understanding was that not pursuing an automated solution could still be in keeping with the TC’s requirements for deprecation, which required that a migration plan be formulated but not that it be automated. Documentation was deemed sufficient, and that was to be the path forward in covering Gap 6. The documentation would allow deployers and operators to devise migration strategies to suit their individual requirements. Then, when the Kilo summit schedule was announced, there was a session scheduled in the nova track for discussing how to implement an automated migration. I only managed to catch the tail end of the session, but the etherpad [2] makes no mention of the rationale for requiring an automated migration in the first place. It was like the discussion at the mid-cycle, and all the talk of the risks outweighing the potential benefits of such an effort, had simply not occurred. So, in the interests of a full and open discussion on this matter, can someone please explain to me why the risks discussed at the mid-cycle were suddenly deemed justifiable, seemingly against all technical rationale? Criticism has been leveled at the neutron project for our supposed inaction in implementing an automated solution, and I don’t think I’m the only one who is concerned that this is an unreasonable requirement imposed without due consideration to the risks involved. Yes, most of us want to see nova-network deprecated, but why is the lack of migration automation blocking that? An automated migration was not a requirement in the TC’s original assessment of the preconditions for deprecation. I think that if neutron is deemed to be of sufficiently high quality that it can serve as an effective replacement for nova-network, and we can document a migration plan between them, then deprecation should proceed. Maru The crux of it comes from the fact that the operator voice (especially those folks with large nova-network deploys) wasn't represented there. Once we got back from the mid-cycle and brought it to the list, there was some very understandable push back on deprecating without a migration plan. I think it’s clear that a migration plan is required. An automated migration, not so much. I believe we landed at the need for the common case, flat multi host networking, to be migrated to something equivalent in neutron land (dvr?). And it needs to be something that Metacloud and CERN can get behind, as they represent 2 very large nova-network deploys (and have reasonably well defined down time allowances for this). This doesn't have to be automation for all cases, but we need to support a happy path from one to the other that's repeatable, reasonably automatic (as much as possible), and provides minimum down time for guests running on the environment. The fact that operators running nova-network would like the upstream community to pay for implementing an automated migration solution for them is hardly surprising. It is less clear to me that implementing such a solution, with all the attendant cost and risks, should take priority over efforts that benefit a broader swath of the community. Are the operators in question so strapped for resources that they are not able to automate their migrations themselves, provided a sufficiently detailed plan to do so? Maru ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] The state of nova-network to neutron migration
Hi Anita, I'm available Tuesday and Wednesday (0800-1600 UTC), Friday (0800-1800 UTC). Belmiro On Tuesday, December 30, 2014, Oleg Bondarev obonda...@mirantis.com wrote: On Tue, Dec 30, 2014 at 12:56 AM, Anita Kuno ante...@anteaya.info javascript:_e(%7B%7D,'cvml','ante...@anteaya.info'); wrote: On 12/24/2014 04:07 AM, Oleg Bondarev wrote: On Mon, Dec 22, 2014 at 10:08 PM, Anita Kuno ante...@anteaya.info javascript:_e(%7B%7D,'cvml','ante...@anteaya.info'); wrote: On 12/22/2014 01:32 PM, Joe Gordon wrote: On Fri, Dec 19, 2014 at 9:28 AM, Kyle Mestery mest...@mestery.com javascript:_e(%7B%7D,'cvml','mest...@mestery.com'); wrote: On Fri, Dec 19, 2014 at 10:59 AM, Anita Kuno ante...@anteaya.info javascript:_e(%7B%7D,'cvml','ante...@anteaya.info'); wrote: Rather than waste your time making excuses let me state where we are and where I would like to get to, also sharing my thoughts about how you can get involved if you want to see this happen as badly as I have been told you do. Where we are: * a great deal of foundation work has been accomplished to achieve parity with nova-network and neutron to the extent that those involved are ready for migration plans to be formulated and be put in place * a summit session happened with notes and intentions[0] * people took responsibility and promptly got swamped with other responsibilities * spec deadlines arose and in neutron's case have passed * currently a neutron spec [1] is a work in progress (and it needs significant work still) and a nova spec is required and doesn't have a first draft or a champion Where I would like to get to: * I need people in addition to Oleg Bondarev to be available to help come up with ideas and words to describe them to create the specs in a very short amount of time (Oleg is doing great work and is a fabulous person, yay Oleg, he just can't do this alone) * specifically I need a contact on the nova side of this complex problem, similar to Oleg on the neutron side * we need to have a way for people involved with this effort to find each other, talk to each other and track progress * we need to have representation at both nova and neutron weekly meetings to communicate status and needs We are at K-2 and our current status is insufficient to expect this work will be accomplished by the end of K-3. I will be championing this work, in whatever state, so at least it doesn't fall off the map. If you would like to help this effort please get in contact. I will be thinking of ways to further this work and will be communicating to those who identify as affected by these decisions in the most effective methods of which I am capable. Thank you to all who have gotten us as far as well have gotten in this effort, it has been a long haul and you have all done great work. Let's keep going and finish this. Thank you, Anita. Thank you for volunteering to drive this effort Anita, I am very happy about this. I support you 100%. I'd like to point out that we really need a point of contact on the nova side, similar to Oleg on the Neutron side. IMHO, this is step 1 here to continue moving this forward. At the summit the nova team marked the nova-network to neutron migration as a priority [0], so we are collectively interested in seeing this happen and want to help in any way possible. With regard to a nova point of contact, anyone in nova-specs-core should work, that way we can cover more time zones. From what I can gather the first step is to finish fleshing out the first spec [1], and it sounds like it would be good to get a few nova-cores reviewing it as well. [0] http://specs.openstack.org/openstack/nova-specs/priorities/kilo-priorities.html [1] https://review.openstack.org/#/c/142456/ Wonderful, thank you for the support Joe. It appears that we need to have a regular weekly meeting to track progress in an archived manner. I know there was one meeting November but I don't know what it was called so so far I can't find the logs for that. It wasn't official, we just gathered together on #novamigration. Attaching the log here. Ah, that would explain why I couldn't find the log. Thanks for the attachment. So if those affected by this issue can identify what time (UTC please, don't tell me what time zone you are in it is too hard to guess what UTC time you are available) and day of the week you are available for a meeting I'll create one and we can start talking to each other. I need to avoid Monday 1500 and 2100 UTC, Tuesday 0800 UTC, 1400 UTC and 1900 - 2200 UTC, Wednesdays 1500 - 1700 UTC, Thursdays 1400 and 2100 UTC. I'm available each weekday 0700-1600 UTC, 1700-1800 UTC is also acceptable. Thanks, Oleg Wonderful, thank you Oleg. We will aim for a
[openstack-dev] The state of nova-network to neutron migration
Rather than waste your time making excuses let me state where we are and where I would like to get to, also sharing my thoughts about how you can get involved if you want to see this happen as badly as I have been told you do. Where we are: * a great deal of foundation work has been accomplished to achieve parity with nova-network and neutron to the extent that those involved are ready for migration plans to be formulated and be put in place * a summit session happened with notes and intentions[0] * people took responsibility and promptly got swamped with other responsibilities * spec deadlines arose and in neutron's case have passed * currently a neutron spec [1] is a work in progress (and it needs significant work still) and a nova spec is required and doesn't have a first draft or a champion Where I would like to get to: * I need people in addition to Oleg Bondarev to be available to help come up with ideas and words to describe them to create the specs in a very short amount of time (Oleg is doing great work and is a fabulous person, yay Oleg, he just can't do this alone) * specifically I need a contact on the nova side of this complex problem, similar to Oleg on the neutron side * we need to have a way for people involved with this effort to find each other, talk to each other and track progress * we need to have representation at both nova and neutron weekly meetings to communicate status and needs We are at K-2 and our current status is insufficient to expect this work will be accomplished by the end of K-3. I will be championing this work, in whatever state, so at least it doesn't fall off the map. If you would like to help this effort please get in contact. I will be thinking of ways to further this work and will be communicating to those who identify as affected by these decisions in the most effective methods of which I am capable. Thank you to all who have gotten us as far as well have gotten in this effort, it has been a long haul and you have all done great work. Let's keep going and finish this. Thank you, Anita. [0] https://etherpad.openstack.org/p/kilo-nova-nova-network-to-neutron [1] https://review.openstack.org/#/c/142456/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
