| *** ryohayakawa has joined #opendev | 00:13 | |
| openstackgerrit | Sean McGinnis proposed opendev/bindep master: Fix formatting issues in docs https://review.opendev.org/742320 | 00:20 |
|---|---|---|
| *** Dmitrii-Sh has quit IRC | 00:25 | |
| *** Dmitrii-Sh has joined #opendev | 00:29 | |
| ianw | https://github.com/pyca/cryptography/issues/5292#issuecomment-662173526 ... dropped a comment offering some arm64 support | 00:31 |
| ianw | hrm, it's been pointed out that the zuul app wants write access | 00:37 |
| clarkb | I think because in an ideal world it will do merges, but for third party ci thats likely too much | 00:38 |
| clarkb | I'm guessing github doesnt let us tune that per install | 00:38 |
| clarkb | there is likely something we can do about that maybe just drop write becausenothing we do against github is using zuul to merge? | 00:39 |
| clarkb | then if that changes it gets the write access app install? | 00:39 |
| clarkb | I find githubs app system confusing... | 00:40 |
| ianw | yeah, i can certainly understand people being hesitant to give write even if we say we're not going to use it | 00:42 |
| clarkb | yup 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 change | 00:43 |
| openstackgerrit | Ian Wienand proposed openstack/project-config master: Add pypa/cryptography to zuul config https://review.opendev.org/742321 | 00:46 |
| ianw | clarkb: ^ i'm thinking maybe a POC job in opendev-jobs is a good start | 00:46 |
| clarkb | ++ wecan show them what it looks like without reporting or the app | 00:47 |
| clarkb | reporting to github I mean. But Im no longer at laptop so may have to review in the morning | 00:47 |
| ianw | ok that just adds it to zuul config; i may just go with that to get things moving. should be able to gate test the rest | 00:48 |
| fungi | apparently the dco-check job for the kata-containers tenant was using the cmd module on the executor | 01:15 |
| fungi | https://zuul.opendev.org/t/kata-containers/build/63a6a774d4634bdb90f0cc958e574fbd | 01:15 |
| fungi | so i think we're now marking all their pull requests as not having signed-off-by | 01:17 |
| ianw | bummer. i doesn't seem worth a node though, what exactly does it do? | 01:17 |
| ianw | https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/validate-dco-license/tasks/main.yaml | 01:18 |
| ianw | i guess it needs to be a protected job? | 01:19 |
| fungi | likely. i'm getting in trouble for being on the computer now, but can probably look at it tomorrow | 01:28 |
| openstackgerrit | Ian Wienand proposed openstack/project-config master: Add pyca/cryptography to zuul config https://review.opendev.org/742321 | 01:37 |
| dmsimard | I 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 |
| dmsimard | for example: https://zuul.opendev.org/t/openstack/buildset/9bae52d964c442dcae53315f090cae1c | 02:53 |
| openstackgerrit | Ian Wienand proposed openstack/project-config master: Add repo for pyca/cryptography Zuul jobs https://review.opendev.org/742337 | 03:36 |
| *** redrobot has quit IRC | 03:42 | |
| openstackgerrit | Ian Wienand proposed openstack/project-config master: Add repo for pyca/cryptography Zuul jobs https://review.opendev.org/742337 | 03:53 |
| ianw | clarkb / infra-root: the arm64 testing for pyca/cryptography is i think on the right track. see updates in https://github.com/pyca/cryptography/issues/5339. a few things on our plate to sort out re the github app and our job repos | 04:23 |
| *** raukadah is now known as chandankumar | 05:10 | |
| openstackgerrit | Ian Wienand proposed zuul/zuul-jobs master: Revert "Enable tls-proxy in ensure-devstack" https://review.opendev.org/742344 | 05:23 |
| openstackgerrit | Ian Wienand proposed openstack/diskimage-builder master: DNM: test revert of tls-proxy change https://review.opendev.org/742345 | 05:23 |
| *** ryohayakawa has quit IRC | 05:37 | |
| *** ryohayakawa has joined #opendev | 05:38 | |
| *** marios has joined #opendev | 05:39 | |
| *** DSpider has joined #opendev | 06:06 | |
| *** iurygregory has joined #opendev | 06:25 | |
| *** elod is now known as elod_off | 06:31 | |
| *** qchris has quit IRC | 06:51 | |
| *** qchris has joined #opendev | 07:05 | |
| *** dougsz has joined #opendev | 07:35 | |
| *** tosky has joined #opendev | 07:39 | |
| *** marios has quit IRC | 07:48 | |
| openstackgerrit | Merged zuul/zuul-jobs master: Add upload-logs-s3 https://review.opendev.org/741809 | 07:50 |
| *** fressi has joined #opendev | 07:50 | |
| *** moppy has quit IRC | 08:01 | |
| *** moppy has joined #opendev | 08:01 | |
| *** ryohayakawa has quit IRC | 08:03 | |
| *** tosky has quit IRC | 08:04 | |
| *** tosky_ has joined #opendev | 08:04 | |
| *** tosky_ is now known as tosky | 08:19 | |
| *** ryohayakawa has joined #opendev | 08:28 | |
| AJaeger | fungi, clarkb, ianw: ricolin proposes in https://review.opendev.org/#/c/742090/1 a couple of arm64 jobs, some advise from you would be welcome there, please | 08:40 |
| *** ryohayakawa has quit IRC | 08:44 | |
| *** marios has joined #opendev | 08:50 | |
| *** ryohayakawa has joined #opendev | 08:50 | |
| *** dtantsur|afk is now known as dtantsur | 08:52 | |
| *** sgw1 has quit IRC | 08:54 | |
| *** sgw has joined #opendev | 09:17 | |
| *** ryohayakawa has quit IRC | 09:20 | |
| *** fressi has quit IRC | 09:47 | |
| openstackgerrit | Thierry Carrez proposed opendev/irc-meetings master: Rotate Large Scale SIG meeting https://review.opendev.org/742386 | 10:28 |
| *** priteau has joined #opendev | 10:33 | |
| *** tkajinam has quit IRC | 10:59 | |
| *** sshnaidm is now known as sshnaidm|afk | 11:14 | |
| *** bolg has joined #opendev | 12:03 | |
| *** rm_work has quit IRC | 12:38 | |
| *** mordred has quit IRC | 12:40 | |
| *** Eighth_Doctor has quit IRC | 12:40 | |
| *** rm_work has joined #opendev | 12:42 | |
| *** fressi has joined #opendev | 12:42 | |
| *** mordred has joined #opendev | 12:49 | |
| *** Eighth_Doctor has joined #opendev | 13:20 | |
| *** sshnaidm|afk is now known as sshnaidm | 13:29 | |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: dco-license: remove the empty nodeset https://review.opendev.org/742430 | 13:41 |
| *** qchris has quit IRC | 13:52 | |
| openstackgerrit | James E. Blair proposed zuul/zuul-jobs master: Temporarily disable tag cleanup in docker promote https://review.opendev.org/742447 | 14:28 |
| *** paladox has quit IRC | 14:32 | |
| *** dougsz has quit IRC | 14:34 | |
| *** mlavalle has joined #opendev | 14:44 | |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: dco-license: remove the empty nodeset https://review.opendev.org/742430 | 14:47 |
| *** dougsz has joined #opendev | 14:49 | |
| *** paladox has joined #opendev | 14:53 | |
| *** qchris has joined #opendev | 15:01 | |
| *** cmurphy_afk is now known as cmurphy | 15:07 | |
| openstackgerrit | Merged zuul/zuul-jobs master: Temporarily disable tag cleanup in docker promote https://review.opendev.org/742447 | 15:07 |
| openstackgerrit | Merged zuul/zuul-jobs master: dco-license: remove the empty nodeset https://review.opendev.org/742430 | 15:23 |
| *** factor has joined #opendev | 15:26 | |
| openstackgerrit | James E. Blair proposed zuul/zuul-jobs master: Reinstate docker tag cleanup https://review.opendev.org/742461 | 15:40 |
| *** zbr|rover is now known as zbr | 15:58 | |
| *** shtepanie has joined #opendev | 16:01 | |
| *** factor has quit IRC | 16:08 | |
| *** factor has joined #opendev | 16:09 | |
| *** marios is now known as marios|out | 16:12 | |
| *** marios|out has quit IRC | 16:13 | |
| *** dougsz has quit IRC | 16:30 | |
| *** dtantsur is now known as dtantsur|afk | 16:35 | |
| *** factor has quit IRC | 16:39 | |
| *** factor has joined #opendev | 16:40 | |
| *** factor has quit IRC | 16:40 | |
| *** fressi has quit IRC | 16:41 | |
| *** factor has joined #opendev | 17:04 | |
| *** sshnaidm is now known as sshnaidm|afk | 17:09 | |
| *** sshnaidm|afk has quit IRC | 17:23 | |
| *** sshnaidm has joined #opendev | 17:27 | |
| *** sshnaidm is now known as sshnaidm|afk | 17:27 | |
| *** icarusfactor has joined #opendev | 18:07 | |
| *** icarusfactor has left #opendev | 18:08 | |
| *** factor has quit IRC | 18:09 | |
| openstackgerrit | Dmitriy Rabotyagov (noonedeadpunk) proposed openstack/project-config master: Remove os_congress gating https://review.opendev.org/742515 | 19:03 |
| openstackgerrit | melanie witt proposed openstack/project-config master: Update ceph grafana for nova https://review.opendev.org/742516 | 19:11 |
| openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Collect partial subunit files https://review.opendev.org/742527 | 19:41 |
| openstackgerrit | Dmitriy Rabotyagov (noonedeadpunk) proposed openstack/project-config master: Remove os_congress gating https://review.opendev.org/742515 | 20:01 |
| openstackgerrit | Dmitriy Rabotyagov (noonedeadpunk) proposed openstack/project-config master: Remove os_congress gating https://review.opendev.org/742515 | 20:02 |
| openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Collect partial subunit files https://review.opendev.org/742527 | 20:03 |
| openstackgerrit | Dmitriy Rabotyagov (noonedeadpunk) proposed openstack/project-config master: Revert "Remove os_congress gating" https://review.opendev.org/742532 | 20:07 |
| openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Collect partial subunit files https://review.opendev.org/742527 | 20:25 |
| openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Disable workspace setup testing https://review.opendev.org/742537 | 20:25 |
| openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Disable workspace setup testing and cleanup z-c testing https://review.opendev.org/742537 | 20:41 |
| openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Collect partial subunit files https://review.opendev.org/742527 | 20:41 |
| *** priteau has quit IRC | 20:47 | |
| openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Disable base role testing that runs code on localhost https://review.opendev.org/742537 | 20:56 |
| openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Collect partial subunit files https://review.opendev.org/742527 | 20:56 |
| mnaser | infra-root: message on openstack-discuss about ask.openstack.org being down (and i confirm it) | 21:05 |
| fungi | mnaser: thanks, i'll see if i can spot the problem | 21:15 |
| fungi | responds to ping, but ssh hangs after key exchange. likely a disk issue, i'll check the console | 21:16 |
| ianw | sounds like eavesdrop the other day; may be they're on the same host/rack/data centre/universe | 21:18 |
| fungi | looks like snmpd stopped responding between 19:30 and 19:35 | 21:18 |
| fungi | ianw: also like zm03, zm04 and zm07 on monday | 21:19 |
| fungi | yeah, similar to what i saw on the mergers | 21:20 |
| fungi | kernel messages about hung tasks, not sure how long ago, but carriage return doesn't give me a new login prompt | 21:20 |
| fungi | time to force reboot via api | 21:21 |
| ianw | clarkb: can you look at https://review.opendev.org/#/c/742344/ ... it seems the change to tls-proxy has broken the dib gate. jobs just time out now; tested with https://review.opendev.org/#/c/742345/ | 21:22 |
| openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Disable base role testing that runs code on localhost https://review.opendev.org/742537 | 21:23 |
| openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Collect partial subunit files https://review.opendev.org/742527 | 21:23 |
| corvus | ianw: regarding https://github.com/pyca/cryptography/issues/5339 | 21:23 |
| corvus | ianw: 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 |
| corvus | ianw: what tenant do you want to add them to? | 21:24 |
| ianw | i don't know, that's all up for discussion | 21:24 |
| fungi | #status log hard rebooted ask.o.o after it was hung for nearly two hours | 21:25 |
| openstackstatus | fungi: finished logging | 21:25 |
| corvus | ianw: regarding the second question -- you say the token thing is intractable -- why? can't we just both use the same token? | 21:25 |
| fungi | ask.o.o is back up, replying to the ml now | 21:25 |
| ianw | corvus: i doubt they're going to give us the token is the thing | 21:25 |
| corvus | ianw: 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 |
| clarkb | ianw: they can encrypt it as a project secret which is likely similar to how they do coverage with other ci providers | 21:26 |
| clarkb | and ya admins can get at it which is the same for travis etc | 21:26 |
| ianw | right, but i think they want to run it in effectively check queue? | 21:26 |
| corvus | that's fine -- do the upload in a trusted post-playbook | 21:26 |
| clarkb | ianw: if there is no trigger for jobs then ya it gets trickier | 21:26 |
| clarkb | er no explicit human trigger for jobs | 21:26 |
| corvus | clarkb: why is it tricky? | 21:26 |
| corvus | the trigger is PR created | 21:27 |
| corvus | it's a check queue | 21:27 |
| clarkb | corvus: yes, but are we going to make their repo a trusted repo on github? | 21:27 |
| corvus | no, we wouldn't define the job in their repo | 21:27 |
| clarkb | right they seem opposed to that | 21:27 |
| corvus | um | 21:27 |
| corvus | i mean we're not going to define the base job in their repo either | 21:28 |
| corvus | i don't get it | 21:28 |
| corvus | zuul is designed for this | 21:28 |
| corvus | the uploading part happens in a trusted playbook | 21:28 |
| fungi | sounds like they want something which isn't zuul | 21:28 |
| corvus | the generate the coverage happens in their repo | 21:28 |
| corvus | fungi: i completely disagree | 21:28 |
| corvus | this is *exactly* what zuul was designed for and it's *exactly* how we used it | 21:28 |
| corvus | split trust horizons | 21:28 |
| fungi | i 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 all | 21:29 |
| corvus | i don't think they said that | 21:29 |
| clarkb | corvus: 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 wrong | 21:29 |
| corvus | they don't have complete control over travis either | 21:29 |
| clarkb | corvus: yes but they feel they do | 21:29 |
| corvus | i think we should avoid jumping to conclusions | 21:30 |
| corvus | okay | 21:30 |
| clarkb | we're a lot more explicit about the split | 21:30 |
| clarkb | if we can explain that then maybe we can work with it | 21:30 |
| ianw | yeah, i think even the fact that zuul admins can decrypt the key *might* be too much | 21:30 |
| clarkb | "in travis its a db lookup you don't control, in zuul its a git repo you don't control" | 21:30 |
| corvus | so can travis/github/etc | 21:30 |
| fungi | likely 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 it | 21:30 |
| clarkb | fungi: yes | 21:30 |
| corvus | this is alex gaynor we're talking about here | 21:30 |
| fungi | i do think he's likely to listen to a reasoned argument | 21:31 |
| ianw | i 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 it | 21:31 |
| corvus | he's not exactly ignorant about open source / proprietary software and inherent security tradeoffs | 21:31 |
| clarkb | probably 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/etc | 21:31 |
| clarkb | ianw: that wouldn't surprise me | 21:32 |
| fungi | also that zuul abstracts much more of its control logic out into "configuration" where similar logic may be hardcoded in other platforms | 21:32 |
| ianw | right; 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 thing | 21:32 |
| corvus | anyway, 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 policy | 21:32 |
| ianw | that said -- it's not a hard reject yet. just the start of a discussion | 21:32 |
| ianw | right, for us to sort out first is the write access on the zuul github bot | 21:33 |
| ianw | we'll either need to turn that off, or as pabelanger suggests, start another one that's targeted at R/O CI | 21:34 |
| openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Disable base role testing that runs code on localhost https://review.opendev.org/742537 | 21:34 |
| openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Collect partial subunit files https://review.opendev.org/742527 | 21:34 |
| clarkb | ianw: since we've got no github projects trying to do gating I think we can change the existing installation | 21:35 |
| ianw | i *do* feel like this is a pretty good opportunity for zuul/opendev to expand itself | 21:35 |
| clarkb | basically 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 that | 21:36 |
| clarkb | (granted the number is small) | 21:36 |
| fungi | for 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 fine | 21:37 |
| clarkb | corvus: 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 arm64 | 21:37 |
| clarkb | where its less third party is in giving them more control over the job details | 21:38 |
| corvus | right, there's https://governance.openstack.org/tc/resolutions/20180215-third-party-check.html which it meets | 21:38 |
| clarkb | given their security concerns I think that is a reasonable compromise in this case | 21:38 |
| clarkb | (because they want to trust the results of the CI and make actiosn on it like subsequently publish arm64 wheels) | 21:38 |
| corvus | we've also discussed in the past that maybe we don't just want to be a free github ci system | 21:38 |
| clarkb | ya, 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 |
| fungi | right, that's where the "in the context of a project hosted in opendev" part comes in | 21:39 |
| ianw | i 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 resources | 21:40 |
| fungi | it'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 opendev | 21:40 |
| corvus | what tenant would we put it in? | 21:40 |
| *** shtepanie has quit IRC | 21:41 | |
| ianw | i was originally thinking adding config to a project under opendev, but if that's not going to fly upstream, not sure | 21:41 |
| clarkb | corvus: I'm not sure I know the answer to that yet because I'm still a bit confused about how the codecov thing would work | 21:41 |
| corvus | ianw: who's upstream? | 21:41 |
| ianw | pyca/cryptography team | 21:41 |
| clarkb | from a third part ci agnel I think it belongs in openstack or zuul | 21:41 |
| ianw | https://review.opendev.org/742337 to be concrete was what i was thinking | 21:42 |
| corvus | clarkb: i don't think it belongs in zuul | 21:42 |
| clarkb | ok I'm just listing those two as they are consumers of it currently hurting from the lack of cryptography wheels | 21:42 |
| corvus | this is really incidental to zuul -- afaict, opendev itself may be the only zuul user interested in using the nodepool builder arm image | 21:42 |
| ianw | i felt like opendev is providing these resources, and installing cryptography from a wheel is a basically a generic thing anyone would do | 21:42 |
| clarkb | openstack has also struggled with this | 21:43 |
| ianw | to me it feels like something opendev would be involved with as part of keeping the arm64 resources as broadly usable as possible | 21:43 |
| clarkb | ianw: 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 openstack | 21:43 |
| clarkb | ianw: thats a fair point, its part of the ci system as well so ya I could see opendev being the hosting tenant as well | 21:44 |
| corvus | ianw: (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 |
| fungi | so reading the suggestion in https://github.com/pyca/cryptography/issues/5292 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 requests | 21:45 |
| ianw | corvus: yeah, my thinking was that we can give permissions on the repo to other people more easily if it's separated | 21:45 |
| corvus | fungi: i don't think reporting is an issue | 21:45 |
| ianw | so as a first step, are we in agreement to turn off the write access on the existing zuul github bot? | 21:46 |
| ianw | that will at least give it a chance of being installed | 21:46 |
| clarkb | yes 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 it | 21:47 |
| clarkb | and that will better reflect how it is used even if cryptography doesn't add it | 21:48 |
| fungi | i 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 gating | 21:48 |
| ianw | ok, i can look into that. it will be one less thing | 21: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 |
| corvus | that 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 |
| corvus | fungi: no, zuul handles errors like that now. we'll just have config errors in that tenant. | 21:50 |
| corvus | that's part of why i don't want it in the zuul tenant | 21:50 |
| fungi | oh, got it. i was thinking in an existing tenant, yeah | 21:51 |
| ianw | corvus: i feel like if we do want that, it will be a case of creating a second instance to do r/w | 21:51 |
| clarkb | corvus: can you clarify that statement about github permissions? Do you just mean people won't want to add write perms back? | 21:51 |
| clarkb | ianw: ya that is what I'm thinking too | 21:51 |
| fungi | so i agree a good policy would be dedicated tenant if we allow in-repo config | 21:51 |
| clarkb | fungi: well I'd argue dedicated tenant violates our third party ci assertion | 21:51 |
| corvus | clarkb: yes, we will have to go hat in hand if we find out we needed it for some other reason | 21:51 |
| clarkb | fungi: the whole point is we're tying the github side to something we've already got | 21:52 |
| clarkb | and ya I guess it comes down to what configuration do they expect in their repo? enabling and disabling jobs? thats easy | 21:52 |
| clarkb | defining jobs? thats potentially doable. Defining everything including the code coverage reporting that is maybe not doable? | 21:53 |
| fungi | clarkb: 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) does | 21:53 |
| ianw | are we talking ilke a "github" tenant, or as specific as a "pyca/cryptography" tenant? | 21:54 |
| clarkb | ianw: I'm saying we shouldn't do that at all :P | 21:54 |
| fungi | i think it would be a pyca-cryptography tenant | 21:54 |
| fungi | if we did it | 21:54 |
| fungi | on the assumption that it wouldn't be the only one in that situation | 21:54 |
| clarkb | ianw: 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 well | 21:54 |
| clarkb | I 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 |
| ianw | yeah, which brings me back to my original question in #zuul :) of ... what's the worst that can happen | 21:55 |
| fungi | but we can't safely do that if we allow them to define jobs in their github-hosted repo | 21:55 |
| corvus | didn't i answer that? | 21:55 |
| clarkb | fungi: I think corvus is saying we can because the blast radius is limited? | 21:55 |
| clarkb | fungi: the tenant will have an error but not necessary road block? | 21:55 |
| fungi | only limited if they have a dedicated tenant | 21:56 |
| clarkb | ah | 21:56 |
| corvus | config errors are not fatal | 21:56 |
| clarkb | corvus: that was what I thought | 21:56 |
| corvus | they are unlikely to break anything else in that tenant | 21:56 |
| fungi | if 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 pain | 21:56 |
| ianw | right, only if they went out of their way to really create conflicting job names or something | 21:56 |
| ianw | but, basically a syntax error type level is not going to stop reloading in general | 21:57 |
| corvus | but 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 |
| clarkb | hrm, thats sort of making me think we'd need to define the jobs on our side then :/ | 21:58 |
| corvus | for 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 tenant | 21:58 |
| ianw | ++ | 21:58 |
| clarkb | ya 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 system | 21:58 |
| clarkb | basically the intent of the github ci we do is to have groups work together and if we can't do that ... | 21:59 |
| fungi | again 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 that | 22:00 |
| clarkb | fungi: which they want | 22:00 |
| clarkb | (I'm somewhat conflating the things because they are related in this case) | 22:00 |
| corvus | i think it's a stretch to say they want to define arbitrary jobs | 22:00 |
| fungi | i agree, i'm just saying the separate tenant isn't the cause, it's just a side effect | 22:00 |
| clarkb | corvus: 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 explained | 22:01 |
| corvus | my read is they want control over this job | 22:01 |
| fungi | if 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 remit | 22:01 |
| fungi | it 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 tests | 22:03 |
| fungi | less to get approval for this particular case, but more for helping provide input on some consistent policy around this sort of case | 22:04 |
| corvus | this does seem worthwhile to me, and it's an unusual situation, since they seem unable to build wheels otherwise | 22:04 |
| ianw | fungi: 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 kept | 22:05 |
| fungi | i 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 excellent | 22:05 |
| corvus | i don't think it's over where config is kept; i think it's about our remit | 22:05 |
| ianw | i 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 guess | 22:06 |
| corvus | taking 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 that | 22:07 |
| fungi | i 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 that | 22:07 |
| ianw | right, 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 yes | 22:08 |
| fungi | where i start to have trouble justifying it is when we just hand over the reins with no oversight and tell them to go hog wild | 22:08 |
| fungi | but ultimately we *do* retain control of the systems running those jobs | 22:09 |
| fungi | and have the ability to see what's running (everyone does, that much is public) and also turn them off if there's a problem | 22:09 |
| corvus | i 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 |
| corvus | we're both going to have to trust each other a bit with that :) | 22:10 |
| fungi | and what about write access for zuul to their repos... required? not required? | 22:11 |
| ianw | i don't see why zuul would need to write | 22:11 |
| corvus | from reading the zuul docs, i don't think it's required, but i don't consider myself expert in that. | 22:11 |
| clarkb | ya it should only be reqired if gating and having zuul click merge | 22:12 |
| fungi | i 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 |
| clarkb | fungi: considering our policy is third party ci focused I don't see that ever needing merge/write | 22:12 |
| clarkb | fungi: 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 write | 22:13 |
| corvus | i agree with clarkb | 22:13 |
| fungi | that sums up my position rather well too | 22:13 |
| fungi | i 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 |
| clarkb | corvus: 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 far | 22:14 |
| clarkb | if mordred will be around we can double check with im that it won't affect the ansbile third part ci at all | 22:14 |
| clarkb | I'm fairly certain it won't bother kata and kata is being turned off soon anyway | 22:14 |
| ianw | clarkb: i think also with ansible, didn't the openstack bits it was monitoring move into collections? | 22:15 |
| clarkb | ianw: oh ya that could be | 22:15 |
| ianw | i couldn't find a recent comment by zuul on ansible, i wanted to link to it as an example | 22:15 |
| corvus | ianw: i think so | 22:16 |
| corvus | mostly | 22:16 |
| corvus | i think it's still there for stable branches? | 22:16 |
| corvus | so it's aging out | 22:16 |
| corvus | i'll work on a reply to that issue | 22:17 |
| fungi | ianw: https://zuul.opendev.org/t/openstack/builds?project=ansible/ansible | 22:18 |
| fungi | https://github.com/ansible/ansible/pull/66526 was a success | 22:18 |
| ianw | corvus: 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 explained | 22:19 |
| ianw | fungi: yeah, they were too old to still have logs | 22:20 |
| fungi | ahh | 22:20 |
| fungi | right, even the most recent failure result was from march | 22:20 |
| ianw | i didn't want to send anyone to a zuul result that wasn't "perfect" :) first impressions and all that :) | 22:20 |
| fungi | so it's not that you couldn't find them, we haven't run them | 22:20 |
| fungi | https://zuul.opendev.org/t/openstack/builds?project=sigmavirus24/github3.py was last exercised in may | 22:23 |
| fungi | still too old | 22:23 |
| fungi | same for https://zuul.opendev.org/t/openstack/builds?project=philpep/testinfra | 22:24 |
| ianw | yeah, i'm not sure if they turned us off again? i'll look into that | 22:25 |
| fungi | so i've gone through all the github sources in the openstack tenant with no luck | 22:25 |
| ianw | fungi: i think we came to the same conclusion :) | 22:25 |
| fungi | i suppose a kata-containers tenant build would work, but they're not really running particularly interesting jobs | 22:25 |
| fungi | and none of our other tenants seem to be running any builds for github projects, yeah | 22:28 |
| openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Disable base role testing that runs code on localhost https://review.opendev.org/742537 | 22:32 |
| openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Collect partial subunit files https://review.opendev.org/742527 | 22:32 |
| ianw | clarkb: sorry, looping back to https://review.opendev.org/#/c/742344/1 ... do you know what might be up with the tls-proxy. i haven't jumped into debugging yet | 22:33 |
| clarkb | ianw: sorry no I finally finished (I think) the zuul-jobs tests cleanup for the local code not permitted thing and was going to look next | 22:33 |
| clarkb | ianw: so I did test it with nodepool | 22:34 |
| clarkb | and it was fine | 22:34 |
| ianw | hrm, did it run the full dib tests? | 22:34 |
| clarkb | maybe? I think its the same job the functional one | 22:34 |
| clarkb | https://zuul.opendev.org/t/zuul/build/0c737c0c04b94b8faab793c7ccf1e857 and https://zuul.opendev.org/t/zuul/build/18fba9da40d244c4ae5344c6bb4defe8 | 22:35 |
| clarkb | which are slightly differently named than the ones dib runs | 22:35 |
| ianw | hrm, yeah, i wonder what's different | 22:35 |
| clarkb | ianw: https://zuul.opendev.org/t/openstack/build/2336111631cc4307a31598793df99f31/log/docker/nodepool_nodepool-builder_1.txt#62 | 22:36 |
| corvus | ianw, clarkb, fungi: something like https://etherpad.opendev.org/p/Agkw5zaoV6jepLbaDszd ? | 22:36 |
| clarkb | I 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 containers | 22:37 |
| clarkb | ianw: I think we can bind mount the CA into the containers and it will work | 22:37 |
| clarkb | ianw: though a revert and trying to address this better when container images build relaibly is also fine with me | 22:37 |
| ianw | ohhh, yeah, that's the difference with the functional jobs | 22:38 |
| ianw | ok, let me look today, see if we can fix it, and make sure it runs for similar in the future | 22:38 |
| clarkb | corvus: line 13: "so the encrypted token can be added to this repo" I would clarify which repo is "this repo" | 22:39 |
| clarkb | corvus: I think you mean the trusted repo hosted on opendev but being clear would probably help everyone udnersatnd better | 22:39 |
| clarkb | corvus: otherwise lgtm | 22:39 |
| corvus | clarkb: sure. was thinking in context of the issue on the repo, but i'll change :) | 22:40 |
| ianw | i 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 expose | 22:42 |
| ianw | and how that's the same situation as uploading something to codecov | 22:42 |
| ianw | just to be clear how it works | 22:42 |
| corvus | ianw: okay, i'm burning out at eod here, maybe you can take a stab at that? | 22:43 |
| ianw | yeah, i don't want it to turn into war and peace either :) | 22:44 |
| clarkb | yes today started very early for me | 22:47 |
| ianw | really, i guess "trusted" roles in zuul are basically what travis ci hides from you | 22:47 |
| clarkb | ianw: yup | 22:48 |
| clarkb | its all the support stuff, we just encode that into the same system whereas other ci systems can implement them more opaquely however they like | 22:48 |
| openstackgerrit | Adam Coldrick proposed opendev/storyboard master: WIP: Optimise the Story browsing query https://review.opendev.org/742046 | 22:50 |
| fungi | corvus: your reply looks good | 22:51 |
| fungi | and 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 zuul | 22:53 |
| ianw | yeah, 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 helps | 22:54 |
| fungi | a link to zuul's docs might help? i dunno | 22:55 |
| *** mlavalle has quit IRC | 23:00 | |
| *** tosky has quit IRC | 23:03 | |
| ianw | they trust travisci with irc secrets i guess https://github.com/pyca/cryptography/blob/master/.travis.yml#L152 | 23:16 |
| ianw | corvus: 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 issue | 23:18 |
| *** DSpider has quit IRC | 23:27 | |
| corvus | ianw: ok posted :) | 23:58 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!