Thursday, 2021-04-15

*** ianychoi has joined #zuul00:46
*** hamalq has quit IRC01:00
*** fsvsbs has quit IRC01:11
*** rlandy|rover|bbl is now known as rlandy|rover01:53
openstackgerritJames E. Blair proposed zuul/zuul-operator master: Flake8 cleanups  https://review.opendev.org/c/zuul/zuul-operator/+/78634901:54
*** aluria has quit IRC01:56
*** aluria has joined #zuul02:00
*** rlandy|rover has quit IRC02:26
*** evrardjp has quit IRC02:33
*** evrardjp has joined #zuul02:33
openstackgerritJames E. Blair proposed zuul/zuul master: Keep jobgraphs frozen across reconfiguration  https://review.opendev.org/c/zuul/zuul/+/78553602:39
*** bhavikdbavishi has joined #zuul03:10
*** bhavikdbavishi1 has joined #zuul03:43
*** bhavikdbavishi has quit IRC03:44
*** bhavikdbavishi1 is now known as bhavikdbavishi03:44
*** ykarel has joined #zuul03:45
*** bhavikdbavishi has quit IRC04:21
*** vishalmanchanda has joined #zuul04:23
*** bhavikdbavishi has joined #zuul04:52
*** bhavikdbavishi has quit IRC04:56
*** bhavikdbavishi has joined #zuul05:07
*** sshnaidm|pto has quit IRC05:47
*** sshnaidm|pto has joined #zuul05:48
*** ykarel has quit IRC06:00
*** ykarel has joined #zuul06:00
*** saneax has joined #zuul06:31
*** icey has quit IRC06:34
*** icey has joined #zuul06:35
*** bhavikdbavishi has quit IRC06:35
*** saneax has quit IRC06:36
*** jcapitao has joined #zuul06:37
*** jcapitao has quit IRC06:37
*** jcapitao has joined #zuul06:39
*** bhavikdbavishi has joined #zuul06:40
*** ykarel_ has joined #zuul06:49
*** reiterative has quit IRC06:49
*** reiterative has joined #zuul06:50
*** ykarel has quit IRC06:51
*** jpena|off is now known as jpena06:55
*** bhavikdbavishi has quit IRC06:57
*** bhavikdbavishi has joined #zuul07:11
*** bhavikdbavishi has quit IRC07:25
*** bhavikdbavishi has joined #zuul07:26
*** ykarel_ is now known as ykarel07:30
*** bhavikdbavishi1 has joined #zuul07:44
*** rpittau|afk is now known as rpittau07:45
*** bhavikdbavishi has quit IRC07:46
*** bhavikdbavishi1 is now known as bhavikdbavishi07:46
*** tosky has joined #zuul07:46
*** nils has joined #zuul08:04
*** ykarel is now known as ykarel|lunch08:33
*** vishalmanchanda has quit IRC09:27
*** saneax has joined #zuul09:29
*** ykarel|lunch is now known as ykarel09:38
*** dpawlik9 has quit IRC09:46
*** vishalmanchanda has joined #zuul09:48
*** jcapitao has quit IRC09:53
*** dpawlik4 has joined #zuul09:59
*** jcapitao has joined #zuul10:01
*** bhavikdbavishi has quit IRC10:07
*** jcapitao is now known as jcapitao_lunch10:28
*** ykarel_ has joined #zuul10:29
*** ykarel has quit IRC10:32
*** ykarel_ has quit IRC10:44
*** ykarel_ has joined #zuul10:45
*** ykarel_ is now known as ykarel11:15
*** jpena is now known as jpena|lunch11:31
*** rlandy has joined #zuul11:46
*** rlandy is now known as rlandy|rover11:46
*** ykarel_ has joined #zuul11:54
*** ykarel has quit IRC11:56
*** rlandy|rover is now known as rlandy|rover|mtg12:01
*** ykarel_ is now known as ykarel12:02
*** jcapitao_lunch is now known as jcapitao12:03
*** bhavikdbavishi has joined #zuul12:29
*** bhavikdbavishi1 has joined #zuul12:32
*** jpena|lunch is now known as jpena12:33
*** bhavikdbavishi has quit IRC12:33
*** bhavikdbavishi1 is now known as bhavikdbavishi12:33
*** rlandy|rover|mtg is now known as rlandy|rover12:42
*** bhavikdbavishi has quit IRC12:43
lyrHi there12:49
lyrGitta migrate secret between two zuul, how can I do that ?12:49
corvuslyr: re-encrypt it for the other zuul, or if you are migrating the whole zuul system and you manage both, then copy the secret keys from the scheduler13:30
lyrI was willing to decrypt on the old & encrypt on the new (to avoid looking everywhere sfor the original secrets), but I can't get this decrypt script https://review.opendev.org/c/zuul/zuul/+/639771 to work13:58
openstackgerritAndy Ladjadj proposed zuul/zuul master: [reporter][elasticsearch] ensure the @timestamp as export with UTC format in case of system has a different timezone  https://review.opendev.org/c/zuul/zuul/+/78644414:04
openstackgerritAndy Ladjadj proposed zuul/zuul master: [reporter][elasticsearch] ensure the @timestamp as export with UTC format in case of system has a different timezone  https://review.opendev.org/c/zuul/zuul/+/78644414:08
openstackgerritFelix Edel proposed zuul/zuul master: Switch to ZooKeeper backed build result events  https://review.opendev.org/c/zuul/zuul/+/78293914:25
*** avass has quit IRC14:42
*** avass has joined #zuul14:43
avasswhen onboarding an organization I noticed that they've structured their repos like <product>, <product>/<component-1> and <product>/<component-2> and I have a feeling that's going to cause some problems in zuul14:45
avassbest case zuul is probably going to delete merger/executor cache a lot, worst case we're gonna be seeing a lot of MERGE_FAILURE or executor errors when setup up the workspace :/14:46
fungiare the projects in gerrit? github? something else?14:47
fungijust curious how the hosting backend handles that14:47
fungiseems like it would similarly conflict in gerrit14:48
avassit's gerrit14:48
fungiany idea how that looks on the gerrit server's filesystem?14:48
avassno clue since we're not hosting any gerrit instance ourselves14:48
avassI would expect other tools like golang to have problems with that as well14:48
fungiyeah14:49
corvusavass: zuul uses golang-style repo layouts, so that will definitely cause issues, though it's not clear to me right now how significant those issues will be14:49
fungiahh, nevermind, gerrit's using bare repos (at least in our deployment), so even though git repositories are in a common file tree, there would be a review_site/git/<product>.git and a review_site/git/<product> directory and they wouldn't conflict14:50
avassme neither, but a nested git repos shows up as a dirty state so that's why I'm guessing that a "parent" repo could cause problems by doing a git clean14:50
corvusavass: is moving product -> product/main  or something an option?  that would almost certainly be best14:50
avasscorvus: I'm checking that with them right now but I have a feeling that they could have a lot of tools dependent on that structure14:51
avassfungi: ah right of course14:51
corvusthere's two things to consider from zuul's pov: the mergers and what zuul checks out for a job in the workspace.  it's probably not too difficult to make the mergers safe for this.  but i have a really hard time thinking that we would be able to actually articulate what a workspace checkout should look like in that case14:53
corvuslike, i'm not sure we would be okay saying that zuul should dirty one git repo checkout with another14:53
mordredyeah14:54
corvus(and it's possible that it could be extremely difficult/impossible to actually get zuul to do that even if we wanted to)14:54
mordredmaybe a (mostly very hidden) option to have workspace checkouts append a .git suffix?14:55
fungialso gerrit could probably similarly break if you had projects named foo and foo.git/bar, so i don't think working around it by suffixing the repository names is necessarily a solution14:55
mordred(I can't even begin to imagine all the things that would break though)14:55
mordredfungi: good point14:55
fungiyeah, probably the only real way to address it would be to make the directory tree something like a sha256 hash of each repository name rather than the actual name14:56
corvusoff the top of my head, if we had to make this work, i think about the only thing we could do is sort of completely punt and do something like ^14:56
fungiand at least then you're down to sha2-256 hash collisions14:56
mordredwhat about an explicit aliasing?14:56
corvusbasically, rename the repo14:56
corvus(in the zuul checkout)14:56
mordredso that someone could configure zuul with a real-name to checkout-name mapping for a project14:57
fungithe git prep role would also have to keep that structure on job nodes/workspaces14:57
fungiwhich means jobs get more complicated since you need a lookup method to sha256sum the name14:58
mordredthen for that org, they could add a config saying project: project/main (for instance)14:58
mordredand there would only be the one impacted repo14:58
corvusmordred: yep.  then if they want to dirty up the repo, add a pre-playbook to move it in place.14:58
mordredyup14:58
mordredand if they're fine with that in their conent - no worries14:59
mordredI think it would want to be a mapping configured in zuul.yaml so that basically everywhere zuul is talking about that project it's talkign about it differently than gerrit is14:59
corvus++14:59
avassfungi: that could be solved by setting zuul.project.src_dir accordingly no?15:00
fungiwe do have similar "translate this branch name to this other branch name" options, so i suppose that would be somewhat consistent with how zuul does branch aliasing15:00
mordred++15:00
fungiavass: it could, but would require that jobs leverage that variable (maybe not the worst thing, but some folks do bake repository names into job definitions)15:01
fungithe checksum solution would be non-backward-compatible with existing job definitions15:02
clarkbme thinking out loud here: from a user experience perspective I think putting the burden on people who want to do weird esoteric things and otherwise making life easy is important. If we did aliasing or mapping of repos it would be good to not apply it globally imo15:03
corvusclarkb: yes, i agree; that is the assumption i'm working from15:04
fungii suppose if the checksum method were desirable, it could have a compatibility method in the git prep role to put the directories in the "legacy" readable directory names15:04
fungiclarkb: yep, that's how the branch aliasing works now too15:04
fungiso i agree, there's precedent for mordred's suggestion15:05
corvusi don't think we should do anything with checksums in the workspace checkout.  it's a useful way to think about the problem (renaming the repo).  it might be part of how we solve the merger side of the problem.15:05
fungialso we'd need to change how project keys are stored right? (or does zk solve that?)15:06
corvusfungi: i think keys are okay (both before and after zk), but worth double checking15:06
corvusjust because they're like "/connection/project/0.key" and "/connection/project/component/0.key"15:07
fungioh, yeah you'd end up with foo/keys... and foo/bar/keys... coexisting in a nested tree, but not a problem unless we had projects named like the key files themselves15:07
avasslooks like renaming their repos is not an option :/15:07
corvusyep.  basically exactly like gerrit15:07
openstackgerritJames E. Blair proposed zuul/zuul-operator master: Flake8 cleanups  https://review.opendev.org/c/zuul/zuul-operator/+/78634915:29
*** saneax has quit IRC15:34
*** xarragon has joined #zuul15:46
*** ykarel has quit IRC15:47
*** bhavikdbavishi has joined #zuul15:48
*** bhavikdbavishi has quit IRC15:53
*** hamalq has joined #zuul16:00
*** hamalq has quit IRC16:02
*** hamalq has joined #zuul16:02
*** jpena is now known as jpena|off16:05
*** jcapitao has quit IRC16:06
*** rpittau is now known as rpittau|afk16:09
clarkbcorvus: looks like testing failed on the end of the consistent buildset revs stack. I think you mentioned the last two needed to be squashed but I would expect the last one to pass testing in that case16:17
clarkboh I see tobiash  mentions linter issues /me should look closer :)16:17
corvusclarkb: yeah, it's just linting; do you want to go ahead and +/-1 that and then i'll fix and squash?16:27
clarkbcorvus: ya I'm running some gerrit account cleanups then will dive into proper review after16:29
corvuscool, no rush16:29
*** nils has quit IRC17:10
corvusclarkb, ianw: the gerrit zuul plugin can be enabled/disabled in the gui: https://imgur.com/a/ElHmyy517:29
corvus(2nd picture is just to show the tooltip)17:30
clarkbcorvus: ya that is a frontend to the project acl file I think (the contributor agreement stuff above goes in the file too)17:31
corvusyep; not *everything* can be changed through the gui, so i thought it notable that this can be17:58
openstackgerritAlbin Vass proposed zuul/nodepool master: WIP: Digitalocean driver  https://review.opendev.org/c/zuul/nodepool/+/75955918:03
clarkbcorvus: ok I left a couple of comments on that stack18:05
clarkbcorvus: oh ya18:05
*** vishalmanchanda has quit IRC18:27
*** holser has quit IRC18:47
corvusclarkb: thx, replied.19:07
corvusclarkb: regarding your comment about the test; do you have a test for that?19:07
clarkbcorvus: https://review.opendev.org/c/zuul/zuul/+/784142/1/tests/unit/test_merger_repo.py is what I put together to test that but I'm not sure how valid it is with the alternative appraoch we have agreed on19:10
*** hamalq has quit IRC19:17
*** rlandy|rover is now known as rlandy|rover|mtg19:28
*** holser has joined #zuul19:28
*** hamalq has joined #zuul19:31
clarkbcorvus: your responses made sense to me thanks19:40
corvusclarkb: thanks, i'll look into adding that test19:44
*** rlandy|rover|mtg is now known as rlandy|rover19:56
*** rlandy|rover is now known as rlandy|rover|bbl22:33
*** tosky has quit IRC22:34
openstackgerritJames E. Blair proposed zuul/nodepool master: Log decline reason at info  https://review.opendev.org/c/zuul/nodepool/+/78651323:25

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!