ianw | "ImportError: libre2.so.0: cannot open shared object file: No such file or directory" | 00:11 |
---|---|---|
ianw | it never ends | 00:11 |
*** rlandy has quit IRC | 00:17 | |
*** tosky has quit IRC | 00:18 | |
ianw | i only have libre2.so.0a.0.0 | 00:19 |
clarkb | ianw: this is running zuul locally? | 00:19 |
clarkb | the re2 stuff should be reasonably well captured in bindep I thought | 00:19 |
ianw | trying to run unittests from tox | 00:20 |
ianw | yeah, i think i have all that ... | 00:20 |
ianw | $ ldd ./.tox/py37/lib/python3.7/site-packages/_re2.cpython-37m-x86_64-linux-gnu.so | 00:20 |
ianw | linux-vdso.so.1 (0x00007fffad3a0000) | 00:20 |
ianw | libre2.so.0 => not found | 00:20 |
ianw | it seems like maybe it's come from a wheel? | 00:21 |
*** erbarr has quit IRC | 00:22 | |
ianw | uninstalling it ,then ".tox/py37/bin/pip install --no-binary :all: fb-re2" seems to have it working now :/ | 00:23 |
openstackgerrit | Ian Wienand proposed zuul/zuul master: [dnm] unit test to see if jobs run when nodes are updated https://review.opendev.org/712821 | 00:25 |
*** jamesmcarthur has joined #zuul | 00:27 | |
*** armstrongs has joined #zuul | 00:34 | |
*** armstrongs has quit IRC | 00:43 | |
*** jamesmcarthur has quit IRC | 00:44 | |
*** jamesmcarthur has joined #zuul | 00:47 | |
*** Goneri has quit IRC | 01:15 | |
*** jamesmcarthur has quit IRC | 01:17 | |
ianw | ok, pebkac as suspected and it's my syntax error that led me down the wrong path | 01:45 |
*** swest has quit IRC | 02:12 | |
*** jamesmcarthur has joined #zuul | 02:25 | |
*** swest has joined #zuul | 02:27 | |
*** jamesmcarthur has quit IRC | 02:47 | |
*** bhavikdbavishi has joined #zuul | 03:25 | |
*** jamesmcarthur has joined #zuul | 03:46 | |
*** jamesmcarthur has quit IRC | 04:00 | |
*** bolg has quit IRC | 04:39 | |
*** bolg has joined #zuul | 05:11 | |
*** evrardjp has quit IRC | 05:35 | |
*** evrardjp has joined #zuul | 05:36 | |
*** dpawlik has quit IRC | 06:37 | |
*** dpawlik has joined #zuul | 06:55 | |
*** dpawlik has quit IRC | 07:10 | |
*** dpawlik has joined #zuul | 07:16 | |
*** Defolos has joined #zuul | 07:56 | |
*** jcapitao has joined #zuul | 07:59 | |
*** hashar has joined #zuul | 08:31 | |
*** harrymichal has joined #zuul | 08:36 | |
*** tosky has joined #zuul | 08:46 | |
*** jpena|off is now known as jpena | 08:53 | |
*** sgw has quit IRC | 10:04 | |
*** bhavikdbavishi has quit IRC | 10:52 | |
*** saneax has quit IRC | 11:12 | |
*** harrymichal has quit IRC | 11:18 | |
*** saneax has joined #zuul | 11:25 | |
*** sanjayu_ has joined #zuul | 11:28 | |
*** avass is now known as Guest97446 | 11:28 | |
*** avass has joined #zuul | 11:28 | |
tobiash | clarkb, ianw: fyi libre2 in latest fedora is incompatible with prebuilt wheel of fb-re2 | 11:30 |
*** saneax has quit IRC | 11:30 | |
*** harrymichal has joined #zuul | 11:33 | |
*** jcapitao is now known as jcapitao_lunch | 11:38 | |
*** zxiiro has joined #zuul | 12:08 | |
*** rlandy has joined #zuul | 12:11 | |
*** bhavikdbavishi has joined #zuul | 12:24 | |
openstackgerrit | Merged zuul/zuul master: Be explicit about source of base images https://review.opendev.org/712772 | 12:26 |
*** jpena is now known as jpena|lunch | 12:30 | |
openstackgerrit | Merged zuul/zuul master: Remove stretch-backports from docker build https://review.opendev.org/712737 | 12:35 |
*** harrymichal has quit IRC | 12:45 | |
*** harrymichal has joined #zuul | 12:45 | |
openstackgerrit | Tobias Henkel proposed zuul/zuul master: Defer setting build pause to event queue https://review.opendev.org/712939 | 12:49 |
tobiash | zuul-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 jcapitao | 13:05 | |
avass | hmm, 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 that | 13:13 |
tobiash | avass: gerrit or github? | 13:13 |
avass | gerrit | 13:15 |
tobiash | hrm, I don't see a reason why this wouldn't work | 13:15 |
*** armstrongs has joined #zuul | 13:16 | |
tobiash | I guess logs of the event that should have worked would help | 13:16 |
avass | I... don't have that | 13:17 |
armstrongs | hey 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 the | 13:19 |
armstrongs | format should be | 13:19 |
armstrongs | are there any examples i could look at you know of? | 13:20 |
armstrongs | http://paste.openstack.org/show/790666/ as an example | 13:22 |
tobiash | armstrongs: that's our trigger config of the check pipeline: http://paste.openstack.org/show/790668/ | 13:29 |
*** avass has quit IRC | 13:31 | |
armstrongs | thanks will give that a go | 13:31 |
armstrongs | :) | 13:31 |
*** Goneri has joined #zuul | 13:33 | |
armstrongs | tobiash: that works thanks so much | 13:34 |
*** jpena|lunch is now known as jpena | 13:35 | |
fungi | when 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 jobs | 13:37 |
*** harrymichal has quit IRC | 13:40 | |
fungi | armstrongs: 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.action | 13:43 |
fungi | is it still "experimental" from zuul's perspective? | 13:43 |
tobiash | fungi: https://zuul-ci.org/docs/zuul/reference/drivers/github.html#value-pipeline.trigger.%3Cgithub%20source%3E.action.requested | 13:44 |
tobiash | fungi: I guess we should add a check_run based reference pipeline | 13:45 |
fungi | oh, yep, i misread. so what is the check parameter then? clearly a filter pattern for the event, but that's what i'm not finding | 13:45 |
*** avass has joined #zuul | 13:46 | |
tobiash | fungi: 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 there | 13:46 |
fungi | and 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 |
tobiash | fungi: 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 events | 13:49 |
zbr | minor nit https://review.opendev.org/#/c/708642/ | 13:49 |
tobiash | e.g. we combine zuul with other github apps that set a status (WIP bot for example) and react on those events as well | 13:50 |
fungi | got 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 for | 13:51 |
armstrongs | its not documented i looked at the code to get it :) | 13:51 |
armstrongs | should say code review | 13:52 |
*** harrymichal has joined #zuul | 13:56 | |
openstackgerrit | Jan Kubovy proposed zuul/zuul master: WIP: Separate connection registries in tests https://review.opendev.org/712958 | 14:06 |
*** bolg has quit IRC | 14:09 | |
*** y2kenny has joined #zuul | 14:09 | |
*** noonedeadpunk has joined #zuul | 14:23 | |
noonedeadpunk | hi 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 |
noonedeadpunk | Like 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 |
clarkb | noonedeadpunk: debian traditionally has a large range of python available. Ubuntu bionic has 2.7, 3.6, 3.7, and 3.8 | 14:26 |
clarkb | all without a ppa | 14:26 |
noonedeadpunk | just debian has them in sid only? | 14:27 |
noonedeadpunk | and in buster it's kinda... missing 3.6 I think... | 14:28 |
noonedeadpunk | clarkb: so you generally suggest using ubuntu instead? | 14:28 |
mordred | noonedeadpunk: our default nodes are all ubuntu | 14:30 |
mordred | I don't know that we "recommend" ubuntu over debian broadly - but it works well for us for the most part for base CI nodes | 14:31 |
clarkb | noonedeadpunk: 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 ubuntu | 14:32 |
mordred | noonedeadpunk: 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 distro | 14:32 |
mnaser | mordred: i was actually thinking about this last night, i think the hard part with that is having to override the all the base jobs somehow | 14:34 |
y2kenny | Hello. 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 |
y2kenny | I am thinking of using Job require/provide but that doesn't seem quite right | 14:34 |
mnaser | and then i wonder the cost of having a new vm spin up from scratch vs pyenv building python ends up being the same time | 14:34 |
clarkb | https://wiki.debian.org/Python#Supported_Python_Versions its a bit more restricted than I thought | 14:34 |
clarkb | y2kenny: we do use replication, but zuul always pulls from gerrit to avoid needing to wait for replication | 14:35 |
fungi | noonedeadpunk: 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 on | 14:36 |
fungi | we've not generally expected to be able to test all python versions on the same platform | 14:36 |
mnaser | noonedeadpunk: 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 debian | 14:37 |
y2kenny | clarkb: 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 |
mnaser | y2kenny: the executor generally caches a copy of the source code so its not a full pull every tim | 14:40 |
clarkb | y2kenny: we havent had problems with the traffic because zuul keeps caches which reduces the overhead | 14:40 |
clarkb | if you find that you do need to leverage replication with zuul that is probably something that can be added, but isnt there now | 14:41 |
mordred | yeah - for the most part zuul is only fetching new refs after the initial clones | 14:41 |
mordred | so in a warm system it's not expensive | 14:41 |
y2kenny | ok. 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 lot | 14:41 |
mordred | the nodes themselves don't clone or fetch anything | 14:41 |
mordred | the 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 low | 14:42 |
y2kenny | this is great, thanks! | 14:43 |
fungi | mnaser: 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 both | 14:44 |
Shrews | ugh, tfw you include 'self' when calling a method on an object and it takes you all morning to find it | 14:53 |
*** harrymichal has quit IRC | 14:58 | |
*** harrymichal has joined #zuul | 14:59 | |
mordred | Shrews: moar koffie | 14:59 |
*** avass has quit IRC | 15:10 | |
*** jamesmcarthur has joined #zuul | 15:29 | |
clarkb | zbr: can you check comments on https://review.opendev.org/#/c/708642/17 I think I may need a bit more clarification on that | 15:42 |
openstackgerrit | Sorin Sbarnea proposed zuul/zuul-jobs master: DNM: rebase unittests to base-minimal-test https://review.opendev.org/712985 | 15:45 |
zbr | clarkb: tbh, i am aware of any case where failed_when: false requires an ignore_errors. | 15:52 |
zbr | in fact, it may be possible that ignore_errors could ignore a module failure (trace), which failed_when does not. | 15:52 |
zbr | which makes use of failed_when even more to be desired | 15:53 |
zbr | but i need to test to get confirmation | 15:53 |
zbr | but you described the issue very well: ignore_errors makes the recording hard to read | 15:53 |
zbr | they soon end-up looking like the xmas tree | 15:54 |
*** sugaar has quit IRC | 15:55 | |
corvus | tristanC: 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 |
clarkb | zbr: ok, in that case I think we should remove that extra ignore_errors and only use failed_when there | 15:57 |
zbr | sure, i will do it, but that change is near the bottom of my prio list :D | 15:57 |
corvus | tristanC: it uses jdk8; i'll just try to move zk-ca to run on a different host | 15:59 |
openstackgerrit | Clark Boylan proposed zuul/nodepool master: Switch min TLS version to 1.1 in the docker images https://review.opendev.org/712997 | 15:59 |
clarkb | fungi: ianw ^ fyi I think that is what fungi is saying will fix that for us | 15:59 |
corvus | clarkb: is that something we do in opendev? (perhaps by virtue of running on xenial?) | 16:00 |
clarkb | corvus: no thats something rackspace does by virtue of we don't know | 16:00 |
*** jamesmcarthur has quit IRC | 16:00 | |
clarkb | or do you mean why does it work in production today? | 16:00 |
corvus | clarkb: er, i don't understand why that's necessary then | 16:00 |
corvus | yes that | 16:00 |
clarkb | yes, I think ubuntu isn't setting that high of a minimum version | 16:01 |
fungi | yeah, we're not running on a new enough distro to have set tls 1.2 as its minimum | 16:01 |
fungi | and rackspace's api endpoint doesn't support tls 1.2 (yet at least) | 16:01 |
clarkb | fwiw ubuntu doesn't seem to set the value at all | 16:01 |
clarkb | so likely depends on whatever they compile into ssl | 16:02 |
fungi | entirely possible ubuntu is more concerned with backward compatibility | 16:02 |
clarkb | mordred: corvus can we indent the blocks that happen after each FROM? | 16:02 |
clarkb | its actually pretty hard to pick out where each image begins and ends in that file | 16:03 |
corvus | clarkb: how about ========================================== instead? | 16:03 |
clarkb | corvus: I think that would work too | 16:03 |
clarkb | I'll try that. Basically need some sort of visual cue | 16:03 |
*** jamesmcarthur has joined #zuul | 16: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 |
clarkb | fungi: corvus "The value None will disable the limit" says the manpage for that file. That means ubuntu isn't setting a lower bound | 16:04 |
corvus | clarkb, fungi: looks like it's more like debian *is* setting a default: https://github.com/openssl/openssl/blob/master/apps/openssl.cnf | 16:07 |
fungi | yep | 16:07 |
openstackgerrit | Clark Boylan proposed zuul/nodepool master: Add visual dividers for each image in Dockerfile https://review.opendev.org/713002 | 16:07 |
clarkb | corvus: ^ I think that actually does help quite a bit | 16:07 |
corvus | that's 2 distros making 2 annoying changes to openssl.cnf in 2 days. grumble. | 16:07 |
fungi | https://salsa.debian.org/debian/openssl/-/blob/debian/unstable/debian/patches/Set-systemwide-default-settings-for-libssl-users.patch | 16:08 |
fungi | for the record | 16:08 |
mordred | corvus: they're "adding value" | 16:10 |
fungi | i too disagree with general purpose distros questioning upstream's position on what is or isn't a secure default | 16:10 |
fungi | it's not like openssl is developed in a vacuum | 16:11 |
fungi | you'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 did | 16:12 |
clarkb | fungi: ssh they might hear you :) | 16:12 |
fungi | oh, it's okay, i'm encrypting this conversation with nacl instead | 16:13 |
fungi | (jk, not really) | 16:13 |
clarkb | fungi: re md5 I believe most modern browsers are no longer trusting md5 so we are likely safe there | 16:16 |
clarkb | basically if chrome stops doing it you're forced to follow | 16:17 |
fungi | yeah, 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 certs | 16:18 |
clarkb | huh | 16:18 |
fungi | i think the latest 3.5 point releases have since fixed their test fixures | 16:19 |
fungi | i haven't checked lately | 16:19 |
*** jcapitao is now known as jcapitao_afk | 16:25 | |
*** openstackgerrit has quit IRC | 16:31 | |
corvus | fungi: all the zk docs use "SSL". should i name the config file entries "ssl_cert" or "tls_cert" ? | 16:35 |
*** hashar has quit IRC | 16: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 |
fungi | it's potato potato... technically it's a x.509 cert | 16:37 |
*** sgw has joined #zuul | 16:37 | |
fungi | it can be used to authenticate a variety of protocols | 16:37 |
corvus | seems like as long as the tls family is among the protocols that are supported, it's probably more correct? | 16:38 |
fungi | per rfc 2246 tls 1.0 is based on ssl v3 so you can call it either | 16:39 |
fungi | i'd consider "tls" a more specific term than "ssl" in this case | 16:39 |
fungi | so yeah, if all you're using it for is tls then calling it by that name is correct and more precise than calling it ssl | 16:40 |
fungi | (which would still also be correct, just slightly more vague) | 16:40 |
corvus | https://www.eclipse.org/jetty/documentation/current/configuring-ssl.html | 16:40 |
corvus | that suggests they're keeping up with the latest tlses (as expected) | 16:41 |
corvus | and sslv3/tls1.0 are not supported by default | 16:41 |
corvus | so... technically 'tls' then | 16:42 |
fungi | these days, pedantry aside, the terms ssl and tls are used synonymously so whichever you like is fine really | 16:42 |
corvus | yeah, 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 aside | 16:43 |
fungi | in 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 |
corvus | i was looking for a way stronger opinion :) | 16:44 |
fungi | i 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 it | 16:44 |
clarkb | I 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 recognizable | 16:45 |
fungi | tls 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 protocols | 16:45 |
fungi | but 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 #zuul | 16:52 | |
*** jcapitao_afk is now known as jcapitao | 16:53 | |
*** openstackgerrit has joined #zuul | 17:00 | |
openstackgerrit | James E. Blair proposed zuul/zuul master: Add TLS support for ZooKeeper https://review.opendev.org/712531 | 17:00 |
openstackgerrit | James E. Blair proposed zuul/zuul master: Use ZK TLS in quickstart https://review.opendev.org/712817 | 17:00 |
corvus | tristanC: ^ that corrects an error with zuul-web, which i found when running the quickstart. i think it should be working now. | 17:01 |
tristanC | corvus: i'll get back to that shortly | 17:02 |
corvus | i 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 that | 17:02 |
corvus | er, "done that" == removed the keytool step from zk-ca.sh | 17:02 |
tristanC | ha that's good | 17:02 |
clarkb | mordred: did hacking break even more https://zuul.opendev.org/t/zuul/build/fe16cb58f5ac468d973ac0c429a94e1e/log/job-output.txt#578 ? | 17:03 |
clarkb | looks like maybe we need to pin flake8? | 17:03 |
corvus | clarkb, mordred: i rechecked https://review.opendev.org/712781 after the dep merged, results just came back from that | 17:04 |
tristanC | corvus: have you seen my comment on https://review.opendev.org/#/c/712816/1 ? it seems like the depends on zuul image doesn't work | 17:04 |
corvus | tristanC: oh, nope, i'll look into that, thanks | 17:04 |
clarkb | corvus: ah ok so probably just need that to land | 17: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 #zuul | 17:05 | |
mordred | corvus: I don't understand that failure :( | 17:05 |
corvus | mordred: this one? https://zuul.opendev.org/t/zuul/build/341f13d88ce24a898a10ae9e8d1d1c69 | 17:05 |
mordred | yeah | 17:05 |
corvus | mordred: yeah, i don't either. <shrug> internet? | 17:06 |
mordred | corvus: that's a fair guess | 17:07 |
mordred | corvus: but ... | 17:07 |
mordred | corvus: https://zuul.opendev.org/t/zuul/build/341f13d88ce24a898a10ae9e8d1d1c69/log/job-output.txt#22958 | 17:08 |
mordred | corvus: interrupted system call | 17:08 |
mordred | that would be from echo "deb http://ppa.launchpad.net/openstack-ci-core/vhd-util/ubuntu bionic main" >> /etc/apt/sources.list | 17:08 |
mordred | apparently the >> failed? | 17:08 |
fungi | is /etc/apt/sources.list writeable? | 17:09 |
fungi | that's about the only thing i can think of that can go wrong there | 17:09 |
fungi | or /etc/apt not existing at all or being set unwriteable or untraversable | 17:10 |
clarkb | or the disk filled | 17:11 |
fungi | oh, yep | 17:12 |
clarkb | if the job was on rax / is relatively small | 17:12 |
fungi | or is mounted read-only for some reason | 17:12 |
clarkb | (though I would still be surprised if that was the issue)_ | 17:12 |
corvus | inap | 17:12 |
fungi | oh, or selinux or apparmor rules rejectnig write | 17:13 |
fungi | generally almost all of those are conditions i would expect to generate more recognizable errors though | 17:14 |
fungi | "interrupted system call" means something generated a signal | 17:14 |
fungi | like maybe a timeout watcher | 17:15 |
fungi | or the server was in the process of shutting down | 17:16 |
*** Defolos has quit IRC | 17:17 | |
mordred | yeah. like - it only happened on the -tips job - so maybe it really just was an unlucky something | 17:19 |
fungi | right, i have a feeling it won't be reproducible (but if it is, maybe set an autohold) | 17:20 |
*** y2kenny has quit IRC | 17:21 | |
*** dpawlik has quit IRC | 17:30 | |
*** evrardjp has quit IRC | 17:35 | |
*** evrardjp has joined #zuul | 17:36 | |
*** sshnaidm|afk has quit IRC | 17:37 | |
openstackgerrit | James E. Blair proposed zuul/zuul-operator master: Use explicit provides/requires for container jobs https://review.opendev.org/712816 | 17:49 |
openstackgerrit | James E. Blair proposed zuul/zuul-operator master: Update to dhall lang v14 https://review.opendev.org/710649 | 17:49 |
openstackgerrit | James E. Blair proposed zuul/zuul-operator master: Add TLS configuration to ZooKeeper service https://review.opendev.org/712759 | 17:49 |
corvus | tristanC: i think i put the requires on the wrong job; that should fix it | 17:49 |
*** armstrongs has quit IRC | 17:50 | |
openstackgerrit | James E. Blair proposed zuul/zuul-operator master: Use explicit provides/requires for container jobs https://review.opendev.org/712816 | 17:51 |
openstackgerrit | James E. Blair proposed zuul/zuul-operator master: Update to dhall lang v14 https://review.opendev.org/710649 | 17:51 |
openstackgerrit | James E. Blair proposed zuul/zuul-operator master: Add TLS configuration to ZooKeeper service https://review.opendev.org/712759 | 17:51 |
corvus | that adds a provides line too (in case we want to "requires: zuul-operator-container-image" in the future) | 17:51 |
*** jamesmcarthur has quit IRC | 17:53 | |
corvus | mnaser: i forwarded your msg to zuul-announce and approved it | 17:53 |
tristanC | corvus: excellentm thanks! | 17:55 |
mnaser | corvus: thank you | 17:55 |
corvus | tristanC: 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#164 | 17:57 |
*** jamesmcarthur has joined #zuul | 17:57 | |
corvus | tristanC: 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 registry | 17:58 |
corvus | tristanC: (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 |
corvus | mordred: 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 |
corvus | Node request <NodeRequest 300-0007905272 <NodeSet [<Node None ('cluster',):centos-7>, <Node None ('launcher',):fedora-30>]>>: failure for nodepool-functional-openshift | 18:04 |
corvus | it kinda looks like opendev is having a thing about fedora-30 now. i will move this to #opendev | 18:05 |
*** jamesmcarthur has quit IRC | 18:05 | |
*** jamesmcarthur has joined #zuul | 18:06 | |
*** jpena is now known as jpena|off | 18:07 | |
*** jcapitao has quit IRC | 18:12 | |
*** hashar has quit IRC | 18:14 | |
*** chandankumar is now known as raukadah | 18:14 | |
*** sanjayu_ has quit IRC | 18:15 | |
corvus | tristanC: 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 IRC | 18:22 | |
*** jamesmcarthur has joined #zuul | 18:22 | |
clarkb | we have centos 8 images | 18:23 |
tristanC | iirc only the nodepool services are running on fedora, we should be able to switch to another system | 18:28 |
tristanC | corvus: 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.txt | 18:29 |
corvus | tristanC: so we could just switch that to ubuntu? | 18:30 |
tristanC | corvus: i think so, let me have a look | 18:31 |
tristanC | well, i'd rather pick centos8 for diversity, but ubuntu should work too | 18:31 |
corvus | it's got to be something with openshift clients | 18:32 |
corvus | i don't think that's an installable package in ubuntu | 18:32 |
tristanC | well, we could use the usual unarchive from upstream release artifact | 18:33 |
openstackgerrit | James E. Blair proposed zuul/nodepool master: WIP test functional-openshift on centos8 https://review.opendev.org/713046 | 18:33 |
fungi | looks like some openshift tools will be in ubuntu 20.04 lts: https://packages.ubuntu.com/openshift so we might eventually be able to use that | 18:34 |
corvus | tristanC: ^ maybe that will work? | 18:34 |
tristanC | corvus: i guess this will be the problematic task: https://opendev.org/zuul/nodepool/src/branch/master/playbooks/nodepool-functional-openshift/pre.yaml#L18 | 18:36 |
tristanC | and i don't know if c8 has zookeeper for https://opendev.org/zuul/nodepool/src/branch/master/playbooks/nodepool-functional-openshift/run.yaml#L12 | 18:36 |
corvus | tristanC: 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 IRC | 18:41 | |
*** jbryce is now known as airship-irc-bot | 19:03 | |
*** airship-irc-bot is now known as jbryce | 19:07 | |
*** harrymichal has quit IRC | 19:20 | |
openstackgerrit | Andreas Jaeger proposed zuul/zuul-jobs master: Use a zuul_* and add an .ansible-lint file https://review.opendev.org/712547 | 19:27 |
*** jamesmcarthur has quit IRC | 19:50 | |
*** jamesmcarthur has joined #zuul | 19:51 | |
*** jamesmcarthur has quit IRC | 19:57 | |
*** jamesmcarthur has joined #zuul | 19:58 | |
openstackgerrit | David Shrewsbury proposed zuul/nodepool master: Stop comparing hostnames to determine ownership https://review.opendev.org/713057 | 19:59 |
*** harrymichal has joined #zuul | 20:05 | |
openstackgerrit | Monty Taylor proposed zuul/nodepool master: Revert "Dockerfile: add support for arbritary uid" https://review.opendev.org/713060 | 20:10 |
openstackgerrit | David Shrewsbury proposed zuul/nodepool master: Stop comparing hostnames to determine ownership https://review.opendev.org/713057 | 20:13 |
clarkb | Shrews: ^ 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 |
clarkb | the 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 IRC | 20:21 | |
Shrews | clarkb: 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 buggy | 20:22 |
clarkb | oh wow I didn't realize the uuids were implemented that long ago ++ I doubt its an issue | 20:23 |
*** hashar has joined #zuul | 20:25 | |
clarkb | I believe the risk to peopel in that situation is that nodepool won't delete things | 20:29 |
clarkb | and they can simply delete things manually in that case (noted on the chagne) | 20:29 |
clarkb | that 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 down | 20:29 |
*** Defolos has joined #zuul | 20:33 | |
*** jamesmcarthur has quit IRC | 20:40 | |
*** jamesmcarthur has joined #zuul | 20:41 | |
*** jamesmcarthur has quit IRC | 20:45 | |
*** jamesmcarthur has joined #zuul | 20:45 | |
*** josefwells has joined #zuul | 21:02 | |
*** jamesmcarthur has quit IRC | 21:05 | |
*** jamesmcarthur has joined #zuul | 21:06 | |
mnaser | https://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 |
mnaser | i.e. i can't have some tenant get access to actions via gsuite, and another one via github | 21:09 |
mnaser | i guess i can define a whole bunch and then use admin-rules that are filtered based on 'iss' | 21:11 |
*** jamesmcarthur has quit IRC | 21:12 | |
josefwells | Hey 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=4 | 21:13 |
*** jamesmcarthur has joined #zuul | 21:13 | |
josefwells | I found the code here: https://github.com/xxiao93/zuul-operator | 21:14 |
josefwells | Thoughts? Any alignment with your zuul-operator work thus far? | 21:14 |
*** jamesmcarthur has quit IRC | 21:15 | |
mordred | josefwells: no - https://opendev.org/zuul/zuul-operator is our zuul operator work | 21:17 |
*** jamesmcarthur has joined #zuul | 21:18 | |
corvus | mnaser: 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-rules | 21:20 |
*** rlandy has quit IRC | 21:21 | |
fungi | josefwells: that was one of several starts at a zuul operator, we're converging on the code in https://opendev.org/zuul/zuul-operator | 21:21 |
corvus | mnaser: i think the expectation is that maybe you'd have 2 authenticators (google and github), then an access rule for each tenant? | 21:22 |
corvus | mnaser: if your reality is different, we should chat with mhu :) | 21:22 |
josefwells | thanks fungi | 21:22 |
mnaser | corvus: 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 thing | 21:23 |
mnaser | and so technically as long as the access rules match on the issuer in tenant config, we'll probably be ok | 21:23 |
*** jamesmcarthur has quit IRC | 21:29 | |
tristanC | josefwells: 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.yaml | 21:33 |
tristanC | josefwells: 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.rst | 21:34 |
tristanC | josefwells: for example, i've proposed to extend the api to support custom secret available in job here: https://review.opendev.org/706639 | 21:34 |
*** jamesmcarthur has joined #zuul | 21:36 | |
josefwells | I 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 manage | 21:41 |
josefwells | glad to bring it to your attention then | 21:41 |
mordred | josefwells: we have sadly not been able to get the folks who worked on that to engage with us directly very much | 21:42 |
mordred | josefwells: I'd definitely look at zuul/zuul-operator that tristanC has been driving if you're interested in that route | 21:42 |
tristanC | josefwells: i think we are all mostly new to operators too. Also note that it's not the only way to get zuul in k8s | 21:42 |
josefwells | for sure | 21:42 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Add CONTRIBUTE file https://review.opendev.org/705535 | 21:43 |
tristanC | mordred: or corvus: would you minding porting the +Workflow on ^ | 21:43 |
josefwells | I've been reading the zuul-discuss stuff (a couple months old now), read up on dhall and looked at the code | 21:43 |
corvus | tristanC: done, but also feel free to reapply a +W after a rebase if nothing has changed :) | 21:44 |
tristanC | corvus: alright, thanks! | 21:45 |
tristanC | josefwells: 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 |
tristanC | please 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.md | 21:50 |
corvus | yeah, help on development and testing is welcome, but we're not quite ready to promise stable production :) | 21:53 |
*** sgw has quit IRC | 21:54 | |
corvus | tristanC: sorry, the fedora30 thing has eaten most of the day; let's pick up zk auth/tls stuff next week? | 21:54 |
tristanC | corvus: sure, i was about to stop for the week. have a good week end! | 21:56 |
openstackgerrit | Merged zuul/zuul-operator master: Add CONTRIBUTE file https://review.opendev.org/705535 | 22:03 |
*** jamesmcarthur has quit IRC | 22:25 | |
*** jamesmcarthur has joined #zuul | 22:33 | |
*** jamesmcarthur has quit IRC | 22:42 | |
*** jamesmcarthur has joined #zuul | 22:43 | |
*** jamesmcarthur has quit IRC | 22:43 | |
*** erbarr has quit IRC | 22:55 | |
*** hashar has quit IRC | 23:01 | |
openstackgerrit | Ian Wienand proposed zuul/nodepool master: Dockerfile: add lsb-release https://review.opendev.org/713079 | 23:18 |
*** zxiiro has quit IRC | 23:19 | |
*** sgw has joined #zuul | 23:19 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!