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 slows down development - and it >>impedes building a trust relationship between nova-core and the sub-team >>to be self-reviewing. > >Matt, I understand that ask. In the past when the team has reviewed the >patches, >Trivial fixes have remained in review for months. > >For example: https://review.openstack.org/#/c/186716/. > >We are really between a rock and a hard place here. You yourself have also >stated that sometimes the review from sub-team members are ignored as they >are not ³trusted². > >So please advise. Here is another fine example - https://review.openstack.org/#/c/163831/ > > >> >>-- >> >>Thanks, >> >>Matt Riedemann >> >> >>_________________________________________________________________________ >>_ >>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