Re: [OpenStack-Infra] [Third Party Testing] Requesting a Service Account
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
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
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
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
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
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
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.
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.
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.
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.
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
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
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