Re: [OpenStack-Infra] [Third Party Testing] Requesting a Service Account

2014-08-18 Thread Anita Kuno
On 08/18/2014 05:13 PM, Charles Hsu wrote:
> HI,
> 
> Here is a wiki page for our cluster
> https://wiki.openstack.org/wiki/ThirdPartySystems/SwiftStack_Cluster_CI
> 
> Thanks
> 
And we have consensus around SwiftStack Cluster CI and swiftstack-cluster-ci

Thanks,
Anita.
> 
> On Sun, Aug 17, 2014 at 11:10 PM, Charles Hsu  wrote:
> 
>> Hi,
>>
>> We're try to setup a CI cluster for swift, please help us to create a
>> gerrit account.
>> Here is required information.
>>
>> 1. SSH Public Key
>>
>> ssh-rsa 
>> B3NzaC1yc2EDAQABAAABAQCy7Dt+tiqeQZgFaFoRi1ItRad0/pt/9ziR/sfh0Vs6Y0vJVI6H+FG4WJyFh3lXcuwMDx2zuVMIdsd+Svq8fYsMsz/RLeF7NCMq7+BGB4CTKq1mAte1cADGOgFxncMjUII1Uwkqi19iP5lJOeXzEchizZ6InEiA5Y0wO0jVLWl274i6ua2K/Na42urMLizcerprAOb5CVly3a+wFZUzfNyOsd6NhOezmTDktw/k3YxbmpgXaa6RdfAhU0UEl3wemeenDmJicf0igJ2yzlZrR7SkYnPI0oHBibKJ/nBmSPYAdNIMB5KXdx51VPOrw4ZO9E2HTGXaW/C63cC0sNJyIMQP
>>  swiftstack@swift-qa-jenkins
>>
>>
>> 2. Company: SwiftStack
>> 3. Project: Swift
>> 4. Email: openstack...@swiftstack.com
>>
>> Thanks
>> --
>> Charles Hsu
>> SwiftStack.com
>>
>>
> 
> 
> 
> 
> ___
> 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] [Third Party Testing] Requesting a Service Account

2014-08-18 Thread Charles Hsu
HI,

Here is a wiki page for our cluster
https://wiki.openstack.org/wiki/ThirdPartySystems/SwiftStack_Cluster_CI

Thanks


On Sun, Aug 17, 2014 at 11:10 PM, Charles Hsu  wrote:

> Hi,
>
> We're try to setup a CI cluster for swift, please help us to create a
> gerrit account.
> Here is required information.
>
> 1. SSH Public Key
>
> ssh-rsa 
> B3NzaC1yc2EDAQABAAABAQCy7Dt+tiqeQZgFaFoRi1ItRad0/pt/9ziR/sfh0Vs6Y0vJVI6H+FG4WJyFh3lXcuwMDx2zuVMIdsd+Svq8fYsMsz/RLeF7NCMq7+BGB4CTKq1mAte1cADGOgFxncMjUII1Uwkqi19iP5lJOeXzEchizZ6InEiA5Y0wO0jVLWl274i6ua2K/Na42urMLizcerprAOb5CVly3a+wFZUzfNyOsd6NhOezmTDktw/k3YxbmpgXaa6RdfAhU0UEl3wemeenDmJicf0igJ2yzlZrR7SkYnPI0oHBibKJ/nBmSPYAdNIMB5KXdx51VPOrw4ZO9E2HTGXaW/C63cC0sNJyIMQP
>  swiftstack@swift-qa-jenkins
>
>
> 2. Company: SwiftStack
> 3. Project: Swift
> 4. Email: openstack...@swiftstack.com
>
> Thanks
> --
> Charles Hsu
> SwiftStack.com
>
>


-- 
Charles Hsu
SwiftStack.com
___
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 "IBM Storwize CI" disabled

2014-08-18 Thread Yi Xuan YX Zhang
Hi Jim,

I have fixed this issue, please check the

https://review.openstack.org/#/c/112714/
and left a link of "dsvm-tempest-full Failure" of IBM Storwize CI, it will
link to

http://dal05.objectstorage.softlayer.net/v1/AUTH_58396f85-2c60-47b9-aaf8-e03bc24a1a6f/IBMStorwizeCI/14/112714/8/check/dsvm-tempest-full/c5f502c/


Could you help to re-enable it, thank you!


Yixuan Zhang  (张怡轩)
IBM China Systems & Technology Lab (CSTL)
TEL:(+86-21)6092-8976  Ext:28976
Email: yixua...@cn.ibm.com   Notes: Yixuan YX Zhang/China/IBM
Address: 3F, Bldg. 10, 399 Ke Yuan Road, Zhang Jiang High Tech Park,
Shanghai 201203, China
地址:  上海浦东张江高科技园区科苑路399号10号楼3楼, 邮��: 201203



From:   cor...@inaugust.com (James E. Blair)
To: openstack-infra@lists.openstack.org
Cc: Yi Xuan YX Zhang/China/IBM@IBMCN
Date:   2014/08/16 08:10
Subject:Third-party CI system "IBM Storwize CI" disabled



Hi,

I have disabled the above CI system because it is in violation of the
following policies:

 * Include a public link to all test artifacts.

In the change https://review.openstack.org/#/c/111460/ this system
left a link to:

  http://9.115.251.56:8080/job/dsvm-tempest-full/78/

Which did not respond.

Additionally, it was leaving "Starting check jobs" comments which is
unnecessary for third-party CI systems.  We neglected to specify this as
a formal requirement, but that will be corrected soon.

Please see the list of requirements as well as instructions on how to
test that your system is functioning correctly in the sandbox repository
before enabling it on actual projects:

  http://ci.openstack.org/third_party.html

Once your system configuration has been corrected, please contact us at
 or in #openstack-infra on
Freenode and we will re-enable it.

-Jim

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


[OpenStack-Infra] [Third Party Testing] Requesting a Service Account

2014-08-18 Thread Charles Hsu
Hi,

We're try to setup a CI cluster for swift, please help us to create a
gerrit account.
Here is required information.

1. SSH Public Key

ssh-rsa 
B3NzaC1yc2EDAQABAAABAQCy7Dt+tiqeQZgFaFoRi1ItRad0/pt/9ziR/sfh0Vs6Y0vJVI6H+FG4WJyFh3lXcuwMDx2zuVMIdsd+Svq8fYsMsz/RLeF7NCMq7+BGB4CTKq1mAte1cADGOgFxncMjUII1Uwkqi19iP5lJOeXzEchizZ6InEiA5Y0wO0jVLWl274i6ua2K/Na42urMLizcerprAOb5CVly3a+wFZUzfNyOsd6NhOezmTDktw/k3YxbmpgXaa6RdfAhU0UEl3wemeenDmJicf0igJ2yzlZrR7SkYnPI0oHBibKJ/nBmSPYAdNIMB5KXdx51VPOrw4ZO9E2HTGXaW/C63cC0sNJyIMQP
swiftstack@swift-qa-jenkins


2. Company: SwiftStack
3. Project: Swift
4. Email: openstack...@swiftstack.com

Thanks
-- 
Charles Hsu
SwiftStack.com
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


Re: [OpenStack-Infra] [openstack-dev] [third-party] One CI for several OpenStack projects

2014-08-18 Thread Jeremy Stanley
On 2014-08-18 20:40:48 +0300 (+0300), Ivan Kolodyazhny wrote:
[...]
> I'm looking for something like following:
> 
> 1) run my Third Party CI for all patch-sets in Cinder
> 2) run my Third Party CI (Cinder + Ceph backend) for Nova only if it
> changes nova/virt/libvirt/rbd.py module.
> 
> Does such approach acceptable for Third Party CI? If yes, does
> Zuul could handle such kind of triggers?

Zuul has the option to run certain jobs only when it sees specific
files mentioned as altered in a Gerrit event. See the "files" option
documented at http://ci.openstack.org/zuul/zuul.html#jobs
specifically. This does mean you'd need different job names for
those separate cases, but they could effectively perform the same
activities (for example if you're also using jenkins-job-builder you
could use a single job-template to generate configuration for both
and embed a parameter expansion in the template name which is unique
per project).
-- 
Jeremy Stanley

___
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 19th at 19:00 UTC

2014-08-18 Thread Elizabeth K. Joseph
Hi everyone,

The OpenStack Infrastructure (Infra) team is hosting our weekly
meeting on Tuesday August 19th, 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


[OpenStack-Infra] [openstack-dev] [third-party] One CI for several OpenStack projects

2014-08-18 Thread Ivan Kolodyazhny
Hi All,

I'm working on Third Party CI for Cinder and I've got several issues with
Zuul configuration.


Third Party CI should run dsvm-tempest-full job to test Cinder driver in my
case. It means, that all components should work well, not only Cinder.

E.g.: I'm working on Cinder + Ceph integration CI. It requires that
RBD-related code in Nova works well.
https://bugs.launchpad.net/nova/+bug/1352595 breaks my Cinder CI with Ceph
backend last week.

So, it looks like I need to setup Cinder Third Party CI with Ceph backend
for Cinder and Nova projects. But there are no needs to test Nova with
Cinder and Ceph for every Nova commit.

I'm looking for something like following:

1) run my Third Party CI for all patch-sets in Cinder
2) run my Third Party CI (Cinder + Ceph backend) for Nova only if it
changes nova/virt/libvirt/rbd.py module.

Does such approach acceptable for Third Party CI? If yes, does Zuul could
handle such kind of triggers?



Regards,
Ivan Kolodyazhny,
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] [openstack-dev] [Devstack] q-svc fails to start in devstack.

2014-08-18 Thread Kevin Benton
I'm not sure why, but the default tenant network type was changed to vxlan.
[1]

You now need to specify Q_ML2_TENANT_NETWORK_TYPE=vlan

1.
https://github.com/openstack-dev/devstack/commit/8feaf6c9516094df58df84479d73779e87a79264


On Mon, Aug 18, 2014 at 9:35 AM, Parikshit Manur  wrote:

>  Hi All,
>
> Start of q-svc  in devstack fails with error message “No
> type driver for tenant network_type: vxlan. Service terminated!”. I have
> not choosen vxlan as ML2 type driver in localrc. I have added the details
> of localrc file for my setup below for reference. Can you please point out
> if I am missing any config or there is any workaround to fix the issue.
> Could you also point me to a separate mailing list for devstack related
> queries if there is any.
>
>
>
> localrc file contents:
>
>
>
> RECLONE=yes
>
> DEST=/opt/stack
>
> SCREEN_LOGDIR=/opt/stack/new/screen-logs
>
> LOGFILE=/opt/stack/new/devstacklog.txt
>
> DATABASE_PASSWORD=password
>
> RABBIT_PASSWORD= password
>
> SERVICE_TOKEN= password
>
> SERVICE_PASSWORD= password
>
> ADMIN_PASSWORD= password
>
> disable_service n-net
>
> enable_service q-svc
>
> enable_service q-agt
>
> enable_service q-dhcp
>
> enable_service q-l3
>
> enable_service q-meta
>
> enable_service q-lbaas
>
> enable_service neutron
>
> # Optional, to enable tempest configuration as part of devstack
>
> enable_service tempest
>
> Q_PLUGIN=ml2
>
> Q_ML2_PLUGIN_MECHANISM_DRIVERS=openvswitch
>
> Q_ML2_PLUGIN_TYPE_DRIVERS=*vlan,flat*
>
> ML2_VLAN_RANGES=physnet1:1500:1600
>
> ENABLE_TENANT_VLANS=True
>
> PHYSICAL_NETWORK=physnet1
>
> OVS_PHYSICAL_BRIDGE=br-eth1
>
>
>
> Thanks,
>
> Parikshit Manur
>
>
>
> ___
> OpenStack-dev mailing list
> openstack-...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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


Re: [OpenStack-Infra] [openstack-dev] [Devstack] q-svc fails to start in devstack.

2014-08-18 Thread Brian Haley
When you don't specify it, the default network type is:

(from lib/neutron_plugins/ml2)
Q_ML2_TENANT_NETWORK_TYPE=${Q_ML2_TENANT_NETWORK_TYPE:-"vxlan"}

You can try specifying that as "vlan" in your local.conf file and see what 
happens.

-Brian

BTW, this probably should have just gone to openst...@lists.openstack.org, not
the -dev list.

On 08/18/2014 12:35 PM, Parikshit Manur wrote:
> Hi All,
> 
> Start of q-svc  in devstack fails with error message “No type
> driver for tenant network_type: vxlan. Service terminated!”. I have not 
> choosen
> vxlan as ML2 type driver in localrc. I have added the details of localrc file
> for my setup below for reference. Can you please point out if I am missing any
> config or there is any workaround to fix the issue. Could you also point me 
> to a
> separate mailing list for devstack related queries if there is any.
> 
>  
> 
> localrc file contents:
> 
>  
> 
> RECLONE=yes
> 
> DEST=/opt/stack
> 
> SCREEN_LOGDIR=/opt/stack/new/screen-logs
> 
> LOGFILE=/opt/stack/new/devstacklog.txt
> 
> DATABASE_PASSWORD=password
> 
> RABBIT_PASSWORD= password
> 
> SERVICE_TOKEN= password
> 
> SERVICE_PASSWORD= password
> 
> ADMIN_PASSWORD= password
> 
> disable_service n-net
> 
> enable_service q-svc
> 
> enable_service q-agt
> 
> enable_service q-dhcp
> 
> enable_service q-l3
> 
> enable_service q-meta
> 
> enable_service q-lbaas
> 
> enable_service neutron
> 
> # Optional, to enable tempest configuration as part of devstack
> 
> enable_service tempest
> 
> Q_PLUGIN=ml2
> 
> Q_ML2_PLUGIN_MECHANISM_DRIVERS=openvswitch
> 
> Q_ML2_PLUGIN_TYPE_DRIVERS=*vlan,flat*
> 
> ML2_VLAN_RANGES=physnet1:1500:1600
> 
> ENABLE_TENANT_VLANS=True
> 
> PHYSICAL_NETWORK=physnet1
> 
> OVS_PHYSICAL_BRIDGE=br-eth1
> 
>  
> 
> Thanks,
> 
> Parikshit Manur
> 
>  
> 
> 
> 
> ___
> OpenStack-dev mailing list
> openstack-...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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


Re: [OpenStack-Infra] [Devstack] q-svc fails to start in devstack.

2014-08-18 Thread Henry Gessau
On 8/18/2014 12:35 PM, Parikshit Manur wrote:
> Start of q-svc  in devstack fails with error message “No type
> driver for tenant network_type: vxlan. Service terminated!”. I have not
> choosen vxlan as ML2 type driver in localrc.

Devstack now defaults to vxlan for the tenant networks type.
You need to override it, see below.

> I have added the details of
> localrc file for my setup below for reference. Can you please point out if I
> am missing any config or there is any workaround to fix the issue. Could you
> also point me to a separate mailing list for devstack related queries if there
> is any.
> 
> localrc file contents:
>  
> RECLONE=yes
> DEST=/opt/stack
> SCREEN_LOGDIR=/opt/stack/new/screen-logs
> LOGFILE=/opt/stack/new/devstacklog.txt
> DATABASE_PASSWORD=password
> RABBIT_PASSWORD= password
> SERVICE_TOKEN= password
> SERVICE_PASSWORD= password
> ADMIN_PASSWORD= password
> disable_service n-net
> enable_service q-svc
> enable_service q-agt
> enable_service q-dhcp
> enable_service q-l3
> enable_service q-meta
> enable_service q-lbaas
> enable_service neutron
> # Optional, to enable tempest configuration as part of devstack
> enable_service tempest
> Q_PLUGIN=ml2
> Q_ML2_PLUGIN_MECHANISM_DRIVERS=openvswitch
> Q_ML2_PLUGIN_TYPE_DRIVERS=*vlan,flat*
> ML2_VLAN_RANGES=physnet1:1500:1600
> ENABLE_TENANT_VLANS=True

You also need to set:
Q_ML2_TENANT_NETWORK_TYPE=vlan

> PHYSICAL_NETWORK=physnet1
> OVS_PHYSICAL_BRIDGE=br-eth1


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


[OpenStack-Infra] [Devstack] q-svc fails to start in devstack.

2014-08-18 Thread Parikshit Manur
Hi All,
Start of q-svc  in devstack fails with error message "No type 
driver for tenant network_type: vxlan. Service terminated!". I have not choosen 
vxlan as ML2 type driver in localrc. I have added the details of localrc file 
for my setup below for reference. Can you please point out if I am missing any 
config or there is any workaround to fix the issue. Could you also point me to 
a separate mailing list for devstack related queries if there is any.

localrc file contents:

RECLONE=yes
DEST=/opt/stack
SCREEN_LOGDIR=/opt/stack/new/screen-logs
LOGFILE=/opt/stack/new/devstacklog.txt
DATABASE_PASSWORD=password
RABBIT_PASSWORD= password
SERVICE_TOKEN= password
SERVICE_PASSWORD= password
ADMIN_PASSWORD= password
disable_service n-net
enable_service q-svc
enable_service q-agt
enable_service q-dhcp
enable_service q-l3
enable_service q-meta
enable_service q-lbaas
enable_service neutron
# Optional, to enable tempest configuration as part of devstack
enable_service tempest
Q_PLUGIN=ml2
Q_ML2_PLUGIN_MECHANISM_DRIVERS=openvswitch
Q_ML2_PLUGIN_TYPE_DRIVERS=vlan,flat
ML2_VLAN_RANGES=physnet1:1500:1600
ENABLE_TENANT_VLANS=True
PHYSICAL_NETWORK=physnet1
OVS_PHYSICAL_BRIDGE=br-eth1

Thanks,
Parikshit Manur

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


Re: [OpenStack-Infra] [infra][Neutron] tempest requirements errors while fetching oslo.i18n>=0.1.0

2014-08-18 Thread Jeremy Stanley
On 2014-08-17 23:53:12 -0700 (-0700), daya kamath wrote:
[...]
> openstack-infra does not get updated as part of the gate jobs
[...]

Right, we use puppet to continuously apply that configuration to our
durable workers and nodepool templates.
-- 
Jeremy Stanley

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


Re: [OpenStack-Infra] [openstack-dev] [Neutron][third-party] Arista CI hits 10, 000 runs this morning

2014-08-18 Thread Luke Gorrie
Congrats Sukhdev :) That's no small feat.

On 7 August 2014 03:41, Sukhdev Kapur  wrote:

> I am looking into the scenario tests. Having some issues with them. Will
> soon be adding a few to the test suite.
>

This is also where I'm at with the Tail-f CI driver. I am running API tests
stably now but I reckon that I need to upgrade my CI infrastructure to run
scenario tests with reliability.

Specifically, I am currently running tests on the "bare metal". The
defensive cleanup scripting I have done is sufficient for running API tests
reliably but I don't think I can stretch it to reliably running scenario
tests. So instead of making an incremental step of enabling scenario
testing my next step is to bring up a new CI that has more
safety/reliability built in.

Is this also your situation? (or anybody else's?)

I am really enjoying the new Wiki pages that give a glimpse of how people
have setup their CIs. I am also really curious for an idea of how much time
other people are allocating for operating their CIs, both for day-to-day
operations and for "deep dives" to replace infrastructure to deal with new
requirements. That could be really useful information for new driver
authors to plan for smooth CI operations from the beginning. (I start to
digress...)

Congrats again :-).

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