Thursday, 2018-11-22

SpamapS#FryingImportantFish00:36
*** mordred has quit IRC00:49
openstackgerritTristan Cacqueray proposed openstack-infra/zuul-jobs master: run-test-command: support list in test_command variable  https://review.openstack.org/61088801:23
*** bhavikdbavishi has joined #zuul02:46
*** bjackman has joined #zuul03:22
*** bhavikdbavishi has quit IRC03:33
*** bhavikdbavishi has joined #zuul03:38
*** rlandy|bbl is now known as rlandy04:21
openstackgerritIan Wienand proposed openstack-infra/nodepool master: Add Fedora 29 testing  https://review.openstack.org/61867104:58
bjackmanAre there still bugs related to https://storyboard.openstack.org/#!/story/2002080 ?05:15
bjackmanMy Depends-On only works if I use the deprecated Change-Id format. I may have something misconfigured, only thing I'm sure of is that my connection['gerrit'].baseurl matches the URL I'm putting in my Depends-On field05:18
bjackmanHowever my conncetion['gerrit'].baseurl is very different from my connection['gerrit'].server (former is external URL, latter is just the name of the docker service)05:18
*** chandankumar has joined #zuul05:33
*** chandankumar is now known as chkumar|ruck05:33
tristanCbjackman: what version of gerrit are you using?05:58
bjackmanThe one from the gerritcodereview/gerrit Docker image, looks to be 2.16.rc0-105:59
bjackmanAh yeah which is the latest AFAICS06:00
bjackman(@ tristanC)06:00
tristanCbjackman: perhaps the schema changed, here is what was needed to close the 2002080 story: https://review.openstack.org/433748 and https://review.openstack.org/57715406:01
tristanC(to support gerrit-2.14)06:01
tristanCbjackman: it seems like the gerrit url format changed, what are you using as depends-on url?06:03
bjackmantristanC, So.. my URLs look like "$baseurl/c/$repo/+/1021"06:03
bjackmantristanC, looking in the zuul source looks like the regex is r"/%s(\#\/c\/)?(\d+)[\w]*" % prefix_ui06:04
tristanCbjackman: yeah, that's probably the issue. the regex needs to be updated for '/c/$repo/+/'06:05
bjackmanI wonder if I can get Gerrit to exclude it06:05
bjackmanActually probably better to update zuul to work with gerrit defaults06:06
tristanC(\#\/c\/|c\/.*\/\+\/)? may be enough?06:07
openstackgerritTobias Henkel proposed openstack-infra/nodepool master: Only setup zNode caches in launcher  https://review.openstack.org/61944006:07
bjackman* Slowly turns the regex-parsing crank on my brain *06:07
*** bhavikdbavishi has quit IRC06:07
bjackmantristanC, Yeah that looks about right (although I think you might need brackets around the subexpressions either side of the '|' ??)06:08
bjackmantristanC, At some point I think I'm gona have to get a dev version of zuul up & running so maybe I can test it then06:08
bjackmantristanC, ATM I'm just using the docker images from the registry06:09
openstackgerritTobias Henkel proposed openstack-infra/nodepool master: Fix print-zk tool for python3  https://review.openstack.org/61944106:10
tristanCbjackman: it seems like you should be able to build them locally using pbrx. i don't know how it works though06:10
bjackmantristanC, OK will give that a go at some point, probably have to be next week though.06:15
bjackmanHopefully there's a way to bind-mount your source directory or something06:15
*** bhavikdbavishi has joined #zuul06:46
*** bhavikdbavishi has quit IRC06:51
*** bjackman has quit IRC07:01
*** quiquell|off is now known as quiquell07:01
*** bjackman has joined #zuul07:01
openstackgerritTristan Cacqueray proposed openstack-infra/nodepool master: Implement an OpenShift resource provider  https://review.openstack.org/57066707:02
openstackgerritTristan Cacqueray proposed openstack-infra/nodepool master: Implement an OpenShift Pod provider  https://review.openstack.org/59033507:02
openstackgerritIan Wienand proposed openstack-infra/nodepool master: Add Fedora 29 testing  https://review.openstack.org/61867107:08
*** bjackman has quit IRC07:11
*** pcaruana has joined #zuul07:22
*** bjackman has joined #zuul07:27
*** eumel8 has joined #zuul07:51
*** bhavikdbavishi has joined #zuul08:12
*** gtema has joined #zuul08:17
*** ParsectiX has joined #zuul08:23
*** jpena|off is now known as jpena08:37
bjackmantristanC, found a lazy way to build a container with my own copy of the zuul source, just made a Dockerfile that uses the default zuul/zuul-scheduler image then overwrites the Python package: https://paste.gnome.org/p5detyvee08:59
*** hashar has joined #zuul09:01
tristanCbjackman: that's smart :)09:02
*** mrhillsman is now known as openlab09:19
*** openlab is now known as mrhillsman09:20
quiquellbjackman: that's cool09:29
quiquelltristanC, bjackman: I am running executor + merger in the same node, runing them at differnt nodes can reduce start time at jobs ?09:30
quiquellI mean parallelizing clones per project and the like09:30
quiquellLike having multiple mergers09:31
tobiashcorvus, Shrews, clarkb: just found out that our launcher registration in zk is broken. We call it /nodepool/launchers but what we actually register is each pool with the supported labels of the whole launcher. I see two ways to solve it. Either really register pools with all supported labels or really register launchers.09:31
tobiashcorvus, Shrews, clarkb: I think what we want is to actually register the launcher right?09:31
tristanCtobiash: not sure if it's related, but node request allocation to provider currently goes through each provider, even if the provider doesn't have the label09:37
tristanCwhich makes the declined_by list hard to investigate when you have many providers with different labels09:38
tobiashtristanC: that's defined behavior, a node request is marked as failed once *all* providers declined09:39
tristanCcouldn't we just check all providers actually providing the labels? :)09:40
tobiashthat requires a more complicated algorithm to determine if a node request failed09:42
tobiashthat would probably be a tradeoff between many declines and more complicated failure detection09:42
tobiashbut I could see some benefit in changing this because it turns out that lock,decline,lock can produce quite some load on the system if you have many providers and pools09:45
tobiashShrews, corvus: what do you think about this idea? ^09:45
tristanCtobiash: yes, so back to your original suggestion, shouldn't we need to register pool and labels?09:46
tobiashtristanC: the original idea was to register the launcher. Your idea above would require that we register pools with labels too (that's exactly what we do now but with the wrong name).09:47
tobiashso maybe we should 'fix' launcher registration and add pool registration if we want to change the decline algorithm09:48
tobiashfor the record, this was the change that introduced the launcher registration: https://review.openstack.org/54837609:50
tobiashso judging from the commit message this really was meant to be the launcher09:51
*** electrofelix has joined #zuul09:52
tobiashoh actually the current decline algorithm treats the registered launchers as pools10:04
*** bhavikdbavishi has quit IRC10:10
*** bjackman has quit IRC10:10
*** ianychoi has quit IRC10:25
*** jpena is now known as jpena|off10:37
*** bhavikdbavishi has joined #zuul10:41
*** bjackman has joined #zuul10:48
*** toabctl has joined #zuul10:54
*** sshnaidm|afk is now known as sshnaidm10:54
quiquellI have a Connetion reset by peer at zuul_log.streamer10:55
quiquellExactly here https://github.com/openstack-infra/zuul/blob/33699fa31689b2b40cff5b103a55f7cbd80fc096/zuul/lib/log_streamer.py#L13910:55
quiquelltobiash, tristanC: ^ any idea what can produce it ?10:56
tristanCquiquell: does the instance accept tcp connection on 19885?10:58
*** bhavikdbavishi has quit IRC11:01
quiquelltristanC: Yep, openned the port at my openstack cloud11:01
quiquelltristanC: I see the "shell" ansible module working11:01
quiquelltristanC: Do wee need something else special about the port ? is just a tcp ingress port ?11:02
tristanCquiquell: oh, so the shell command works but it fails after?11:03
quiquelltristanC: Something like that, it also get stuck there and zuul job never ends11:05
quiquelltristanC: If I go to the node, I see different playboks being executed11:05
quiquelltristanC: Me having the rest by peer is bad but the issue is how zuul is handling it having the job stuck11:06
tristanCquiquell: that's odd, is this happening with the static node from the quickstart?11:06
quiquelltristanC: nope openstack node11:06
quiquelltristanC: I am connecting to my rdo personal tenant11:07
tristanCthere shouldn't be multiple playbooks being executed on an openstack node11:07
tristanCperhaps your job is changing the firewall or killing the console log stream?11:07
*** zigo has joined #zuul11:08
tristanCquiquell: you say the job is getting stuck, maybe there is something going on with docker-compose outbound connection from the zuul-executor container?11:09
tristanCis there connection error in executor.log?11:09
quiquelltristanC: I have this https://paste.fedoraproject.org/paste/bIJF03NhF5nUuL1iiG-eAg11:14
quiquelltristanC: between good line and reset by pair are 5 idle minutes... maybe there is a timeout11:14
tristanCquiquell: perhaps it's because of https://success.docker.com/article/ipvs-connection-timeout-issue ?11:16
quiquelltristanC: Could be, so I have to change the systctl.conf of the container ?11:17
tristanCquiquell: probably from the host, i don't know much how docker actually works...11:18
quiquelllooks like apine is tuning the tcp stuff11:19
tristanCdoes docker-compose uses ipvs?11:20
quiquelltristanC: no, but the sysctl is valid I can set it in the executor11:21
quiquellgoing to try it11:21
*** dkehn has quit IRC11:22
*** hashar has quit IRC11:24
bjackmanDo I have the right remote URL to submit patches here: git://git.openstack.org/openstack-infra/zuul ?11:27
*** ianychoi has joined #zuul11:31
AJaegerbjackman: you submit to gerrit via git-review, see http://docs.openstack.org/infra/manual/developers.html - but that's the rightr URL for the Zuul repo11:33
AJaegerbjackman: http://git.openstack.org/cgit/openstack-infra/zuul/tree/README.rst#n3311:34
bjackmanYeah I'm getting "fatal: remote error: access denied or repository not exported: /openstack-infra/zuul". Will scour the docs to see if I've missed something11:34
openstackgerritFabien Boucher proposed openstack-infra/nodepool master: Add ip-pool option to the openstack provider  https://review.openstack.org/61952511:38
fboShrews: pabelanger hi I was surprised to not found an option to set the floating ip pool in the openstack provider pool defition. I got trouble in a new cloud I was tested where multiple floating ip pool were available to the tenant.11:44
tobiashfbo: you can set this in the clouds.yaml11:44
fbotobiash: how ?11:45
tobiashlet me dig it up11:45
tobiashfbo: https://review.openstack.org/60261811:46
tobiashyou probably want nat_source11:46
tobiashbut that's very new in the openstacksdk so you should check if you have a new-enough version11:47
fbotobiash: ok I have the 0.19 that should be fine. I don't see any doc in the patch. I'm testing it11:53
fboI guess I only add nat_source: <floating-ip-pool-name> in clouds.yaml11:54
openstackgerritBrendan proposed openstack-infra/zuul master: Update change URL for Gerrit v2.16  https://review.openstack.org/61953311:55
AJaegerbjackman: worked? ^ Great!11:55
tristanCbjackman: gg :)11:56
bjackmanGot there in the end :D11:57
bjackmantristanC, I stole your regex BTW, is there a way to credit you? In linux I've put a "Suggested-By"11:58
tobiashfbo: yes, that should work12:00
tristanCbjackman: oh that's ok. In openstack we use "Co-Authored-By: ", but no need here :)12:01
fbotobiash: It does not work. I added it in clouds.yaml clouds.<name>.nat_source: <name>12:01
fboI see in the nodepool launcher log (DEBUG) that a POST is done on os-floating-ips endpoint on the wrong floating ip pool (not the one I specified)12:03
fbotobiash: With the patch I submitted the ip-pool is took in account and the right pool is used. Also advantage is the setting is by provider's pool not provider global.12:04
bjackmanSo, I'd to get the Gerrit driver to optionally behave a bit more like the Github driver in that it doesn't need to run every individual commit through every pipeline (my team has lots of pressure on test resources due to specialised HW)12:29
bjackmanObviously the semantics of Gerrit are pretty different from Github so there's some discussion to be had on what that behaviour would even look like.12:29
bjackmanWhat's the best way to start that discussion? Mailing list? Or are people happy discussing that kind of thing here"12:29
tristanCbjackman: how would you like zuul to behave then?12:31
tristanCbjackman: there has been discussion to be able to skip the gate pipeline when check ran on the same state as when approved (e.g. if no change got merged after the check result)12:33
bjackmantristanC, well I'm not at all sure of the details but what I ultimately want is to run check against every commit, but "chunk" the gate pipeline wrt. commits. So if you submit 10 commits in a single stack, it can just run the gate pipeline once against the whole stack12:35
bjackmanOne way I can see that behaving is that the changes don't run in the gate pipeline until the whole patch stack has the pipeline.require.gerrit satisfied12:37
bjackmanThen it just runs the tip of the stack12:37
tristanCbjackman: is the stack part of a single project?12:38
bjackmanYeah I'd imagine if you submitted changes to multiple projects it would consider them as multiple stacks12:38
bjackmantristanC, so I think when I say "stack" I mean what Gerrit calls a "relation chain" and not the "same topic" or "submitted together"12:40
tristanCbjackman: that's an interesting idea, it may be possible to implement it without a major refactor, but you should ask corvus, or maybe write it down the mailing list12:41
bjackmantristanC, OK I will send a little proposal to the mailing list as I'm heading off soon (UTC+7).12:44
*** gtema has quit IRC12:45
*** hashar has joined #zuul12:48
quiquelltristanC: after seting the tcp keepalive, looks like it's working :-)12:59
quiquelltristanC: you can set it up in the docker-compose so maybe you guys want it at zuul quickstart12:59
tristanCquiquell: nice13:00
*** hashar has quit IRC13:21
*** gtema has joined #zuul13:37
*** bjackman has quit IRC13:41
*** hashar has joined #zuul13:45
*** pcaruana has quit IRC13:50
*** dkehn has joined #zuul13:56
*** chkumar|ruck has quit IRC14:02
*** nilashishc has joined #zuul14:04
*** rfolco has quit IRC14:15
*** rfolco has joined #zuul14:17
*** pcaruana has joined #zuul14:25
quiquelltristanC: now I don't havate the tcp issue but log streaming is not closing https://paste.fedoraproject.org/paste/NJPokn-PbQpv0vYpy-nL1Q14:33
quiquelltristanC: But don't know if it causes the 'ERROR'14:35
tobiashquiquell: did you start the zuul_stream module in your base job?14:37
openstackgerritTobias Henkel proposed openstack-infra/nodepool master: Add second level cache of nodes  https://review.openstack.org/61902514:37
openstackgerritTobias Henkel proposed openstack-infra/nodepool master: Add second level cache to node requests  https://review.openstack.org/61906914:37
openstackgerritTobias Henkel proposed openstack-infra/nodepool master: Only setup zNode caches in launcher  https://review.openstack.org/61944014:37
openstackgerritTobias Henkel proposed openstack-infra/nodepool master: Asynchronously update node statistics  https://review.openstack.org/61958914:37
quiquelltobiash: I run "start-zuul-console"14:39
quiquelltobiash: at pre14:39
quiquelltobiash: this is it ?14:39
tobiashquiquell: yes, that was what I meant14:39
* tobiash keeps forgetting this name14:40
tobiashquiquell: is that a shell/command task on a remote host?14:40
quiquelltobiash: but looking at code does not look related to the job failing, is just a message at cleanup14:40
quiquelltobiash: yep14:40
tobiashwith ssh connection?14:40
quiquelltobiash: yep14:40
tobiashhrm14:40
quiquelltobiash: Looking here https://github.com/openstack-infra/zuul/blob/5ae158a4f65cb4e3ed1558e9e12a36b021386340/zuul/ansible/callback/zuul_stream.py#L28314:41
quiquelltobiash: It cannot break the job, it's just a message about linguering stuff14:41
tobiashyes, so if the console stream is missing you might want to check the buildlog.json file14:41
tobiashthis often contains more information if log streaming had a problem14:41
tobiashthe log streaming is only used for the buildlog.txt file and live streaming14:42
quiquelltobiash: You right found it, I don't have it at .txt because log stream is broken but, I see the task that fails14:44
quiquelltobiash: thanks14:44
quiquelltobiash: Question is why log streamer get bad14:45
tobiashquiquell: the zuul action module sends an exit code via the log stream. That is the stop indication the executor waits for.14:46
tobiashquiquell: so the interesting part would be, is there an error in the ansible module so it doesn't send it?14:46
tobiashquiquell: are you able to share the part of the json with the failed task?14:46
tobiashquiquell: just to double check, do you have this problem for all shell/command tasks or just for this one?14:47
* quiquell peparing a pastbinb14:49
quiquelltobiash: https://paste.fedoraproject.org/paste/XI0koy2neiDuggiVs0hh4g14:49
quiquelltobiash: it's huge14:49
quiquelltobiash: look for "TASK [standalone : Lint playbooks]"14:50
quiquelltobiash: The failure is expected and legit14:50
quiquelltobiash: that's why zuul is failing, but I don't see it at .log14:50
quiquell.txt I mean14:50
*** quiquell is now known as quiquell|off14:53
quiquell|offtobiash: Have to drop now14:54
quiquell|offtobiash: I will read the stuff tomorrow in case you find something14:54
quiquell|offtobiash: thanks a lot !!!14:54
*** bhavikdbavishi has joined #zuul14:55
evrardjpI am curious about the isolation of the pre-run and run plays. If I set_fact in a pre-run, will the fact be available/set on the 'run' play?15:01
dmsimardevrardjp: it won't15:03
dmsimardevrardjp: that's not a zuul thing, that's an ansible thing15:03
dmsimardevrardjp: variables do not carry from one play to the next, even if it's two plays in the same playbook15:03
evrardjpthat's not true , except if that changed15:04
dmsimardis it ?15:04
evrardjpyou can define it in a play, it will be accessible in next play of the same playbook15:04
evrardjp(so you have to keep the same runner)15:04
dmsimardah, I guess you're right15:04
dmsimardbut they definitely wouldn't carry across different playbooks15:04
evrardjpofc it is dependning on where you set said fact :)15:05
evrardjpthat's true15:05
dmsimardmaybe they would carry with import_playbook but not through different ansible-playbook executions for sure15:05
evrardjpso that's why I am asking if pre-run run and post-run are basically 'assembled' into a a run of a runner, or if they spawn different runners15:05
dmsimardzuul currently runs a single ansible-playbook execution per playbook15:05
evrardjpok15:05
dmsimarddifferent15:05
evrardjpthat clarifies it :)15:05
evrardjpyeah so that won't work15:06
evrardjpthanks!15:06
dmsimardwhat are you trying to do ?15:06
evrardjpweird stuff again :)15:06
tobiashevrardjp: if you want to do that you currently need to dump the vars to disk and load them in the next playbook15:06
evrardjptobiash: yeah that would do the trick15:06
dmsimardI wonder if ara_record could be used for this15:06
dmsimardyou'd still need a way to refer to the previous playbook or something15:07
evrardjpdmsimard: I wanted to re-use a single playbook: defining a parent job with pre-run and run, and a child job which defined another pre-run, so it would automatically alter behavior of run without changing code of run15:07
evrardjpbasically adding extra tasks in between conditionally on jobs15:08
evrardjpbut I will do this differently :)15:08
dmsimardevrardjp: I've done something like this before iirc15:08
dmsimardlet me check15:08
evrardjpwhat I did was already use the "onion layers" part of zuul to make things more modular, but never use it as an injector of tasks :p15:09
evrardjpnever used*15:09
evrardjpdmsimard: you don't have holidays?15:09
dmsimardCanadian and American thanksgiving are different :)15:09
evrardjpI thought that kind of tradition extended to Canada15:09
dmsimardlike, literally different date15:09
evrardjpI see15:09
evrardjpmakes sense15:10
dmsimardwell, I mean, stores are all over black friday15:10
tobiashquiquell|off: that log looks a bit weird to me, are you running ansible within a command task?15:10
evrardjpdmsimard: even here we have "black friday" at every corner15:10
evrardjpthat doesn't mean ANYTHING.15:10
dmsimardevrardjp: ah, so the way I've done it wasn't with set_fact15:11
dmsimardevrardjp: but rather using vars in the job15:11
dmsimardand job vars carry across all playbooks15:11
evrardjpyeah15:12
evrardjpI have done that already :)15:12
dmsimardtobiash: could evrardjp use zuul_return for passing data from a playbook to the next ?15:13
evrardjpIt was task injection that had my interest, not really var injection. But I guess I can add tasks conditionally and pass a var to trigger that behaviour15:13
dmsimardpabelanger: ^ I think you were doing something like that at one point ?15:13
tobiashdmsimard, evrardjp: currently only to the next job15:13
tobiashto the next job is an open issue15:13
dmsimardtobiash: ah, next job -- not next playbook15:13
evrardjpthat's still interesting15:13
tobiashopen means open for contribution ;)15:13
evrardjpofc15:14
dmsimardoh yeah I remember now15:14
dmsimardwe were trying to dynamically trigger jobs based on the results of a "parent" job15:14
tobiashI think that was already discussed some months ago but I didn't see a patch that add this15:14
evrardjpIs there a doc pointing to this kind of "next job" pipeline?15:14
dmsimardbecause the parent job had business logic15:14
evrardjppipeline is probably the wrong term15:14
evrardjpcertainly the wrong term15:14
*** quiquell|off is now known as quiquell15:15
dmsimardevrardjp: https://zuul-ci.org/docs/zuul/user/jobs.html?highlight=zuul_return#return-values ?15:15
tobiashyes, that describes what you can do with zuul_return15:15
tobiashit's a lot :)15:15
evrardjp:)15:16
evrardjpGives me enough bullets :D15:16
dmsimardtobiash: next step is a zuul_job ansible module which triggers a job through the zuul api :P15:17
evrardjpdmsimard: interesting :)15:19
evrardjpthat's a way to keep things between runs easily :p15:19
tobiashit can at least already used to skip child jobs15:19
quiquelltobiash: Yep, we are not fully integrated with zuulv3 using pure ansible15:37
quiquelltobiash: we have some glue bash code still15:37
*** quiquell is now known as quiquell|off15:49
*** hashar has quit IRC16:10
*** bhavikdbavishi has quit IRC16:19
*** bhavikdbavishi has joined #zuul16:20
*** bhavikdbavishi1 has joined #zuul16:23
*** bhavikdbavishi has quit IRC16:24
*** bhavikdbavishi1 is now known as bhavikdbavishi16:24
*** bhavikdbavishi has quit IRC16:48
*** nilashishc has quit IRC17:38
pabelangerdmsimard: evrardjp: because of the fact cache we enable in zuul, you should be able to use set_fact: foo, cachable: true and the next playbook should get access to it.  However, I haven't actually tried it17:43
pabelangerhttps://docs.ansible.com/ansible/2.5/modules/set_fact_module.html17:43
openstackgerritMarkus Hosch proposed openstack-infra/zuul master: Add config parameters for WinRM timeouts  https://review.openstack.org/61963017:46
dmsimardpabelanger: TIL about cacheable but I'm not convinced that was the intended purpose17:47
dmsimardwhich is okay, I just wonder if we can rely on it17:47
pabelangeractually, These variables will be available to subsequent plays during an ansible-playbook run, but will not be saved across executions even if you use a fact cache.17:48
dmsimardpersisting facts would typically be done through /etc/ansible/facts.d17:49
dmsimardpabelanger: ah, there you go17:49
pabelangernot sure why it wouldn't persist across executions, that is the purpose of the fact cache too17:50
pabelangerI'd give it a test, just to be sure17:50
pabelangerbut yah, facts.d is likely the best way17:51
*** gtema has quit IRC18:07
openstackgerritTobias Henkel proposed openstack-infra/zuul master: Fix manual dequeue of github items  https://review.openstack.org/61927218:39
openstackgerritTobias Henkel proposed openstack-infra/zuul master: Retry queries for commits  https://review.openstack.org/57513718:40
*** electrofelix has quit IRC18:53
tobiashpabelanger: I saw that you abandoned your fedmsg change, shall we close https://storyboard.openstack.org/#!/story/2001350 too?19:08
*** hashar has joined #zuul19:55
tobiashpabelanger: left a comment/question on 59315020:01
openstackgerritMerged openstack-infra/nodepool master: Move k8s install to pre playbook  https://review.openstack.org/61769920:12
openstackgerritMerged openstack-infra/zuul master: Add allowed-triggers and allowed-reporters tenant settings  https://review.openstack.org/55408220:14
openstackgerritMerged openstack-infra/zuul master: encrypt_secret: support self-signed certificates via --insecure argument  https://review.openstack.org/61728120:14
openstackgerritMerged openstack-infra/zuul-jobs master: upload-logs-swift: Turn FileList into a context manager  https://review.openstack.org/59285020:41
openstackgerritMerged openstack-infra/zuul-jobs master: upload-logs-swift: Keep the FileList in the indexer class  https://review.openstack.org/59285120:41
openstackgerritIan Wienand proposed openstack-infra/nodepool master: [wip] Add Fedora 29 testing  https://review.openstack.org/61867120:55
pabelangertobiash: re: fedmsg, I only abandoned it because it seemed some of the fedmsg libraries in fedora were going away.  Given we have mqtt now, I figured we'd just use thta21:15
*** hashar has quit IRC22:14

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