From Remo at italy1.com Sat Jun 2 19:48:59 2018 From: Remo at italy1.com (Remo Mattei) Date: Sat, 2 Jun 2018 12:48:59 -0700 Subject: [OpenStack-Infra] Kops cube with OpenStack Message-ID: Hello all, I have a group of people that are using basic services with AWS, and are using kops to spin up kubernetes. Any suggestions on how I could replicate this with OpenStack? I would love to have them use Kops Thanks Remo -------------- next part -------------- An HTML attachment was scrubbed... URL: From corvus at inaugust.com Thu Jun 7 22:31:11 2018 From: corvus at inaugust.com (James E. Blair) Date: Thu, 07 Jun 2018 15:31:11 -0700 Subject: [OpenStack-Infra] [infra][all] Upcoming Zuul behavior change for files and irrelevant-files Message-ID: <874lie1b68.fsf@meyer.lemoncheese.net> Hi, Earlier[1][2], we discussed proposals to make files and irrelevant-files easier to use -- particularly ways to make them overridable. We settled on an approach, and it is now implemented. We plan on upgrading OpenStack's Zuul to the new behavior on Monday, June 11, 2018. To summarize the change: Files and irrelevant-files are treated as overwriteable attributes and evaluated after branch-matching variants are combined. * Files and irrelevant-files are overwritten, so the last value encountered when combining all the matching variants (looking only at branches) wins. * It's possible to both reduce and expand the scope of jobs, but the user may need to manually copy values from a parent or other variant in order to do so. * It will no longer be possible to alter a job attribute by adding a variant with only a files matcher -- in all cases files and irrelevant-files are used solely to determine whether the job is run, not to determine whether to apply a variant. This is a behavior change to Zuul that is not possible[3] to support in a backwards compatible way. That means that on Monday, there may be sudden alterations to the set of jobs which run on changes. Considering that many of us can barely predict what happens at all when multiple irrelevant-files stanzas enter the picture, it's not possible[4] to say in advance exactly what the changes will be. Suffice it to say that, on Monday, if some jobs you were expecting to run on a change don't, or some jobs you were not expecting to run do, then you will need to alter the files or irrelevant-files matchers on those jobs. Hopefully the new approach is sufficiently intuitive that corrective changes will be simple to make. Jobs which have no more than one files or irrelevant-files attribute involved in their construction (likely the bulk of the jobs out there) are unlikely to need any immediate changes. Please let us know in #openstack-infra if you encounter any problems and we'll be happy to help. Hopefully after we cross this speedbump we'll find the files and irrelevant-files matchers much more useful. -Jim [1] http://lists.openstack.org/pipermail/openstack-dev/2018-May/130074.html [2] http://lists.zuul-ci.org/pipermail/zuul-discuss/2018-May/000397.html [3] At least, not possible with a reasonable amount of effort. [4] Of course it's possible but only with an unhealthy amount of beer. From xinliang.liu at linaro.org Thu Jun 14 10:42:15 2018 From: xinliang.liu at linaro.org (Xinliang Liu) Date: Thu, 14 Jun 2018 18:42:15 +0800 Subject: [OpenStack-Infra] [Ask for Help] docker-mtu-issues-on-openstack Message-ID: Hi guys, The arm64 kolla building job[1] will run containers while building kolla images. But we met the mtu mismatched issue[2] between container and vm. That makes network accessing very unstable or failed in containers. I wonder how this issue handled on x86 clouds? And how to fix such issue? [1] https://review.openstack.org/#/c/557659/ [2] https://www.variantweb.net/blog/docker-mtu-issues-on-openstack/ From cboylan at sapwetik.org Thu Jun 14 21:07:28 2018 From: cboylan at sapwetik.org (Clark Boylan) Date: Thu, 14 Jun 2018 14:07:28 -0700 Subject: [OpenStack-Infra] [Ask for Help] docker-mtu-issues-on-openstack In-Reply-To: References: Message-ID: <1529010448.2221238.1408473312.5D32421D@webmail.messagingengine.com> On Thu, Jun 14, 2018, at 3:42 AM, Xinliang Liu wrote: > Hi guys, > > The arm64 kolla building job[1] will run containers while building kolla images. > But we met the mtu mismatched issue[2] between container and vm. That > makes network accessing very unstable or failed in containers. > > I wonder how this issue handled on x86 clouds? And how to fix such issue? I believe all of our x86 clouds give us MTUs of 1500 not 1450. I did double check and indeed our linaro instances have MTUs of 1450. There are two approaches we can take to fix this. The cloud can be updated to provide MTUs of 1500. I think most clouds do this by allowing their hypervisors to use jumbo frames then the nested overlay networks can use MTUs of 1500 without fragmentation. This would be a cloud side change and may not be possible depending on hardware (this is out of infra's control). The other approach is the one detailed in the blog post you linked. Make sure to create any new interfaces with an MTU that is equal to or smaller than your external interface. In this case that would be via docker config as in the blog post. You would update your job to do this. Hope this helps, Clark > > > [1] https://review.openstack.org/#/c/557659/ > > [2] https://www.variantweb.net/blog/docker-mtu-issues-on-openstack/ > > _______________________________________________ > OpenStack-Infra mailing list > OpenStack-Infra at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra From xinliang.liu at linaro.org Fri Jun 15 01:26:34 2018 From: xinliang.liu at linaro.org (Xinliang Liu) Date: Fri, 15 Jun 2018 09:26:34 +0800 Subject: [OpenStack-Infra] [Ask for Help] docker-mtu-issues-on-openstack In-Reply-To: <1529010448.2221238.1408473312.5D32421D@webmail.messagingengine.com> References: <1529010448.2221238.1408473312.5D32421D@webmail.messagingengine.com> Message-ID: On 15 June 2018 at 05:07, Clark Boylan wrote: > On Thu, Jun 14, 2018, at 3:42 AM, Xinliang Liu wrote: >> Hi guys, >> >> The arm64 kolla building job[1] will run containers while building kolla images. >> But we met the mtu mismatched issue[2] between container and vm. That >> makes network accessing very unstable or failed in containers. >> >> I wonder how this issue handled on x86 clouds? And how to fix such issue? > > I believe all of our x86 clouds give us MTUs of 1500 not 1450. I did double check and indeed our linaro instances have MTUs of 1450. > > There are two approaches we can take to fix this. The cloud can be updated to provide MTUs of 1500. I think most clouds do this by allowing their hypervisors to use jumbo frames then the nested overlay networks can use MTUs of 1500 without fragmentation. This would be a cloud side change and may not be possible depending on hardware (this is out of infra's control). > > The other approach is the one detailed in the blog post you linked. Make sure to create any new interfaces with an MTU that is equal to or smaller than your external interface. In this case that would be via docker config as in the blog post. You would update your job to do this. > > Hope this helps, Yes, it's very helpful. will consider the first approach first. Thank you very much:-). Xinliang > Clark > >> >> >> [1] https://review.openstack.org/#/c/557659/ >> >> [2] https://www.variantweb.net/blog/docker-mtu-issues-on-openstack/ >> >> _______________________________________________ >> OpenStack-Infra mailing list >> OpenStack-Infra at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > > _______________________________________________ > OpenStack-Infra mailing list > OpenStack-Infra at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra From xinliang.liu at linaro.org Fri Jun 15 01:31:35 2018 From: xinliang.liu at linaro.org (Xinliang Liu) Date: Fri, 15 Jun 2018 09:31:35 +0800 Subject: [OpenStack-Infra] [Ask for Help] docker-mtu-issues-on-openstack In-Reply-To: References: Message-ID: On 15 June 2018 at 08:47, Jeffrey Zhang wrote: > Is your current issue caused by mtu? > ​Yes, mtu issue makes network accessing unstable.​ > > From the logs in patch, i found this[0]. For x86 test, i don't see this > kind of problem. > > 2018-06-12 11:39:00.154618 | primary | Ign:10 http://mirror.xtom.com.hk > stretch/updates InRelease > 2018-06-12 11:39:00.248832 | primary | Err:11 http://mirror.xtom.com.hk > stretch/updates Release > 2018-06-12 11:39:00.248988 | primary | 404 Not Found [IP: 61.244.214.6 > 80] > 2018-06-12 11:39:01.706093 | primary | Reading package lists... > 2018-06-12 11:39:01.751383 | primary | W: The repository ' > http://mirror.regionone.linaro.openstack.org/debian stretch-backports > Release' is not signed. > 2018-06-12 11:39:01.751571 | primary | W: The repository ' > http://mirror.regionone.linaro.openstack.org/debian stretch Release' is > not signed. > 2018-06-12 11:39:01.751703 | primary | W: The repository ' > http://mirror.regionone.linaro.openstack.org/debian stretch-updates > Release' is not signed. > 2018-06-12 11:39:01.751821 | primary | E: The repository ' > http://security.debian.org stretch/updates Release' does no longer have a > Release file. > > and i doubt you are using vxlan for your vm? check this[1], the vm nic is > using mtu=1450. So you need change you docker's mtu through docker daemon > start parameter. > > dockerd --mtu=1450 xxx > ​will try to see if we can use jumble frame first. Because this might be the common and simple approach for the clouds.​ I also see one x86 cloud use mtu=1500 for the vms. Thanks, Xinliang > > > > [0] http://logs.openstack.org/59/557659/19/experimental/kolla- > build-debian-source-arm64/2065879/job-output.txt.gz#_ > 2018-06-12_11_39_00_248832 > [1] http://logs.openstack.org/59/557659/19/experimental/ > kolla-build-debian-source-arm64/2065879/zuul-info/zuul-info.primary.txt > > On Thu, Jun 14, 2018 at 6:43 PM Xinliang Liu > wrote: > >> Hi guys, >> >> The arm64 kolla building job[1] will run containers while building kolla >> images. >> But we met the mtu mismatched issue[2] between container and vm. That >> makes network accessing very unstable or failed in containers. >> >> I wonder how this issue handled on x86 clouds? And how to fix such issue? >> >> >> [1] https://review.openstack.org/#/c/557659/ >> >> [2] https://www.variantweb.net/blog/docker-mtu-issues-on-openstack/ >> >> > > -- > 张雷 Jeffrey Zhang > 九州云信息科技有限公司 99Cloud Inc. > > 邮箱： jeffrey.zhang at 99cloud.net > 地址： 北京海淀区上地三街9 > > 号楼嘉华大厦B座806 > 电话： +86 15532797613 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iwienand at redhat.com Mon Jun 18 04:58:35 2018 From: iwienand at redhat.com (Ian Wienand) Date: Mon, 18 Jun 2018 14:58:35 +1000 Subject: [OpenStack-Infra] mirror.opensuse : AFS file name size issues Message-ID: <37072099-05cc-6af9-d223-01585bd15ab1@redhat.com> Hi, It seems like the opensuse mirror has been on a bit of a growth spurt [1]. Monitoring alerted me that the volume had not released for several days, which lead me to look at the logs. The rsync is failing with "File too large (27)" as it goes through the tumbleweed sync. As it turns out, AFS has a hard limit on the combined size of the file names within a directory. There are a couple of threads [2] around from people who have found this out in pretty much the same way as me ... when it starts failing :) So you have 64k slots per directory, and file metadata+name takes up slots per the formula: /* Find out how many entries are required to store a name. */ int afs_dir_NameBlobs(char *name) { int i; i = strlen(name) + 1; return 1 + ((i + 15) >> 5); } This means we have a problem with the large opensuse tumbleweed/repo/oss/x86_64 directory, which has a lot of files with quite long names. Please, check my command/math, but if you run the following command: $ rsync --list-only rsync://mirrors.rit.edu/opensuse/tumbleweed/repo/oss/x86_64/ \ | awk ' function slots(x) { i = length(x)+1; return 1 + rshift((i+15), 5) } { n += slots($5) } END {print n} ' I come out with 82285, which is significantly more than the 64k slots available. I don't know what to do here, and it's really going to be up to people interested in opensuse. The most immediate thing is unnecessary packages could be pruned from tumbleweed/repo/oss/x86_64/ during the rsync. Where unnecessary is in the eye of the beholder ... :) See my note below, but it may have to be quite under 64k. If we have any sway with upstream, maybe they could shard this directory; similar to debian [3] or fedora [4] (that said, centos does the same thing [5], but due to less packages and shorter names etc it's only about 40% allocated). Note that (open)AFS doesn't hard-link across directories, so some sort of "rsync into smaller directories then hardlink tree" doesn't really work. Ideas, suggestions, reviews welcome :) -- ps There's an additional complication in that the slots fragment over time and file names must be contiguous. This means in practice, you do get even less. There is potential to "defrag" (I bet post Windows 95 you never thought you'd hear that again :) by rebuilding the directories with the salvager [6]. However, there are additional complications again... To simply do this we have to run a complete salvage of the *entire* partition. Although I have added "-salvagedirs" to afs01's salvageserver (via [7]) in an attempt to do this for just one volume, it turns out this is not obeyed until after [8] which is not in the Xenial AFS version we use. I really do not want to salvage all the other volumes, most of which are huge. The other option is to create a new AFS server, move the volume to that so it's the only thing on the partition, and run it there, then move it back [9]. I actually suspect an rm -rf * might also do it, and probably be faster because we'd only move the data down once from the remote mirror, rather than to a new server and back But defragging is rather secondary if the directory is oversubscribed anyway. -i [1] http://grafana02.openstack.org/d/ACtl1JSmz/afs?orgId=1&from=now-7d&to=now&panelId=28&fullscreen [2] https://lists.openafs.org/pipermail/openafs-info/2016-July/041859.html [3] http://mirror.iad.rax.openstack.org/debian/pool/main/ [4] http://mirror.iad.rax.openstack.org/fedora/releases/28/Everything/x86_64/os/Packages/ [5] http://mirror.iad.rax.openstack.org/centos/7/os/x86_64/Packages/ [6] http://docs.openafs.org/Reference/8/salvager.html [7] https://docs.openstack.org/infra/system-config/afs.html#updating-settings [8] https://gerrit.openafs.org/#/c/12461/ From colleen at gazlene.net Mon Jun 18 07:26:57 2018 From: colleen at gazlene.net (Colleen Murphy) Date: Mon, 18 Jun 2018 09:26:57 +0200 Subject: [OpenStack-Infra] mirror.opensuse : AFS file name size issues In-Reply-To: <37072099-05cc-6af9-d223-01585bd15ab1@redhat.com> References: <37072099-05cc-6af9-d223-01585bd15ab1@redhat.com> Message-ID: <1529306817.3707137.1411399728.08DB205B@webmail.messagingengine.com> On Mon, Jun 18, 2018, at 6:58 AM, Ian Wienand wrote: > Hi, > > It seems like the opensuse mirror has been on a bit of a growth spurt > [1]. Monitoring alerted me that the volume had not released for > several days, which lead me to look at the logs. > > The rsync is failing with "File too large (27)" as it goes through > the tumbleweed sync. > > As it turns out, AFS has a hard limit on the combined size of the > file names within a directory. There are a couple of threads [2] > around from people who have found this out in pretty much the same way > as me ... when it starts failing :) > > So you have 64k slots per directory, and file metadata+name takes up > slots per the formula: > > /* Find out how many entries are required to store a name. */ > int > afs_dir_NameBlobs(char *name) > { > int i; > i = strlen(name) + 1; > return 1 + ((i + 15) >> 5); > } > > This means we have a problem with the large opensuse > tumbleweed/repo/oss/x86_64 directory, which has a lot of files with > quite long names. Please, check my command/math, but if you run the > following command: > > $ rsync --list-only > rsync://mirrors.rit.edu/opensuse/tumbleweed/repo/oss/x86_64/ \ > | awk ' > function slots(x) { > i = length(x)+1; > return 1 + rshift((i+15), 5) > } > { n += slots($5) } > END {print n} > ' > > I come out with 82285, which is significantly more than the 64k slots > available. > > I don't know what to do here, and it's really going to be up to people > interested in opensuse. The most immediate thing is unnecessary > packages could be pruned from tumbleweed/repo/oss/x86_64/ during the > rsync. Where unnecessary is in the eye of the beholder ... :) > See my note below, but it may have to be quite under 64k. It looks like the repo carries at least two versions of each package. We could start by only syncing the latest, which would about halve the number of files. Colleen > > If we have any sway with upstream, maybe they could shard this > directory; similar to debian [3] or fedora [4] (that said, centos does > the same thing [5], but due to less packages and shorter names etc > it's only about 40% allocated). > > Note that (open)AFS doesn't hard-link across directories, so some sort > of "rsync into smaller directories then hardlink tree" doesn't really > work. > > Ideas, suggestions, reviews welcome :) > > -- ps > > There's an additional complication in that the slots fragment over > time and file names must be contiguous. This means in practice, you do > get even less. > > There is potential to "defrag" (I bet post Windows 95 you never > thought you'd hear that again :) by rebuilding the directories with > the salvager [6]. However, there are additional complications > again... > > To simply do this we have to run a complete salvage of the *entire* > partition. Although I have added "-salvagedirs" to afs01's > salvageserver (via [7]) in an attempt to do this for just one volume, > it turns out this is not obeyed until after [8] which is not in the > Xenial AFS version we use. I really do not want to salvage all the > other volumes, most of which are huge. The other option is to create > a new AFS server, move the volume to that so it's the only thing on > the partition, and run it there, then move it back [9]. > > I actually suspect an rm -rf * might also do it, and probably be faster > because we'd only move the data down once from the remote mirror, > rather than to a new server and back > > But defragging is rather secondary if the directory is oversubscribed > anyway. > > -i > > [1] > http://grafana02.openstack.org/d/ACtl1JSmz/afs?orgId=1&from=now-7d&to=now&panelId=28&fullscreen > [2] > https://lists.openafs.org/pipermail/openafs-info/2016-July/041859.html > [3] http://mirror.iad.rax.openstack.org/debian/pool/main/ > [4] > http://mirror.iad.rax.openstack.org/fedora/releases/28/Everything/x86_64/os/Packages/ > [5] http://mirror.iad.rax.openstack.org/centos/7/os/x86_64/Packages/ > [6] http://docs.openafs.org/Reference/8/salvager.html > [7] > https://docs.openstack.org/infra/system-config/afs.html#updating-settings > [8] https://gerrit.openafs.org/#/c/12461/ > > _______________________________________________ > OpenStack-Infra mailing list > OpenStack-Infra at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra From agbedko at gmail.com Tue Jun 5 02:59:44 2018 From: agbedko at gmail.com (kodzo agbedanu) Date: Mon, 4 Jun 2018 21:59:44 -0500 Subject: [OpenStack-Infra] I would like to join an openstack channel Message-ID: Hi, I would like to join an openstack channel. let me know what is the process. Thanks, kodzo -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffrey.zhang at 99cloud.net Fri Jun 15 00:47:21 2018 From: jeffrey.zhang at 99cloud.net (Jeffrey Zhang) Date: Fri, 15 Jun 2018 08:47:21 +0800 Subject: [OpenStack-Infra] [Ask for Help] docker-mtu-issues-on-openstack In-Reply-To: References: Message-ID: Is your current issue caused by mtu? >From the logs in patch, i found this[0]. For x86 test, i don't see this kind of problem. 2018-06-12 11:39:00.154618 | primary | Ign:10 http://mirror.xtom.com.hk stretch/updates InRelease 2018-06-12 11:39:00.248832 | primary | Err:11 http://mirror.xtom.com.hk stretch/updates Release 2018-06-12 11:39:00.248988 | primary | 404 Not Found [IP: 61.244.214.6 80] 2018-06-12 11:39:01.706093 | primary | Reading package lists... 2018-06-12 11:39:01.751383 | primary | W: The repository ' http://mirror.regionone.linaro.openstack.org/debian stretch-backports Release' is not signed. 2018-06-12 11:39:01.751571 | primary | W: The repository ' http://mirror.regionone.linaro.openstack.org/debian stretch Release' is not signed. 2018-06-12 11:39:01.751703 | primary | W: The repository ' http://mirror.regionone.linaro.openstack.org/debian stretch-updates Release' is not signed. 2018-06-12 11:39:01.751821 | primary | E: The repository ' http://security.debian.org stretch/updates Release' does no longer have a Release file. and i doubt you are using vxlan for your vm? check this[1], the vm nic is using mtu=1450. So you need change you docker's mtu through docker daemon start parameter. dockerd --mtu=1450 xxx [0] http://logs.openstack.org/59/557659/19/experimental/kolla-build-debian-source-arm64/2065879/job-output.txt.gz#_2018-06-12_11_39_00_248832 [1] http://logs.openstack.org/59/557659/19/experimental/kolla-build-debian-source-arm64/2065879/zuul-info/zuul-info.primary.txt On Thu, Jun 14, 2018 at 6:43 PM Xinliang Liu wrote: > Hi guys, > > The arm64 kolla building job[1] will run containers while building kolla > images. > But we met the mtu mismatched issue[2] between container and vm. That > makes network accessing very unstable or failed in containers. > > I wonder how this issue handled on x86 clouds? And how to fix such issue? > > > [1] https://review.openstack.org/#/c/557659/ > > [2] https://www.variantweb.net/blog/docker-mtu-issues-on-openstack/ > > -- 张雷 Jeffrey Zhang 九州云信息科技有限公司 99Cloud Inc. 邮箱： jeffrey.zhang at 99cloud.net 地址： 北京海淀区上地三街9号楼嘉华大厦B座806 电话： +86 15532797613 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cboylan at sapwetik.org Tue Jun 19 18:33:51 2018 From: cboylan at sapwetik.org (Clark Boylan) Date: Tue, 19 Jun 2018 11:33:51 -0700 Subject: [OpenStack-Infra] I would like to join an openstack channel In-Reply-To: References: Message-ID: <1529433231.2550697.1413498664.753C3232@webmail.messagingengine.com> On Mon, Jun 4, 2018, at 7:59 PM, kodzo agbedanu wrote: > Hi, I would like to join an openstack channel. > let me know what is the process. > > Thanks, > kodzo Assuming you intend on connecting to one of the many OpenStack IRC channels you will need an IRC client and connect it to Freenode. https://docs.openstack.org/contributors/common/irc.html#setup-irc covers this process Linux, Windows, and OS X. I would start there and if you have more questions feel free to follow up with them here. Hope this helps, Clark From amrith.kumar at gmail.com Tue Jun 19 21:04:43 2018 From: amrith.kumar at gmail.com (Amrith) Date: Tue, 19 Jun 2018 17:04:43 -0400 Subject: [OpenStack-Infra] I would like to join an openstack channel In-Reply-To: <1529433231.2550697.1413498664.753C3232@webmail.messagingengine.com> References: <1529433231.2550697.1413498664.753C3232@webmail.messagingengine.com> Message-ID: <036b01d40811$2644db20$72ce9160$@gmail.com> Kodzo, Drop me a note if you have additional questions. -amrith > -----Original Message----- > From: Clark Boylan > Sent: Tuesday, June 19, 2018 2:34 PM > To: openstack-infra at lists.openstack.org > Subject: Re: [OpenStack-Infra] I would like to join an openstack channel > > On Mon, Jun 4, 2018, at 7:59 PM, kodzo agbedanu wrote: > > Hi, I would like to join an openstack channel. > > let me know what is the process. > > > > Thanks, > > kodzo > > Assuming you intend on connecting to one of the many OpenStack IRC > channels you will need an IRC client and connect it to Freenode. > https://docs.openstack.org/contributors/common/irc.html#setup-irc covers > this process Linux, Windows, and OS X. I would start there and if you have > more questions feel free to follow up with them here. > > Hope this helps, > Clark > > _______________________________________________ > OpenStack-Infra mailing list > OpenStack-Infra at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra From honjo.rikimaru at po.ntt-tx.co.jp Wed Jun 20 08:16:52 2018 From: honjo.rikimaru at po.ntt-tx.co.jp (Rikimaru Honjo) Date: Wed, 20 Jun 2018 17:16:52 +0900 Subject: [OpenStack-Infra] How can I get the each node's IP address? Message-ID: Hello, I installed Zuul v3 and Nodepool in my environment. In the old Nodepool, I could get sub node's IP address from /etc/nodepool/sub_nodes. But, this file has been removed. How can I get each node's IP address when using multiple nodes in my job? I'd like to use Controller node's IP address for Compute nodes. I read the following document. But I couldn't find the describe about my question. https://docs.openstack.org/infra/zuul/ Best regards, -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Rikimaru Honjo E-mail:honjo.rikimaru at po.ntt-tx.co.jp From dirk at dmllr.de Wed Jun 20 11:10:57 2018 From: dirk at dmllr.de (=?UTF-8?B?RGlyayBNw7xsbGVy?=) Date: Wed, 20 Jun 2018 13:10:57 +0200 Subject: [OpenStack-Infra] mirror.opensuse : AFS file name size issues In-Reply-To: <4243044.UfzGtDNDJl@oldboy> References: <4243044.UfzGtDNDJl@oldboy> Message-ID: > I come out with 82285, which is significantly more than the 64k slots > available. It looks like that is a particular issue with this mirror not able to keep up with tumbleweed. As an explanation, tumbleweed recently switched to gcc8, which triggered a full rebuild. The way the mirroring works is that it first mirrors the new package, and then on next run removes the old ones. So this particular mirror is now back to 43000 entries again (~ 41000 on the master), so the mirroring should have resumed. On manual inspection, there is still some duplicated packages on the main server for tumbleweed, I'm trying to find out how to get that resolved. So with other words: hopefully things are back to normal now. Greetings, Dirk From fungi at yuggoth.org Wed Jun 20 12:47:49 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 20 Jun 2018 12:47:49 +0000 Subject: [OpenStack-Infra] How can I get the each node's IP address? In-Reply-To: References: Message-ID: <20180620124749.pgkma2pyt4qewszg@yuggoth.org> On 2018-06-20 17:16:52 +0900 (+0900), Rikimaru Honjo wrote: > I installed Zuul v3 and Nodepool in my environment. > > In the old Nodepool, I could get sub node's IP address from > /etc/nodepool/sub_nodes. But, this file has been removed. > > How can I get each node's IP address when using multiple nodes in > my job? > > I'd like to use Controller node's IP address for Compute nodes. I > read the following document. But I couldn't find the describe > about my question. https://docs.openstack.org/infra/zuul/ The official URL for Zuul's documentation these days is https://zuul-ci.org/docs/ (both URLs serve the same content for now though) and the relevant section is https://zuul-ci.org/docs/zuul/user/jobs.html?highlight=inventory#job-variables Confusion is understandable as the documentation doesn't dive into the particular variables Ansible supplies and isn't written as a guide for migrating from Zuul v2 to v3. That information which used to be written to /etc/nodepool can now be inferred from the Ansible inventory and is exposed as host vars for use in jobs. As an example, here's how the OpenStack community recreated the old Zuul v2 /etc/nodepool files with Ansible in their Zuul v3 deployment for transitional purposes: https://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/playbooks/legacy/pre.yaml?id=842f241#n8 Of course, in Zuul v3 you no longer need to stash these values in files on the nodes because you can simply reference the variables directly in your job definitions. Also, there is a specific discussion list for Zuul these days, you might prefer to use in the future: http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From honjo.rikimaru at po.ntt-tx.co.jp Thu Jun 21 01:04:41 2018 From: honjo.rikimaru at po.ntt-tx.co.jp (Rikimaru Honjo) Date: Thu, 21 Jun 2018 10:04:41 +0900 Subject: [OpenStack-Infra] How can I get the each node's IP address? In-Reply-To: <20180620124749.pgkma2pyt4qewszg@yuggoth.org> References: <20180620124749.pgkma2pyt4qewszg@yuggoth.org> Message-ID: Hello Jeremy, Thank you for the information! On 2018/06/20 21:47, Jeremy Stanley wrote: > On 2018-06-20 17:16:52 +0900 (+0900), Rikimaru Honjo wrote: >> I installed Zuul v3 and Nodepool in my environment. >> >> In the old Nodepool, I could get sub node's IP address from >> /etc/nodepool/sub_nodes. But, this file has been removed. >> >> How can I get each node's IP address when using multiple nodes in >> my job? >> >> I'd like to use Controller node's IP address for Compute nodes. I >> read the following document. But I couldn't find the describe >> about my question. https://docs.openstack.org/infra/zuul/ > > The official URL for Zuul's documentation these days is > https://zuul-ci.org/docs/ (both URLs serve the same content for now > though) and the relevant section is > https://zuul-ci.org/docs/zuul/user/jobs.html?highlight=inventory#job-variables Oh, sorry. I had misunderstood the official URL. > Confusion is understandable as the documentation doesn't dive into > the particular variables Ansible supplies and isn't written as a > guide for migrating from Zuul v2 to v3. That information which used > to be written to /etc/nodepool can now be inferred from the Ansible > inventory and is exposed as host vars for use in jobs. As an > example, here's how the OpenStack community recreated the old Zuul > v2 /etc/nodepool files with Ansible in their Zuul v3 deployment for > transitional purposes: > > https://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/playbooks/legacy/pre.yaml?id=842f241#n8 This is very useful for me. I could understand how to get IP address and other information. > Of course, in Zuul v3 you no longer need to stash these values in > files on the nodes because you can simply reference the variables > directly in your job definitions. > > Also, there is a specific discussion list for Zuul these days, you > might prefer to use in the future: > > http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss I got it. Thank you for your suggestions. > > > _______________________________________________ > OpenStack-Infra mailing list > OpenStack-Infra at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > Best regards, -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Rikimaru Honjo E-mail:honjo.rikimaru at po.ntt-tx.co.jp From xudan16 at huawei.com Thu Jun 21 04:16:27 2018 From: xudan16 at huawei.com (xudan (N)) Date: Thu, 21 Jun 2018 04:16:27 +0000 Subject: [OpenStack-Infra] [shade] Get server public/private ip failed on VLAN environment Message-ID: <04392915A1E57942AEFA2896DFC280AD012E338B@DGGEMI521-MBX.china.huawei.com> Hi all, I am from OPNFV community and working on Dovetail project. I have a question about shade getting server public ipv4 ip and private ipv4 ip with VLAN environment. The private ip I got is None and the public ip I got is not the floating ip assigned to the server. I guess this is because of shade filters the public ip with 'router:external = True' or 'provider:physical_network' https://github.com/openstack-infra/shade/blob/master/shade/openstackcloud.py#L2494 For vlan, all networks have the attribute 'provider:physical_network', so all networks are regarded as public network. Also it filters private ip with condition 'not network.get('router:external', False) and not network.get('provider:physical_network')' https://github.com/openstack-infra/shade/blob/master/shade/openstackcloud.py#L2509 Then there is no private network for vlan. So the server's private ip is None. I reached out you for some suggestions about how to use shade for VLAN environment? Have you considered that or I just misunderstood something. Regards, Xudan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mordred at inaugust.com Thu Jun 21 22:49:32 2018 From: mordred at inaugust.com (Monty Taylor) Date: Thu, 21 Jun 2018 17:49:32 -0500 Subject: [OpenStack-Infra] [shade] Get server public/private ip failed on VLAN environment In-Reply-To: <04392915A1E57942AEFA2896DFC280AD012E338B@DGGEMI521-MBX.china.huawei.com> References: <04392915A1E57942AEFA2896DFC280AD012E338B@DGGEMI521-MBX.china.huawei.com> Message-ID: <6ceb386c-f2cb-665d-7811-d4ba7056a995@inaugust.com> On 06/20/2018 11:16 PM, xudan (N) wrote: > Hi all, > > I am from OPNFV community and working on Dovetail project. Hi! > I have a question about shade getting server public ipv4 ip and private > ipv4 ip with VLAN environment. > > The private ip I got is None and the public ip I got is not the floating > ip assigned to the server. > > I guess this is because of shade filters the public ip with > ‘router:external = True’ or ‘provider:physical_network’ > https://github.com/openstack-infra/shade/blob/master/shade/openstackcloud.py#L2494 > > For vlan, all networks have the attribute ‘provider:physical_network’, > so all networks are regarded as public network. > > Also it filters private ip with condition ‘not > network.get('router:external', False) and not > network.get(‘provider:physical_network')’ > https://github.com/openstack-infra/shade/blob/master/shade/openstackcloud.py#L2509 > > Then there is no private network for vlan. So the server’s private ip is > None. > > I reached out you for some suggestions about how to use shade for VLAN > environment? Have you considered that or I just misunderstood something. Well - first of all, sorry that this is strange. This is all to work around there being no neutron concept of a "public" or "private" network. For scenarios such as yours, there are some config overrides you can use in clouds.yaml. An example can be seen here: http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/templates/puppetmaster/all-clouds.yaml.erb#n2 In the Internap cloud, all accounts are assigned a dedicated WAN and LAN network - but from the code perspective they look identical and we can't properly discover what should be used for what. We mark the WAN network as "routes_externally: true" so that shade will pick it. We didn't do the same thing for the other network because we're not using it. I think for your case, you could list both, and list one as true and one as false. If you want to use the auto_ip feature, you might also need to mark the internal network as nat_destination: true. The full docs are here: https://docs.openstack.org/openstacksdk/latest/user/config/network-config.html It's also possible there is some better way to detect the difference that could be added to the existing code. If we can do that and have it not break the existing discovery, I'd love to support more things. Does this help? Thanks! Monty From yamamoto at midokura.com Sat Jun 23 02:51:29 2018 From: yamamoto at midokura.com (Takashi Yamamoto) Date: Sat, 23 Jun 2018 11:51:29 +0900 Subject: [OpenStack-Infra] How to take over a project? (tap-as-a-service) In-Reply-To: References: Message-ID: thank you! On Sat, Jun 23, 2018 at 5:01 AM, Anil Rao wrote: > Hi, > > Sorry for the delay in getting to this … > > I have [finally] changed the maintainer from Anil Rao to Yamamoto Takashi. > > I think this should do the trick. > > Regards, > Anil > > On Wed, May 30, 2018 at 10:52 PM, Takashi Yamamoto > wrote: >> >> hi, >> >> i want to take over tap-as-a-service project. >> >> originally the project had two leaders. but one of them (vinay) has not >> been >> responding these days. another (anil) recently told us he might not work >> on it anymore. this email has cc: to them. >> >> i think gerrit is ok as i'm already a member of tap-as-a-service-core >> group. >> >> however, for launchpad, i'm not sure who can change the permissions. >> can the infra team help? >> the LP project is this one: https://launchpad.net/tap-as-a-service >> >> thank you. > > From honjo.rikimaru at po.ntt-tx.co.jp Mon Jun 25 10:50:47 2018 From: honjo.rikimaru at po.ntt-tx.co.jp (Rikimaru Honjo) Date: Mon, 25 Jun 2018 19:50:47 +0900 Subject: [OpenStack-Infra] How does Zuulv3 distinguish "Build successful" or failure? Message-ID: Hello, Sorry, I have a new question about Zuul V3. (Perhaps this is my last question...) I created my job of ZuulV3. And I deliberately failed my job to test my settings. As a result, a message like this was reported to gerrit. ----- Patch Set 1: Build successful. * foo-bar-tempest-test http://localhost:8000/421/1/20180625101836 : FAILURE in 7m 06s (non-voting) ----- "FAILURE" is OK. This is same as my expectation. Because this job was deliberately failed by me. But, "Build successful." was different from my expectation. How does Zuulv3 distinguish "Build successful" or failure? (Should I register the result to a specific variable in playbook?) Best regards, -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Rikimaru Honjo E-mail:honjo.rikimaru at po.ntt-tx.co.jp From Tobias.Henkel at bmw.de Mon Jun 25 11:06:09 2018 From: Tobias.Henkel at bmw.de (Tobias.Henkel at bmw.de) Date: Mon, 25 Jun 2018 11:06:09 +0000 Subject: [OpenStack-Infra] How does Zuulv3 distinguish "Build successful" or failure? In-Reply-To: References: Message-ID: <9CC39121-D069-4191-9D26-C75DC7E17570@bmw.de> Hi, On 25.06.18, 12:52, "Rikimaru Honjo" wrote: Hello, Sorry, I have a new question about Zuul V3. (Perhaps this is my last question...) I created my job of ZuulV3. And I deliberately failed my job to test my settings. As a result, a message like this was reported to gerrit. ----- Patch Set 1: Build successful. * foo-bar-tempest-test http://localhost:8000/421/1/20180625101836 : FAILURE in 7m 06s (non-voting) ----- "FAILURE" is OK. This is same as my expectation. Because this job was deliberately failed by me. But, "Build successful." was different from my expectation. How does Zuulv3 distinguish "Build successful" or failure? (Should I register the result to a specific variable in playbook?) Zuul ignores non-voting jobs for the overall build result. By declaring your job non-voting you tell zuul that you don't care about the build result of that job. Best regards, -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Rikimaru Honjo E-mail:honjo.rikimaru at po.ntt-tx.co.jp - Tobias From honjo.rikimaru at po.ntt-tx.co.jp Tue Jun 26 00:55:26 2018 From: honjo.rikimaru at po.ntt-tx.co.jp (Rikimaru Honjo) Date: Tue, 26 Jun 2018 09:55:26 +0900 Subject: [OpenStack-Infra] How does Zuulv3 distinguish "Build successful" or failure? In-Reply-To: <9CC39121-D069-4191-9D26-C75DC7E17570@bmw.de> References: <9CC39121-D069-4191-9D26-C75DC7E17570@bmw.de> Message-ID: <67a67756-0a9f-fe79-2fbb-a99a5fb9bde7@po.ntt-tx.co.jp> Hello Tobias, Thank you for great information! > Zuul ignores non-voting jobs for the overall build result. By declaring your > job non-voting you tell zuul that you don't care about the build result of that > job. OK, I got it. Best regards, On 2018/06/25 20:06, Tobias.Henkel at bmw.de wrote: > Hi, > > On 25.06.18, 12:52, "Rikimaru Honjo" wrote: > > Hello, > > Sorry, I have a new question about Zuul V3. > (Perhaps this is my last question...) > > I created my job of ZuulV3. > And I deliberately failed my job to test my settings. > > As a result, a message like this was reported to gerrit. > > ----- > Patch Set 1: > Build successful. > * foo-bar-tempest-test http://localhost:8000/421/1/20180625101836 : FAILURE in 7m 06s (non-voting) > ----- > > "FAILURE" is OK. This is same as my expectation. > Because this job was deliberately failed by me. > > But, "Build successful." was different from my expectation. > How does Zuulv3 distinguish "Build successful" or failure? > (Should I register the result to a specific variable in playbook?) > > Zuul ignores non-voting jobs for the overall build result. By declaring your > job non-voting you tell zuul that you don't care about the build result of that > job. > > Best regards, > -- > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > Rikimaru Honjo > E-mail:honjo.rikimaru at po.ntt-tx.co.jp > > > - Tobias > > > > -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Rikimaru Honjo E-mail:honjo.rikimaru at po.ntt-tx.co.jp From cboylan at sapwetik.org Tue Jun 26 21:12:42 2018 From: cboylan at sapwetik.org (Clark Boylan) Date: Tue, 26 Jun 2018 14:12:42 -0700 Subject: [OpenStack-Infra] Denver PTG 2018 Planning Message-ID: <1530047562.2738591.1421406744.4AA93AE4@webmail.messagingengine.com> Hello everyone, I've started an etherpad where we can collect thoughts on items we should talk about and work on at the 2018 Denver PTG. Feel free to propose items at https://etherpad.openstack.org/p/infra-ptg-denver-2018. Note that the rough schedule there is based on rumor and probably shouldn't be used to book travel at this point, but gives you an idea of the time we will have together. Looking forward to seeing what you all want to work on at the PTG. Thank you, Clark From corvus at inaugust.com Wed Jun 27 00:18:24 2018 From: corvus at inaugust.com (James E. Blair) Date: Tue, 26 Jun 2018 17:18:24 -0700 Subject: [OpenStack-Infra] [infra] Behavior change in Zuul post pipeline Message-ID: <871sctjd4f.fsf@meyer.lemoncheese.net> Hi, We recently changed the behavior* of the post pipeline in Zuul to only run jobs for the most recently merged changes on each project's branches. If you were relying on the old behavior where jobs ran on every merged change, let us know, we can make a new pipeline for that. But for the typical case, this should result in some improvements: 1) We waste fewer build resources building intermediate build artifacts (e.g., documentation for a version which is already obsoleted by the change which landed after it). 2) Races in artifact build jobs will no longer result in old versions of documentation being published because they ran on a slightly faster node than the newer version. If you observe any unexpected behavior as the result of this change, please let us know in #openstack-infra. -Jim * The thing which implements this behavior in Zuul is the "supercedent"** pipeline manager[1]. Zuul has had, since the initial commit six years ago, a pluggable system for controlling the behavior in its pipelines. To date, we have only had two pipeline managers: "dependent" which controls the gate, and "independent" which controls everything else. [1] https://zuul-ci.org/docs/zuul/user/config.html#value-pipeline.manager.supercedent ** It may or may not be named after anyone you know. From thierry at openstack.org Wed Jun 27 07:49:53 2018 From: thierry at openstack.org (Thierry Carrez) Date: Wed, 27 Jun 2018 09:49:53 +0200 Subject: [OpenStack-Infra] [infra] Behavior change in Zuul post pipeline In-Reply-To: <871sctjd4f.fsf@meyer.lemoncheese.net> References: <871sctjd4f.fsf@meyer.lemoncheese.net> Message-ID: James E. Blair wrote: > [...] > 2) Races in artifact build jobs will no longer result in old versions of > documentation being published because they ran on a slightly faster node > than the newer version. Great news! That was a standing issue for releases.openstack.org around release time :) -- Thierry Carrez (ttx) From arao012 at gmail.com Fri Jun 22 20:01:39 2018 From: arao012 at gmail.com (Anil Rao) Date: Fri, 22 Jun 2018 13:01:39 -0700 Subject: [OpenStack-Infra] How to take over a project? (tap-as-a-service) In-Reply-To: References: Message-ID: Hi, Sorry for the delay in getting to this … I have [finally] changed the maintainer from Anil Rao to Yamamoto Takashi. I think this should do the trick. Regards, Anil On Wed, May 30, 2018 at 10:52 PM, Takashi Yamamoto wrote: > hi, > > i want to take over tap-as-a-service project. > > originally the project had two leaders. but one of them (vinay) has not > been > responding these days. another (anil) recently told us he might not work > on it anymore. this email has cc: to them. > > i think gerrit is ok as i'm already a member of tap-as-a-service-core > group. > > however, for launchpad, i'm not sure who can change the permissions. > can the infra team help? > the LP project is this one: https://launchpad.net/tap-as-a-service > > thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: