Re: [openstack-dev] [Stable][Nova] VMware NSXv Support
On Wednesday, August 12, 2015, Thierry Carrez thie...@openstack.org wrote: Gary Kotton wrote: On 8/12/15, 12:12 AM, Mike Perez thin...@gmail.com javascript:; wrote: On 15:39 Aug 11, Gary Kotton wrote: On 8/11/15, 6:09 PM, Jay Pipes jaypi...@gmail.com javascript:; wrote: Are you saying that *new functionality* was added to the stable/kilo branch of *Neutron*, and because new functionality was added to stable/kilo's Neutron, that stable/kilo *Nova* will no longer work? Yes. That is exactly what I am saying. The issues is as follows. The NSXv manager requires the virtual machines VNIC index to enable the security groups to work. Without that a VM will not be able to send and receive traffic. In addition to this the NSXv plugin does not have any agents so we need to do the metadata plugin changes to ensure metadata support. So effectively with the patches: https://review.openstack.org/209372 and https://review.openstack.org/209374 the stable/kilo nova code will not work with the stable/kilo neutron NSXv plugin. snip So what do you suggest? This was added in Neutron during Kilo [1]. It's the responsibility of the patch owner to revert things if something doesn't land in a dependency patch of some other project. I'm not familiar with the patch, but you can see if Neutron folks will accept a revert in stable/kilo. There's no reason to get other projects involved because this wasn't handled properly. [1] - https://review.openstack.org/#/c/144278/ So you are suggesting that we revert the neutron plugin? I do not think that a revert is relevant here. Yeah, I'm not sure reverting the Neutron patch would be more acceptable. That one landed in Neutron kilo in time. The issue here is that due to Nova's review velocity during the kilo cycle (and arguably the failure to raise this as a cross-project issue affecting the release), the VMware NSXv support was shipped as broken in Kilo, and requires non-trivial changes to get fixed. I see this as Nova not shipping with VMware NSXv support in kilo, the feature was never completed, rather than it being broken. I could be missing something, but I also know that difference doesn't really help anyone. We have two options: bending the stable rules to allow the fix to be backported, or document it as broken in Kilo with the invasive patches being made available for people and distributions who still want to apply it. Given that we are 4 months into Kilo, I'd say stable/kilo users are used to this being broken at this point, so my vote would go for the second option. This would be backporting a new driver to an older release. That seems like a bad idea. That said, we should definitely raise [1] as a cross-project issue and see how we could work it into Liberty, so that we don't end up in the same dark corner in 4 months. I just don't want to break the stable rules (and the user confidence we've built around us applying them) to retroactively pay back review velocity / trust issues within Nova. [1] https://review.openstack.org/#/c/165750/ So this is the same issue. The VMware neutron driver has merged support for a feature where we have not managed to get into Nova yet. First the long term view... This is happening more frequently with Cinder drivers/features, Neutron things, and to a lesser extent Glance. The great work the Cinder folks have done with brick, is hopefully going to improve the situation for Cinder. There are a group of folks working on a similar VIF focused library to help making it easier to add support for new Neutron VIF drivers without needing to merge things in Nova. Right now those above efforts are largely focused on libvirt, but using oslo.vmware, or probably something else, I am sure we could evolve something similar for VMware, but I haven't dug into that. There are lots of coding efforts and process efforts to make the most of our current review bandwidth and to expand that bandwidth, but I don't think it's helpful to get into that here. So, more short term and specific points... This patch had no bug or blueprint attached. It eventually got noticed a few weeks after the blueprint freeze. It's hard to track cross project dependencies if we don't know they exist. None of the various escalation paths raised this patch. None of those things are good, they happened, things happen. Now it's a priority call. We have already delayed several blueprints (20 or 30) to try and get as many bugs fixed on features that have already made it into tree (we already have a backlog of well over 100 bug patches to review) and keep the priorities moving forward (that are mostly to help us go faster in the near future). Right now my gut tells me, partly in fairness to all the other things we have just not managed to get reviewed that did follow the process and met all the deadlines but were also unable to get merged, we should wait until Mitaka for this one,
Re: [openstack-dev] [Stable][Nova] VMware NSXv Support
On 13 August 2015 at 09:50, John Garbutt j...@johngarbutt.com wrote: On Wednesday, August 12, 2015, Thierry Carrez thie...@openstack.org wrote: Gary Kotton wrote: On 8/12/15, 12:12 AM, Mike Perez thin...@gmail.com wrote: On 15:39 Aug 11, Gary Kotton wrote: On 8/11/15, 6:09 PM, Jay Pipes jaypi...@gmail.com wrote: Are you saying that *new functionality* was added to the stable/kilo branch of *Neutron*, and because new functionality was added to stable/kilo's Neutron, that stable/kilo *Nova* will no longer work? Yes. That is exactly what I am saying. The issues is as follows. The NSXv manager requires the virtual machines VNIC index to enable the security groups to work. Without that a VM will not be able to send and receive traffic. In addition to this the NSXv plugin does not have any agents so we need to do the metadata plugin changes to ensure metadata support. So effectively with the patches: https://review.openstack.org/209372 and https://review.openstack.org/209374 the stable/kilo nova code will not work with the stable/kilo neutron NSXv plugin. snip So what do you suggest? This was added in Neutron during Kilo [1]. It's the responsibility of the patch owner to revert things if something doesn't land in a dependency patch of some other project. I'm not familiar with the patch, but you can see if Neutron folks will accept a revert in stable/kilo. There's no reason to get other projects involved because this wasn't handled properly. [1] - https://review.openstack.org/#/c/144278/ So you are suggesting that we revert the neutron plugin? I do not think that a revert is relevant here. Yeah, I'm not sure reverting the Neutron patch would be more acceptable. That one landed in Neutron kilo in time. The issue here is that due to Nova's review velocity during the kilo cycle (and arguably the failure to raise this as a cross-project issue affecting the release), the VMware NSXv support was shipped as broken in Kilo, and requires non-trivial changes to get fixed. I see this as Nova not shipping with VMware NSXv support in kilo, the feature was never completed, rather than it being broken. I could be missing something, but I also know that difference doesn't really help anyone. We have two options: bending the stable rules to allow the fix to be backported, or document it as broken in Kilo with the invasive patches being made available for people and distributions who still want to apply it. Given that we are 4 months into Kilo, I'd say stable/kilo users are used to this being broken at this point, so my vote would go for the second option. This would be backporting a new driver to an older release. That seems like a bad idea. That said, we should definitely raise [1] as a cross-project issue and see how we could work it into Liberty, so that we don't end up in the same dark corner in 4 months. I just don't want to break the stable rules (and the user confidence we've built around us applying them) to retroactively pay back review velocity / trust issues within Nova. [1] https://review.openstack.org/#/c/165750/ So this is the same issue. The VMware neutron driver has merged support for a feature where we have not managed to get into Nova yet. First the long term view... This is happening more frequently with Cinder drivers/features, Neutron things, and to a lesser extent Glance. The great work the Cinder folks have done with brick, is hopefully going to improve the situation for Cinder. There are a group of folks working on a similar VIF focused library to help making it easier to add support for new Neutron VIF drivers without needing to merge things in Nova. Right now those above efforts are largely focused on libvirt, but using oslo.vmware, or probably something else, I am sure we could evolve something similar for VMware, but I haven't dug into that. That is definetely the way to go in my opinion. I reckon VIF plugging is an area where there is a lot of coupling with Neutron, and decentralizing will be definetely beneficial for both contributors and reviewers. It should be ok to have a VMware-specific VIF library - it would not work really like cinderbrick, but from the nova perspective I think this does not matter. There are lots of coding efforts and process efforts to make the most of our current review bandwidth and to expand that bandwidth, but I don't think it's helpful to get into that here. So, more short term and specific points... This patch had no bug or blueprint attached. It eventually got noticed a few weeks after the blueprint freeze. It's hard to track cross project dependencies if we don't know they exist. None of the various escalation paths raised this patch. None of those things are good, they happened, things happen. The blueprint was indeed attached to the commit message only on the last patchset. This has been handled poorly by the
Re: [openstack-dev] [Stable][Nova] VMware NSXv Support
Gary Kotton wrote: On 8/12/15, 12:12 AM, Mike Perez thin...@gmail.com wrote: On 15:39 Aug 11, Gary Kotton wrote: On 8/11/15, 6:09 PM, Jay Pipes jaypi...@gmail.com wrote: Are you saying that *new functionality* was added to the stable/kilo branch of *Neutron*, and because new functionality was added to stable/kilo's Neutron, that stable/kilo *Nova* will no longer work? Yes. That is exactly what I am saying. The issues is as follows. The NSXv manager requires the virtual machines VNIC index to enable the security groups to work. Without that a VM will not be able to send and receive traffic. In addition to this the NSXv plugin does not have any agents so we need to do the metadata plugin changes to ensure metadata support. So effectively with the patches: https://review.openstack.org/209372 and https://review.openstack.org/209374 the stable/kilo nova code will not work with the stable/kilo neutron NSXv plugin. snip So what do you suggest? This was added in Neutron during Kilo [1]. It's the responsibility of the patch owner to revert things if something doesn't land in a dependency patch of some other project. I'm not familiar with the patch, but you can see if Neutron folks will accept a revert in stable/kilo. There's no reason to get other projects involved because this wasn't handled properly. [1] - https://review.openstack.org/#/c/144278/ So you are suggesting that we revert the neutron plugin? I do not think that a revert is relevant here. Yeah, I'm not sure reverting the Neutron patch would be more acceptable. That one landed in Neutron kilo in time. The issue here is that due to Nova's review velocity during the kilo cycle (and arguably the failure to raise this as a cross-project issue affecting the release), the VMware NSXv support was shipped as broken in Kilo, and requires non-trivial changes to get fixed. We have two options: bending the stable rules to allow the fix to be backported, or document it as broken in Kilo with the invasive patches being made available for people and distributions who still want to apply it. Given that we are 4 months into Kilo, I'd say stable/kilo users are used to this being broken at this point, so my vote would go for the second option. That said, we should definitely raise [1] as a cross-project issue and see how we could work it into Liberty, so that we don't end up in the same dark corner in 4 months. I just don't want to break the stable rules (and the user confidence we've built around us applying them) to retroactively pay back review velocity / trust issues within Nova. [1] https://review.openstack.org/#/c/165750/ -- Thierry Carrez (ttx) __ 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] [Stable][Nova] VMware NSXv Support
Apologies to go back in time in the tread, but I wanted to share some extra context... On 10 August 2015 at 16:17, Gary Kotton gkot...@vmware.com wrote: I agree that the sub team(s) need to review more. The question is how do the team member feel like they are making progress? That is, do they see patches Land. Do they receive postive feedback from cores that things are good, bad or ugly? I have tried to write up why I think everyone should do more reviews: https://wiki.openstack.org/wiki/Nova/Mentoring#Why_do_code_reviews_if_I_am_not_in_nova-core.3F I think that the PTL should assign at least 2 cores to each sub team. Let the team have accountability. Without that there is no way of getting anything done and we are back in the same spot. Without that we are just doing more of the same. The current plan (started at beginning of liberty) is to get subteams to help focus the core review effort by tell us what patches they have reviewed already, and think are the most important: https://etherpad.openstack.org/p/liberty-nova-priorities-tracking This worked well in kilo for the priorities and trivial patches. We are trying to extend it. I am regularly asking all cores to prefer review patches listed in the etherpad. It appears this is now starting to happen, slowly. I hope that recommendation becomes trusted enough to mean more than just please review me: https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#Subteam_recommendation_as_a_.2B2 Thanks, John PS A poor summary of some of the related discussions in the past, can be found here: https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#Splitting_out_the_virt_drivers_.28or_other_bits_of_code.29 __ 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] [Stable][Nova] VMware NSXv Support
On 15:39 Aug 11, Gary Kotton wrote: On 8/11/15, 6:09 PM, Jay Pipes jaypi...@gmail.com wrote: Are you saying that *new functionality* was added to the stable/kilo branch of *Neutron*, and because new functionality was added to stable/kilo's Neutron, that stable/kilo *Nova* will no longer work? Yes. That is exactly what I am saying. The issues is as follows. The NSXv manager requires the virtual machines VNIC index to enable the security groups to work. Without that a VM will not be able to send and receive traffic. In addition to this the NSXv plugin does not have any agents so we need to do the metadata plugin changes to ensure metadata support. So effectively with the patches: https://review.openstack.org/209372 and https://review.openstack.org/209374 the stable/kilo nova code will not work with the stable/kilo neutron NSXv plugin. snip So what do you suggest? This was added in Neutron during Kilo [1]. It's the responsibility of the patch owner to revert things if something doesn't land in a dependency patch of some other project. I'm not familiar with the patch, but you can see if Neutron folks will accept a revert in stable/kilo. There's no reason to get other projects involved because this wasn't handled properly. [1] - https://review.openstack.org/#/c/144278/ -- Mike Perez __ 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] [Stable][Nova] VMware NSXv Support
Hi, This is a stable issue - please see https://review.openstack.org/165750. This is required to support the plugin developed in Liberty. It is a bug too. This is now blocked in L and will also be 50/50 from landing in M. So will be in the same position again. As a result of the mail sent yesterday this was -2’ed. So please how can anyone actually add anything to Nova? There is the option of taking code and adding it out of tree to get features in like this, for example https://github.com/openstack/networking-vsphere/tree/master/networking_vsph ere/nova/virt/vmwareapi, but that is not healthy and prone to breakage. But this is what people have chosen as adding anything driver specific in Nova is likely to be blocked due to process. Thanks Gary On 8/10/15, 6:45 PM, Kuvaja, Erno kuv...@hp.com wrote: -Original Message- From: Gary Kotton [mailto:gkot...@vmware.com] Sent: Monday, August 10, 2015 4:18 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Stable][Nova] VMware NSXv Support On 8/10/15, 6:05 PM, Gary Kotton gkot...@vmware.com wrote: On 8/10/15, 6:03 PM, Gary Kotton gkot...@vmware.com wrote: On 8/10/15, 5:46 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 8/10/2015 9:17 AM, Gary Kotton wrote: Hi, I am not really sure what to say here. The code was in review for over 8 months. On a side note but related - we have a patch for a plugin developed in Liberty - https://review.openstack.org/#/c/165750/. This has been in review since March. I really hope that that lands in Liberty. If not we will go through the same thing again. Working in Nova on code that is self contained within a driver is difficult - terribly difficult. Not only is this demotivating, it also effectively does not help any of the drivers actually add any features. A sad day for OpenStack. Thanks Gary On 8/5/15, 4:01 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I think Erno made a valid point here. If that would touch only vmware code, that could be an option to consider. But it looks like both patches are very invasive, and they are not just enabling features that are already in the tree, but introduce new stuff that is not even tested for long in master. I guess we'll need to wait for those till Liberty. Unless nova-core-maint has a different opinion and good arguments to approach the merge. Ihar On 08/05/2015 12:37 PM, Kuvaja, Erno wrote: Hi Gary, While I do understand the interest to get this functionality included, I really fail to see how it would comply with the Stable Branch Policy: https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy Obviously the last say is on stable-maint-core, but normally new features are really no-no to stable branches. My concerns are more on the metadata side of your changes. Even the refactoring is fairly clean it is major part of the metadata handler. It also changes the API (In the case of X-Metadata-Provider being present) which tends to be sacred on stable branches. The changes here does not actually fix any bug but just implements new functionality that missed kilo not even slightly but by months. Thus my -1 for merging these. - Erno *From:*Gary Kotton [mailto:gkot...@vmware.com] *Sent:* Wednesday, August 05, 2015 8:03 AM *To:* OpenStack List *Subject:* [openstack-dev] [Stable][Nova] VMware NSXv Support Hi, In the Kilo cycle a Neutron driver was added for supporting the Vmware NSXv plugin. This required patches in Nova to enable the plugin to work with Nova. These patches finally landed yesterday. I have back ported them to stable/kilo as the Neutron driver is unable to work without these in stable/kilo. The patches can be found at: 1. VNIC support - https://review.openstack.org/209372 2. Metadata support - https://review.openstack.org/209374 I hope that the stable team can take this into consideration. Thanks in advance Gary __ ___ _ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVwgkjAAoJEC5aWaUY1u57NacIALsJ8oo6eJKqJIidBSFzwxv g zqJXHE56Lpg62/afRF94B2edfhm791Mz42LTFn0BHHRjV51TQX4k/Jf3Wr22CEv m zFZkU5eVMVOSL3GGnOZqSv/T06gBWmlMVodmSKQjGxrIL1s8G1m4aTwe6P qs+lie N+cT0pZbcjL/P1wYTac6XMpF226gO1owUjhE4oj9VZzx7kEqNsv22SIzVN2fQcc o YLs/LEcabMhuuV4Amde3RqUr0BkB+mlIX1TUv5/FTXT/F4ZwzYS/DBH9MaBJ5t 8n hgCTJzCeg598+irgOt3VJ3Jn3Unljz6LNzKIM8RnBG0o51fp8vfE/mODQQaUKOg = =ZYP8 -END PGP SIGNATURE
Re: [openstack-dev] [Stable][Nova] VMware NSXv Support
On 2015-08-11 13:49:37 + (+), Gary Kotton wrote: This is a stable issue - please see https://review.openstack.org/165750. This is required to support the plugin developed in Liberty. [...] I'm still missing the connection to stable. That review is targeting master (liberty). Stable currently means backports to kilo or juno. -- Jeremy Stanley __ 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] [Stable][Nova] VMware NSXv Support
On 08/11/2015 10:57 AM, Gary Kotton wrote: On 8/11/15, 5:08 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-08-11 13:49:37 + (+), Gary Kotton wrote: This is a stable issue - please see https://review.openstack.org/165750. This is required to support the plugin developed in Liberty. [...] I'm still missing the connection to stable. That review is targeting master (liberty). Stable currently means backports to kilo or juno. The patch has a -2 for Liberty. So it means that is is blocked as it is not a high priority nova BP. What does this mean, it means that nova will not be able to work with the neutron liberty plugin. This is exactly the same story that we had with the NSXv plugin. The nova stable kilo code will not work with the neutron stable kilo code. How can we as a community address this? Neutron enabled the community to develop at their own pace, whilst nova still has us in chains. Well, inflammatory statements probably won't help the situation, Gary :) Are you saying that *new functionality* was added to the stable/kilo branch of *Neutron*, and because new functionality was added to stable/kilo's Neutron, that stable/kilo *Nova* will no longer work? Best, -jay __ 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] [Stable][Nova] VMware NSXv Support
On 8/11/15, 6:09 PM, Jay Pipes jaypi...@gmail.com wrote: On 08/11/2015 10:57 AM, Gary Kotton wrote: On 8/11/15, 5:08 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-08-11 13:49:37 + (+), Gary Kotton wrote: This is a stable issue - please see https://review.openstack.org/165750. This is required to support the plugin developed in Liberty. [...] I'm still missing the connection to stable. That review is targeting master (liberty). Stable currently means backports to kilo or juno. The patch has a -2 for Liberty. So it means that is is blocked as it is not a high priority nova BP. What does this mean, it means that nova will not be able to work with the neutron liberty plugin. This is exactly the same story that we had with the NSXv plugin. The nova stable kilo code will not work with the neutron stable kilo code. How can we as a community address this? Neutron enabled the community to develop at their own pace, whilst nova still has us in chains. Well, inflammatory statements probably won't help the situation, Gary :) Jay, that is really what I feel. I am sorry but there is no other way that I can express myself. Are you saying that *new functionality* was added to the stable/kilo branch of *Neutron*, and because new functionality was added to stable/kilo's Neutron, that stable/kilo *Nova* will no longer work? Yes. That is exactly what I am saying. The issues is as follows. The NSXv manager requires the virtual machines VNIC index to enable the security groups to work. Without that a VM will not be able to send and receive traffic. In addition to this the NSXv plugin does not have any agents so we need to do the metadata plugin changes to ensure metadata support. So effectively with the patches: https://review.openstack.org/209372 and https://review.openstack.org/209374 the stable/kilo nova code will not work with the stable/kilo neutron NSXv plugin. Now having said that I understand the issues with this maybe breaking the stable back port rules. So the work around on my behalf was to update the wiki - https://wiki.openstack.org/wiki/Neutron/VMware_NSX_plugins - and whoever wants or needs this code can take the relevant patches. I guess that each distrobution can you their discretion if they want to take this or not - without it the plugin will not work. Now, it is not worthwhile crying over spilt milk for the kilo stuff. That boat has sailed. But for Liberty we need - https://review.openstack.org/165750. If this does not land in L we are going to be having the same thread again about 6 months time. This code is blocked with a -2. So what do you suggest? Best, -jay __ 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 __ 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] [Stable][Nova] VMware NSXv Support
On 08/11/2015 11:39 AM, Gary Kotton wrote: On 8/11/15, 6:09 PM, Jay Pipes jaypi...@gmail.com wrote: Are you saying that *new functionality* was added to the stable/kilo branch of *Neutron*, and because new functionality was added to stable/kilo's Neutron, that stable/kilo *Nova* will no longer work? Yes. That is exactly what I am saying. The issues is as follows. The NSXv manager requires the virtual machines VNIC index to enable the security groups to work. Without that a VM will not be able to send and receive traffic. In addition to this the NSXv plugin does not have any agents so we need to do the metadata plugin changes to ensure metadata support. So effectively with the patches: https://review.openstack.org/209372 and https://review.openstack.org/209374 the stable/kilo nova code will not work with the stable/kilo neutron NSXv plugin. Now having said that I understand the issues with this maybe breaking the stable back port rules. Not maybe. Definitely. :) So the work around on my behalf was to update the wiki - https://wiki.openstack.org/wiki/Neutron/VMware_NSX_plugins - and whoever wants or needs this code can take the relevant patches. I guess that each distrobution can you their discretion if they want to take this or not - without it the plugin will not work. Now, it is not worthwhile crying over spilt milk for the kilo stuff. That boat has sailed. But for Liberty we need - https://review.openstack.org/165750. If this does not land in L we are going to be having the same thread again about 6 months time. This code is blocked with a -2. So what do you suggest? Looking at https://review.openstack.org/165750, it looks like although you pushed the patch back in March, nobody other than Salvatore looked at it until two days ago. I think you probably could have notified folks that you needed reviews some time in between March and August. Personally, I've reviewed a number of VMWare patches over the last couple months, and I'm still a little annoyed about the whole Well, NSXv *requires* the (completely and utterly Nova-specific and non-ordinal) vNIC index to be specified in the VIF plug() request thing. I just think that the fact that NSXv relies on Nova's view of the sequential order of vNICs during plug() operations is an indication that the NSXv APIs are totally b0rked-by-design. But, you asked for my suggestion. And my suggestion would be more prior notification of critical dependencies like this. Best, -jay __ 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] [Stable][Nova] VMware NSXv Support
Sorry my bad. 7 months :) On 8/10/15, 5:17 PM, Gary Kotton gkot...@vmware.com wrote: Hi, I am not really sure what to say here. The code was in review for over 8 months. On a side note but related - we have a patch for a plugin developed in Liberty - https://review.openstack.org/#/c/165750/. This has been in review since March. I really hope that that lands in Liberty. If not we will go through the same thing again. Working in Nova on code that is self contained within a driver is difficult - terribly difficult. Not only is this demotivating, it also effectively does not help any of the drivers actually add any features. A sad day for OpenStack. Thanks Gary On 8/5/15, 4:01 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I think Erno made a valid point here. If that would touch only vmware code, that could be an option to consider. But it looks like both patches are very invasive, and they are not just enabling features that are already in the tree, but introduce new stuff that is not even tested for long in master. I guess we'll need to wait for those till Liberty. Unless nova-core-maint has a different opinion and good arguments to approach the merge. Ihar On 08/05/2015 12:37 PM, Kuvaja, Erno wrote: Hi Gary, While I do understand the interest to get this functionality included, I really fail to see how it would comply with the Stable Branch Policy: https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy Obviously the last say is on stable-maint-core, but normally new features are really no-no to stable branches. My concerns are more on the metadata side of your changes. Even the refactoring is fairly clean it is major part of the metadata handler. It also changes the API (In the case of X-Metadata-Provider being present) which tends to be sacred on stable branches. The changes here does not actually fix any bug but just implements new functionality that missed kilo not even slightly but by months. Thus my -1 for merging these. - Erno *From:*Gary Kotton [mailto:gkot...@vmware.com] *Sent:* Wednesday, August 05, 2015 8:03 AM *To:* OpenStack List *Subject:* [openstack-dev] [Stable][Nova] VMware NSXv Support Hi, In the Kilo cycle a Neutron driver was added for supporting the Vmware NSXv plugin. This required patches in Nova to enable the plugin to work with Nova. These patches finally landed yesterday. I have back ported them to stable/kilo as the Neutron driver is unable to work without these in stable/kilo. The patches can be found at: 1. VNIC support - https://review.openstack.org/209372 2. Metadata support - https://review.openstack.org/209374 I hope that the stable team can take this into consideration. Thanks in advance Gary __ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVwgkjAAoJEC5aWaUY1u57NacIALsJ8oo6eJKqJIidBSFzwxvg zqJXHE56Lpg62/afRF94B2edfhm791Mz42LTFn0BHHRjV51TQX4k/Jf3Wr22CEvm zFZkU5eVMVOSL3GGnOZqSv/T06gBWmlMVodmSKQjGxrIL1s8G1m4aTwe6Pqs+lie N+cT0pZbcjL/P1wYTac6XMpF226gO1owUjhE4oj9VZzx7kEqNsv22SIzVN2fQcco YLs/LEcabMhuuV4Amde3RqUr0BkB+mlIX1TUv5/FTXT/F4ZwzYS/DBH9MaBJ5t8n hgCTJzCeg598+irgOt3VJ3Jn3Unljz6LNzKIM8RnBG0o51fp8vfE/mODQQaUKOg= =ZYP8 -END PGP SIGNATURE- _ _ 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 __ 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 __ 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] [Stable][Nova] VMware NSXv Support
On 8/10/2015 9:17 AM, Gary Kotton wrote: Hi, I am not really sure what to say here. The code was in review for over 8 months. On a side note but related - we have a patch for a plugin developed in Liberty - https://review.openstack.org/#/c/165750/. This has been in review since March. I really hope that that lands in Liberty. If not we will go through the same thing again. Working in Nova on code that is self contained within a driver is difficult - terribly difficult. Not only is this demotivating, it also effectively does not help any of the drivers actually add any features. A sad day for OpenStack. Thanks Gary On 8/5/15, 4:01 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I think Erno made a valid point here. If that would touch only vmware code, that could be an option to consider. But it looks like both patches are very invasive, and they are not just enabling features that are already in the tree, but introduce new stuff that is not even tested for long in master. I guess we'll need to wait for those till Liberty. Unless nova-core-maint has a different opinion and good arguments to approach the merge. Ihar On 08/05/2015 12:37 PM, Kuvaja, Erno wrote: Hi Gary, While I do understand the interest to get this functionality included, I really fail to see how it would comply with the Stable Branch Policy: https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy Obviously the last say is on stable-maint-core, but normally new features are really no-no to stable branches. My concerns are more on the metadata side of your changes. Even the refactoring is fairly clean it is major part of the metadata handler. It also changes the API (In the case of X-Metadata-Provider being present) which tends to be sacred on stable branches. The changes here does not actually fix any bug but just implements new functionality that missed kilo not even slightly but by months. Thus my -1 for merging these. - Erno *From:*Gary Kotton [mailto:gkot...@vmware.com] *Sent:* Wednesday, August 05, 2015 8:03 AM *To:* OpenStack List *Subject:* [openstack-dev] [Stable][Nova] VMware NSXv Support Hi, In the Kilo cycle a Neutron driver was added for supporting the Vmware NSXv plugin. This required patches in Nova to enable the plugin to work with Nova. These patches finally landed yesterday. I have back ported them to stable/kilo as the Neutron driver is unable to work without these in stable/kilo. The patches can be found at: 1. VNIC support - https://review.openstack.org/209372 2. Metadata support - https://review.openstack.org/209374 I hope that the stable team can take this into consideration. Thanks in advance Gary __ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVwgkjAAoJEC5aWaUY1u57NacIALsJ8oo6eJKqJIidBSFzwxvg zqJXHE56Lpg62/afRF94B2edfhm791Mz42LTFn0BHHRjV51TQX4k/Jf3Wr22CEvm zFZkU5eVMVOSL3GGnOZqSv/T06gBWmlMVodmSKQjGxrIL1s8G1m4aTwe6Pqs+lie N+cT0pZbcjL/P1wYTac6XMpF226gO1owUjhE4oj9VZzx7kEqNsv22SIzVN2fQcco YLs/LEcabMhuuV4Amde3RqUr0BkB+mlIX1TUv5/FTXT/F4ZwzYS/DBH9MaBJ5t8n hgCTJzCeg598+irgOt3VJ3Jn3Unljz6LNzKIM8RnBG0o51fp8vfE/mODQQaUKOg= =ZYP8 -END PGP SIGNATURE- __ 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 __ 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 https://review.openstack.org/#/c/165750/ is a feature add but it's not targeted against a blueprint, so it's just running as a random thing outside any tracking mechanism for features (launchpad). Salvatore made some comments back in March but otherwise no one from the VMware development team has even commented on this. As I've said in some other VMware patches in Nova lately, I expect the VMware sub-team to be doing a better job of reviewing each other's code first since they are supposed to be the subject matter experts here. I know Gary reviews pretty much all of the changes that go into the VMware driver in Nova but I don't see the same reciprocated from other members of that team which I think also slows down development - and it impedes building a trust relationship between nova-core and the sub-team to be self-reviewing. -- Thanks, Matt Riedemann
Re: [openstack-dev] [Stable][Nova] VMware NSXv Support
On 8/10/15, 5:46 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 8/10/2015 9:17 AM, Gary Kotton wrote: Hi, I am not really sure what to say here. The code was in review for over 8 months. On a side note but related - we have a patch for a plugin developed in Liberty - https://review.openstack.org/#/c/165750/. This has been in review since March. I really hope that that lands in Liberty. If not we will go through the same thing again. Working in Nova on code that is self contained within a driver is difficult - terribly difficult. Not only is this demotivating, it also effectively does not help any of the drivers actually add any features. A sad day for OpenStack. Thanks Gary On 8/5/15, 4:01 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I think Erno made a valid point here. If that would touch only vmware code, that could be an option to consider. But it looks like both patches are very invasive, and they are not just enabling features that are already in the tree, but introduce new stuff that is not even tested for long in master. I guess we'll need to wait for those till Liberty. Unless nova-core-maint has a different opinion and good arguments to approach the merge. Ihar On 08/05/2015 12:37 PM, Kuvaja, Erno wrote: Hi Gary, While I do understand the interest to get this functionality included, I really fail to see how it would comply with the Stable Branch Policy: https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy Obviously the last say is on stable-maint-core, but normally new features are really no-no to stable branches. My concerns are more on the metadata side of your changes. Even the refactoring is fairly clean it is major part of the metadata handler. It also changes the API (In the case of X-Metadata-Provider being present) which tends to be sacred on stable branches. The changes here does not actually fix any bug but just implements new functionality that missed kilo not even slightly but by months. Thus my -1 for merging these. - Erno *From:*Gary Kotton [mailto:gkot...@vmware.com] *Sent:* Wednesday, August 05, 2015 8:03 AM *To:* OpenStack List *Subject:* [openstack-dev] [Stable][Nova] VMware NSXv Support Hi, In the Kilo cycle a Neutron driver was added for supporting the Vmware NSXv plugin. This required patches in Nova to enable the plugin to work with Nova. These patches finally landed yesterday. I have back ported them to stable/kilo as the Neutron driver is unable to work without these in stable/kilo. The patches can be found at: 1. VNIC support - https://review.openstack.org/209372 2. Metadata support - https://review.openstack.org/209374 I hope that the stable team can take this into consideration. Thanks in advance Gary __ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVwgkjAAoJEC5aWaUY1u57NacIALsJ8oo6eJKqJIidBSFzwxvg zqJXHE56Lpg62/afRF94B2edfhm791Mz42LTFn0BHHRjV51TQX4k/Jf3Wr22CEvm zFZkU5eVMVOSL3GGnOZqSv/T06gBWmlMVodmSKQjGxrIL1s8G1m4aTwe6Pqs+lie N+cT0pZbcjL/P1wYTac6XMpF226gO1owUjhE4oj9VZzx7kEqNsv22SIzVN2fQcco YLs/LEcabMhuuV4Amde3RqUr0BkB+mlIX1TUv5/FTXT/F4ZwzYS/DBH9MaBJ5t8n hgCTJzCeg598+irgOt3VJ3Jn3Unljz6LNzKIM8RnBG0o51fp8vfE/mODQQaUKOg= =ZYP8 -END PGP SIGNATURE- __ 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 _ _ 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 https://review.openstack.org/#/c/165750/ is a feature add but it's not targeted against a blueprint, so it's just running as a random thing outside any tracking mechanism for features (launchpad). Salvatore made some comments back in March but otherwise no one from the VMware development team has even commented on this. As I've said in some other VMware patches in Nova lately, I expect the VMware sub-team to be doing a better job of reviewing each other's code first since they are supposed to be the subject matter experts here. I know Gary reviews pretty much all of the changes that go into the VMware driver in Nova but I don't see the same reciprocated from other members of that team which I think also slows down development - and it impedes building a trust
Re: [openstack-dev] [Stable][Nova] VMware NSXv Support
-Original Message- From: Gary Kotton [mailto:gkot...@vmware.com] Sent: Monday, August 10, 2015 4:18 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Stable][Nova] VMware NSXv Support On 8/10/15, 6:05 PM, Gary Kotton gkot...@vmware.com wrote: On 8/10/15, 6:03 PM, Gary Kotton gkot...@vmware.com wrote: On 8/10/15, 5:46 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 8/10/2015 9:17 AM, Gary Kotton wrote: Hi, I am not really sure what to say here. The code was in review for over 8 months. On a side note but related - we have a patch for a plugin developed in Liberty - https://review.openstack.org/#/c/165750/. This has been in review since March. I really hope that that lands in Liberty. If not we will go through the same thing again. Working in Nova on code that is self contained within a driver is difficult - terribly difficult. Not only is this demotivating, it also effectively does not help any of the drivers actually add any features. A sad day for OpenStack. Thanks Gary On 8/5/15, 4:01 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I think Erno made a valid point here. If that would touch only vmware code, that could be an option to consider. But it looks like both patches are very invasive, and they are not just enabling features that are already in the tree, but introduce new stuff that is not even tested for long in master. I guess we'll need to wait for those till Liberty. Unless nova-core-maint has a different opinion and good arguments to approach the merge. Ihar On 08/05/2015 12:37 PM, Kuvaja, Erno wrote: Hi Gary, While I do understand the interest to get this functionality included, I really fail to see how it would comply with the Stable Branch Policy: https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy Obviously the last say is on stable-maint-core, but normally new features are really no-no to stable branches. My concerns are more on the metadata side of your changes. Even the refactoring is fairly clean it is major part of the metadata handler. It also changes the API (In the case of X-Metadata-Provider being present) which tends to be sacred on stable branches. The changes here does not actually fix any bug but just implements new functionality that missed kilo not even slightly but by months. Thus my -1 for merging these. - Erno *From:*Gary Kotton [mailto:gkot...@vmware.com] *Sent:* Wednesday, August 05, 2015 8:03 AM *To:* OpenStack List *Subject:* [openstack-dev] [Stable][Nova] VMware NSXv Support Hi, In the Kilo cycle a Neutron driver was added for supporting the Vmware NSXv plugin. This required patches in Nova to enable the plugin to work with Nova. These patches finally landed yesterday. I have back ported them to stable/kilo as the Neutron driver is unable to work without these in stable/kilo. The patches can be found at: 1. VNIC support - https://review.openstack.org/209372 2. Metadata support - https://review.openstack.org/209374 I hope that the stable team can take this into consideration. Thanks in advance Gary __ ___ _ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVwgkjAAoJEC5aWaUY1u57NacIALsJ8oo6eJKqJIidBSFzwxv g zqJXHE56Lpg62/afRF94B2edfhm791Mz42LTFn0BHHRjV51TQX4k/Jf3Wr22CEv m zFZkU5eVMVOSL3GGnOZqSv/T06gBWmlMVodmSKQjGxrIL1s8G1m4aTwe6P qs+lie N+cT0pZbcjL/P1wYTac6XMpF226gO1owUjhE4oj9VZzx7kEqNsv22SIzVN2fQcc o YLs/LEcabMhuuV4Amde3RqUr0BkB+mlIX1TUv5/FTXT/F4ZwzYS/DBH9MaBJ5t 8n hgCTJzCeg598+irgOt3VJ3Jn3Unljz6LNzKIM8RnBG0o51fp8vfE/mODQQaUKOg = =ZYP8 -END PGP SIGNATURE- _ __ ___ _ _ __ 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 __ __ ___ _ _ _ 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 https://review.openstack.org/#/c/165750/ is a feature add but it's not targeted against a blueprint, so it's just running as a random thing outside any tracking mechanism for features (launchpad). Salvatore made some comments back in March
Re: [openstack-dev] [Stable][Nova] VMware NSXv Support
On 8/10/15, 6:03 PM, Gary Kotton gkot...@vmware.com wrote: On 8/10/15, 5:46 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 8/10/2015 9:17 AM, Gary Kotton wrote: Hi, I am not really sure what to say here. The code was in review for over 8 months. On a side note but related - we have a patch for a plugin developed in Liberty - https://review.openstack.org/#/c/165750/. This has been in review since March. I really hope that that lands in Liberty. If not we will go through the same thing again. Working in Nova on code that is self contained within a driver is difficult - terribly difficult. Not only is this demotivating, it also effectively does not help any of the drivers actually add any features. A sad day for OpenStack. Thanks Gary On 8/5/15, 4:01 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I think Erno made a valid point here. If that would touch only vmware code, that could be an option to consider. But it looks like both patches are very invasive, and they are not just enabling features that are already in the tree, but introduce new stuff that is not even tested for long in master. I guess we'll need to wait for those till Liberty. Unless nova-core-maint has a different opinion and good arguments to approach the merge. Ihar On 08/05/2015 12:37 PM, Kuvaja, Erno wrote: Hi Gary, While I do understand the interest to get this functionality included, I really fail to see how it would comply with the Stable Branch Policy: https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy Obviously the last say is on stable-maint-core, but normally new features are really no-no to stable branches. My concerns are more on the metadata side of your changes. Even the refactoring is fairly clean it is major part of the metadata handler. It also changes the API (In the case of X-Metadata-Provider being present) which tends to be sacred on stable branches. The changes here does not actually fix any bug but just implements new functionality that missed kilo not even slightly but by months. Thus my -1 for merging these. - Erno *From:*Gary Kotton [mailto:gkot...@vmware.com] *Sent:* Wednesday, August 05, 2015 8:03 AM *To:* OpenStack List *Subject:* [openstack-dev] [Stable][Nova] VMware NSXv Support Hi, In the Kilo cycle a Neutron driver was added for supporting the Vmware NSXv plugin. This required patches in Nova to enable the plugin to work with Nova. These patches finally landed yesterday. I have back ported them to stable/kilo as the Neutron driver is unable to work without these in stable/kilo. The patches can be found at: 1. VNIC support - https://review.openstack.org/209372 2. Metadata support - https://review.openstack.org/209374 I hope that the stable team can take this into consideration. Thanks in advance Gary __ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVwgkjAAoJEC5aWaUY1u57NacIALsJ8oo6eJKqJIidBSFzwxvg zqJXHE56Lpg62/afRF94B2edfhm791Mz42LTFn0BHHRjV51TQX4k/Jf3Wr22CEvm zFZkU5eVMVOSL3GGnOZqSv/T06gBWmlMVodmSKQjGxrIL1s8G1m4aTwe6Pqs+lie N+cT0pZbcjL/P1wYTac6XMpF226gO1owUjhE4oj9VZzx7kEqNsv22SIzVN2fQcco YLs/LEcabMhuuV4Amde3RqUr0BkB+mlIX1TUv5/FTXT/F4ZwzYS/DBH9MaBJ5t8n hgCTJzCeg598+irgOt3VJ3Jn3Unljz6LNzKIM8RnBG0o51fp8vfE/mODQQaUKOg= =ZYP8 -END PGP SIGNATURE- ___ _ __ 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 _ _ 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 https://review.openstack.org/#/c/165750/ is a feature add but it's not targeted against a blueprint, so it's just running as a random thing outside any tracking mechanism for features (launchpad). Salvatore made some comments back in March but otherwise no one from the VMware development team has even commented on this. As I've said in some other VMware patches in Nova lately, I expect the VMware sub-team to be doing a better job of reviewing each other's code first since they are supposed to be the subject matter experts here. I know Gary reviews pretty much all of the changes that go into the VMware driver in Nova but I don't see the same reciprocated from other members of that team which I think also
Re: [openstack-dev] [Stable][Nova] VMware NSXv Support
On 8/10/15, 6:05 PM, Gary Kotton gkot...@vmware.com wrote: On 8/10/15, 6:03 PM, Gary Kotton gkot...@vmware.com wrote: On 8/10/15, 5:46 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 8/10/2015 9:17 AM, Gary Kotton wrote: Hi, I am not really sure what to say here. The code was in review for over 8 months. On a side note but related - we have a patch for a plugin developed in Liberty - https://review.openstack.org/#/c/165750/. This has been in review since March. I really hope that that lands in Liberty. If not we will go through the same thing again. Working in Nova on code that is self contained within a driver is difficult - terribly difficult. Not only is this demotivating, it also effectively does not help any of the drivers actually add any features. A sad day for OpenStack. Thanks Gary On 8/5/15, 4:01 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I think Erno made a valid point here. If that would touch only vmware code, that could be an option to consider. But it looks like both patches are very invasive, and they are not just enabling features that are already in the tree, but introduce new stuff that is not even tested for long in master. I guess we'll need to wait for those till Liberty. Unless nova-core-maint has a different opinion and good arguments to approach the merge. Ihar On 08/05/2015 12:37 PM, Kuvaja, Erno wrote: Hi Gary, While I do understand the interest to get this functionality included, I really fail to see how it would comply with the Stable Branch Policy: https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy Obviously the last say is on stable-maint-core, but normally new features are really no-no to stable branches. My concerns are more on the metadata side of your changes. Even the refactoring is fairly clean it is major part of the metadata handler. It also changes the API (In the case of X-Metadata-Provider being present) which tends to be sacred on stable branches. The changes here does not actually fix any bug but just implements new functionality that missed kilo not even slightly but by months. Thus my -1 for merging these. - Erno *From:*Gary Kotton [mailto:gkot...@vmware.com] *Sent:* Wednesday, August 05, 2015 8:03 AM *To:* OpenStack List *Subject:* [openstack-dev] [Stable][Nova] VMware NSXv Support Hi, In the Kilo cycle a Neutron driver was added for supporting the Vmware NSXv plugin. This required patches in Nova to enable the plugin to work with Nova. These patches finally landed yesterday. I have back ported them to stable/kilo as the Neutron driver is unable to work without these in stable/kilo. The patches can be found at: 1. VNIC support - https://review.openstack.org/209372 2. Metadata support - https://review.openstack.org/209374 I hope that the stable team can take this into consideration. Thanks in advance Gary _ _ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVwgkjAAoJEC5aWaUY1u57NacIALsJ8oo6eJKqJIidBSFzwxvg zqJXHE56Lpg62/afRF94B2edfhm791Mz42LTFn0BHHRjV51TQX4k/Jf3Wr22CEvm zFZkU5eVMVOSL3GGnOZqSv/T06gBWmlMVodmSKQjGxrIL1s8G1m4aTwe6Pqs+lie N+cT0pZbcjL/P1wYTac6XMpF226gO1owUjhE4oj9VZzx7kEqNsv22SIzVN2fQcco YLs/LEcabMhuuV4Amde3RqUr0BkB+mlIX1TUv5/FTXT/F4ZwzYS/DBH9MaBJ5t8n hgCTJzCeg598+irgOt3VJ3Jn3Unljz6LNzKIM8RnBG0o51fp8vfE/mODQQaUKOg= =ZYP8 -END PGP SIGNATURE- __ _ _ __ 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 ___ _ _ _ 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 https://review.openstack.org/#/c/165750/ is a feature add but it's not targeted against a blueprint, so it's just running as a random thing outside any tracking mechanism for features (launchpad). Salvatore made some comments back in March but otherwise no one from the VMware development team has even commented on this. As I've said in some other VMware patches in Nova lately, I expect the VMware sub-team to be doing a better job of reviewing each other's code first since they are supposed to be the subject matter experts here. I know Gary reviews pretty much all of the changes that go into the VMware driver in Nova but I don't see the same
Re: [openstack-dev] [Stable][Nova] VMware NSXv Support
Hi, I am not really sure what to say here. The code was in review for over 8 months. On a side note but related - we have a patch for a plugin developed in Liberty - https://review.openstack.org/#/c/165750/. This has been in review since March. I really hope that that lands in Liberty. If not we will go through the same thing again. Working in Nova on code that is self contained within a driver is difficult - terribly difficult. Not only is this demotivating, it also effectively does not help any of the drivers actually add any features. A sad day for OpenStack. Thanks Gary On 8/5/15, 4:01 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I think Erno made a valid point here. If that would touch only vmware code, that could be an option to consider. But it looks like both patches are very invasive, and they are not just enabling features that are already in the tree, but introduce new stuff that is not even tested for long in master. I guess we'll need to wait for those till Liberty. Unless nova-core-maint has a different opinion and good arguments to approach the merge. Ihar On 08/05/2015 12:37 PM, Kuvaja, Erno wrote: Hi Gary, While I do understand the interest to get this functionality included, I really fail to see how it would comply with the Stable Branch Policy: https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy Obviously the last say is on stable-maint-core, but normally new features are really no-no to stable branches. My concerns are more on the metadata side of your changes. Even the refactoring is fairly clean it is major part of the metadata handler. It also changes the API (In the case of X-Metadata-Provider being present) which tends to be sacred on stable branches. The changes here does not actually fix any bug but just implements new functionality that missed kilo not even slightly but by months. Thus my -1 for merging these. - Erno *From:*Gary Kotton [mailto:gkot...@vmware.com] *Sent:* Wednesday, August 05, 2015 8:03 AM *To:* OpenStack List *Subject:* [openstack-dev] [Stable][Nova] VMware NSXv Support Hi, In the Kilo cycle a Neutron driver was added for supporting the Vmware NSXv plugin. This required patches in Nova to enable the plugin to work with Nova. These patches finally landed yesterday. I have back ported them to stable/kilo as the Neutron driver is unable to work without these in stable/kilo. The patches can be found at: 1. VNIC support - https://review.openstack.org/209372 2. Metadata support - https://review.openstack.org/209374 I hope that the stable team can take this into consideration. Thanks in advance Gary __ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVwgkjAAoJEC5aWaUY1u57NacIALsJ8oo6eJKqJIidBSFzwxvg zqJXHE56Lpg62/afRF94B2edfhm791Mz42LTFn0BHHRjV51TQX4k/Jf3Wr22CEvm zFZkU5eVMVOSL3GGnOZqSv/T06gBWmlMVodmSKQjGxrIL1s8G1m4aTwe6Pqs+lie N+cT0pZbcjL/P1wYTac6XMpF226gO1owUjhE4oj9VZzx7kEqNsv22SIzVN2fQcco YLs/LEcabMhuuV4Amde3RqUr0BkB+mlIX1TUv5/FTXT/F4ZwzYS/DBH9MaBJ5t8n hgCTJzCeg598+irgOt3VJ3Jn3Unljz6LNzKIM8RnBG0o51fp8vfE/mODQQaUKOg= =ZYP8 -END PGP SIGNATURE- __ 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 __ 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
[openstack-dev] [Stable][Nova] VMware NSXv Support
Hi, In the Kilo cycle a Neutron driver was added for supporting the Vmware NSXv plugin. This required patches in Nova to enable the plugin to work with Nova. These patches finally landed yesterday. I have back ported them to stable/kilo as the Neutron driver is unable to work without these in stable/kilo. The patches can be found at: 1. VNIC support - https://review.openstack.org/209372 2. Metadata support - https://review.openstack.org/209374 I hope that the stable team can take this into consideration. Thanks in advance Gary __ 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] [Stable][Nova] VMware NSXv Support
Hi Gary, While I do understand the interest to get this functionality included, I really fail to see how it would comply with the Stable Branch Policy: https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy Obviously the last say is on stable-maint-core, but normally new features are really no-no to stable branches. My concerns are more on the metadata side of your changes. Even the refactoring is fairly clean it is major part of the metadata handler. It also changes the API (In the case of X-Metadata-Provider being present) which tends to be sacred on stable branches. The changes here does not actually fix any bug but just implements new functionality that missed kilo not even slightly but by months. Thus my -1 for merging these. - Erno From: Gary Kotton [mailto:gkot...@vmware.com] Sent: Wednesday, August 05, 2015 8:03 AM To: OpenStack List Subject: [openstack-dev] [Stable][Nova] VMware NSXv Support Hi, In the Kilo cycle a Neutron driver was added for supporting the Vmware NSXv plugin. This required patches in Nova to enable the plugin to work with Nova. These patches finally landed yesterday. I have back ported them to stable/kilo as the Neutron driver is unable to work without these in stable/kilo. The patches can be found at: 1. VNIC support - https://review.openstack.org/209372 2. Metadata support - https://review.openstack.org/209374 I hope that the stable team can take this into consideration. Thanks in advance Gary __ 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] [Stable][Nova] VMware NSXv Support
Hi, Thanks for the comments. I agree with you that this does not comply with the policy. I wanted to raise the issue as whoever is going to use the Neutron driver with stable/kilo will need these patches. I will update the plugin wiki indicating that these two patches are required to get it working for stable/kilo. Thanks Gary From: Kuvaja, Erno kuv...@hp.commailto:kuv...@hp.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, August 5, 2015 at 1:37 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Stable][Nova] VMware NSXv Support Hi Gary, While I do understand the interest to get this functionality included, I really fail to see how it would comply with the Stable Branch Policy: https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy Obviously the last say is on stable-maint-core, but normally new features are really no-no to stable branches. My concerns are more on the metadata side of your changes. Even the refactoring is fairly clean it is major part of the metadata handler. It also changes the API (In the case of X-Metadata-Provider being present) which tends to be sacred on stable branches. The changes here does not actually fix any bug but just implements new functionality that missed kilo not even slightly but by months. Thus my -1 for merging these. - Erno From: Gary Kotton [mailto:gkot...@vmware.com] Sent: Wednesday, August 05, 2015 8:03 AM To: OpenStack List Subject: [openstack-dev] [Stable][Nova] VMware NSXv Support Hi, In the Kilo cycle a Neutron driver was added for supporting the Vmware NSXv plugin. This required patches in Nova to enable the plugin to work with Nova. These patches finally landed yesterday. I have back ported them to stable/kilo as the Neutron driver is unable to work without these in stable/kilo. The patches can be found at: 1. VNIC support - https://review.openstack.org/209372 2. Metadata support - https://review.openstack.org/209374 I hope that the stable team can take this into consideration. Thanks in advance Gary __ 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] [Stable][Nova] VMware NSXv Support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I think Erno made a valid point here. If that would touch only vmware code, that could be an option to consider. But it looks like both patches are very invasive, and they are not just enabling features that are already in the tree, but introduce new stuff that is not even tested for long in master. I guess we'll need to wait for those till Liberty. Unless nova-core-maint has a different opinion and good arguments to approach the merge. Ihar On 08/05/2015 12:37 PM, Kuvaja, Erno wrote: Hi Gary, While I do understand the interest to get this functionality included, I really fail to see how it would comply with the Stable Branch Policy: https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy Obviously the last say is on stable-maint-core, but normally new features are really no-no to stable branches. My concerns are more on the metadata side of your changes. Even the refactoring is fairly clean it is major part of the metadata handler. It also changes the API (In the case of X-Metadata-Provider being present) which tends to be sacred on stable branches. The changes here does not actually fix any bug but just implements new functionality that missed kilo not even slightly but by months. Thus my -1 for merging these. - Erno *From:*Gary Kotton [mailto:gkot...@vmware.com] *Sent:* Wednesday, August 05, 2015 8:03 AM *To:* OpenStack List *Subject:* [openstack-dev] [Stable][Nova] VMware NSXv Support Hi, In the Kilo cycle a Neutron driver was added for supporting the Vmware NSXv plugin. This required patches in Nova to enable the plugin to work with Nova. These patches finally landed yesterday. I have back ported them to stable/kilo as the Neutron driver is unable to work without these in stable/kilo. The patches can be found at: 1. VNIC support - https://review.openstack.org/209372 2. Metadata support - https://review.openstack.org/209374 I hope that the stable team can take this into consideration. Thanks in advance Gary __ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVwgkjAAoJEC5aWaUY1u57NacIALsJ8oo6eJKqJIidBSFzwxvg zqJXHE56Lpg62/afRF94B2edfhm791Mz42LTFn0BHHRjV51TQX4k/Jf3Wr22CEvm zFZkU5eVMVOSL3GGnOZqSv/T06gBWmlMVodmSKQjGxrIL1s8G1m4aTwe6Pqs+lie N+cT0pZbcjL/P1wYTac6XMpF226gO1owUjhE4oj9VZzx7kEqNsv22SIzVN2fQcco YLs/LEcabMhuuV4Amde3RqUr0BkB+mlIX1TUv5/FTXT/F4ZwzYS/DBH9MaBJ5t8n hgCTJzCeg598+irgOt3VJ3Jn3Unljz6LNzKIM8RnBG0o51fp8vfE/mODQQaUKOg= =ZYP8 -END PGP SIGNATURE- __ 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
