Friday, 2020-03-13

ianw"ImportError: libre2.so.0: cannot open shared object file: No such file or directory"00:11
ianwit never ends00:11
*** rlandy has quit IRC00:17
*** tosky has quit IRC00:18
ianwi only have libre2.so.0a.0.000:19
clarkbianw: this is running zuul locally?00:19
clarkbthe re2 stuff should be reasonably well captured in bindep I thought00:19
ianwtrying to run unittests from tox00:20
ianwyeah, i think i have all that ...00:20
ianw$ ldd ./.tox/py37/lib/python3.7/site-packages/_re2.cpython-37m-x86_64-linux-gnu.so00:20
ianwlinux-vdso.so.1 (0x00007fffad3a0000)00:20
ianwlibre2.so.0 => not found00:20
ianwit seems like maybe it's come from a wheel?00:21
*** erbarr has quit IRC00:22
ianwuninstalling it ,then ".tox/py37/bin/pip install --no-binary :all:  fb-re2" seems to have it working now :/00:23
openstackgerritIan Wienand proposed zuul/zuul master: [dnm] unit test to see if jobs run when nodes are updated  https://review.opendev.org/71282100:25
*** jamesmcarthur has joined #zuul00:27
*** armstrongs has joined #zuul00:34
*** armstrongs has quit IRC00:43
*** jamesmcarthur has quit IRC00:44
*** jamesmcarthur has joined #zuul00:47
*** Goneri has quit IRC01:15
*** jamesmcarthur has quit IRC01:17
ianwok, pebkac as suspected and it's my syntax error that led me down the wrong path01:45
*** swest has quit IRC02:12
*** jamesmcarthur has joined #zuul02:25
*** swest has joined #zuul02:27
*** jamesmcarthur has quit IRC02:47
*** bhavikdbavishi has joined #zuul03:25
*** jamesmcarthur has joined #zuul03:46
*** jamesmcarthur has quit IRC04:00
*** bolg has quit IRC04:39
*** bolg has joined #zuul05:11
*** evrardjp has quit IRC05:35
*** evrardjp has joined #zuul05:36
*** dpawlik has quit IRC06:37
*** dpawlik has joined #zuul06:55
*** dpawlik has quit IRC07:10
*** dpawlik has joined #zuul07:16
*** Defolos has joined #zuul07:56
*** jcapitao has joined #zuul07:59
*** hashar has joined #zuul08:31
*** harrymichal has joined #zuul08:36
*** tosky has joined #zuul08:46
*** jpena|off is now known as jpena08:53
*** sgw has quit IRC10:04
*** bhavikdbavishi has quit IRC10:52
*** saneax has quit IRC11:12
*** harrymichal has quit IRC11:18
*** saneax has joined #zuul11:25
*** sanjayu_ has joined #zuul11:28
*** avass is now known as Guest9744611:28
*** avass has joined #zuul11:28
tobiashclarkb, ianw: fyi libre2 in latest fedora is incompatible with prebuilt wheel of fb-re211:30
*** saneax has quit IRC11:30
*** harrymichal has joined #zuul11:33
*** jcapitao is now known as jcapitao_lunch11:38
*** zxiiro has joined #zuul12:08
*** rlandy has joined #zuul12:11
*** bhavikdbavishi has joined #zuul12:24
openstackgerritMerged zuul/zuul master: Be explicit about source of base images  https://review.opendev.org/71277212:26
*** jpena is now known as jpena|lunch12:30
openstackgerritMerged zuul/zuul master: Remove stretch-backports from docker build  https://review.opendev.org/71273712:35
*** harrymichal has quit IRC12:45
*** harrymichal has joined #zuul12:45
openstackgerritTobias Henkel proposed zuul/zuul master: Defer setting build pause to event queue  https://review.opendev.org/71293912:49
tobiashzuul-maint: this fixes a node leak caused by a race when combining job pause and child job skipping ^12:50
*** jcapitao_lunch is now known as jcapitao13:05
avasshmm, is there any reason why a change doesn't want to start gating if it's a bit old? a simple rebase usually helps but I don't see why zuul can't handle that13:13
tobiashavass: gerrit or github?13:13
avassgerrit13:15
tobiashhrm, I don't see a reason why this wouldn't work13:15
*** armstrongs has joined #zuul13:16
tobiashI guess logs of the event that should have worked would help13:16
avassI... don't have that13:17
armstrongshey im using the new check_run event on github im wondering how to scope it to a particular job as when i click the button on github to rerun a failed check it is firing all checks. It doesn't look like this is documented but i seen on the test fixture it has check: zuul:(tenant)/(gate):.* which i believe should do it but im not sure what the13:19
armstrongsformat should be13:19
armstrongsare there any examples i could look at you know of?13:20
armstrongshttp://paste.openstack.org/show/790666/ as an example13:22
tobiasharmstrongs: that's our trigger config of the check pipeline: http://paste.openstack.org/show/790668/13:29
*** avass has quit IRC13:31
armstrongsthanks will give that a go13:31
armstrongs:)13:31
*** Goneri has joined #zuul13:33
armstrongstobiash: that works thanks so much13:34
*** jpena|lunch is now known as jpena13:35
fungiwhen avass comes back, recommend setting debug in the project-pipeline on that change and seeing if it reports why it's not selecting any jobs. also check the status dashboard for the little "bell" notification icon where zuul might be trying to signal a configuration error for that project or its jobs13:37
*** harrymichal has quit IRC13:40
fungiarmstrongs: tobiash: i'm not finding that check action listed at https://zuul-ci.org/docs/zuul/reference/drivers/github.html#attr-pipeline.trigger.%3Cgithub%20source%3E.action13:43
fungiis it still "experimental" from zuul's perspective?13:43
tobiashfungi: https://zuul-ci.org/docs/zuul/reference/drivers/github.html#value-pipeline.trigger.%3Cgithub%20source%3E.action.requested13:44
tobiashfungi: I guess we should add a check_run based reference pipeline13:45
fungioh, yep, i misread. so what is the check parameter then? clearly a filter pattern for the event, but that's what i'm not finding13:45
*** avass has joined #zuul13:46
tobiashfungi: it's the same as https://zuul-ci.org/docs/zuul/reference/drivers/github.html#value-pipeline.trigger.%3Cgithub%20source%3E.action.status but you're right, that's missing there13:46
fungiand just trying to understand from context what that's for, since i'm unfamiliar with it... this is because you may have multiple ci systems configured as github checks and you want to only enqueue into zuul pipelines when hitting the recheck button for specific ones?13:46
fungi(rather than triggering all your different ci systems to reeuqueue the pr)13:47
fungi(even when the failed build wasn't one of zuul's)13:48
tobiashfungi: the status and check_run events are pretty much the same in zuul and are originally designed to be generic enough so you can specify if you want to react on any or just on some events13:49
zbrminor nit https://review.opendev.org/#/c/708642/13:49
tobiashe.g. we combine zuul with other github apps that set a status (WIP bot for example) and react on those events as well13:50
fungigot it. so in the check_run case you don't necessarily want to trigger zuul to enqueue the pr unless a recheck was requested for something it's actually responsible for13:51
armstrongsits not documented i looked at the code to get it :)13:51
armstrongsshould say code review13:52
*** harrymichal has joined #zuul13:56
openstackgerritJan Kubovy proposed zuul/zuul master: WIP: Separate connection registries in tests  https://review.opendev.org/71295814:06
*** bolg has quit IRC14:09
*** y2kenny has joined #zuul14:09
*** noonedeadpunk has joined #zuul14:23
noonedeadpunkhi folks. I was wondering, where did you get from python versions installed by https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-python/tasks/main.yaml ?14:23
noonedeadpunkLike for ubuntu I've found https://launchpad.net/~deadsnakes/+archive/ubuntu/ppa but not sure if it is going to suite the debian and if you do you it or whatever else repo?14:24
clarkbnoonedeadpunk: debian traditionally has a large range of python available. Ubuntu bionic has 2.7, 3.6, 3.7, and 3.814:26
clarkball without a ppa14:26
noonedeadpunkjust debian has them in sid only?14:27
noonedeadpunkand in buster it's kinda... missing 3.6 I think...14:28
noonedeadpunkclarkb: so you generally suggest using ubuntu instead?14:28
mordrednoonedeadpunk: our default nodes are all ubuntu14:30
mordredI don't know that we "recommend" ubuntu over debian broadly - but it works well for us for the most part for base CI nodes14:31
clarkbnoonedeadpunk: Im not sure what mix of debian repos you need to have that range but it was my understanding you could get afew like on ubuntu14:32
mordrednoonedeadpunk: depending on the use case, there are other options. for instance, I personally use pyenv to get python - and I could imagine setting up a CI system that made base nodes using debian that used pyenv instead of distro packages to get all the different python versions - but there's also flaws with that, since you woud;nt be testing the actual python shipped by the distro14:32
mnasermordred: i was actually thinking about this last night, i think the hard part with that is having to override the all the base jobs somehow14:34
y2kennyHello.  Do you guys use gerrit's replication plugin?  how do you guys take advantage of ref-replicated events?  (For example, change updated on one server but executor/nodes pull from a replicated mirror and replication hasn't propagated yet.)14:34
y2kennyI am thinking of using Job require/provide but that doesn't seem quite right14:34
mnaserand then i wonder the cost of having a new vm spin up from scratch vs pyenv building python ends up being the same time14:34
clarkbhttps://wiki.debian.org/Python#Supported_Python_Versions its a bit more restricted than I thought14:34
clarkby2kenny: we do use replication, but zuul always pulls from gerrit to avoid needing to wait for replication14:35
funginoonedeadpunk: the general solution we use in opendev is to choose an appropriate platform which provides the desired python packages, so if you need to run something against python 3.4 use debian stretch, 3.5 use ubuntu xenial, and so on14:36
fungiwe've not generally expected to be able to test all python versions on the same platform14:36
mnasernoonedeadpunk: i wonder if we want to continue using debian as a base platform, we can setup a repo/job which builds all sorts of different pythons and packages them for debian14:37
y2kennyclarkb: are there ways to leverage the replication complete mechanism?  Or is the traffic hitting the git server much less of a problem since the executor is serving the source code?14:39
mnasery2kenny: the executor generally caches a copy of the source code so its not a full pull every tim14:40
clarkby2kenny: we havent had problems with the traffic because zuul keeps caches which reduces the overhead14:40
clarkbif you find that you do need to leverage replication with zuul that is probably something that can be added, but isnt there now14:41
mordredyeah - for the most part zuul is only fetching new refs after the initial clones14:41
mordredso in a warm system it's not expensive14:41
y2kennyok.  I will go with that for now.  This is probably another zuul advantage because we used to have jenkins slave hitting gerrit master directly a lot14:41
mordredthe nodes themselves don't clone or fetch anything14:41
mordredthe executors push the git state to the nodes - we do build base images with our git repos cached on them already so that the git push from the executor to the build nodes is more minimized - but even without that the load on gerrit should be very low14:42
y2kennythis is great, thanks!14:43
fungimnaser: noonedeadpunk: the packages in the deadsnakes ppa are generally installable on debian, even though they're built on ubuntu people tend to use them on both14:44
Shrewsugh, tfw you include 'self' when calling a method on an object and it takes you all morning to find it14:53
*** harrymichal has quit IRC14:58
*** harrymichal has joined #zuul14:59
mordredShrews: moar koffie14:59
*** avass has quit IRC15:10
*** jamesmcarthur has joined #zuul15:29
clarkbzbr: can you check comments on https://review.opendev.org/#/c/708642/17 I think I may need a bit more clarification on that15:42
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: DNM: rebase unittests to base-minimal-test  https://review.opendev.org/71298515:45
zbrclarkb: tbh, i am aware of any case where failed_when: false requires an ignore_errors.15:52
zbrin fact, it may be possible that ignore_errors could ignore a module failure (trace), which failed_when does not.15:52
zbrwhich makes use of failed_when even more to be desired15:53
zbrbut i need to test to get confirmation15:53
zbrbut you described the issue very well: ignore_errors makes the recording hard to read15:53
zbrthey soon end-up looking like the xmas tree15:54
*** sugaar has quit IRC15:55
corvustristanC: i think the keytool in the zookeeper image is different than what's in fedora and ubuntu, so i'm getting a different kind of keystore when i run zk-ca.sh on the zk node in quickstart.  i think that's what's driving the cipher suite errors.15:56
clarkbzbr: ok, in that case I think we should remove that extra ignore_errors and only use failed_when there15:57
zbrsure, i will do it, but that change is near the bottom of my prio list :D15:57
corvustristanC: it uses jdk8; i'll just try to move zk-ca to run on a different host15:59
openstackgerritClark Boylan proposed zuul/nodepool master: Switch min TLS version to 1.1 in the docker images  https://review.opendev.org/71299715:59
clarkbfungi: ianw ^ fyi I think that is what fungi is saying will fix that for us15:59
corvusclarkb: is that something we do in opendev?  (perhaps by virtue of running on xenial?)16:00
clarkbcorvus: no thats something rackspace does by virtue of we don't know16:00
*** jamesmcarthur has quit IRC16:00
clarkbor do you mean why does it work in production today?16:00
corvusclarkb: er, i don't understand why that's necessary then16:00
corvusyes that16:00
clarkbyes, I think ubuntu isn't setting that high of a minimum version16:01
fungiyeah, we're not running on a new enough distro to have set tls 1.2 as its minimum16:01
fungiand rackspace's api endpoint doesn't support tls 1.2 (yet at least)16:01
clarkbfwiw ubuntu doesn't seem to set the value at all16:01
clarkbso likely depends on whatever they compile into ssl16:02
fungientirely possible ubuntu is more concerned with backward compatibility16:02
clarkbmordred: corvus can we indent the blocks that happen after each FROM?16:02
clarkbits actually pretty hard to pick out where each image begins and ends in that file16:03
corvusclarkb: how about ========================================== instead?16:03
clarkbcorvus: I think that would work too16:03
clarkbI'll try that. Basically need some sort of visual cue16:03
*** jamesmcarthur has joined #zuul16:03
corvus(otherwise, i worry that we'll be fiddling with our editors and hitting tab all the time since i don't think that's a standard thing)16:03
clarkbfungi: corvus "The value None will disable the limit" says the manpage for that file. That means ubuntu isn't setting a lower bound16:04
corvusclarkb, fungi: looks like it's more like debian *is* setting a default: https://github.com/openssl/openssl/blob/master/apps/openssl.cnf16:07
fungiyep16:07
openstackgerritClark Boylan proposed zuul/nodepool master: Add visual dividers for each image in Dockerfile  https://review.opendev.org/71300216:07
clarkbcorvus: ^ I think that actually does help quite a bit16:07
corvusthat's 2 distros making 2 annoying changes to openssl.cnf in 2 days.  grumble.16:07
fungihttps://salsa.debian.org/debian/openssl/-/blob/debian/unstable/debian/patches/Set-systemwide-default-settings-for-libssl-users.patch16:08
fungifor the record16:08
mordredcorvus: they're "adding value"16:10
fungii too disagree with general purpose distros questioning upstream's position on what is or isn't a secure default16:10
fungiit's not like openssl is developed in a vacuum16:11
fungiyou'd think the debian openssl maintainers, especially, would rethink that sort of behavior in light of the last time doing something like that revealed they knew far less about the software than they thought they did16:12
clarkbfungi: ssh they might hear you :)16:12
fungioh, it's okay, i'm encrypting this conversation with nacl instead16:13
fungi(jk, not really)16:13
clarkbfungi: re md5 I believe most modern browsers are no longer trusting md5 so we are likely safe there16:16
clarkbbasically if chrome stops doing it you're forced to follow16:17
fungiyeah, i mention that setting because i had to set it to get python 3.5's selftests to complete, since they embedded some old md5 certs16:18
clarkbhuh16:18
fungii think the latest 3.5 point releases have since fixed their test fixures16:19
fungii haven't checked lately16:19
*** jcapitao is now known as jcapitao_afk16:25
*** openstackgerrit has quit IRC16:31
corvusfungi: all the zk docs use "SSL".  should i name the config file entries "ssl_cert" or "tls_cert" ?16:35
*** hashar has quit IRC16:35
corvus(i'm not sure if that's just cause the zk docs are written by the developers who are using old java method names with ssl and use that by habit, while us forward-looking folks should be saying 'tls' everywhere, or if there's some distinction that warrants using ssl still)16:36
fungiit's potato potato... technically it's a x.509 cert16:37
*** sgw has joined #zuul16:37
fungiit can be used to authenticate a variety of protocols16:37
corvusseems like as long as the tls family is among the protocols that are supported, it's probably more correct?16:38
fungiper rfc 2246 tls 1.0 is based on ssl v3 so you can call it either16:39
fungii'd consider "tls" a more specific term than "ssl" in this case16:39
fungiso yeah, if all you're using it for is tls then calling it by that name is correct and more precise than calling it ssl16:40
fungi(which would still also be correct, just slightly more vague)16:40
corvushttps://www.eclipse.org/jetty/documentation/current/configuring-ssl.html16:40
corvusthat suggests they're keeping up with the latest tlses (as expected)16:41
corvusand sslv3/tls1.0 are not supported by default16:41
corvusso... technically 'tls' then16:42
fungithese days, pedantry aside, the terms ssl and tls are used synonymously so whichever you like is fine really16:42
corvusyeah, but since we're about to commit to some config file terms, pretty much forever, i thought this is the moment not to set pedantry aside16:43
fungiin the sense that tls-1.1 is not backwards compatible with sslv3 it's tls and not ssl, but in the sense that tls is a successor to ssl and could be considered sslv4 by another name, meh...16:43
corvus(we currently use "ssl_cert" for gearman, so we could be consistent and use the same for zk, but gearman is going away, so i think we can break precedent if we want to switch)16:43
corvusi was looking for a way stronger opinion :)16:44
fungii wouldn't bat an eyelash at either name, and i don't think either one is likely to confuse anybody, so it's hard to have a strong opinion on it16:44
clarkbI think SSL is still commonly used. For this audience I would expect ssl and tls to work equally fine (and tls is more correct), but for a less technical audience ssl is probably more recognizable16:45
fungitls has been around long enough now that i've stopped seeing people recoil at the term ssl and thinking that it means something lacks tls support or is still actually using old deprecated protocols16:45
fungibut yes, these are all good cases for choosing tls for the name. ssl is also acceptable but maybe barely less preferable?16:46
*** erbarr has joined #zuul16:52
*** jcapitao_afk is now known as jcapitao16:53
*** openstackgerrit has joined #zuul17:00
openstackgerritJames E. Blair proposed zuul/zuul master: Add TLS support for ZooKeeper  https://review.opendev.org/71253117:00
openstackgerritJames E. Blair proposed zuul/zuul master: Use ZK TLS in quickstart  https://review.opendev.org/71281717:00
corvustristanC: ^ that corrects an error with zuul-web, which i found when running the quickstart.  i think it should be working now.17:01
tristanCcorvus: i'll get back to that shortly17:02
corvusi believe we don't actually need to run keytool, i think doing an openssl export to pkcs12 is sufficient to get a file that zk can read, so i've done that17:02
corvuser, "done that" == removed the keytool step from zk-ca.sh17:02
tristanCha that's good17:02
clarkbmordred: did hacking break even more https://zuul.opendev.org/t/zuul/build/fe16cb58f5ac468d973ac0c429a94e1e/log/job-output.txt#578 ?17:03
clarkblooks like maybe we need to pin flake8?17:03
corvusclarkb, mordred: i rechecked https://review.opendev.org/712781 after the dep merged, results just came back from that17:04
tristanCcorvus: have you seen my comment on https://review.opendev.org/#/c/712816/1 ?  it seems like the depends on zuul image doesn't work17:04
corvustristanC: oh, nope, i'll look into that, thanks17:04
clarkbcorvus: ah ok so probably just need that to land17:04
clarkb(I had noticed it was more than just the license messages now hence my question about more breakage)17:05
*** hashar has joined #zuul17:05
mordredcorvus: I don't understand that failure :(17:05
corvusmordred: this one?  https://zuul.opendev.org/t/zuul/build/341f13d88ce24a898a10ae9e8d1d1c6917:05
mordredyeah17:05
corvusmordred: yeah, i don't either.  <shrug> internet?17:06
mordredcorvus: that's a fair guess17:07
mordredcorvus: but ...17:07
mordredcorvus: https://zuul.opendev.org/t/zuul/build/341f13d88ce24a898a10ae9e8d1d1c69/log/job-output.txt#2295817:08
mordredcorvus: interrupted system call17:08
mordredthat would be from echo "deb http://ppa.launchpad.net/openstack-ci-core/vhd-util/ubuntu bionic main" >> /etc/apt/sources.list17:08
mordredapparently the >> failed?17:08
fungiis /etc/apt/sources.list writeable?17:09
fungithat's about the only thing i can think of that can go wrong there17:09
fungior /etc/apt not existing at all or being set unwriteable or untraversable17:10
clarkbor the disk filled17:11
fungioh, yep17:12
clarkbif the job was on rax / is relatively small17:12
fungior is mounted read-only for some reason17:12
clarkb(though I would still be surprised if that was the issue)_17:12
corvusinap17:12
fungioh, or selinux or apparmor rules rejectnig write17:13
fungigenerally almost all of those are conditions i would expect to generate more recognizable errors though17:14
fungi"interrupted system call" means something generated a signal17:14
fungilike maybe a timeout watcher17:15
fungior the server was in the process of shutting down17:16
*** Defolos has quit IRC17:17
mordredyeah. like - it only happened on the -tips job - so maybe it really just was an unlucky something17:19
fungiright, i have a feeling it won't be reproducible (but if it is, maybe set an autohold)17:20
*** y2kenny has quit IRC17:21
*** dpawlik has quit IRC17:30
*** evrardjp has quit IRC17:35
*** evrardjp has joined #zuul17:36
*** sshnaidm|afk has quit IRC17:37
openstackgerritJames E. Blair proposed zuul/zuul-operator master: Use explicit provides/requires for container jobs  https://review.opendev.org/71281617:49
openstackgerritJames E. Blair proposed zuul/zuul-operator master: Update to dhall lang v14  https://review.opendev.org/71064917:49
openstackgerritJames E. Blair proposed zuul/zuul-operator master: Add TLS configuration to ZooKeeper service  https://review.opendev.org/71275917:49
corvustristanC: i think i put the requires on the wrong job; that should fix it17:49
*** armstrongs has quit IRC17:50
openstackgerritJames E. Blair proposed zuul/zuul-operator master: Use explicit provides/requires for container jobs  https://review.opendev.org/71281617:51
openstackgerritJames E. Blair proposed zuul/zuul-operator master: Update to dhall lang v14  https://review.opendev.org/71064917:51
openstackgerritJames E. Blair proposed zuul/zuul-operator master: Add TLS configuration to ZooKeeper service  https://review.opendev.org/71275917:51
corvusthat adds a provides line too (in case we want to "requires: zuul-operator-container-image" in the future)17:51
*** jamesmcarthur has quit IRC17:53
corvusmnaser: i forwarded your msg to zuul-announce and approved it17:53
tristanCcorvus: excellentm thanks!17:55
mnasercorvus: thank you17:55
corvustristanC: oh, one more thing for future debugging -- in that log you linked, the correct image actually is listed here: https://zuul.opendev.org/t/zuul/build/3b7c283e4c7f4f97886b1a27bd9c4054/log/zuul-info/inventory.yaml#16417:57
*** jamesmcarthur has joined #zuul17:57
corvustristanC: both artifacts show up in the list, but the later one ends up overwriting the first.  but only if it's actually imported into the buildset registry17:58
corvustristanC: (so now that we've moved the requires line to the image build job, which is the one that runs the pull-from-intermediate-registry role, it should get that list of artifacts instead of the functional test job, and pull them into the buildset registry)17:59
corvusmordred: fwiw, the nodepool-functional-openshift is the only gating job that failed on 712781, and that was a node_failure (?).  we could probably ignore the siblings jobs, except, given that the patch is all about prickly openstack project dependency issues, it seems like it's worth getting check results on that (ie, it seems plausible to me that this work could somehow prove buggy in the siblings context)18:03
corvusNode request <NodeRequest 300-0007905272 <NodeSet [<Node None ('cluster',):centos-7>, <Node None ('launcher',):fedora-30>]>>: failure for nodepool-functional-openshift18:04
corvusit kinda looks like opendev is having a thing about fedora-30 now.  i will move this to #opendev18:05
*** jamesmcarthur has quit IRC18:05
*** jamesmcarthur has joined #zuul18:06
*** jpena is now known as jpena|off18:07
*** jcapitao has quit IRC18:12
*** hashar has quit IRC18:14
*** chandankumar is now known as raukadah18:14
*** sanjayu_ has quit IRC18:15
corvustristanC: it appears that due to an accident, opendev has temporarily lost the ability to supply any fedora images.  is there an alternative we can use for the nodepool-functional-openshift job?18:21
*** jamesmcarthur has quit IRC18:22
*** jamesmcarthur has joined #zuul18:22
clarkbwe have centos 8 images18:23
tristanCiirc only the nodepool services are running on fedora, we should be able to switch to another system18:28
tristanCcorvus: success, zookeeper tls configured by the zuul-operator worked! https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_562/712759/9/check/zuul-operator-functional-k8s/562b3ab/docker/k8s_zk_zuul-zk-0_default_4883b6a7-39da-4b58-980a-2430d3d13d6b_0.txt18:29
corvustristanC: so we could just switch that to ubuntu?18:30
tristanCcorvus: i think so, let me have a look18:31
tristanCwell, i'd rather pick centos8 for diversity, but ubuntu should work too18:31
corvusit's got to be something with openshift clients18:32
corvusi don't think that's an installable package in ubuntu18:32
tristanCwell, we could use the usual unarchive from upstream release artifact18:33
openstackgerritJames E. Blair proposed zuul/nodepool master: WIP test functional-openshift on centos8  https://review.opendev.org/71304618:33
fungilooks like some openshift tools will be in ubuntu 20.04 lts: https://packages.ubuntu.com/openshift so we might eventually be able to use that18:34
corvustristanC: ^ maybe that will work?18:34
tristanCcorvus: i guess this will be the problematic task: https://opendev.org/zuul/nodepool/src/branch/master/playbooks/nodepool-functional-openshift/pre.yaml#L1818:36
tristanCand i don't know if c8 has zookeeper for https://opendev.org/zuul/nodepool/src/branch/master/playbooks/nodepool-functional-openshift/run.yaml#L1218:36
corvustristanC: okay, we're working out how to fix f30 in #opendev -- i'm hoping we might have it back in a few hours.   so if centos8 doesn't just work, i think we should wait for the f30 fix.18:37
*** bhavikdbavishi has quit IRC18:41
*** jbryce is now known as airship-irc-bot19:03
*** airship-irc-bot is now known as jbryce19:07
*** harrymichal has quit IRC19:20
openstackgerritAndreas Jaeger proposed zuul/zuul-jobs master: Use a zuul_* and add an .ansible-lint file  https://review.opendev.org/71254719:27
*** jamesmcarthur has quit IRC19:50
*** jamesmcarthur has joined #zuul19:51
*** jamesmcarthur has quit IRC19:57
*** jamesmcarthur has joined #zuul19:58
openstackgerritDavid Shrewsbury proposed zuul/nodepool master: Stop comparing hostnames to determine ownership  https://review.opendev.org/71305719:59
*** harrymichal has joined #zuul20:05
openstackgerritMonty Taylor proposed zuul/nodepool master: Revert "Dockerfile: add support for arbritary uid"  https://review.opendev.org/71306020:10
openstackgerritDavid Shrewsbury proposed zuul/nodepool master: Stop comparing hostnames to determine ownership  https://review.opendev.org/71305720:13
clarkbShrews: ^ thinking about that should we add a release note that you'll need to have all nodepool servers running at least version 3.x.y?20:19
clarkbthe risk is if you are in a mixed old and new environment right? as the old servers won't be able to use uuids?20:20
*** harrymichal has quit IRC20:21
Shrewsclarkb: well, someone would have to be running version 0.4.0 or older for them to be affected. That's 3 years old and highly buggy20:22
clarkboh wow I didn't realize the uuids were implemented that long ago ++ I doubt its an issue20:23
*** hashar has joined #zuul20:25
clarkbI believe the risk to peopel in that situation is that nodepool won't delete things20:29
clarkband they can simply delete things manually in that case (noted on the chagne)20:29
clarkbthat is a pretty safe failure mode so +2 from me. I didn't approve since I know others are lokoing at this recently too and wanted to give them a chance once stuff settles down20:29
*** Defolos has joined #zuul20:33
*** jamesmcarthur has quit IRC20:40
*** jamesmcarthur has joined #zuul20:41
*** jamesmcarthur has quit IRC20:45
*** jamesmcarthur has joined #zuul20:45
*** josefwells has joined #zuul21:02
*** jamesmcarthur has quit IRC21:05
*** jamesmcarthur has joined #zuul21:06
mnaserhttps://zuul-ci.org/docs/zuul/discussion/components.html#enabling-tenant-scoped-access-to-privileged-actions -- am i correct in my assumption that zuul in this case does not allow for an authenticator _per tenant_21:09
mnaseri.e. i can't have some tenant get access to actions via gsuite, and another one via github21:09
mnaseri guess i can define a whole bunch and then use admin-rules that are filtered based on 'iss'21:11
*** jamesmcarthur has quit IRC21:12
josefwellsHey zuul'rs, mostly tristanC, I have been following the discussion about zuul k8s operators, and I saw this video (on the openstack youtube) https://www.youtube.com/watch?v=oGD9bazvhps&list=PLKkmfepLcP3DDsXTkBCDClfw24q83iw49&index=421:13
*** jamesmcarthur has joined #zuul21:13
josefwellsI found the code here: https://github.com/xxiao93/zuul-operator21:14
josefwellsThoughts?  Any alignment with your zuul-operator work thus far?21:14
*** jamesmcarthur has quit IRC21:15
mordredjosefwells: no - https://opendev.org/zuul/zuul-operator is our zuul operator work21:17
*** jamesmcarthur has joined #zuul21:18
corvusmnaser: aiui, you would define all the authenticators in the conf file, and then set up access rules for each tenant that refer to them: https://zuul-ci.org/docs/zuul/reference/tenants.html#attr-tenant.admin-rules21:20
*** rlandy has quit IRC21:21
fungijosefwells: that was one of several starts at a zuul operator, we're converging on the code in https://opendev.org/zuul/zuul-operator21:21
corvusmnaser: i think the expectation is that maybe you'd have 2 authenticators (google and github), then an access rule for each tenant?21:22
corvusmnaser: if your reality is different, we should chat with mhu :)21:22
josefwellsthanks fungi21:22
mnasercorvus: yeah -- i'm thinking that is probably going to work out ok for most use cases, i guess if someone is using something like okta or keycloak, they'd get their own auth thing21:23
mnaserand so technically as long as the access rules match on the issuer in tenant config, we'll probably be ok21:23
*** jamesmcarthur has quit IRC21:29
tristanCjosefwells: i was not aware of the project, it seems like the api defined is quite different see https://github.com/xxiao93/zuul-operator/blob/master/deploy/crds/cache_v1alpha1_zuul_cr.yaml and https://opendev.org/zuul/zuul-operator/src/branch/master/deploy/crds/zuul-ci_v1alpha1_zuul_cr.yaml21:33
tristanCjosefwells: i would be happy to help converge toward a common implementation, but i think this should happen through the spec defined in https://opendev.org/zuul/zuul/src/branch/master/doc/source/reference/developer/specs/kubernetes-operator.rst21:34
tristanCjosefwells: for example, i've proposed to extend the api to support custom secret available in job here: https://review.opendev.org/70663921:34
*** jamesmcarthur has joined #zuul21:36
josefwellsI just stumbled on it today when I had some time, I'm not totally up on this stuff, operators are new to me, but I know I want any services running in our k8s cluster and not on a server I manage21:41
josefwellsglad to bring it to your attention then21:41
mordredjosefwells: we have sadly not been able to get the folks who worked on that to engage with us directly very much21:42
mordredjosefwells: I'd definitely look at zuul/zuul-operator that tristanC has been driving if you're interested in that route21:42
tristanCjosefwells: i think we are all mostly new to operators too. Also note that it's not the only way to get zuul in k8s21:42
josefwellsfor sure21:42
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Add CONTRIBUTE file  https://review.opendev.org/70553521:43
tristanCmordred: or corvus: would you minding porting the +Workflow on ^21:43
josefwellsI've been reading the zuul-discuss stuff (a couple months old now), read up on dhall and looked at the code21:43
corvustristanC: done, but also feel free to reapply a +W after a rebase if nothing has changed :)21:44
tristanCcorvus: alright, thanks!21:45
tristanCjosefwells: that's good to hear. I think the current code merged in the zuul-operator is a good foundation, but note that it is missing some critical feature like a proper database and zookeeper setup.21:47
tristanCplease let me know if you need help get started. hopefully the instructions in the upcoming CONTRIBUTE file are good enough: https://review.opendev.org/#/c/705535/4/CONTRIBUTE.md21:50
corvusyeah, help on development and testing is welcome, but we're not quite ready to promise stable production :)21:53
*** sgw has quit IRC21:54
corvustristanC: sorry, the fedora30 thing has eaten most of the day; let's pick up zk auth/tls stuff next week?21:54
tristanCcorvus: sure, i was about to stop for the week. have a good week end!21:56
openstackgerritMerged zuul/zuul-operator master: Add CONTRIBUTE file  https://review.opendev.org/70553522:03
*** jamesmcarthur has quit IRC22:25
*** jamesmcarthur has joined #zuul22:33
*** jamesmcarthur has quit IRC22:42
*** jamesmcarthur has joined #zuul22:43
*** jamesmcarthur has quit IRC22:43
*** erbarr has quit IRC22:55
*** hashar has quit IRC23:01
openstackgerritIan Wienand proposed zuul/nodepool master: Dockerfile: add lsb-release  https://review.opendev.org/71307923:18
*** zxiiro has quit IRC23:19
*** sgw has joined #zuul23:19

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!