Re: [OpenStack-Infra] 3rd party CI account request

[Sergey Lukjanov]

Aaron, please, confirm that vmware-congress-ci works ok for you.

On Sun, Aug 10, 2014 at 9:48 AM, Anita Kuno  wrote:
> On 08/04/2014 04:51 AM, Sergey Lukjanov wrote:
>> Anita, could you please confirm that congress-ci "Congress CI" is an
>> acceptable name?
> Sorry I have been traveling.
>
> Actually we should go with VMware Congress CI. I hope to have gerrit
> permissions to edit third party ci gerrit account names soon so I can
> fix it then.
>
> Thanks,
> Anita.
>>
>> On Wed, Jul 30, 2014 at 1:29 AM, Aaron Rosen  wrote:
>>> Hi,
>>>
>>> I was on #openstack-infra I should also include a few more things which are
>>> new requirements:
>>>
>>> company: VMware
>>> Providing CI for the Openstack Congress project:
>>> https://github.com/stackforge/congress
>>>
>>> Thanks,
>>>
>>> Aaron
>>>
>>>
>>> On Tue, Jul 29, 2014 at 11:26 AM, Aaron Rosen  wrote:

 Hi,

 I'm following what's outlined here
 (http://ci.openstack.org/third_party.html#requesting-a-service-account) to
 setup a new account for 3rd party testing for a new openstack stackforge
 project.

 Desired username: Congress-CI
 contact: congres...@gmail.com
 Pub ssh key attached.

 Thanks!

 Aaron
>>>
>>>
>>>
>>> ___
>>> OpenStack-Infra mailing list
>>> OpenStack-Infra@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>>>
>>
>>
>>
>



-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Rechecking OpenStack CI

[Sergey Lukjanov]

FWIW it's already configured to recheck on recheck .*

https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/zuul/layout.yaml#L18

On Fri, Aug 8, 2014 at 5:56 AM, Joshua Hesketh
 wrote:
> Howdy,
>
> So I'm wondering if we can optimise our resource usage by limiting when we
> run rechecks a little tighter. A recent change[0] removed the need for
> supplying 'no bug' or 'bug #' as it was decided these were unnecessary.
> However we are now triggering rechecks on 'recheck*' which means when
> somebody wants to recheck a third party they will also be wasting
> OpenStack's resources (eg 'recheck migrations' will trigger both
> turbo-hipster and jenkins).
>
> There is also the case where we might want to recheck Jenkins and not a
> third party. Most 1st and 3rd party systems both currently trigger on
> 'recheck no bug' for legacy reasons but it is wasting both 3rd and 1st party
> resources. Basically we need a way of rechecking only the failing system or
> the system the commenter is concerned with.
>
> I'd like to propose that OpenStack's CI triggers on the following comments:
>
> recheck no bug
> recheck bug #
> recheck openstack-ci
> recheck jenkins
> recheck all
>
> The first two would be there for legacy matching while we re-train users to
> use the latter. The thought process here is that once we figure out the
> naming of CI systems we can just use 'recheck system-name' and save on
> resources by not rechecking everything all the time. Rechecking based on the
> username commenting on the system is a usability thing in my mind. This
> should make it obvious to developers how to target their rechecks.
>
> Thoughts?
>
> Cheers,
> Josh
>
> [0] https://review.openstack.org/#/c/108724/
>
> --
> Rackspace Australia
>
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] how to install ipset in jenkins

[shihanzhang]

Hi all,
   I have a Neutron BP that add ipset to neutron security 
group:https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security, 
this BP require the ipset is installed on L2 agent node, but I don't know how 
to config that when my patch commit to jenkins, who can help me, thanks very 
much!___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] how to install ipset in jenkins

[Jeremy Stanley]

On 2014-08-11 20:32:10 +0800 (+0800), shihanzhang wrote:
> I have a Neutron BP that add ipset to neutron security
> group:https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security,
> this BP require the ipset is installed on L2 agent node, but I
> don't know how to config that when my patch commit to jenkins, who
> can help me, thanks very much!

If Neutron is going to start using the ipset utility, then you
should patch openstack-dev/devstack to install it.
-- 
Jeremy Stanley

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Third Party CI System account

[Erlon Cruz]

Hi Anita,


>  What are you verifying to require you to have your CI system report on
> cinder patches?


Yes.

Is it a cinder driver? If yes, do you have a link to the
> cinder driver blueprint or spec?
>

https://blueprints.launchpad.net/cinder/+spec/hds-hnas
https://blueprints.launchpad.net/cinder/+spec/hitachi-block-storage-driver

Just to avoid confusions we are partners of HDS/Hitachi and are
developing/maintaining their drivers.
I have access to this account: openstackdevelopm...@hds.com. Can you
confirm that this account has the access permissions we need?
Also, I see in some patches one account per driver. Those blueprints
actually implements 4 drivers. Do we need 4 accounts?

Thanks,


>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] how to install ipset in jenkins

[Kyle Mestery]

On Mon, Aug 11, 2014 at 7:55 AM, Jeremy Stanley  wrote:
> On 2014-08-11 20:32:10 +0800 (+0800), shihanzhang wrote:
>> I have a Neutron BP that add ipset to neutron security
>> group:https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security,
>> this BP require the ipset is installed on L2 agent node, but I
>> don't know how to config that when my patch commit to jenkins, who
>> can help me, thanks very much!
>
> If Neutron is going to start using the ipset utility, then you
> should patch openstack-dev/devstack to install it.

+1

This needs a devstack patch to install ipset there as Jeremy says.

Thanks,
Kyle


> --
> Jeremy Stanley
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] how to install ipset in jenkins

[Henry Gessau]

Jeremy Stanley  wrote:
> On 2014-08-11 20:32:10 +0800 (+0800), shihanzhang wrote:
>> I have a Neutron BP that add ipset to neutron security
>> group:https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security,
>> this BP require the ipset is installed on L2 agent node, but I
>> don't know how to config that when my patch commit to jenkins, who
>> can help me, thanks very much!
> 
> If Neutron is going to start using the ipset utility, then you
> should patch openstack-dev/devstack to install it.

Here is an example that added the installation of radvd:
https://review.openstack.org/107801


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] [Infra] Meeting Tuesday August 12th at 19:00 UTC

[Elizabeth K. Joseph]

Hi everyone,

The OpenStack Infrastructure (Infra) team is hosting our weekly
meeting on Tuesday August 12th, at 19:00 UTC in #openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)

Everyone interested in infrastructure and process surrounding
automated testing and deployment is encouraged to attend.

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2
http://www.princessleia.com

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] 3rd party CI account request

[Aaron Rosen]

Hi,

Sure vmware-congress-ci works for me.

Aaron


On Mon, Aug 11, 2014 at 4:52 AM, Sergey Lukjanov 
wrote:

> Aaron, please, confirm that vmware-congress-ci works ok for you.
>
> On Sun, Aug 10, 2014 at 9:48 AM, Anita Kuno  wrote:
> > On 08/04/2014 04:51 AM, Sergey Lukjanov wrote:
> >> Anita, could you please confirm that congress-ci "Congress CI" is an
> >> acceptable name?
> > Sorry I have been traveling.
> >
> > Actually we should go with VMware Congress CI. I hope to have gerrit
> > permissions to edit third party ci gerrit account names soon so I can
> > fix it then.
> >
> > Thanks,
> > Anita.
> >>
> >> On Wed, Jul 30, 2014 at 1:29 AM, Aaron Rosen 
> wrote:
> >>> Hi,
> >>>
> >>> I was on #openstack-infra I should also include a few more things
> which are
> >>> new requirements:
> >>>
> >>> company: VMware
> >>> Providing CI for the Openstack Congress project:
> >>> https://github.com/stackforge/congress
> >>>
> >>> Thanks,
> >>>
> >>> Aaron
> >>>
> >>>
> >>> On Tue, Jul 29, 2014 at 11:26 AM, Aaron Rosen 
> wrote:
> 
>  Hi,
> 
>  I'm following what's outlined here
>  (
> http://ci.openstack.org/third_party.html#requesting-a-service-account) to
>  setup a new account for 3rd party testing for a new openstack
> stackforge
>  project.
> 
>  Desired username: Congress-CI
>  contact: congres...@gmail.com
>  Pub ssh key attached.
> 
>  Thanks!
> 
>  Aaron
> >>>
> >>>
> >>>
> >>> ___
> >>> OpenStack-Infra mailing list
> >>> OpenStack-Infra@lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> >>>
> >>
> >>
> >>
> >
>
>
>
> --
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Principal Software Engineer
> Mirantis Inc.
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] Account Request

[Steven Sonnenberg]

We have an existing account HDS-CI, but we need at least 2 accounts to cover 
the different driver code bases.


1.Please rename (hds-ci) HDS CI to (hds-hnas-ci) HDS HNAS CI.


2.Please create another account as follows:


Email: openstackdevelopm...@hds.com

Account Username (short): hds-hbsd-ci

Account Username (long): HDS HBSD CI

Contact Info: Steven Sonnenberg, 
steve.sonnenb...@hds.com, IRC handle: 
steveisoft, Mobile: 443-929-6543

Public Key:  sh-rsa 
B3NzaC1yc2EBIwAAAIEA2qs+GtPkRc7SNJLDF51J6IewX9Kt1mEMEGqi4ngBMovN9zwRXo+uAtgHxQ0zBghsdvpXlVocsC02vlfSVAl6HkXgz2MDl+hPhWchJZegtzN1h5HOfWMYmCWeV1yturDn+j5lrg3mRTBW35eze7hmZPBsvZhhZIOntS49lPa1jzc=
 openstackdevelopm...@hds.com

Thanks,
-steve
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Account Request

[Anita Kuno]

On 08/11/2014 09:20 PM, Steven Sonnenberg wrote:
> 
> We have an existing account HDS-CI, but we need at least 2 accounts to cover 
> the different driver code bases.
> 
> 
> 1.Please rename (hds-ci) HDS CI to (hds-hnas-ci) HDS HNAS CI.
> 
> 
> 2.Please create another account as follows:
> 
> 
> Email: openstackdevelopm...@hds.com
> 
> Account Username (short): hds-hbsd-ci
> 
> Account Username (long): HDS HBSD CI
> 
> Contact Info: Steven Sonnenberg, 
> steve.sonnenb...@hds.com, IRC handle: 
> steveisoft, Mobile: 443-929-6543
> 
> Public Key:  sh-rsa 
> B3NzaC1yc2EBIwAAAIEA2qs+GtPkRc7SNJLDF51J6IewX9Kt1mEMEGqi4ngBMovN9zwRXo+uAtgHxQ0zBghsdvpXlVocsC02vlfSVAl6HkXgz2MDl+hPhWchJZegtzN1h5HOfWMYmCWeV1yturDn+j5lrg3mRTBW35eze7hmZPBsvZhhZIOntS49lPa1jzc=
>  openstackdevelopm...@hds.com
> 
> Thanks,
> -steve
> 
> 
> 
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> 
Slow down, slow down.

I do believe there is an outstanding question about how many accounts
you need and I have tried to respond to your email all day and never got
to it.

Please allow me to respond to your original email prior to requesting an
additional account which you may not in fact need, I don't know yet, I
am still going through the material.

Thank you,
Anita.

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Rechecking OpenStack CI

[Joshua Hesketh]

Hi Sergey,

Right, what I am actually proposing is to /remove/ that functionality.

Specifically how it is currently configured there is no way to trigger 
3rd party tests without rerunning (and hence wasting) 1st party CI.


Cheers,
Josh

Rackspace Australia

On 8/11/14 9:54 PM, Sergey Lukjanov wrote:

FWIW it's already configured to recheck on recheck .*

https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/zuul/layout.yaml#L18

On Fri, Aug 8, 2014 at 5:56 AM, Joshua Hesketh
 wrote:

Howdy,

So I'm wondering if we can optimise our resource usage by limiting when we
run rechecks a little tighter. A recent change[0] removed the need for
supplying 'no bug' or 'bug #' as it was decided these were unnecessary.
However we are now triggering rechecks on 'recheck*' which means when
somebody wants to recheck a third party they will also be wasting
OpenStack's resources (eg 'recheck migrations' will trigger both
turbo-hipster and jenkins).

There is also the case where we might want to recheck Jenkins and not a
third party. Most 1st and 3rd party systems both currently trigger on
'recheck no bug' for legacy reasons but it is wasting both 3rd and 1st party
resources. Basically we need a way of rechecking only the failing system or
the system the commenter is concerned with.

I'd like to propose that OpenStack's CI triggers on the following comments:

recheck no bug
recheck bug #
recheck openstack-ci
recheck jenkins
recheck all

The first two would be there for legacy matching while we re-train users to
use the latter. The thought process here is that once we figure out the
naming of CI systems we can just use 'recheck system-name' and save on
resources by not rechecking everything all the time. Rechecking based on the
username commenting on the system is a usability thing in my mind. This
should make it obvious to developers how to target their rechecks.

Thoughts?

Cheers,
Josh

[0] https://review.openstack.org/#/c/108724/

--
Rackspace Australia


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra






___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] how to install ipset in jenkins

[shihanzhang]

I got it, thanks very much!

At 2014-08-12 00:45:49, "Henry Gessau"  wrote:
>Jeremy Stanley  wrote:
>> On 2014-08-11 20:32:10 +0800 (+0800), shihanzhang wrote:
>>> I have a Neutron BP that add ipset to neutron security
>>> group:https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security,
>>> this BP require the ipset is installed on L2 agent node, but I
>>> don't know how to config that when my patch commit to jenkins, who
>>> can help me, thanks very much!
>> 
>> If Neutron is going to start using the ipset utility, then you
>> should patch openstack-dev/devstack to install it.
>
>Here is an example that added the installation of radvd:
>https://review.openstack.org/107801
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra