Wednesday, 2020-04-08

mnasers/playbook/image/00:00
mordredclarkb: https://zuul.opendev.org/t/openstack/build/52f37432128747bea37c791194671d7900:03
mordredclarkb: did something go wrong with that playbook update?00:04
mordredmnaser: it does not seem to have run - but I'm looking in to an overall issue there00:05
clarkbmordred: oh I probably need a become00:05
openstackgerritClark Boylan proposed opendev/system-config master: Become root when fixing bridge logging  https://review.opendev.org/71828000:07
mnaseris the opendev pattern: executor adds bridge to inventory and runs playbooks on it?  curious as to why its not adding the host-to-run-things-on (im sure there is logical reasoning)00:07
clarkbmordred: ^ that shouldn't have affected anything about the running of the inner playbook though00:07
clarkbmnaser: our ssh configs don't allow it and we'd need to manage a zuul user on all the servers00:08
mordredclarkb: no - but it affected the _next_ job00:08
clarkbmordred: ah00:08
mordredso we didnt' run the etherpad job because update-system-config failed00:08
mnaserclarkb: oh ok, right00:08
mordredI'm guessing the same thing is the reason mnaser's job didn't run00:08
clarkbmnaser: basically keeping the bastion as a bastion simplifies a lot of stuff00:08
mordredmnaser: you're getting all the luck here :)00:08
clarkbmnaser: we don't have to retrofit literally everything this way00:09
mnaser:D00:09
clarkbit also gives us a place to put logs safely00:09
mnaserit's interesting to hear the reasoning behind the decision00:09
mordredclarkb: also - I responded on remote-puppet-else - the short answer is "no, it doesn't need to depend on update-system-config" - the long answer is "wow it's super broken and it's parented on itself, but if it were parented on the right base job, the base job would depend on update-system-config"00:09
clarkbmordred: so it does need that dep to exist, but not directly?00:10
mordredyah00:11
openstackgerritMonty Taylor proposed opendev/system-config master: Run AFS in zuul  https://review.opendev.org/71705600:11
openstackgerritMonty Taylor proposed opendev/system-config master: Run remote-puppet-else in zuul  https://review.opendev.org/71705700:11
openstackgerritMonty Taylor proposed opendev/system-config master: Remove run_all.sh and ansible cron job  https://review.opendev.org/71705800:11
openstackgerritMonty Taylor proposed opendev/system-config master: Remove ansible-cron role  https://review.opendev.org/71705900:11
openstackgerritMonty Taylor proposed opendev/system-config master: Trigger everything on inventory changes  https://review.opendev.org/71711400:11
mordredclarkb: there ya go ^^00:12
mordredthat shoudl fix the afs and else jobs - which were in fact both broken00:12
mordredcorvus: fwiw - zuul did not complain that we pushed up patches where the job listed itself as its own parent00:12
corvusmordred: it'll complain if you try to run them00:14
corvusbut i agree, that's probably an easy extra check we could add to catch things earlier :)00:14
fungimnaser: another thing hopping through the bastion and running ansible there gets us is a central place we can temporarily disable all updates for a server on the fly, which tends to be useful in emergencies00:14
fungithough probably something similar could be done with static nodes in nodepool00:15
mordredcorvus: yeah - we may just not have thought about that as a thing to check for :)00:20
mordredfungi, corvus : mind +Aing https://review.opendev.org/#/c/718280 - we're not running any prod playbooks00:21
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure pip role  https://review.opendev.org/71763900:22
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure-pip: export ensure_pip_virtualenv_command  https://review.opendev.org/71822400:22
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] fetch-zuul-cloner: use ensure-pip  https://review.opendev.org/71788200:23
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] use ensure-pip in fetch-subunit-output test  https://review.opendev.org/71822500:23
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure-tox: use ensure-pip role  https://review.opendev.org/71766300:23
openstackgerritIan Wienand proposed zuul/zuul-jobs master: Update Fedora to 31  https://review.opendev.org/71765700:23
openstackgerritIan Wienand proposed zuul/zuul-jobs master: ensure-tox: make idempotent and update testing  https://review.opendev.org/71828400:23
openstackgerritMonty Taylor proposed opendev/system-config master: Run review and review-dev in zuul  https://review.opendev.org/71705400:23
openstackgerritMonty Taylor proposed opendev/system-config master: Run gitea in zuul  https://review.opendev.org/71705500:23
openstackgerritMonty Taylor proposed opendev/system-config master: Run AFS in zuul  https://review.opendev.org/71705600:23
openstackgerritMonty Taylor proposed opendev/system-config master: Run remote-puppet-else in zuul  https://review.opendev.org/71705700:23
openstackgerritMonty Taylor proposed opendev/system-config master: Remove run_all.sh and ansible cron job  https://review.opendev.org/71705800:23
openstackgerritMonty Taylor proposed opendev/system-config master: Remove ansible-cron role  https://review.opendev.org/71705900:23
openstackgerritMonty Taylor proposed opendev/system-config master: Trigger everything on inventory changes  https://review.opendev.org/71711400:23
ianwclarkb / mordred: interested in early thoughts on -> https://review.opendev.org/71828400:24
ianwupdates ensure-tox to always export tox_exectuable; however for the stack ontop of it, the most important bit is removing the testing assumption that tox is pre-installed00:24
mordredianw: I think it's a great idea00:25
clarkbianw: for some reason I thought it already did that00:26
clarkbso ya ++ good idea00:26
clarkbnow just working my way through the test changes00:27
ianwthanks ... i shall see how it falls out with the stack ontop of it.  having the plain node in there for testing is good, and by the top of the stack should hopefully go green00:28
clarkbya I agree on the test change it seems the first two cases are effectively the same00:28
clarkbianw: I think you can self approve it if ready now or wait for more test info?00:29
ianwclarkb: thanks, i'll wait for the stack ontop ... it should help https://review.opendev.org/#/c/717663/ go green on the -plain nodes00:30
openstackgerritMerged opendev/system-config master: Become root when fixing bridge logging  https://review.opendev.org/71828001:09
*** ysandeep|away is now known as ysandeep|rover01:17
openstackgerritIan Wienand proposed zuul/zuul-jobs master: ensure-tox: make idempotent and update testing  https://review.opendev.org/71828401:20
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure pip role  https://review.opendev.org/71763901:20
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure-pip: export ensure_pip_virtualenv_command  https://review.opendev.org/71822401:20
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] fetch-zuul-cloner: use ensure-pip  https://review.opendev.org/71788201:20
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] use ensure-pip in fetch-subunit-output test  https://review.opendev.org/71822501:20
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure-tox: use ensure-pip role  https://review.opendev.org/71766301:20
openstackgerritIan Wienand proposed zuul/zuul-jobs master: Update Fedora to 31  https://review.opendev.org/71765701:20
ianwmordred / clarkb : testing order was wrong; first step was install tox to a virtualenv, then because we made it idempotent, when we ran it again it (correctly) found the existing install and didn't do anything01:22
*** ysandeep|rover is now known as ysandeep|brb02:10
ianw2020-04-08 01:26:53.352582 | gentoo-17-0-systemd | Fetching file gentoo-20200228.tar.gz.md5sum ...02:30
ianw2020-04-08 01:26:53.405965 | gentoo-17-0-systemd | Fetching file portage-20200228.tar.gz.md5sum ...02:30
ianw2020-04-08 01:26:53.457829 | gentoo-17-0-systemd | 20200228 snapshot was not found02:30
ianwprometheanfire: ^02:30
ianwhttps://zuul.opendev.org/t/zuul/build/1e072187006d46a8afa452d2c77d5f20/log/job-output.txt02:30
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure-tox: use ensure-pip role  https://review.opendev.org/71766302:30
openstackgerritIan Wienand proposed zuul/zuul-jobs master: Update Fedora to 31  https://review.opendev.org/71765702:30
prometheanfiresup02:38
prometheanfirehmm, snapshot being the portage I imagine02:38
prometheanfirewhy are you downloading 20200228?02:39
prometheanfiretar.gz seems odd too02:39
openstackgerritIan Wienand proposed openstack/project-config master: Move suse builds to nb04, drop pip-and-virtualenv  https://review.opendev.org/71829902:39
prometheanfireit's bz2 or xz now http://distfiles.gentoo.org/snapshots/02:40
prometheanfireianw: looks like I'm still waiting on a new stage3 for systemd (and general)02:40
prometheanfireat least got the gcc build time fix02:41
* prometheanfire is really looking to move to stage3 files instead of stage4 (gentoo releng likes that as well)02:41
ianwprometheanfire: i have no idea, this is just one of the zuul-jobs tests02:42
ianwhappens out of TASK [configure-mirrors : Update Gentoo cache]02:42
prometheanfireI'd call it ephemeral02:42
prometheanfireemerge-webrsync should be calling the xz or bz202:43
prometheanfireit would have failed anyway with the gcc build02:44
*** ysandeep|brb is now known as ysandeep|rover03:42
*** ykarel|away is now known as ykarel04:24
*** calcmandan has joined #opendev04:53
*** sgw has quit IRC05:13
*** DSpider has joined #opendev05:53
openstackgerritIan Wienand proposed zuul/zuul-jobs master: Update Fedora to 31  https://review.opendev.org/71765706:05
*** slittle1 has quit IRC06:07
openstackgerritIan Wienand proposed zuul/zuul-jobs master: Update Fedora to 31  https://review.opendev.org/71765706:27
AJaegerianw: with your tox changes, do we need zbr's https://review.opendev.org/690057 ?06:36
ianwAJaeger: i'm ... not sure.  i'm not quite sure what that is going for06:37
AJaegerneither am I ;(06:38
ianwAJaeger: i think the stack from https://review.opendev.org/#/c/717657/ is actually in pretty much final shape.  i haven't written change descriptions yet06:40
*** lpetrut has joined #opendev07:09
*** rpittau|afk is now known as rpittau07:17
*** ysandeep|rover is now known as ysandeep|lunch07:24
*** ralonsoh has joined #opendev07:33
zbrsuper cool: zuul returns 500 if you try to post an emoji comment07:41
zbrianw: i see your work overlaps with mine on ensure-tox a lot, what can I do to help getting our changes merged?07:44
zbri had a big interest in making tox upgradable because it blocks me on ansible-zuul on few repos that need newer tox07:45
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: tox: allow tox to be upgraded  https://review.opendev.org/69005707:52
*** tosky has joined #opendev08:00
*** dpawlik has joined #opendev08:08
*** sshnaidm has joined #opendev08:23
sshnaidmhi, how can I delete the stein branch for tripleo-ansible repo?08:27
AJaegerinfra-root, can either of you help, sshnaidm, please?08:28
AJaegersshnaidm: why do you need to delete it? Isn't stein still under maintenance?08:28
*** ysandeep|lunch is now known as ysandeep|rover08:29
ianwzbr: sorry i'm out of time for today.08:29
sshnaidmit doesn't contain anything meaningful and makes problems for other stein jobs by its existence08:30
ianwzbr: the stack at https://review.opendev.org/#/c/717657 downwards is pretty much what i'm thinking, but i don't expect you to look at it yet as it has no explanation at all ... i will write proper change logs tomorrow08:30
ianwi think it will probably eliminate the need to upgrade things; we can avoid pre-installing tox until the job phase.  but we will have to see08:31
zbrianw: i already reviewed that one, afaik is ready to review.08:31
zbri can understand the fedora bump and the removal of the workaround is welcomed.08:32
zbrianw: but the problem is is the chain....08:33
zbrbut it would be great to fix and merge https://review.opendev.org/#/c/718284/08:34
zbrwhich is not working on plain ubuntu08:34
zbrianw: it would be so cool to have more zuul cores in EU timezones, nowadays not much gets reviewed or merged while US is sleeping.08:45
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: tox: allow tox to be upgraded  https://review.opendev.org/69005708:48
*** ykarel is now known as ykarel|lunch08:53
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: tox: allow tox to be upgraded  https://review.opendev.org/69005709:26
*** ykarel|lunch is now known as ykarel10:12
*** rpittau is now known as rpittau|bbl10:24
*** ysandeep|rover is now known as ysandeep|afk10:30
*** sshnaidm is now known as sshnaidm|afk10:56
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: tox: allow tox to be upgraded  https://review.opendev.org/69005710:59
openstackgerritSlawek Kaplonski proposed openstack/project-config master: Update Neutron Granafa dashboard  https://review.opendev.org/71839211:02
*** calcmandan has quit IRC11:25
*** calcmandan has joined #opendev11:25
*** slittle1 has joined #opendev11:28
*** ysandeep|afk is now known as ysandeep|rover11:31
*** sshnaidm|afk is now known as sshnaidm12:19
*** rpittau|bbl is now known as rpittau12:23
*** roman_g has joined #opendev12:24
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: tox: allow tox to be upgraded  https://review.opendev.org/69005712:32
*** ykarel is now known as ykarel|afk12:56
*** sgw has joined #opendev13:02
openstackgerritMonty Taylor proposed opendev/system-config master: Depend on infra-prod-update-system-config  https://review.opendev.org/71843413:03
*** ysandeep|rover is now known as ysandeep|away13:25
*** hashar has joined #opendev13:28
fungisshnaidm: before we can delete a branch, check with the release team to make sure it's not listed in the releases repo (or else release jobs will helpfully recreate it), and also abandon any open changes in gerrit targeting that branch13:32
sshnaidmfungi, and who is the release team?13:33
AJaegersshnaidm: #openstack-release13:33
AJaegersshnaidm: https://governance.openstack.org/tc/reference/projects/release-management.html13:34
fungisshnaidm: the *openstack* release team, since tripleo-ansible is an official openstack deliverable13:34
fungisshnaidm: i see there's also a stable/train branch, isn't that causing you similar problems?13:34
sshnaidmfungi, train is fine13:34
sshnaidmfungi, only stein to delete13:34
fungiwhy do you have a train branch but not want a stein branch?13:35
fungito be fair, i don't really care, these are probably just questions the release team is going to be asking you13:35
sshnaidmbecause stein doesn't contain anything meaningful13:36
fungias long as *openstack* (represented in this case by either the release team or the technical committee) is okay with us deleting a stable branch from an official deliverable on basically no notice, then i'm happy to help13:36
fungii'm not one to judge what is meaningful for one of openstack's repositories13:36
fungiusually branch deletions come with some sort of discussion and advance notice13:37
*** ykarel|afk is now known as ykarel13:37
fungiwhich is why i'm trying to make sure we follow proper channels for authorization13:38
openstackgerritSean McGinnis proposed openstack/project-config master: Add tooling to update python jobs on branch creation  https://review.opendev.org/67301913:44
AJaegerfungi, could you review the change above for release team, please? ^13:50
mordredAJaeger: seems like we should maybe move that stuff into the release repo at some point, no/13:56
mordred?13:56
openstackgerritMerged opendev/system-config master: Depend on infra-prod-update-system-config  https://review.opendev.org/71843414:02
AJaegermordred: I runs in post or so and we wanted that here for security reasons AFAIK (or it did not work in another repo since not trusted).14:03
mnasergood morning, it is me again asking about zuul-preview14:06
mordredmnaser: that patch that just merged ^^ should fix it (famous last words)14:10
fungimordred: AJaeger: also we'd probably need to create a separate gerrit account for their repo's use if we moved those jobs into it14:12
AJaegerfj14:12
AJaegerfungi: understood14:12
fungi(those jobs do a lot of writes to gerrit, creating branches, pushing changes, et cetera)14:12
fungi(...pushing tags...)14:12
openstackgerritMerged openstack/project-config master: Add tooling to update python jobs on branch creation  https://review.opendev.org/67301914:19
*** mlavalle has joined #opendev14:41
*** lpetrut has quit IRC14:46
openstackgerritThierry Carrez proposed opendev/system-config master: [WIP] Disable global Github replication  https://review.opendev.org/71847814:47
openstackgerritThierry Carrez proposed openstack/project-config master: Introduce job for granular GitHub mirroring  https://review.opendev.org/71847914:48
ttxalright, first draft14:49
*** ykarel is now known as ykarel|away15:04
mordredmnaser: look at the status page - infra-prod-service-zuul-preview is in the opendev-prod-hourly pipeline!15:12
mordredmnaser: we're actually going to run the playbook15:12
fungithe evolution of zuul-driven continuous deployment15:14
mordredfungi: it really helps when you get the job names right15:15
fungifeh15:15
fungiinfra-root: our certcheck notified us that the tarballs.opendev.org cert is a month from expiring. i took a look at the certs on static.opendev.org and most of them haven't been renewed since february, but the acme.sh log says there are no changes... i'll start looking deeper into this mystery shortly, but if anybody has ideas as to what might have silently broken this, i'm happy to hear them and shorten my15:17
fungiinvestigation15:17
clarkbfungi: we renew after 60 days15:19
clarkbso depending when in february they were created it may still be within that window. For tarballs if it is tripping the certcheck it has missed that 60 day window I think15:20
mordredalso maybe due to zuul cd the letsencrypt playbook could have not run recently?15:22
clarkbmordred: oh ya we may want to make that a daily periodic job if it isn't already?15:22
mordredhttps://zuul.opendev.org/t/openstack/builds?job_name=infra-prod-service-letsencrypt15:23
fungiclarkb: oh, okay, in that case maybe we need to tune our renewal frequency or our certcheck warning window15:23
mordredclarkb: it is - but it was skipped on its last run due to something before it not running I think15:23
fungiclarkb: because certcheck is set to warn us at 30 days remaining, and the certs are good for 9015:23
clarkbfungi: ya I think its set up where we should renew before certcheck runs, but if we miss a single day it will trip15:23
clarkbsince we normally renew just fine without tripping certcheck15:24
clarkbmaybe a few extra days in between is worthwhile just to accomodate changes to the config management :)15:25
fungiright, minor race condition there15:25
fungiis renewing monthly too frequent for letsencrypt's rate limit?15:26
mordredclarkb: we had a timeout on running base - which then caused the other nightlies to skip15:26
mordredclarkb: oh - we only ran it with 5 forks - I thought I'd fixed that15:26
clarkbfungi: mordred to tl;dr we need to continue to tune the periodic jobs but once those are running properly that should fix any LE issues15:29
mordredclarkb: I'm confused - the ansible_forks: 50 in .zuul.yaml for infra-prod-base doesn't seem to have overridden the ansible_forks: 5 in infra-prod-playbook15:29
clarkbthe good thing about warning early is we've got the warning early :)15:29
mordred++15:29
fungiclarkb: i wouldn't rely on certcheck to let us know overall reconfiguration is broken, because there's no guarantee we've got a cert ready to expire15:31
mordredcorvus: when you're awake/around - am I doing something wrong in infra-prod-base wrt ansible_forks?15:31
fungibut yeah, it's at least warning us before it becomes a cert expiration emergency15:31
clarkbfungi: right, its letting us know the cert is going to expire and we have ~a month to fix that15:31
clarkbregardless of what may be causing it15:31
fungithough maybe this is also an argument for leaving the certcheck cronjob in actual cron and not running it from zuul, as belt and suspenders since relying on the same mechanism both to update certs and to check that certs are getting updated is not that robust15:33
clarkb++ (note I don't think there has been any work or plan to put it into zuul as it isn't a playbook)15:34
corvusmordred: have a link to a run?15:34
mordredcorvus: no - the log file is on bridge15:34
mordredcorvus: oh - wait - one sec15:34
mordredcorvus: on bridge the playbook log is /var/log/ansible/base.yaml.log15:34
corvusmordred: i'm looking for a job15:34
corvusa build15:34
mordredcorvus: in zuul, the log is https://zuul.opendev.org/t/openstack/build/17b539528e6b4976827606d1ab95556615:35
mordredyeah15:35
corvusmordred: thanks15:35
mordredcorvus: I see 50 in the inventory - but still 5 on the invocation - could this be an issue with the variable being named ansible_ ?15:38
corvusmordred: yep: https://docs.ansible.com/ansible/latest/reference_appendices/special_variables.html#magic15:42
corvusmordred: it's a "magic" variable which apparently always means "the number of forks allowed by this (ie, the executor) ansible process"15:42
corvusmordred: so i think we just need to rename it everywhere15:43
mordredcorvus: kk. fixing15:43
clarkbttx: looks like fungi and AJaeger have some minor tweaks for the github replication job suggested15:46
openstackgerritMonty Taylor proposed opendev/system-config master: Run review and review-dev in zuul  https://review.opendev.org/71705415:47
openstackgerritMonty Taylor proposed opendev/system-config master: Run gitea in zuul  https://review.opendev.org/71705515:47
openstackgerritMonty Taylor proposed opendev/system-config master: Run AFS in zuul  https://review.opendev.org/71705615:47
openstackgerritMonty Taylor proposed opendev/system-config master: Run remote-puppet-else in zuul  https://review.opendev.org/71705715:47
openstackgerritMonty Taylor proposed opendev/system-config master: Remove run_all.sh and ansible cron job  https://review.opendev.org/71705815:47
openstackgerritMonty Taylor proposed opendev/system-config master: Remove ansible-cron role  https://review.opendev.org/71705915:47
openstackgerritMonty Taylor proposed opendev/system-config master: Trigger everything on inventory changes  https://review.opendev.org/71711415:47
openstackgerritMonty Taylor proposed opendev/system-config master: Rename ansible_forks to infra_prod_ansible_forks  https://review.opendev.org/71849715:47
mordredclarkb, corvus : ^^ 718497 should fix the forks issue, which should let base run in a reasonable amount of time15:48
fungiclarkb: ttx: well, it doesn't hurt to add it to reno initially and then add it to more repos after it merges15:48
mordredI also had to update the afs and else changes15:48
clarkbmordred: k will look shortly15:48
clarkbfungi: there is also a suggestion to disambiguate the jobs purpose15:48
AJaegerclarkb: I'm wondering how to limit the job only to official projects. Could somebody add that in-tree for a random project?15:50
openstackgerritSlawek Kaplonski proposed openstack/project-config master: Update Neutron Grafana dashboard  https://review.opendev.org/71839215:51
openstackgerritSlawek Kaplonski proposed openstack/project-config master: Update Neutron Grafana dashboard  https://review.opendev.org/71839215:51
mordredAJaeger: well- if they did and the target repo didn't exist, it wouldn't work15:51
clarkbAJaeger: there are a couple protections. The first is on the zuul side. You could make the job protected and only allow it to be used in project-config then have reviewers enforce that. The other is I think github now forces you to acknowlege new group memberships so random repos woudln't be able to add that user to their github repos15:51
AJaegerah, ok15:51
fungialso there's the fact that the job itself hard-codes the openstack/ namespace15:52
AJaegerclarkb: sshould we ask fungi to make it protected?15:52
AJaegerask ttx I mean15:52
clarkb(it should be noted I'm not a github expert  I just seem to recall them no longer allowing anyone to add you to various things anymore)15:53
fungii thought the only way to successfully add that job to a project-pipeline was in the project-config repo anyway?15:53
mordredmnaser: the zuul-preview playbook has run, so I would expect it to be running latest now15:53
clarkbfungi: ya I think the secret use may already imply that15:53
AJaegerttx, do you want to merge the change as is or make some changes? I'm fine either way...15:56
clarkbmordred: forks fix lgtm and has been approved15:59
mnasermordred: http://site.925bfe37815144d0859f260605d5fb98.zuul.zuul-preview.opendev.org well i guess its still broken15:59
clarkbthe process has been running since yesterday16:00
*** sshnaidm is now known as sshnaidm|afk16:04
mordredhrm16:04
clarkbthe ansible log claims that it updated the image and that it ran docker compose up16:05
clarkbbut maybe the implication is the image was up to date after all16:05
*** hashar is now known as hasharAway16:05
clarkbah yup: Status: Image is up to date for zuul/zuul-preview:latest16:05
mordredthe sha of the docker image on zp shows the correct sha16:06
clarkbI think that means the deployment stuff is probably not the problem16:06
mordredlet's look at logs16:06
mordredI don't see any new coredumps at least16:07
mordredzuul-preview_1  | [Wed Apr 08 16:07:30.498638 2020] [proxy:warn] [pid 310:tid 140643527550720] [client 2600:1700:72e2:4810:6cf7:8f33:6360:1849:60229] AH01144: No protocol handler was valid for the URL / (scheme 'https'). If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.16:08
corvusdid we never proxy to an https url?16:08
mordredI'm guessing not - proxy_ssl is not enabled in the image16:09
corvusok, you can leave this to me if you want16:09
corvus(it's easy to test changes to zuul-preview locally)16:10
mordredkk16:10
mordredmore and more of this is working though16:10
mordredinfra-root: I'm running the etherpad playbook manually again since there was a different issue yesterday with the auto-triggered one16:14
fungiout of curiosity, will we need to change how we interact with the admin api on the new deployment?16:19
clarkbfungi: you'll need to retrieve the admin token value out of the container `sudo docker exec etherpadcontainername cat path_to_token_file`16:20
clarkbfungi: but then because we use host networking all of your curling can be done as usual16:20
clarkbfungi: if the path_to_token_file is part of a bind mount from the host you'll be able to cat it off the host side too16:21
clarkb(I'm just not sure if that is the case)16:21
fungiso http://localhost:9001/api/ will still be reachable outside the container?16:21
clarkbfungi: yes, beacuse the container and the host share the same network stack (so localhost is the same to each of them)16:21
clarkbmordred: and other people that grok ansible better than me. I elft a comment on https://review.opendev.org/#/c/718224/4/roles/ensure-pip/tasks/main.yaml about some ansible stuff and how it interacts with zuul. Would be great if someone can double chck that and or provide better ideas16:22
fungilooks like it works just fine on the new server, yep16:22
fungimostly just making sure we aren't missing anything we need to be able to do manual fixing of stuff via the api, as i rely on it ~weekly16:22
clarkbfungi: if we weren't using host networking we'd probably do NAT. If we did NAT we'd probably do a 9001:9001 forward and it would still work16:22
fungicool16:23
*** hasharAway is now known as hashar16:23
*** rpittau is now known as rpittau|afk16:23
fungilooks like /var/lib/docker/overlay2/049ba88dab1cd8a7cb3971688b4707114560a732cc5f97f3f556bf88e56d659d/merged/opt/etherpad-lite/APIKEY.txt is it16:24
clarkbfungi: and if you check /etc/etherpad-docker/docker-compose.yaml that inner path isn't bind mounted from the host16:26
clarkbfungi: the easiest way to get at it will be using docker exec though16:26
clarkb(then you don't need to care where docker is storing the filesystem)16:26
mordredclarkb, fungi : /etc/letsencrypt-certs/etherpad.opendev.org/etherpad.opendev.org.cer16:27
mordredis missing - but the key file is there16:27
clarkbmordred: that means LE hasn't run successfully16:27
clarkbmordred: we generate the key, then need to verify the the domain with LE to get the .cer16:27
mordredyeah. the other thing that failed on the LE playbook was restarting the apache on etherpad.opendev.org16:28
clarkb/var/log/acme.sh is where I'd start16:28
mordredon etherpad?16:28
clarkbya16:28
clarkbthoguh why would it restart apache if it didn't make a .cer /me looks at the LE dir16:28
mordredh - it can't find the openstack.org dns record16:28
mordredI could have sworn I added one16:29
*** dpawlik has quit IRC16:29
clarkbI agree that is what acme.sh says16:29
fungiaccording to /etc/etherpad-docker/docker-compose.yaml the service is named etherpad, but is that not also the name of the container? docker exec seems to believe there's "No such container"16:29
clarkbfungi: it is etherpaddocker_etherpad_1 discoverable via `sudo docker ps -a`16:30
clarkbI think if you used docker-compose exec you can use the 'etherpad' name and it would figure it out for you16:31
fungiahh, thanks16:31
fungiclarkb: looks like the answer is:16:35
fungiwget -qO- 'http://localhost:9001/api/1/getText?apikey='$(sudo docker-compose -f /etc/etherpad-docker/docker-compose.yaml exec etherpad cat /opt/etherpad-lite/APIKEY.txt)'&padID=Virtual_PTG_Planning&rev=640'16:35
fungi(as an example)16:35
fungithat pad doesn't actually exist so the api returns a "padID does not exist" error16:36
fungibut that gets the api key plumbed in effectively16:36
fungii'll make a note in my to do list to update our runbook16:37
mordredDOH16:38
mordredI made an acme cname of _acme-challenge.etherpad01.openstack.org - not very useful16:39
mordredclarkb: re: ensure-pip16:42
mordredclarkb: this works because fact cache16:42
mordredclarkb: (we use the pattern in several places)16:42
clarkbmordred: aha16:42
clarkbmordred: do we need to explicitly cache the fact?16:43
mordredclarkb: yes16:44
mordredcacheable: true16:44
clarkbah that is in your comment. Thank you for that16:46
mordredinfra-root: https://etherpad.opendev.org/ is up ... I will now run in the db dump16:51
mordredSIGH16:52
mordredoh wait16:52
mordredclarkb: why is this: https://review.opendev.org/#/c/718497 not in the gate?17:09
mordrednevermind17:09
mordredclean check17:09
mordredit's still in check17:09
openstackgerritIvan Kolodyazhny proposed openstack/project-config master: Add publish-to-pypi jobs for new Vitrage xstatic-* projects  https://review.opendev.org/71663017:20
mnasercorvus, mordred: thank you for the work on zuul-preview, looks like we're good to go :)17:39
mordredmnaser: woot!17:39
mordredmnaser: wow - so we landed a change and it properly ran in prod!17:40
mnaseryes, i guess :D17:41
openstackgerritMerged opendev/system-config master: Rename ansible_forks to infra_prod_ansible_forks  https://review.opendev.org/71849717:46
mordredmnaser: thanks for being patient on that ... I think the end state is going to be very pleasing17:47
openstackgerritMerged opendev/system-config master: Run review and review-dev in zuul  https://review.opendev.org/71705417:53
openstackgerritMerged opendev/system-config master: Run gitea in zuul  https://review.opendev.org/71705517:53
*** ralonsoh has quit IRC18:01
*** diablo_rojo has quit IRC18:02
*** diablo_rojo has joined #opendev18:06
mordredclarkb, corvus : when you get a sec, https://review.opendev.org/#/c/717057/ and https://review.opendev.org/#/c/717056 need re-review due to rebasing and propagatig a couple of fixes18:22
mordredinfra-root: I have applied the db dump from etherpad.openstack.org to etherpad.opendev.org18:23
mordredso - we can commence to test it18:23
fungimordred: are you able to load any old pads on it? i see that https://etherpad.opendev.org/p/Virtual_PTG_Planning doesn't have the content from https://etherpad.openstack.org/p/Virtual_PTG_Planning (picked from my recent history)18:26
mordredfungi: yes - but I made the dump several days ago18:26
mordredso if it's content from this week it's probablynot there18:26
mordredhttps://etherpad.opendev.org/p/gerrit-2020-03-20 loads fine18:26
fungioh, hrm, yeah maybe too new. i'll pick another one18:27
clarkbhttps://etherpad.opendev.org/p/clarkb-test loads for me18:28
clarkbwe should find a 4 byte utf8 glyph and test that it works18:28
fungiyep, okay, security-sig-newsletter is there18:29
fungiand i can query the api for the pad text from it too18:29
mordredyay18:31
clarkbmy browser seems to have a hard time with the example sheets I've found (likely because my font simply lacks chinese characters?)18:31
mordredclarkb: example?18:31
mordred(clarkb-test is fine for me)18:31
clarkbhttp://www.i18nguy.com/unicode/supplementary-test.html18:31
clarkbmordred: I want to take a 4 byte utf8 char and put it in a pad and make sure it can be ready back out again18:32
mordredclarkb: I just pasted in one of teh chunks from that18:32
mordred(to clarkb-test)18:32
clarkbmordred: that caused my browser to reconnet and the error glyphs that were there when you pasted are gone18:33
clarkbI'm not sure that is working quite right18:33
mordredweird18:33
clarkbmordred: if you refresh the pad are they there for you?18:33
*** hashar has quit IRC18:33
clarkbit could be this is all client side issues because my font lacks the characters18:34
mordredoh - nope18:34
clarkbof course this isn't necessarily a regression18:34
clarkbwe could test similar on the old server18:34
mordredworked on the old server18:34
mordredso yea - I thnk there's something going on there18:34
*** hashar has joined #opendev18:36
clarkbk18:37
corvusfwiw, li confirms the translation of "project management combat operations" as "more or less right if you break it down" :)  [as jargon it may mean something a little different]18:41
mordredcorvus: I feel like project management combat operations are something we should perhaps practice around here18:42
corvusmordred: you know how we've been frustrated at the changing definition of gitops?  here's a solution staring us in the face.18:42
mordred++18:43
clarkbI feel like I'm lacking context but combat operations is not quite how I would describe what we do with computers :)18:43
corvusline 9-15 of the etherpad18:44
clarkbah18:44
mordredclarkb: I agree- but apparently people feel that "gitops" should imply a convergence engine now (kind of lie how cloud native somehow became synonymous with containers) - so maybe calling what we do 项目管理实战操作 would be cooler18:44
mordredalthough it is more letters than gitops18:44
clarkbmore bytes too18:44
fungiand for some reason all blank in my irc client18:45
corvusclarkb: i dunno, i feel "no project management plan survives contact with the production system" seems apt18:45
clarkbcorvus: ha18:45
clarkbfungi: your font likely lacks the glyphs18:45
fungilikely18:45
clarkbmine has those but not the 4 byte ones mordred was testing with18:45
clarkbmordred: for the 4 byte problem we should maybe double check that mariadb hasn't changed the behavior around utf8 with respect to mysql behavior?18:45
corvusanyway, sorry to distract -- anything i can do to help? :)18:46
fungiwell, except my terminal is supposed to actually incorporate glyphs form other fonts if my preferred font is missing them, so i presume i just entirely lack any font containing representations of those codepoints18:46
clarkbcorvus: I think its looking good except for the 4 byte character handling18:46
clarkbcorvus: basically modrred pasted in 4 byte utf8 chars and the pad lost them18:47
clarkb(and my client was forced to reconnect)18:47
JayFA great 4-byte emoji that you can use, (which I've confirmed blows up on mysql `utf8` but not `utf8_mb4`) is the poop emoji.18:47
corvusclarkb: oh, so they're not in the pad at all; that's why i can't find it?  did we confirm that works on the current one?18:47
clarkbcorvus: yes mordred reports this works on the old one18:47
clarkband ya not in the pad at all18:48
corvusJayF: yeah, that one killed the prod server during a summit18:48
clarkbthey were pasted in at line 1818:48
clarkbetherpad basically ate the line18:48
clarkbI wonder how dangerous googling "poop emoji" will be18:48
corvusclarkb, mordred: what pad on the current prod server has the 4bytes?18:48
clarkbmordred: ^18:49
corvusclarkb: i think the main danger would be if the kids discovered there was a poop emoji and started wanting to use it everywhere18:49
clarkbya the results are pretty tame18:50
corvusotherwise, i think you're clear from a 'goatse' pov18:50
clarkbunfortunately my terminal font does not have that glyph18:50
clarkbotherwise I'd share it here just for fun18:50
corvuspeople also ask: "Is poop emoji really poop?"18:50
clarkbhahahaha18:51
mordredI restarted the opendev etherpad server18:51
fungii'm personally surprised "poop emoji" wasn't one of the stars of the popular animated emoji movie18:51
mordredwith the mb4 charsets in the my.cnf18:51
corvusmordred: can i see your 4byte test on current etherpad prod?18:51
mordrednope. because it doesn't write18:52
mordredI just tried pasting it in to clarkb-test18:52
clarkbmordred: on openstack.org18:52
mordredoh - one sec18:52
mordredI just used a throwaawy - lemme do it on clarkb-test there18:52
mordredcorvus: you see it on https://etherpad.openstack.org/p/clarkb-test ?18:53
corvusmordred: line 17?18:53
*** diablo_rojo has quit IRC18:53
mordredcorvus: yes18:54
mordredso - on the new etherpad, we're getting an unhandled promise exception18:54
mordredlemme recreate18:54
corvussomething like 60 han-like chars?18:54
mordredetherpad_1  | [2020-04-08 18:54:40.245] [ERROR] console - Error: ER_TRUNCATED_WRONG_VALUE_FOR_FIELD: Incorrect string value: '\xF0\xA0\x9C\x8E \xF0...' for column `etherpad-lite`.`store`.`value` at row 118:54
mordredcorvus: yup18:54
fungihan solo is a han-like character18:54
corvusmordred: i see them on opendev.org too18:55
mordredthat's the issue we're getting etherpad side when I paste those18:55
mordredcorvus: you do?18:55
corvusoh wow, i reloaded and they disappeared18:55
mordredyeah18:55
corvusbut they must have shown up when you pasted them18:55
mordredyeah - I thnk it's a db write issue18:55
mordrednow the question is - why18:55
corvusagreed18:55
fungithat would make sense given the symptom18:55
clarkbcorvus: yup they showed up for me as error glpyhs then I was force reconencted and they were gone18:56
corvusfor me, they showed up correctly, and i was not forced to reconnect (i chose to reload)18:56
corvusnot sure if that's because of a server-side change or just differing local conditions18:57
* mordred is going to restart again18:58
mordredok - I think I fixed it18:59
mordredI'll push up the changes19:00
corvusmordred: lgtm!19:00
clarkbthe error glpyhs are there for me now19:00
clarkbwhcih is what I'd expect given my font situation19:00
openstackgerritMonty Taylor proposed opendev/system-config master: Configure etherpad to use utf8mb4  https://review.opendev.org/71853619:02
openstackgerritMonty Taylor proposed opendev/system-config master: Configure etherpad to use utf8mb4  https://review.opendev.org/71853619:02
mordredclarkb, corvus : I applied that ^^ directly on the server19:02
mordredoh - there's another thing19:02
openstackgerritMonty Taylor proposed opendev/system-config master: Set production NODE_ENV  https://review.opendev.org/71853819:05
mordredclarkb, corvus : ^^ that19:05
AJaegermnaser: could you abandon these, please? https://review.opendev.org/#/q/project:openstack/openstack-ansible-pip_install+is:open19:07
AJaegernoonedeadpunk: or you ^19:07
noonedeadpunkyeah, sure19:07
noonedeadpunkdone19:09
AJaegerconfig-core, 2 repos are ready to retire: please review https://review.opendev.org/#/c/717775 to finalize19:14
AJaegernoonedeadpunk: thanks19:14
openstackgerritMerged openstack/project-config master: Add vexxhost/ansible-role-base-server  https://review.opendev.org/71819919:28
*** hashar has quit IRC20:19
mordredcorvus, fungi : if you have a sec, https://review.opendev.org/#/c/718536/ and https://review.opendev.org/#/c/718538/ would be nice20:23
corvuswhat's the deal with "Comments left for invalid file tools/irc_checks.py" ?20:24
fungiso far i've assumed that's related to one of the linters but since zuul doesn't say which one left the comments i haven't taken time to go looking through every result link20:25
mordredcorvus: https://zuul.opendev.org/t/openstack/build/0aa2330d82bd4fa79b16f540edb68f54/log/job-output.txt#58120:25
corvusit looks like this is showing up in the tox output:20:25
corvustools/irc_checks.py:25: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.20:25
corvus  config = yaml.load(open('hiera/common.yaml', 'r'))20:25
corvusyeah that20:25
mordredshould we make that safe_load just to shut up the warning?20:26
corvusthat's a python warnings module outuput from running the script20:26
corvuswhich i guess happens to match the tox inline comment regex?20:26
mordredyeah20:26
fungineat!20:26
corvusmordred: yeah, i can go ahead and fix the script -- but do you think we should make any changes to the regex?20:27
fungisomebody raised a similar point today on the openstack-discuss thread about inline comments20:27
mordredcorvus: I'm not sure we can ... that's pretty much the exact output we'd see from flake820:28
fungihttp://lists.openstack.org/pipermail/openstack-discuss/2020-April/013989.html20:28
corvusmordred: yeah, and that file *is* in the repo20:28
fungiexample here: https://review.opendev.org/#/c/717879/1/oslo_policy/policy.py@67720:28
mordredcorvus: yup20:28
corvusfor the oslo policy issue -- i think the solutions there would be to do something other than the warning module, or turn off inline comments for the tox-py* and lower-constraints jobs in that repo20:30
mordredcorvus: maybe we should add a flag somewhere to tell zuul not to warn on non-matching files for a given set of inline comments, then set that in our tox inline return? since it's a general comment returner, the warning about non-matching isn't usually useful to the person writing the patch20:30
fungithere's also an outstanding patch to have zuul mention which job is responsible for that comment, right?20:31
mordredno - not for the warnings20:31
fungiahh20:31
mordredwe updated the inline comments20:31
corvusmordred: then no one would ever see the error?20:32
mordredcorvus: well - they would whenver they make a patch that touches the file in question20:32
corvusto be clear, i'm not complaining about the warning, it's doing it's job -- it's alerting us to something not working as expected20:33
corvusand we're going to act on it20:33
corvusso for me, this is an unconvincing reason to suppress the warning :)20:33
mordredI think maybe the fact that it shows up as a warning from zuul is the thing the's troubling. it makes it seem like there is a zuul issue, rather than "I have detected an issue in the output but there is no file to report it against so I'll tell you about it in the comment"20:34
corvuswell, it's saying that the job is flawed20:34
mordredbecause the _warning_ aspect is "this job might be misconfigured and reporting information incorrectly"20:35
corvusmordred: i think we can tighten up the regex20:35
mordredok20:35
corvusa pep8 error looks like "tests/test_discovery.py:219:46: E128 continuation line under-indented for visual indent"20:36
corvusbut this has an extra "...Warning:" section20:37
mordredcorvus: we should also check the sphinx error lines20:37
corvusyeah, i think a check for ".*Warning:" will clear those too20:38
mordredcorvus: but if we tighten the regex to exclude those warnings, isn't that just more suppression? like - this did report a thing that we're going to fix, and the fix isn't that the job is broken20:38
corvusmordred: yes, i'm trying to keep these two things separate :)20:38
corvus1) the job is returning inline comments that are invalid for the change which we did not intend to be included.  that's why i think the zuul warning is working appropriately.  2) there's a problem that we arguably should fix.  we could decide that we want to get information like that from inline comments, and i'm somewhat ambivalent about that, but i think the oslo folks would suggest that they just want20:40
corvusto see pep8 errors from the pep8 job20:40
openstackgerritSean McGinnis proposed openstack/project-config master: Fix branch to series matching logic in job updates  https://review.opendev.org/71854920:41
mordredcorvus: nod, that's helpful20:42
corvusmordred: i think i'll propose a change to zuul-jobs with a test case, and a regex explicitly for user warnings, and we can bikeshed about whether it should be included or excluded :)20:43
mordred:)20:43
mordredcorvus: just what we all need, more bikeshedding!20:43
corvusmordred: i'm confused; i wrote the unit test for this and it passed, because the pep8 regex should already exclude these comments20:55
mordredcorvus: uhm20:56
corvusi'll keep digging20:56
corvusoh i think it's hitting the sphinx matcher20:57
mordredyeah - was just about to say that20:57
openstackgerritMerged opendev/system-config master: Configure etherpad to use utf8mb4  https://review.opendev.org/71853621:16
openstackgerritJames E. Blair proposed zuul/zuul-jobs master: tox: Don't inline python warnings  https://review.opendev.org/71855421:18
corvusmordred: regarding the case of https://review.opendev.org/#/c/717879/1/oslo_policy/policy.py@677  --  do you think we should toggle the flag for the 3 jobs that are reporting just on that repo, or do it for all of 'openstack-tox-py36' etc?21:20
mordredcorvus: I don't think we should turn if off for openstack-tox-py36 broadly - I think landing your warnings patch while we ponder the broader topic would be better21:22
corvusmordred: oh, so you don't think i should turn it off just for oslo.policy?21:23
corvus(ie, just land the warnings patch in zuul-jobs, then think about re-expanding it later?)21:23
openstackgerritJames E. Blair proposed opendev/system-config master: Use SafeLoader in irc_checks  https://review.opendev.org/71855821:25
mordredcorvus: yeah21:25
corvusokay, then i think that bottoms out this rabbit hole for now :)21:25
mordred\o/21:25
openstackgerritMerged openstack/project-config master: Fix branch to series matching logic in job updates  https://review.opendev.org/71854921:31
openstackgerritMonty Taylor proposed opendev/system-config master: Don't log the public loop on master-nameserver  https://review.opendev.org/71855921:38
*** DSpider has quit IRC21:50
openstackgerritSean McGinnis proposed openstack/project-config master: Add expression switch to job update sed statement  https://review.opendev.org/71856422:08
mnaserbtw: i know we've been using more and more of opendev, so i'm happy to help drive some things (probably the small quirks and not major things like docker-ifying a whole service as that's a bit hard without having visiblity of root -- for now at least)22:42
openstackgerritMerged openstack/project-config master: Add expression switch to job update sed statement  https://review.opendev.org/71856422:47
openstackgerritMerged opendev/system-config master: Set production NODE_ENV  https://review.opendev.org/71853823:08
fungimnaser: the help is most welcome! (not that you haven't already been helping in a multitude of ways)23:13
fungiwhatever we've got going on that you want to pitch in on would be cool23:13
mnaseri'll need to get a bit of the hang of system-config23:14
fungitake all the time you need. i still feel like i'm getting the hang of system-config and i've been here longer than it has23:14
*** tosky has quit IRC23:20

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