Wednesday, 2020-07-22

*** ryohayakawa has joined #opendev00:13
openstackgerritSean McGinnis proposed opendev/bindep master: Fix formatting issues in docs
*** Dmitrii-Sh has quit IRC00:25
*** Dmitrii-Sh has joined #opendev00:29
ianw ... dropped a comment offering some arm64 support00:31
ianwhrm, it's been pointed out that the zuul app wants write access00:37
clarkbI think because in an ideal world it will do merges, but for third party ci thats likely too much00:38
clarkbI'm guessing github doesnt let us tune that per install00:38
clarkbthere is likely something we can do about that  maybe just drop write becausenothing we do against github is using zuul to merge?00:39
clarkbthen if that changes it gets the write access app install?00:39
clarkbI find githubs app system confusing...00:40
ianwyeah, i can certainly understand people being hesitant to give write even if we say we're not going to use it00:42
clarkbyup and since nothing ended up using write (it waskata we expected to useit iirc) wecan probbaly just drop it for now and revisit later if things change00:43
openstackgerritIan Wienand proposed openstack/project-config master: Add pypa/cryptography to zuul config
ianwclarkb: ^ i'm thinking maybe a POC job in opendev-jobs is a good start00:46
clarkb++ wecan show them what it looks like without reporting or the app00:47
clarkbreporting to github I mean. But Im no longer at laptop so may have to review in the morning00:47
ianwok that just adds it to zuul config; i may just go with that to get things moving.  should be able to gate test the rest00:48
fungiapparently the dco-check job for the kata-containers tenant was using the cmd module on the executor01:15
fungiso i think we're now marking all their pull requests as not having signed-off-by01:17
ianwbummer.  i doesn't seem worth a node though, what exactly does it do?01:17
ianwi guess it needs to be a protected job?01:19
fungilikely. i'm getting in trouble for being on the computer now, but can probably look at it tomorrow01:28
openstackgerritIan Wienand proposed openstack/project-config master: Add pyca/cryptography to zuul config
dmsimardI don't know if there's a lot of things using ara-report but it's failing due to new zuul localhost command execution and sent most ara jobs in POST_FAILUREs :(02:52
dmsimardfor example:
openstackgerritIan Wienand proposed openstack/project-config master: Add repo for pyca/cryptography Zuul jobs
*** redrobot has quit IRC03:42
openstackgerritIan Wienand proposed openstack/project-config master: Add repo for pyca/cryptography Zuul jobs
ianwclarkb / infra-root: the arm64 testing for pyca/cryptography is i think on the right track.  see updates in  a few things on our plate to sort out re the github app and our job repos04:23
*** raukadah is now known as chandankumar05:10
openstackgerritIan Wienand proposed zuul/zuul-jobs master: Revert "Enable tls-proxy in ensure-devstack"
openstackgerritIan Wienand proposed openstack/diskimage-builder master: DNM: test revert of tls-proxy change
*** ryohayakawa has quit IRC05:37
*** ryohayakawa has joined #opendev05:38
*** marios has joined #opendev05:39
*** DSpider has joined #opendev06:06
*** iurygregory has joined #opendev06:25
*** elod is now known as elod_off06:31
*** qchris has quit IRC06:51
*** qchris has joined #opendev07:05
*** dougsz has joined #opendev07:35
*** tosky has joined #opendev07:39
*** marios has quit IRC07:48
openstackgerritMerged zuul/zuul-jobs master: Add upload-logs-s3
*** fressi has joined #opendev07:50
*** moppy has quit IRC08:01
*** moppy has joined #opendev08:01
*** ryohayakawa has quit IRC08:03
*** tosky has quit IRC08:04
*** tosky_ has joined #opendev08:04
*** tosky_ is now known as tosky08:19
*** ryohayakawa has joined #opendev08:28
AJaegerfungi, clarkb, ianw: ricolin proposes in a couple of arm64 jobs, some advise from you would be welcome there, please08:40
*** ryohayakawa has quit IRC08:44
*** marios has joined #opendev08:50
*** ryohayakawa has joined #opendev08:50
*** dtantsur|afk is now known as dtantsur08:52
*** sgw1 has quit IRC08:54
*** sgw has joined #opendev09:17
*** ryohayakawa has quit IRC09:20
*** fressi has quit IRC09:47
openstackgerritThierry Carrez proposed opendev/irc-meetings master: Rotate Large Scale SIG meeting
*** priteau has joined #opendev10:33
*** tkajinam has quit IRC10:59
*** sshnaidm is now known as sshnaidm|afk11:14
*** bolg has joined #opendev12:03
*** rm_work has quit IRC12:38
*** mordred has quit IRC12:40
*** Eighth_Doctor has quit IRC12:40
*** rm_work has joined #opendev12:42
*** fressi has joined #opendev12:42
*** mordred has joined #opendev12:49
*** Eighth_Doctor has joined #opendev13:20
*** sshnaidm|afk is now known as sshnaidm13:29
openstackgerritTristan Cacqueray proposed zuul/zuul-jobs master: dco-license: remove the empty nodeset
*** qchris has quit IRC13:52
openstackgerritJames E. Blair proposed zuul/zuul-jobs master: Temporarily disable tag cleanup in docker promote
*** paladox has quit IRC14:32
*** dougsz has quit IRC14:34
*** mlavalle has joined #opendev14:44
openstackgerritTristan Cacqueray proposed zuul/zuul-jobs master: dco-license: remove the empty nodeset
*** dougsz has joined #opendev14:49
*** paladox has joined #opendev14:53
*** qchris has joined #opendev15:01
*** cmurphy_afk is now known as cmurphy15:07
openstackgerritMerged zuul/zuul-jobs master: Temporarily disable tag cleanup in docker promote
openstackgerritMerged zuul/zuul-jobs master: dco-license: remove the empty nodeset
*** factor has joined #opendev15:26
openstackgerritJames E. Blair proposed zuul/zuul-jobs master: Reinstate docker tag cleanup
*** zbr|rover is now known as zbr15:58
*** shtepanie has joined #opendev16:01
*** factor has quit IRC16:08
*** factor has joined #opendev16:09
*** marios is now known as marios|out16:12
*** marios|out has quit IRC16:13
*** dougsz has quit IRC16:30
*** dtantsur is now known as dtantsur|afk16:35
*** factor has quit IRC16:39
*** factor has joined #opendev16:40
*** factor has quit IRC16:40
*** fressi has quit IRC16:41
*** factor has joined #opendev17:04
*** sshnaidm is now known as sshnaidm|afk17:09
*** sshnaidm|afk has quit IRC17:23
*** sshnaidm has joined #opendev17:27
*** sshnaidm is now known as sshnaidm|afk17:27
*** icarusfactor has joined #opendev18:07
*** icarusfactor has left #opendev18:08
*** factor has quit IRC18:09
openstackgerritDmitriy Rabotyagov (noonedeadpunk) proposed openstack/project-config master: Remove os_congress gating
openstackgerritmelanie witt proposed openstack/project-config master: Update ceph grafana for nova
openstackgerritClark Boylan proposed zuul/zuul-jobs master: Collect partial subunit files
openstackgerritDmitriy Rabotyagov (noonedeadpunk) proposed openstack/project-config master: Remove os_congress gating
openstackgerritDmitriy Rabotyagov (noonedeadpunk) proposed openstack/project-config master: Remove os_congress gating
openstackgerritClark Boylan proposed zuul/zuul-jobs master: Collect partial subunit files
openstackgerritDmitriy Rabotyagov (noonedeadpunk) proposed openstack/project-config master: Revert "Remove os_congress gating"
openstackgerritClark Boylan proposed zuul/zuul-jobs master: Collect partial subunit files
openstackgerritClark Boylan proposed zuul/zuul-jobs master: Disable workspace setup testing
openstackgerritClark Boylan proposed zuul/zuul-jobs master: Disable workspace setup testing and cleanup z-c testing
openstackgerritClark Boylan proposed zuul/zuul-jobs master: Collect partial subunit files
*** priteau has quit IRC20:47
openstackgerritClark Boylan proposed zuul/zuul-jobs master: Disable base role testing that runs code on localhost
openstackgerritClark Boylan proposed zuul/zuul-jobs master: Collect partial subunit files
mnaserinfra-root: message on openstack-discuss about being down (and i confirm it)21:05
fungimnaser: thanks, i'll see if i can spot the problem21:15
fungiresponds to ping, but ssh hangs after key exchange. likely a disk issue, i'll check the console21:16
ianwsounds like eavesdrop the other day; may be they're on the same host/rack/data centre/universe21:18
fungilooks like snmpd stopped responding between 19:30 and 19:3521:18
fungiianw: also like zm03, zm04 and zm07 on monday21:19
fungiyeah, similar to what i saw on the mergers21:20
fungikernel messages about hung tasks, not sure how long ago, but carriage return doesn't give me a new login prompt21:20
fungitime to force reboot via api21:21
ianwclarkb: can you look at ... it seems the change to tls-proxy has broken the dib gate.  jobs just time out now; tested with
openstackgerritClark Boylan proposed zuul/zuul-jobs master: Disable base role testing that runs code on localhost
openstackgerritClark Boylan proposed zuul/zuul-jobs master: Collect partial subunit files
corvusianw: regarding
corvusianw: at this point, i don't think it's a huge deal to allow in-repo config on github.  the main issue is that if they aren't gating, they can create zuul config errors in that tenant.21:24
corvusianw: what tenant do you want to add them to?21:24
ianwi don't know, that's all up for discussion21:24
fungi#status log hard rebooted ask.o.o after it was hung for nearly two hours21:25
openstackstatusfungi: finished logging21:25
corvusianw: regarding the second question -- you say the token thing is intractable -- why?  can't we just both use the same token?21:25
fungiask.o.o is back up, replying to the ml now21:25
ianwcorvus: i doubt they're going to give us the token is the thing21:25
corvusianw: well they don't have to give it to us, they can encode it into their repo (though our admins would be able to decrypt it)21:25
clarkbianw: they can encrypt it as a project secret which is likely similar to how they do coverage with other ci providers21:26
clarkband ya admins can get at it which is the same for travis etc21:26
ianwright, but i think they want to run it in effectively check queue?21:26
corvusthat's fine -- do the upload in a trusted post-playbook21:26
clarkbianw: if there is no trigger for jobs then ya it gets trickier21:26
clarkber no explicit human trigger for jobs21:26
corvusclarkb: why is it tricky?21:26
corvusthe trigger is PR created21:27
corvusit's a check queue21:27
clarkbcorvus: yes, but are we going to make their repo a trusted repo on github?21:27
corvusno, we wouldn't define the job in their repo21:27
clarkbright they seem opposed to that21:27
corvusi mean we're not going to define the base job in their repo either21:28
corvusi don't get it21:28
corvuszuul is designed for this21:28
corvusthe uploading part happens in a trusted playbook21:28
fungisounds like they want something which isn't zuul21:28
corvusthe generate the coverage happens in their repo21:28
corvusfungi: i completely disagree21:28
corvusthis is *exactly* what zuul was designed for and it's *exactly* how we used it21:28
corvussplit trust horizons21:28
fungii mean, if they object to any job configuration existing outside their repository, then it sounds like they want something which is either their own zuul or not zuul at all21:29
corvusi don't think they said that21:29
clarkbcorvus: having read other bugs, one of their explicit concerns is that they have as much control as possible (because they provide security adjacent tooling). That coupled with the comments from alex on the issue imply to me that they wouldn't be happy to have a gerrit repo somewhere else with other approvers controlling access to things like that, but I may be wrong21:29
corvusthey don't have complete control over travis either21:29
clarkbcorvus: yes but they feel they do21:29
corvusi think we should avoid jumping to conclusions21:30
clarkbwe're a lot more explicit about the split21:30
clarkbif we can explain that then maybe we can work with it21:30
ianwyeah, i think even the fact that zuul admins can decrypt the key *might* be too much21:30
clarkb"in travis its a db lookup you don't control, in zuul its a git repo you don't control"21:30
corvusso can travis/github/etc21:30
fungilikely the open source nature of the platform is the problem there. with travis they don't have to think about how much control the travis admins have over their software because they can't see it21:30
clarkbfungi: yes21:30
corvusthis is alex gaynor we're talking about here21:30
fungii do think he's likely to listen to a reasoned argument21:31
ianwi also think travis has some sort of magic connection with codecov and git hub.  somehow if you have a public repo i think you don't need to share the key to upload to it21:31
corvushe's not exactly ignorant about open source / proprietary software and inherent security tradeoffs21:31
clarkbprobably the thing to do is describe what it looks like in zuul, explain that fundamentally other CI systems expose similar concerns just with different shapes/colors/etc21:31
clarkbianw: that wouldn't surprise me21:32
fungialso that zuul abstracts much more of its control logic out into "configuration" where similar logic may be hardcoded in other platforms21:32
ianwright; also on a tangent i find it a bit ... i don't know, annoying, for an open source project to reject a completely open source CI solution providing value in an uncovered area over integration with a closed-source thing21:32
corvusanyway, i've read the tickets, and none of this is technically impossible, and i feel like it would meet their requirements.  i'm unclear how this fits into our policy21:32
ianwthat said -- it's not a hard reject yet.  just the start of a discussion21:32
ianwright, for us to sort out first is the write access on the zuul github bot21:33
ianwwe'll either need to turn that off, or as pabelanger suggests, start another one that's targeted at R/O CI21:34
openstackgerritClark Boylan proposed zuul/zuul-jobs master: Disable base role testing that runs code on localhost
openstackgerritClark Boylan proposed zuul/zuul-jobs master: Collect partial subunit files
clarkbianw: since we've got no github projects trying to do gating I think we can change the existing installation21:35
ianwi *do* feel like this is a pretty good opportunity for zuul/opendev to expand itself21:35
clarkbbasically all of that was there with the intent of being able to gate things and since then every single projcets has said they don't want that21:36
clarkb(granted the number is small)21:36
fungifor opendev ci with external code hosting policy, what we've asserted in the past is that if what's being tested is in the context of a project hosted in opendev then running such jobs against and reporting back to proposed changes for projects hosted outside opendev is fine21:37
clarkbcorvus: from a policy side it feels a lot like third party ci, its a tool that is consumed by openstack and zuul and we've been struggling with it in both contexts on arm6421:37
clarkbwhere its less third party is in giving them more control over the job details21:38
corvusright, there's which it meets21:38
clarkbgiven their security concerns I think that is a reasonable compromise in this case21:38
clarkb(because they want to trust the results of the CI and make actiosn on it like subsequently publish arm64 wheels)21:38
corvuswe've also discussed in the past that maybe we don't just want to be a free github ci system21:38
clarkbya, and one of the issues there has been a lack of involvement from the other side. Basically it breaks, they say nothing, don't ask for help, then just turn it off and complain about us.21:39
fungiright, that's where the "in the context of a project hosted in opendev" part comes in21:39
ianwi feel like from the spirit of what linaro is providing the underlying resources for, helping fix what is clearly a pain-point (no aarch64 wheels for a very common package) would, in this case, be a good use of their resources21:40
fungiit's not really a free github ci if what we're testing is whether a change to cryptography is going to break something hosted in opendev21:40
corvuswhat tenant would we put it in?21:40
*** shtepanie has quit IRC21:41
ianwi was originally thinking adding config to a project under opendev, but if that's not going to fly upstream, not sure21:41
clarkbcorvus: I'm not sure I know the answer to that yet because I'm still a bit confused about how the codecov thing would work21:41
corvusianw: who's upstream?21:41
ianwpyca/cryptography team21:41
clarkbfrom a third part ci agnel I think it belongs in openstack or zuul21:41
ianw to be concrete was what i was thinking21:42
corvusclarkb: i don't think it belongs in zuul21:42
clarkbok I'm just listing those two as they are consumers of it currently hurting from the lack of cryptography wheels21:42
corvusthis is really incidental to zuul -- afaict, opendev itself may be the only zuul user interested in using the nodepool builder arm image21:42
ianwi felt like opendev is providing these resources, and installing cryptography from a wheel is a basically a generic thing anyone would do21:42
clarkbopenstack has also struggled with this21:43
ianwto me it feels like something opendev would be involved with as part of keeping the arm64 resources as broadly usable as possible21:43
clarkbianw: ya but the appraoch we've taken is that we're providing testing for things our users integrate with and we've hosted those integrations within the context of the opendev hosted project side. ansible ci is hosted in openstack21:43
clarkbianw: thats a fair point, its part of the ci system as well so ya I could see opendev being the hosting tenant as well21:44
corvusianw: (incidentally -- we don't need a new project to configure jobs for cryptography -- we can add it in the tenant's config-project, which is how we usually do this, eg for ansible)21:44
fungiso reading the suggestion in i expect we could start out with a non-reporting pipeline and show them the results, then let them decide whether they want it reporting on their pull requests21:45
ianwcorvus: yeah, my thinking was that we can give permissions on the repo to other people more easily if it's separated21:45
corvusfungi: i don't think reporting is an issue21:45
ianwso as a first step, are we in agreement to turn off the write access on the existing zuul github bot?21:46
ianwthat will at least give it a chance of being installed21:46
clarkbyes I don't think that will cause any problems. If we are concerned about it we can wait for kata to turn off (ttx made it sound like that would be happening tomorrow potentially) then change it21:47
clarkband that will better reflect how it is used even if cryptography doesn't add it21:48
fungii can't think of any reason we have for continuing to maintain write access for github, no. the kata experiment is nearly over at this point, and they never showed any interest in taking advantage of gating21:48
ianwok, i can look into that.  it will be one less thing21:49
fungi*if* we allow configuration in their repositories, we'll have to be comfortable with the idea that they could cause problems by, say, defining jobs which are also defined in gated repositories in gerrit (that would effectively render both projects broken, reight?)21:50
corvusthat sounds good to me.  i'll just note we should be really sure about that because if we give up the permission, it's going to be hard to get it back.21:50
corvusfungi: no, zuul handles errors like that now.  we'll just have config errors in that tenant.21:50
corvusthat's part of why i don't want it in the zuul tenant21:50
fungioh, got it. i was thinking in an existing tenant, yeah21:51
ianwcorvus: i feel like if we do want that, it will be a case of creating a second instance to do r/w21:51
clarkbcorvus: can you clarify that statement about github permissions? Do you just mean people won't want to add write perms back?21:51
clarkbianw: ya that is what I'm thinking too21:51
fungiso i agree a good policy would be dedicated tenant if we allow in-repo config21:51
clarkbfungi: well I'd argue dedicated tenant violates our third party ci assertion21:51
corvusclarkb: yes, we will have to go hat in hand if we find out we needed it for some other reason21:51
clarkbfungi: the whole point is we're tying the github side to something we've already got21:52
clarkband ya I guess it comes down to what configuration do they expect in their repo? enabling and disabling jobs? thats easy21:52
clarkbdefining jobs? thats potentially doable. Defining everything including the code coverage reporting that is maybe not doable?21:53
fungiclarkb: yeah, i don't think the dedicated tenant part makes it stop being a test in the context of opendev-hosted software, but giving them control over the job configuration (the reason we'd require it be a separate tenant) does21:53
ianware we talking ilke a "github" tenant, or as specific as a "pyca/cryptography" tenant?21:54
clarkbianw: I'm saying we shouldn't do that at all :P21:54
fungii think it would be a pyca-cryptography tenant21:54
fungiif we did it21:54
fungion the assumption that it wouldn't be the only one in that situation21:54
clarkbianw: I've suggested openstack and zuul. Zuul has said no. OpenDev also seems reasonable after you point out its a thing we need to run the ci system for arm as well21:54
clarkbI think that means we can put it in opendev or openstack and it will be ok.21:55
corvus(well, one zuul maintainer said no :)21:55
ianwyeah, which brings me back to my original question in #zuul :)  of ... what's the worst that can happen21:55
fungibut we can't safely do that if we allow them to define jobs in their github-hosted repo21:55
corvusdidn't i answer that?21:55
clarkbfungi: I think corvus is saying we can because the blast radius is limited?21:55
clarkbfungi: the tenant will have an error but not necessary road block?21:55
fungionly limited if they have a dedicated tenant21:56
corvusconfig errors are not fatal21:56
clarkbcorvus: that was what I thought21:56
corvusthey are unlikely to break anything else in that tenant21:56
fungiif they define a job which shadows a job we rely on to merge changes in our repos within the *same* tenant that seems like it could be a pain21:56
ianwright, only if they went out of their way to really create conflicting job names or something21:56
ianwbut, basically a syntax error type level is not going to stop reloading in general21:57
corvusbut they can make errors, and they could create config objects with names that could interfere with other projects ability to use them.  it's a bad idea to have multiple projects defining jobs in a tenant if those projects don't talk to each other.21:57
clarkbhrm, thats sort of making me think we'd need to define the jobs on our side then :/21:58
corvusfor a situation like this, where they want to define their own config and presumably don't want to participate in another community, they should probably have their own tenant21:58
clarkbya I agree whta they need/want is a tenant, but in my head that violates the rules we've asserted around being another github ci system21:58
clarkbbasically the intent of the github ci we do is to have groups work together and if we can't do that ...21:59
fungiagain i don't think it's the separate tenant which makes us become a free arbitrary github ci, it's the ability for a project hosted outside opendev to define/add jobs which does that22:00
clarkbfungi: which they want22:00
clarkb(I'm somewhat conflating the things because they are related in this case)22:00
corvusi think it's a stretch to say they want to define arbitrary jobs22:00
fungii agree, i'm just saying the separate tenant isn't the cause, it's just a side effect22:00
clarkbcorvus: you think they may just want to control what jobs are in their pipelines?22:01
ianw... to be fair, it might also have been a pithy statement fired off by one upstream project maintainer, who might be convinced otherwise if things are explained22:01
corvusmy read is they want control over this job22:01
fungiif a project hosted in opendev wants to perform certain tests against pull requests for pyca/cryptography then i think that's within our scope. if pyca/cryptography wants to perform certain tests against pull requests for pyca/cryptography that is less within our remit22:01
fungiit also might be an excellent topic to bring up with our advisory board, since that includes representatives from some of the organizations donating the resources which would be running those tests22:03
fungiless to get approval for this particular case, but more for helping provide input on some consistent policy around this sort of case22:04
corvusthis does seem worthwhile to me, and it's an unusual situation, since they seem unable to build wheels otherwise22:04
ianwfungi: i do see that point.  it feels a shame to have great arm64 resources, an awesome CI system and everything available to help push on something that would be widely of help but for it to fall apart over where config is kept22:05
fungii agree it seems like it could be a great way to help out another open source project on which many of our projects rely heavily, so coming up with a mutually agreeable solution would be excellent22:05
corvusi don't think it's over where config is kept; i think it's about our remit22:05
ianwi think they're not prepared to take the latency hit for travisci's arm64 support, which given how slow it was must be emulated i guess22:06
corvustaking donated resources and our time to support a standalone project from another community in a different development ecosystem -- we should have a good reason for doing that22:07
fungii think the case can be made that we're relying heavily on arm support in cryptography and want to make sure that continues to work, and i could certainly see us agreeing with whatever job selections the cryptography maintainers think would accomplish that22:07
ianwright, as i said i think if you asked linaro "are you happy your donated resources are being used to push arm64 wheels more broadly so that people can use the arm64 python ecosystem more easily" the answer would be yes22:08
fungiwhere i start to have trouble justifying it is when we just hand over the reins with no oversight and tell them to go hog wild22:08
fungibut ultimately we *do* retain control of the systems running those jobs22:09
fungiand have the ability to see what's running (everyone does, that much is public) and also turn them off if there's a problem22:09
corvusi think the best course to try to navigate would be a dedicated tenant (so they don't have to coordinate with other projects), a config-project hosted in opendev (so we control access to the executors), and adding cryptography as an untrusted project with config loading.22:10
corvuswe're both going to have to trust each other a bit with that :)22:10
fungiand what about write access for zuul to their repos... required? not required?22:11
ianwi don't see why zuul would need to write22:11
corvusfrom reading the zuul docs, i don't think it's required, but i don't consider myself expert in that.22:11
clarkbya it should only be reqired if gating and having zuul click merge22:12
fungii meant more from a policy standpoint. is it something we want to require, or is it something we can't imagine ever actually utilizing, or is it somewhere in between?22:12
clarkbfungi: considering our policy is third party ci focused I don't see that ever needing merge/write22:12
clarkbfungi: and so I think it better reflects out intent to remove that option. if we need it in the future we can add a second app that has write22:13
corvusi agree with clarkb22:13
fungithat sums up my position rather well too22:13
fungii just wanted to be sure, since the point was raised earlier that once turned off it might be a challenge to return if we did want it (not that i think we will)22:14
clarkbcorvus: I think the course you describe is a reasonable one. Maybe we present that to cryptography and ask if it seems reasonable to them (particularly the trust each other a bit part) and if so push on it. If not try to further understand their concerns as they are somewhat vague in actual requirements so far22:14
clarkbif mordred will be around we can double check with im that it won't affect the ansbile third part ci at all22:14
clarkbI'm fairly certain it won't bother kata and kata is being turned off soon anyway22:14
ianwclarkb: i think also with ansible, didn't the openstack bits it was monitoring move into collections?22:15
clarkbianw: oh ya that could be22:15
ianwi couldn't find a recent comment by zuul on ansible, i wanted to link to it as an example22:15
corvusianw: i think so22:16
corvusi think it's still there for stable branches?22:16
corvusso it's aging out22:16
corvusi'll work on a reply to that issue22:17
fungi was a success22:18
ianwcorvus: thanks, i'd appreciate that; i don't want to read too much into a two line comment and they may be open to discussion when things are explained22:19
ianwfungi: yeah, they were too old to still have logs22:20
fungiright, even the most recent failure result was from march22:20
ianwi didn't want to send anyone to a zuul result that wasn't "perfect" :)  first impressions and all that :)22:20
fungiso it's not that you couldn't find them, we haven't run them22:20
fungi was last exercised in may22:23
fungistill too old22:23
fungisame for
ianwyeah, i'm not sure if they turned us off again?  i'll look into that22:25
fungiso i've gone through all the github sources in the openstack tenant with no luck22:25
ianwfungi: i think we came to the same conclusion :)22:25
fungii suppose a kata-containers tenant build would work, but they're not really running particularly interesting jobs22:25
fungiand none of our other tenants seem to be running any builds for github projects, yeah22:28
openstackgerritClark Boylan proposed zuul/zuul-jobs master: Disable base role testing that runs code on localhost
openstackgerritClark Boylan proposed zuul/zuul-jobs master: Collect partial subunit files
ianwclarkb: sorry, looping back to ... do you know what might be up with the tls-proxy.  i haven't jumped into debugging yet22:33
clarkbianw: sorry no I finally finished (I think) the zuul-jobs tests cleanup for the local code not permitted thing and was going to look next22:33
clarkbianw: so I did test it with nodepool22:34
clarkband it was fine22:34
ianwhrm, did it run the full dib tests?22:34
clarkbmaybe? I think its the same job the functional one22:34
clarkb and
clarkbwhich are slightly differently named than the ones dib runs22:35
ianwhrm, yeah, i wonder what's different22:35
corvusianw, clarkb, fungi: something like ?22:36
clarkbI think I know. I ignored the container jobs on my test change because nodepool image builds are broken with the arm problems. But dib is doing x86 only? and the ca isn't availabel in the containers22:37
clarkbianw: I think we can bind mount the CA into the containers and it will work22:37
clarkbianw: though a revert and trying to address this better when container images build relaibly is also fine with me22:37
ianwohhh, yeah, that's the difference with the functional jobs22:38
ianwok, let me look today, see if we can fix it, and make sure it runs for similar in the future22:38
clarkbcorvus: line 13: "so the encrypted token can be added to this repo" I would clarify which repo is "this repo"22:39
clarkbcorvus: I think you mean the trusted repo hosted on opendev but being clear would probably help everyone udnersatnd better22:39
clarkbcorvus: otherwise lgtm22:39
corvusclarkb: sure.  was thinking in context of the issue on the repo, but i'll change :)22:40
ianwi don't know, i'm thinking something like explaining a bit more how the jobs upload logs to storage providers and need keys that obviously you don't want to expose22:42
ianwand how that's the same situation as uploading something to codecov22:42
ianwjust to be clear how it works22:42
corvusianw: okay, i'm burning out at eod here, maybe you can take a stab at that?22:43
ianwyeah, i don't want it to turn into war and peace either :)22:44
clarkbyes today started very early for me22:47
ianwreally, i guess "trusted" roles in zuul are basically what travis ci hides from you22:47
clarkbianw: yup22:48
clarkbits all the support stuff, we just encode that into the same system whereas other ci systems can implement them more opaquely however they like22:48
openstackgerritAdam Coldrick proposed opendev/storyboard master: WIP: Optimise the Story browsing query
fungicorvus: your reply looks good22:51
fungiand i agree, like i said earlier, much of the control logic hidden in proprietary ci providers just happens to be abstracted into the same job configuration language in zuul, and exposed publicly for opendev's zuul22:53
ianwyeah, i'm happy with it.  i want to go on and on about zuul's job hierarchy and what not but i don't think it helps22:54
fungia link to zuul's docs might help? i dunno22:55
*** mlavalle has quit IRC23:00
*** tosky has quit IRC23:03
ianwthey trust travisci with irc secrets i guess
ianwcorvus: sorry, i can't come up with anything better, i just get too long winded.  please go ahead if you get a chance, i'll look at the r/w issue23:18
*** DSpider has quit IRC23:27
corvusianw: ok posted :)23:58

Generated by 2.17.2 by Marius Gedminas - find it at!