Open Stack

On 8/10/15, 6:03 PM, "Gary Kotton" <gkotton at vmware.com> wrote:

>
>
>On 8/10/15, 5:46 PM, "Matt Riedemann" <mriedem at 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" <ihrachys at 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:gkotton at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>