Open Stack

On 31 October 2015 at 23:06, Armando M. <armamig at gmail.com> wrote:
> On 30 October 2015 at 23:59, Matt Riedemann <mriedem at linux.vnet.ibm.com>
> wrote:
>> On 10/30/2015 7:41 AM, Armando M. wrote:
>>> On 30 October 2015 at 18:41, Francesco Santoro
>>> <francesco.santoro at 6wind.com <mailto:francesco.santoro at 6wind.com>> wrote:
>>>     Hi Armando,
>>>     thanks for you answer.
>>>
>>>     We actually just want approval for posting non voting comments to
>>>     neutron.
>>>     As you said we don't have a significant history on Gerrit because,
>>>     after some successful tests, we stopped posting comments on neutron
>>>     (and nova) waiting for core maintainers approval.
>>>     Our current CI activity is obviously not long enough to request
>>>     voting rights.
>>>
>>>     We are still commenting back to Gerrit on ci-devstack but there is
>>>     no big activity on this project.
>>>     Since our idea (for future) is to obtain voting rights we need to
>>>     post comments to have a stronger Gerrit activity and to let you
>>>     evaluate the stability of our CI.
>>>
>>>     Do you suggest to keep posting on ci-devstack or can we enable
>>>     comments to neutron as well?
>>>
>>>
>>> I would be ok to have this voting for now.
>>>
>>> Having said that, Mike (cc-ed here) will be working closely with the
>>> Neutron team to re-align/improve Neutron 3rd party CI support, so stay
>>> tuned for progresses on this front.
>>>
>>> Cheers,
>>> Armando
>>>
>>>
>>>     Regards,
>>>     Francesco
>>>     On Fri, Oct 30, 2015 at 1:17 AM, Armando M. <armamig at gmail.com
>>>     <mailto:armamig at gmail.com>> wrote:
>>>
>>>
>>>
>>>         On 30 October 2015 at 02:49, Matt Riedemann
>>>         <mriedem at linux.vnet.ibm.com <mailto:mriedem at linux.vnet.ibm.com>>
>>>
>>>         wrote:
>>>
>>>
>>>
>>>             On 10/29/2015 12:13 PM, Francesco Santoro wrote:
>>>
>>>                 Dear Infra team,
>>>
>>>                 According to the requirements specified in [1] posting
>>>                 comments on
>>>                 patches needs approval from core maintainers of projects.
>>>
>>>                 Here at 6WIND we deployed and successfully tested [2]
>>>                 (using ci-sandbox
>>>                 project) our third party CI system [4] following all the
>>>                 steps defined
>>>                 in [1].
>>>                 We also run our CI on nova (and neutron) patches without
>>>                 posting
>>>                 comments just to test a bigger jobs load.
>>>                 Example artifacts are available at [3]
>>>
>>>                 For this reason we would like to get your official
>>>                 approval for posting
>>>                 non voting comments to both nova and neutron.
>>>
>>>
>>>         The CI hasn't been doing this long enough [1] to really see how
>>>         reliable it is, but it's been promising so far.
>>>
>>>
>>>         [1]
>>>
>>> https://review.openstack.org/#/q/reviewer:%226WIND+Networking+CI+%253Copenstack-networking-ci%25406wind.com%253E%22+project:openstack/neutron,n,z
>>>
>>>
>>>
>>>                 Kind regards,
>>>                 Francesco
>>>
>>>                 [1]
>>>
>>> http://docs.openstack.org/infra/system-config/third_party.html#requirements
>>>                 [2] https://review.openstack.org/#/c/238139/ or
>>>                 https://review.openstack.org/#/c/226956/
>>>                 [3]
>>>                 http://openstack-ci.6wind.com/networking-6wind-ci/230537
>>> or
>>>                 http://openstack-ci.6wind.com/networking-6wind-ci/202098
>>>                 [4]
>>>
>>> https://wiki.openstack.org/wiki/ThirdPartySystems/6WIND_Networking_CI
>>>
>>>
>>>
>>> __________________________________________________________________________
>>>                 OpenStack Development Mailing List (not for usage
>>> questions)
>>>                 Unsubscribe:
>>>
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>
>>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>             Do you have any code in nova that's specific to your
>>>             configuration?
>>>
>>>             --
>>>
>>>             Thanks,
>>>
>>>             Matt Riedemann
>>>
>>>
>>>
>>> __________________________________________________________________________
>>>             OpenStack Development Mailing List (not for usage questions)
>>>             Unsubscribe:
>>>             OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> <http://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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
>>>
>>
>> Personally I wouldn't want the noise in nova from a neutron 3rd party
>> vendor CI until there is code in nova (whatever the monkey patch is). Things
>> get a bit tricky when one project has a lot of out of tree stuff (neutron
>> stadium) and another doesn't support that (nova), and the CI is caught in
>> the middle.

For extra context:

The os vif lib effort is looking to help address that miss match, over
the long term.
Also, the consensus was to not block new VIF drivers while we get os
vif lib in place

> Makes sense, but I wonder why nova chose the path of an implicit hook
> mechanism.
>
> What was the purpose for it, if not to allow extensions to plug in without
> the need of being part of the nova tree? I might be missing something.

os vif lib is looking at a stevedore based system to support plugins
in a better way.

Thanks,
johnthetubaguy