[openstack-dev] [nova] [infra] The same SRIOV / NFV CI failures missed a regression, why?

Jay Pipes jaypipes at gmail.com
Tue Apr 5 00:06:03 UTC 2016

On 04/04/2016 06:56 PM, Jeremy Stanley wrote:
> On 2016-04-04 13:54:34 -0400 (-0400), Jay Pipes wrote:
>> On 03/30/2016 11:00 PM, Robert Collins wrote:
>>> On 26 March 2016 at 09:08, Jeremy Stanley <fungi at yuggoth.org> wrote:
>>>> On 2016-03-25 15:20:00 -0400 (-0400), Jay Pipes wrote:
>>>> [...]
>>>>> 3) The upstream Infrastructure team works with the hired system
>>>>> administrators to create a single CI system that can spawn
>>>>> functional test jobs on the lab hardware and report results back
>>>>> to upstream Gerrit
>>>> [...]
>>>> This bit is something the TripleO team has struggled to accomplish
>>>> over the past several years (running a custom OpenStack deployment
>>>> tied directly into our CI), so at a minimum we'd want to know how
>>>> the proposed implementation would succeed in ways that they've so
>>>> far found a significant challenge even with a larger sysadmin team
>>>> than you estimate being required.
>>> I think what Jay is getting at is to have the *exact same approach*
>>> third-party CI for NFV and PCI have been using - so whatever
>>> $behind-the-abstraction setup they are using, but community accessible
>>> and visible, unlike the current behind-corprorate-firewall setups.
>>> I'm not saying this is better or worse, but it is different to the
>>> tripleo approach of providing a Nova API endpoint for zuul.
>> Yes, thank you Rob, that is precisely what I'm getting at.
> In that case, I'm not sure a third-party CI system needs close
> coordination with "The upstream Infrastructure team" nor "hired
> system administrators" employed by the OpenStack Foundation, which
> were the parts of the original proposal I was concerned with. Set
> up a third-party CI system and start voting on changes (with the
> consent of those projects anyway).

I'm really not sure why you are being so hostile to my proposal. 
Essentially, I wanted to involve the upstream Infra team in this so they 
can advise on the project and ensure that the 3rd party CI system that 
gets built matches what is used for the upstream system.

I'm not trying to add load to the infra team. Quite the opposite, I am 
attempting to gain a level of coordination to ensure an aligned CI 
system is produced that won't be a giant pain for all involved.


More information about the OpenStack-dev mailing list