Monday, 2020-04-13

mordredinfra-root: ^^ first of those is green now - I'm hoping the second two will be to - I think the tests are testing a good potion of that, but we should carefully review those. I also want to do corvus' suggestion of writing out the ansible.cnf to /opt/system-config too ... but I'm gonna do that as a followup00:01
*** ysandeep|off is now known as ysandeep|rover04:07
*** ykarel|away is now known as ykarel04:58
openstackgerritAlbin Vass proposed opendev/gerritlib master: Use ensure-* roles  https://review.opendev.org/71940407:36
openstackgerritAlbin Vass proposed opendev/system-config master: Use ensure-* roles  https://review.opendev.org/71783307:38
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Remove install-* roles  https://review.opendev.org/71932207:52
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Remove install-* roles  https://review.opendev.org/71932207:52
*** ysandeep|rover is now known as ysandeep|lunch08:07
*** ykarel is now known as ykarel|lunch08:52
fricklercorvus: just saw this on a jitsi channel, not sure if it affects us or if we are safe because we run on lo only https://github.com/jitsi/docker-jitsi-meet/commit/a015710e547e8746023f12ee33d2482dabf8ce0f09:00
*** ysandeep|lunch is now known as ysandeep|rover09:05
*** DSpider has joined #opendev09:14
yoctozeptomorning folks; is etherpad down? https://etherpad.opendev.org/p/KollaWhiteBoard - Internal Server Error09:20
*** tosky has joined #opendev09:25
*** ykarel|lunch is now known as ykarel09:38
*** lpetrut has joined #opendev10:30
*** ysandeep|rover is now known as ysandeep|coffee11:02
*** ysandeep|coffee is now known as ysandeep|rover11:35
*** drifterza has joined #opendev12:10
*** rosmaita has joined #opendev12:36
rosmaitayoctozepto: it12:39
rosmaitas happening for me too -- https://etherpad.opendev.org/p/cinder-ussuri-meetings12:39
rosmaitagiving internal server error12:39
* mordred is checking12:40
mordredrosmaita, yoctozepto : sorry for the issue - should be fixed12:41
rosmaitamordred: ty, working now12:41
mordredI have a theory on what's happening there and will work on a fix as soon as coffee is in the mouth12:41
rosmaitamordred: no rush, now that i know the content hasn't been lost!12:42
yoctozeptothanks mordred12:58
openstackgerritMonty Taylor proposed opendev/system-config master: Build and use our own etherpad image  https://review.opendev.org/71945513:08
mordredrosmaita, yoctozepto: fwiw, that should prevent the issue from occurring again ^^13:09
mordredfrickler: I believe it doesn't affect us because those services are only talking across lo13:11
mordredfrickler: (we, in fact, set passwords for those, but we set them publically, so I'm assuming corvus did not think they were real passwords)13:12
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Test base-test  https://review.opendev.org/71945713:13
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Test base-test  https://review.opendev.org/71945713:14
rosmaitamordred: makes sense to me & should prevent future coronaries13:17
mordredrosmaita: coronary prevention is job 113:24
rosmaita:)13:24
mordredrosmaita: so you're saying we should back up that database?13:24
fungiheh13:25
rosmaitamordred: i know that "etherpad" is supposed to imply non-permanence, but i don't think we (openstack) use it like that anymore!13:25
rosmaita+1 on db backups13:25
openstackgerritMonty Taylor proposed opendev/system-config master: Back up a single gitea backend  https://review.opendev.org/71946513:35
*** ykarel is now known as ykarel|afk13:39
corvusfrickler, mordred: yeah, i think we'd need to secure that if we exposed the xmpp service (which we talked about doing)13:41
mordredrosmaita: (we're already backing it up - that was a bad attempt at dry humor on my part) :)13:43
rosmaita:D13:44
openstackgerritMonty Taylor proposed opendev/system-config master: Back up a single gitea backend  https://review.opendev.org/71946513:50
openstackgerritMonty Taylor proposed opendev/system-config master: Back up eavesdrop  https://review.opendev.org/71948413:50
openstackgerritMonty Taylor proposed opendev/system-config master: Back up a single gitea backend  https://review.opendev.org/71946513:53
openstackgerritMonty Taylor proposed opendev/system-config master: Back up eavesdrop  https://review.opendev.org/71948413:53
openstackgerritMonty Taylor proposed opendev/system-config master: Don't back up docker containers  https://review.opendev.org/71948813:53
mordredfungi: ^^13:53
mordredfungi: we should probably _not_ back up docker containers13:53
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Adds roles to install and run hashicorp packer  https://review.opendev.org/70929214:04
*** ykarel|afk is now known as ykarel14:04
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Adds roles to install and run hashicorp packer  https://review.opendev.org/70929214:10
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Adds roles to install and run hashicorp packer  https://review.opendev.org/70929214:11
*** ysandeep|rover is now known as ysandeep|away14:12
fungibig storms are rolling through here, so electricity and internet are rather unstable at the moment.  i'll be around whenever meteorologically possible14:14
openstackgerritMonty Taylor proposed opendev/system-config master: Use project-config from zuul instead of direct clones  https://review.opendev.org/71934314:20
mordredfungi: try to not get washed away14:20
fungii'll hold onto the keyboard14:21
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Test base-test  https://review.opendev.org/71945714:27
openstackgerritMerged opendev/system-config master: Build and use our own etherpad image  https://review.opendev.org/71945514:37
*** lpetrut has quit IRC14:39
openstackgerritMerged opendev/system-config master: Don't back up docker containers  https://review.opendev.org/71948814:41
*** ykarel is now known as ykarel|away14:41
mordredcorvus: for our deploy jobs - shoudl we have them provides/requires on themselves?14:43
mordredcorvus: so taht in the deploy pipeline zuul will be sure to schedule them in order?14:43
mordredor do we not need to worry about that14:44
openstackgerritMerged opendev/system-config master: Use SafeLoader in irc_checks  https://review.opendev.org/71855814:44
corvusmordred: pipelines are already ordered, so we don't need to worry about it14:44
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Adds roles to install and run hashicorp packer  https://review.opendev.org/70929214:44
corvusmordred: (so in this case, the mutex of 1 gives us the same behavior)14:45
mordredcorvus: kk14:46
mordredetherpad is now running from our image14:49
* fungi tests14:49
fungipads are still loading fine for me, including style headers14:50
mordredwoot14:50
fungilooks good!14:50
mordredwe should not have the issue with things going to 500 after ansible runs any more :)14:50
corvusi am not used to this being so fast :)14:50
mordredit's very exciting14:50
fungiindeed. thanks mordred!14:50
fungiwe seem to be getting a pattern down for these too14:51
mordred++14:51
mordredfungi: if you haven't seen https://review.opendev.org/#/c/719343/ and its two parents yet - that's the next step in speed and correctness14:51
mordred(once it works)14:51
corvusit's pretty cool you're getting -1s on that :)14:52
openstackgerritMonty Taylor proposed opendev/system-config master: Use project-config from zuul instead of direct clones  https://review.opendev.org/71934314:52
mordredcorvus: yes indeed!14:53
fungimultiple times a day, the track-upstream cron on review-dev is emitting this: /usr/local/lib/python3.7/dist-packages/paramiko/client.py:837: UserWarning: Unknown ssh-rsa host key for [review-dev.opendev.org]:29418: b'03cb1cc7df724fe7d53cc06a8d9cef5c' key.get_name(), hostname, hexlify(key.get_fingerprint())14:53
mordredfungi: well that's annoying14:53
fungii think it started when we updated how track-upstream was being run14:53
fungior maybe we just started running track-upstream on review-dev14:53
mordredyeah. maybe we need to bind-mount the .ssh dir in more?14:53
mordredeyah - that too14:53
mordredfungi: yeah - we should probably accept the hosts host key and then add .ssh/known_hosts to the bindmounts?14:54
fungii think elsewhere we used configuration management to install the known hosts entry14:57
fungiespecially for well-known host keys like the gerrit service14:57
mordredfungi: yeah. that's probably the better idea14:58
clarkbwhat was causing etherpad to crash?15:03
mordredclarkb: something about re-installing the npm module in ansible was causing etherpad to get confused with the bindmount15:05
clarkband that is why switchign to an image with it built in fixes things15:06
mordrednot 100% _why_ - but since we wanted ot replace that with installing the npm module during an image build, I didn't dig too deeply15:06
mordredyeah15:06
clarkbmordred: fungi one thing I saw scroll past over the weekend was we ignore the disabled list for backups?15:09
openstackgerritMonty Taylor proposed opendev/system-config master: Add self host keys to known_hosts on gerrit  https://review.opendev.org/71956815:11
mordredclarkb: fixed15:11
mordredfungi, clarkb: ^^ how's that look for the host key thing?15:12
clarkbmordred: fixed meaning now we don't ignore the disabled list?15:12
mordredclarkb: https://review.opendev.org/#/c/719309/15:12
mordredthat's right15:12
clarkbgot it, thanks for clearing that up. I didn't have time to dig into it over the weekend but it caught my eye15:13
fungiclarkb: the disable list now affects whether or not the backups cronjob gets installed, not whether it runs15:13
mordredclarkb: oh - https://review.opendev.org/#/c/719465/ is from you mentioning we should do that, btw15:14
clarkbmordred: TIL [] escapes are valid in fqdn and ipv4 address contexts. At least for ssh hostkey listings15:15
mordredclarkb: I totally copy-pastad that syntax from manifests/site.pp - we do it for accepting gerrit host keys in zuul15:15
*** mtreinish has quit IRC15:18
openstackgerritMonty Taylor proposed opendev/system-config master: Use project-config from zuul instead of direct clones  https://review.opendev.org/71934315:22
corvusi'm having trouble adding avass to zuul-jobs-core15:33
corvushttps://review.opendev.org/#/admin/groups/1771,members15:33
corvuswhen i type in "albin" i get two popups that are identical15:33
corvusand when i select either one, and hit add, i get an error15:34
*** mlavalle has joined #opendev15:34
corvusi don't see anything in the gerrit error log15:34
fungisounds like the typical gerrit "dulpicate e-mail address" failure15:34
fungii'll check the db15:35
corvusoh yeah, they both have the same email15:35
fungithat causes gerrit to pretend the account isn't valid when adding to groups or as a requested reviewer15:35
corvusso we need to figure out which is correct, then remove or alter the email address for the other?15:36
fungitwo active accounts (29671 created 2018-12-13, 31007 created 2019-09-19)15:36
clarkbI think if you use the specific account id then you can getaround the error adding to the group, but the accounts should probably be combined15:37
clarkbor disambiguated if there is a need for two15:37
corvuslooks like the 29671 is what's used15:37
fungiyeah, 31007 looks like it may have been the result of logging into ubuntuone with a gmail address15:37
fungithe older account has a username of albin_vass while the newer has a username of vass15:38
fungithe challenge i sometimes run into is when a user has gotten themselves into a situation where they're using one account in the webui and associated another with their ssh access15:38
corvusgood point, so we need to ask avass if he's (even inadvertantly) using both accounts15:40
fungiyep15:40
corvusi'll hold off on using the numeric workaround for now; hopefully he can drop by and we can work out a better solution soon15:41
fungiunfortunately it's become harder to look up ssh keys since recent gerrit started sticking that somewhere other than in the sql db15:41
*** avass has joined #opendev15:41
fungihere's avass!15:41
avassHey :)15:41
corvusavass: hi!  we found you have two accounts in gerrit15:41
avasscorvus: right, I think I might have accidentally created another15:42
avasslet me check15:42
corvusthey both have the same email address, but they have different ssh user names; account id 29671==albin_vass and 31007==vass15:42
corvusit looks like you're using 29671==albin_vass to upload changes15:43
avassshould be albin_vass15:43
avassyeah15:43
corvusavass: can you visit https://review.opendev.org/#/settings/15:43
corvusavass: with whatever account you usually use to use the web interface, and tell us what "Account ID" says there?15:43
fungi(also if you're using gertty, it would be good to double-check the username configured in it too)15:44
avassid=2967115:44
corvusokay, so it looks like 31007==vass is unused15:44
fungisounds like we should be safe to just mark that newer account inactive15:44
corvusfungi: can you do that?15:44
fungiyep, gimme one sec15:45
fungiand done15:45
corvuslooks good!15:45
*** olaph has quit IRC15:45
corvusavass: this should make it easier for folks to add you as a reviewer15:45
corvusand it makes it easier for me to add you to the zuul-job-core group15:46
fungi#status log set unused gerrit account 31007 inactive for avass15:46
openstackstatusfungi: finished logging15:46
openstackgerritMonty Taylor proposed opendev/system-config master: Use project-config from zuul instead of direct clones  https://review.opendev.org/71934315:48
fungiclarkb: corvus: not sure if you saw me mention yesterday, but etherpad 1.8.0 seems to have fixed line number alignment for us: https://etherpad.opendev.org/p/tANNPB4DN0J936odiiBj15:49
corvusand that's with the style plugin too, nice!15:51
*** drifterza has quit IRC15:52
avassI guess it's done, thanks!15:52
corvusavass: yep, let us know if there's any unexpected fallout from this :)15:53
fungialso, this looks promising: https://github.com/ether/etherpad-lite/issues/386115:53
clarkbTIL that docker-composes file formats are not actually fixed in time :/ stop_grace_period is a valid v2 directive but not in the version of docker-compose we install15:54
avasscorvus: will do! :)15:54
mordredclarkb: boo15:54
clarkbmordred: kinda makes you wonder why bother with the file versions at all...15:54
mordredclarkb: I guess docker-compose isn't in the docker apt repo we install :(15:54
clarkb1.10 docker-compose added stop_grace_period. On bionic we have 1.515:54
clarkbmordred: I don't think so but its a pypi package so we could in theory install it from pypi15:55
clarkbI'll work on a change to do that and the whole thing should be self testing15:55
mordred++15:56
mordredclarkb: it seems like a reasonable example of a real reason to use a more recent version than what's in distro15:56
mordredoh - you know ...15:56
openstackgerritClark Boylan proposed opendev/system-config master: Use HUP to stop gerrit in docker-compose  https://review.opendev.org/71905115:59
openstackgerritClark Boylan proposed opendev/system-config master: Install docker-compose from pypi  https://review.opendev.org/71958915:59
clarkbwe can see if that ^ makes things happy at least15:59
*** rosmaita has left #opendev16:02
slittle1Could we get eyes on  https://review.opendev.org/#/c/713968/ ... there is a bit of urgency to get this new git set up.  Thanks16:02
fungislittle1: wrong change? or wrong irc channel?16:03
mordrednope. (I was checking to see if there was a newer docker-compose in a backports repo)16:06
AJaegerslittle1: do you mean https://review.opendev.org/718772 ?16:07
openstackgerritMerged zuul/zuul-jobs master: ensure-tox: make idempotent and update testing  https://review.opendev.org/71828416:12
openstackgerritMonty Taylor proposed opendev/system-config master: Use project-config from zuul instead of direct clones  https://review.opendev.org/71934316:22
AJaegerinfra-root, team, FYI, we have errors in openstack tenant, see https://zuul.opendev.org/t/openstack/config-errors - the repo openstack/openstack-ansible-pip_install was retired but some jobs still have required-projects setup. Seems also that the role is still used for older branches, so shouldn't have been retired as is ;( I raised this already on #openstack-ansible and expect that mnaser will16:27
AJaegerlook into it.16:27
corvusAJaeger: i'm guessing we don't remove .zuul.yaml from old branches, which is why no one saw the problem before the project was removed from the config?16:28
corvusoh, but if it's included as a "role" even that may not have shown us the problem16:29
AJaegercorvus: it's a job in another repo. The deleted repo was used as a role but it breaks since the job in the other repo uses required-projects to check it out.16:29
AJaegercorvus: there're no self-checks to warn us about these AFAIK16:30
corvusyep, i think that's the case16:30
openstackgerritMerged zuul/zuul-jobs master: Fix check_jobs_documented linter  https://review.opendev.org/71905416:31
AJaegercorvus: https://review.opendev.org/719029 is one of those changes to remove the required-projects.16:31
AJaegerBut team needs to figure out now how to handle these branches16:31
openstackgerritMonty Taylor proposed opendev/system-config master: Add self host keys to known_hosts on gerrit  https://review.opendev.org/71956816:33
clarkbmordred: infra-root I believe that installing docker-compose from pypi has fixed the gerrit stop_grace_period issue. Now we need to decide if that is how we want to install docker-compose I guess16:35
clarkbcurrent change only affects gerrit installs as we don't have a common docker-compose role16:36
clarkband now I need to pop out nad prep for school at home today. Back in a bit16:36
mordredclarkb: I think we should move installing docker-compose into the install-docker role16:38
mordredclarkb: and then just install it the same way everywhere16:38
mordred(there's basically nowhere that we're using docker in prod where we're not using docker-compose - or where having docker-compose installed would be weird)16:39
mordredclarkb, corvus, fungi : booyah. I think https://review.opendev.org/#/c/719343 and its two parents are now ready for review16:52
clarkbmordred: are we comfortable using the pypi version considering we now have a need for newer features?16:58
clarkbalso I've realized that my keyboard might be too loud for class time. I may need to switch to laptop17:00
mordredclarkb: I am - but we should take temperatures from folks17:00
mordredclarkb: becuase I think that is a legit worthwhile feature17:00
mordrednot just a nice-to-have17:00
clarkbya17:01
clarkbI'll start on a docker-compose role in a bit under the assumption we'll move forard like that17:02
mordredclarkb: ++ - and then we can just include_role: docker-compose in install-docker?17:03
clarkbya17:03
clarkbmordred: ci is still failing on the project-config from zuul change17:04
mordreddammit17:05
mordredah - it's a new gitea error - cool17:05
openstackgerritMonty Taylor proposed opendev/system-config master: Use project-config from zuul instead of direct clones  https://review.opendev.org/71934317:08
*** prometheanfire has quit IRC17:14
mordredclarkb: our testing is doing a good job17:20
*** olaph has joined #opendev17:22
clarkbmordred: looking at docker-compose more, really the only generic thing is the package install. I almost wonder if we should just put that in the docker role and not bother with a separate role17:22
mordredclarkb: yeah. probably so17:23
mordredclarkb: it's really not a thing we do independently17:23
mordredclarkb, fungi : https://review.opendev.org/#/c/719568/ is green - should fix the track_upstream issue from earlier17:27
clarkbmordred: isn't that the comment field? why did we haev to change it?17:28
mordredclarkb: the module does a validation - the name is actually supposed to be one of the hosts in the entry17:29
clarkbthats ok17:29
mordredso it writes the entry to a file, then does an ssh-keygen -F {{ name }} on it17:30
openstackgerritClark Boylan proposed opendev/system-config master: Install docker-compose from pypi  https://review.opendev.org/71958917:38
openstackgerritClark Boylan proposed opendev/system-config master: Use HUP to stop gerrit in docker-compose  https://review.opendev.org/71905117:38
clarkbsomething like that maybe for docker compose17:38
mordredclarkb: ++17:40
fungisorry, was on a call, catching back up on the flurry of patches17:50
mordredclarkb, fungi, corvus : https://review.opendev.org/#/c/719343 is finally fully green17:53
clarkbk will take a look at it momentarily17:54
mordred(and I have good confidence in that green, given all the various reasons it was red before)17:54
clarkbmordred: reading https://review.opendev.org/#/c/719186/6//COMMIT_MSG does PWD need to be /opt/system-config or do we just need to run a playbook from /opt/system-config/playbooks for that chagne of context to apply?17:58
mordredclarkb: PWD needs to be /opt/system-config for the ansible.cfg to get picked up17:58
mordredclarkb: and I'm going to do a followup that will write that ansible.cfg out from the same template as /etc/ansible/ansible.cfg but with  different inputs17:59
mordredbut - too many spinning plates17:59
clarkbmordred: thinking out loud here why not keep the structure the same but with different paths pointed to in config? that way we don't accidentaly use the zuul version if not cd'd into /opt/sytem-config?18:01
clarkbbasically make the global install not work18:01
fungimordred: i approved 719568 though noted we may want to consider if using /etc/ssh/ssh_known_hosts for these keys in the future makes any of this easier (compared to dotdirs in homedirs)18:01
clarkband force all commands to be explicit about the install they want18:01
mordredclarkb: yeah - I think I can ponder that in the followup18:02
mordredclarkb: for the most part it shouldn't matter - but I think that'sa. good improvement18:02
mordredfungi: good thought18:03
mordredfungi: would it be useful at all to do sshfp dns records?18:03
fungiprobably not as that requires additional client configuration18:03
fungiassuming you mean auto-accept host keys if they have valid sshfp records18:04
fungiby default the openssh client behavior is to report whether the sshfp record matches, but it won't auto-add without explicitly telling it that's the behavior we want18:04
*** prometheanfire has joined #opendev18:05
mordredfungi: is auto-add ust about adding to known-hosts?18:05
fungiyep18:05
fungiand accepting the host key18:05
mordredalso I guess we have paramiko in places too18:05
fungiyou need to set VerifyHostKeyDNS=yes if you want it to implicitly trust sshfp records18:06
mordredthat said - we could probably enable that in /etc/ssh/ssh_config globally if we wanted - assuming paramiko can grok sshfp records too18:06
mordredjust seems a little lame that we have to write host keys out when we also have a dnssec signed dns18:06
fungialso we would need to be sure that all our resolvers are doing dnssec validation, because if there's no dnssec chain of trust to the root for those sshfp records then the client will ignore them anyway18:06
fungithough i think we're probably okay on that at this point18:07
fungiat least for anything in domains we're hosting18:07
mordredyeah18:07
fungiif we don't want to fiddle with ssh client configuration then we could pass -oVerifyHostKeyDNS=1 on the cli, but that's probably at least as hard to update everywhere18:09
mordredyeah - I think setting known_hosts is easier than that18:10
mordredHOWEVER - it looks like paramiko doesn't support sshfp without a custom policy like this: https://www.xpra.org/trac/attachment/ticket/2097/_sshfp_policy.py18:10
fungineat18:10
mordredso it doesn't seem like it would be a huge win anyway18:10
mordredfungi: that said - we _could_ publish sshfp records anyway :)18:11
fungiyes, that's still valuable. i've used VerifyHostKeyDNS=ask in my client configs because maintain sshfp records for my own systems18:11
fungiit solves the tofu problem18:11
fungii wish ask was the default there18:12
mordredyeah.18:12
mordredif I don't have the key, but there is one in dns that's a much more reasonable thing to ask me if it's opk18:12
mordredclarkb: yes to your question on https://review.opendev.org/#/c/71919018:13
fungiright, it shifts the problem from "the odds that someone is monkeying with my initial connection are low and at least if i accept this key then i'll detect when it does happen later" to "whoever maintains dns says this is the correct key"18:14
fungiyou still get the usual behavior with key changes too, where you'll need to delete the old conflicting key18:14
clarkbmordred: ok the last change inthe stack is the one that has my brain most melted. It seems we've sort of punted on the actual git repo updating and are just synchronizing what we've currently got. Comments with more details18:17
openstackgerritMonty Taylor proposed opendev/system-config master: Update install-ansible away from /opt/system-config  https://review.opendev.org/71918618:20
openstackgerritMonty Taylor proposed opendev/system-config master: Run playbooks out of zuul checkout  https://review.opendev.org/71919018:20
openstackgerritMonty Taylor proposed opendev/system-config master: Use project-config from zuul instead of direct clones  https://review.opendev.org/71934318:20
mordredclarkb: o - I missed your second comment - one sec18:20
openstackgerritMonty Taylor proposed opendev/system-config master: Use project-config from zuul instead of direct clones  https://review.opendev.org/71934318:25
mordredclarkb: ok - I think I addressed your second comment - good catch18:25
clarkbmordred: we still need something to update the non zuul side?18:26
clarkbalso slightly worried this is complicated enough we are likely to run manage projects with the wrong version of projects.yaml at some point18:27
clarkbmordred: maybe we should have the manual side use /home/zuul/src too?18:27
clarkbthen we are always in sync with the last zuul run18:27
clarkb(that could be racy though)18:27
mordredclarkb: I don't think we should have anything update the non-zuul side18:28
mordredI think that's purposefully manual18:28
mordredset system-config (and optionally project-config) to the ref you want18:28
clarkbmordred: I worry that we'll run manage projects manually assumign its up to date18:28
mordredI think we shoudl not do that :)18:28
mordredbut - I mean - we can certainly add a sync18:29
mordredeasy enough to do18:29
clarkbmordred: maybe we should invert the default path. Make the default zuul then force manual users to point at what they know to be accurate?18:29
mordredI'm just arguing we shouldn't do it because it's most of the time work that's not needed, and it only causes us to need to be careful to put bridge into the disabled list if we want to do something manually18:29
mordredclarkb: that's a good idea18:29
mordredclarkb: and I can get behind that18:29
mordreddefault empty basically18:30
clarkbya18:30
mordredif you want to run manage-projects by hand, pass -eproject_config_src18:30
mordredone sec, fixing18:30
clarkbthat way its clear you need to do the extra step18:30
clarkbbecause the current default is almost never what you want unless you've taken extra steps18:30
openstackgerritMonty Taylor proposed opendev/system-config master: Use project-config from zuul instead of direct clones  https://review.opendev.org/71934318:32
mordredclarkb: totally agree18:32
corvusmordred: are you saying we would need to install https://www.xpra.org/trac/attachment/ticket/2097/_sshfp_policy.py in the ansible running on bridge in order for sshfp to help?18:35
mordredclarkb: or - do you think, if it's not set, we should clone latest to project-config and then use that?18:35
mordredcorvus: yeah - I think so18:35
mordredcorvus: which means I think it's not very useful18:35
mordredcorvus: oh - well, not ansible - doesn't ansible use openssh?18:36
mordredcorvus: I think we'd have to install it in jeepyb if we wanted to use sshfp for jeepyb scripts instead of installing host keys for them18:36
mordredfor openssh we could just set the config value in /etc/ssh18:36
corvusmordred: oh, yeah.  well, that seems like a big win then.18:37
corvusand the jeepyb thing is fixable by us to, so that should catch the last 5%18:37
mordredcorvus: should we add that to zuul?18:37
corvusmordred: where?18:38
mordredin gerritlib I guess18:38
corvusah yeah, that's a good idea18:38
clarkbmordred: I think if it isn't set thats a good cue to the human to be specific about what they want18:38
mordredclarkb: kk18:38
clarkbmordred: we can even add a note about it in the readme so that when it fails and they go looking they get that info18:38
openstackgerritMonty Taylor proposed opendev/system-config master: Add asserts about project_config_src  https://review.opendev.org/71966518:38
mordredclarkb: ^^ there's an assert18:38
openstackgerritMerged opendev/system-config master: Add self host keys to known_hosts on gerrit  https://review.opendev.org/71956818:42
clarkbmordred: k I'm figuring out lunch and will rerevie stack after18:42
mordredcool18:42
openstackgerritMonty Taylor proposed opendev/system-config master: Update install-ansible away from /opt/system-config  https://review.opendev.org/71918619:22
openstackgerritMonty Taylor proposed opendev/system-config master: Run playbooks out of zuul checkout  https://review.opendev.org/71919019:22
openstackgerritMonty Taylor proposed opendev/system-config master: Use project-config from zuul instead of direct clones  https://review.opendev.org/71934319:22
openstackgerritMonty Taylor proposed opendev/system-config master: Add asserts about project_config_src  https://review.opendev.org/71966519:22
openstackgerritTristan Cacqueray proposed zuul/zuul-jobs master: use-buildset-registry: wait for kubernetes service to be available  https://review.opendev.org/71967319:27
*** olaph has quit IRC20:01
*** olaph has joined #opendev20:01
*** olaph has quit IRC20:02
clarkbmordred: stack lgtm though I left another ocmment on https://review.opendev.org/#/c/719343/920:14
clarkbbasically I think the current setup of setting the var always but only consuming (and having the repo present) in a small subset of cases may be confusing20:15
clarkband if we add more of those cases chances of getting it wrong are higher than just having the repo update each time20:15
openstackgerritMerged zuul/zuul-jobs master: use-buildset-registry: wait for kubernetes service to be available  https://review.opendev.org/71967320:19
clarkbhttps://zuul.opendev.org/t/openstack/build/5622bbf19fa54ad1ac448778f2846a09/log/job-output.txt#48525 the joys of upgrading. Good thing we have tests20:19
clarkbnow to see if there are other places where we rely on the names being static20:19
clarkbmordred: also any idea if that is dangerous for the running services?20:19
clarkbugh20:19
openstackgerritClark Boylan proposed opendev/system-config master: Install docker-compose from pypi  https://review.opendev.org/71958920:27
openstackgerritClark Boylan proposed opendev/system-config master: Use HUP to stop gerrit in docker-compose  https://review.opendev.org/71905120:27
clarkbI'm going to WIP ^ until we can think about if/how the container names will affect our running services.20:28
clarkbmordred: corvus ^ you might have existing setup that can test that quickly? Basically I think we want to know if `docker-compose up` on new version of docker-compose will properly stop the old container then start the new containers with the name transition (and everything else that ahs changed)20:29
*** olaph has joined #opendev20:30
clarkbotherwise we might have to do a stop on the old version and a start on the new?20:30
clarkbI'm trying to construct a change that will test it in zuul now20:31
openstackgerritClark Boylan proposed opendev/system-config master: DNM Test docker-compose upgrade  https://review.opendev.org/71968220:44
clarkbI think ^ may cover this for us, its weird because we really need old and new verification to be split but we should be able to infer if its generally working or not even if the test cases fail20:44
mordredclarkb: was on phone - reading scrollback21:00
mordredclarkb: oh fun! (re: naming)21:00
mordredclarkb: I don't know the answer to the upgrade question21:00
clarkbmordred: I think I hacked together a thing that will test it reasonably well at https://review.opendev.org/71968221:01
clarkbso we can watch that space and see what happens?21:01
clarkbits possible I need to edit more files so that more jobs run but one step at a time21:01
mordredclarkb: I agree - I think that should tel us some things21:01
openstackgerritMonty Taylor proposed opendev/system-config master: Write project_config_src in a vars file per job  https://review.opendev.org/71968521:13
mordredclarkb: ^^ what do you think about the shape of that?21:13
openstackgerritClark Boylan proposed opendev/system-config master: DNM Test docker-compose upgrade  https://review.opendev.org/71968221:17
clarkbmordred: ^ I needed to make mroe changes so that more jobs would run21:17
mordredclarkb: ++21:18
mordredclarkb: the thing above is my stab at addressing your issue with the var being set on the base job but only used sometimes21:18
clarkbmordred: +2 I like that makes it explicit to those jobs21:18
clarkbrather than half global21:18
mordredyeah - and gives us a mechanism ot pass arbitrary vars, rather than hardcoding that one21:19
mordredclarkb, corvus : hrm. the change I made to update the gitea homepage template is resulting in failed run-gitea job - and I don't understnad what's broken yet21:28
mordredwouldn't mind an extra set of eyes21:29
clarkbmordred: have a link?21:29
mordredhttps://zuul.opendev.org/t/openstack/build/07034064f75e43ee94c567e6e0297c8921:29
clarkbmordred: https://zuul.opendev.org/t/openstack/build/07034064f75e43ee94c567e6e0297c89/log/gitea99.opendev.org/docker/giteadocker_gitea-web_1.txt#129 it can't find its cert21:30
clarkbmordred: did you remove the LE test machinery maybe?21:31
clarkbor possible that le dev just failed21:31
mordredhrm. I don't _think_ I removed it21:31
clarkbmordred: the LE test machinery talks to LE's dev servers and expects everything to "work" then it provides a self signed cert from the server itself21:32
clarkbif LE dev servers fail then I think we may fail in that way21:32
mordrednod21:32
mordredclarkb: how do we see that failure?21:33
mordredclarkb: https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_070/718764/1/gate/system-config-run-gitea/0703406/bridge.openstack.org/ara-report/result/61eccc7c-e562-420d-960f-87795f5e20d1/21:34
mordredthere's the running of acme.sh21:34
clarkbmordred: https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_070/718764/1/gate/system-config-run-gitea/0703406/bridge.openstack.org/ara-report/reports/e6f93bce-d23d-4b7b-87af-c95f0a41bdda.html21:35
clarkbthats green though21:35
clarkbso maybe that didn't fail21:35
mordredyeah- but cert.pem not being there does seem like a red flag21:39
mordredsince we should be bind-mounting it in21:39
clarkbmordred: ya LE creates the file in /etc/lesomething21:39
clarkbthen we run a handler that is supposed to copy it to /var/gitea/something21:39
clarkbmaybe that handler idnd't fire21:39
mordredclarkb: well - actually21:39
mordredoh, you already said21:39
mordredclarkb: it doesn't look like handlers log very well21:39

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