*** mattw4 has quit IRC | 00:02 | |
*** saneax has quit IRC | 00:31 | |
*** roman_g has quit IRC | 02:34 | |
*** rf0lc0 has quit IRC | 03:05 | |
*** noorul has joined #zuul | 04:33 | |
*** saneax has joined #zuul | 04:57 | |
*** noorul has quit IRC | 04:58 | |
*** pcaruana has joined #zuul | 05:02 | |
*** saneax has quit IRC | 05:06 | |
*** badboy has joined #zuul | 05:20 | |
*** swest has joined #zuul | 05:21 | |
badboy | hi, is it possible to have "Expand by default" always checked or set in config file? | 05:23 |
---|---|---|
badboy | in Zuul web UI of course | 05:23 |
badboy | another one in the nice-to-have category, is it possible to configure or at least show info about timezone used on the Zuul website? Right now it's confusing as the Zuul server time is PST but customers have CET or HKT | 05:26 |
*** saneax has joined #zuul | 05:46 | |
*** saneax has quit IRC | 06:23 | |
badboy | can somebody help me with executor tmp dir not being cleaned? http://paste.openstack.org/show/775602/ | 06:39 |
*** badboy has quit IRC | 06:40 | |
*** badboy has joined #zuul | 06:50 | |
*** badboy has quit IRC | 07:00 | |
*** tosky has joined #zuul | 07:10 | |
*** badboy has joined #zuul | 07:16 | |
*** tosky_ has joined #zuul | 07:18 | |
*** shachar has quit IRC | 07:20 | |
*** tosky has quit IRC | 07:21 | |
*** tosky_ is now known as tosky | 07:38 | |
*** jpena|off is now known as jpena | 07:40 | |
*** hashar has joined #zuul | 07:50 | |
*** avass has joined #zuul | 08:01 | |
*** snapiri has joined #zuul | 08:26 | |
*** roman_g has joined #zuul | 08:34 | |
*** hashar has quit IRC | 10:02 | |
*** pcaruana has quit IRC | 10:11 | |
*** saneax has joined #zuul | 10:19 | |
*** shachar has joined #zuul | 10:20 | |
*** snapiri has quit IRC | 10:23 | |
*** gtema_ has joined #zuul | 11:17 | |
*** pcaruana has joined #zuul | 11:24 | |
*** sshnaidm|rover is now known as sshnaidm|off | 11:40 | |
*** hashar has joined #zuul | 11:45 | |
*** jpena is now known as jpena|lunch | 11:48 | |
*** badboy has quit IRC | 11:57 | |
*** Goneri has joined #zuul | 12:32 | |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: fetch-tox-output: introduce zuul_use_fetch_output https://review.opendev.org/681864 | 12:35 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: fetch-subunit-output: introduce zuul_use_fetch_output https://review.opendev.org/681882 | 12:35 |
*** rlandy has joined #zuul | 12:35 | |
*** rf0lc0 has joined #zuul | 12:44 | |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: fetch-tox-output: introduce zuul_use_fetch_output https://review.opendev.org/681864 | 12:52 |
*** EmilienM is now known as EvilienM | 12:55 | |
*** jpena|lunch is now known as jpena | 12:59 | |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: fetch-output-openshift: initial role https://review.opendev.org/682044 | 13:05 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: fetch-subunit-output: introduce zuul_use_fetch_output https://review.opendev.org/681882 | 13:05 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: DNM: test tox-py36 on openshift node https://review.opendev.org/682049 | 13:22 |
tristanC | corvus: flaper87: successful run of tox-py36 on openshift resources performed with: https://review.opendev.org/682049 | 13:26 |
flaper87 | tristanC: niiiice! thanks for keeping in the loop | 13:27 |
tristanC | flaper87: in the commit message you'll find a link to a dockerfile with a few tricks to make the pod works smoothly with zuul-jobs | 13:31 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: fetch-sphinx-tarball: introduce zuul_use_fetch_output https://review.opendev.org/681870 | 13:42 |
*** panda|ruck has quit IRC | 14:28 | |
*** panda has joined #zuul | 14:29 | |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: fetch-sphinx-tarball: introduce zuul_use_fetch_output https://review.opendev.org/681870 | 14:29 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: fetch-translation-output: introduce zuul_use_fetch_output https://review.opendev.org/681887 | 14:29 |
*** jangutter has quit IRC | 14:42 | |
*** mattw4 has joined #zuul | 14:48 | |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: fetch-javascript-content-tarball: introduce zuul_use_fetch_output https://review.opendev.org/681903 | 14:48 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: fetch-sphinx-output: introduce zuul_use_fetch_output https://review.opendev.org/681905 | 14:48 |
*** recheck has quit IRC | 15:04 | |
*** recheck has joined #zuul | 15:05 | |
*** mattw4 has quit IRC | 15:11 | |
*** jamesmcarthur has joined #zuul | 15:15 | |
*** recheck has quit IRC | 15:15 | |
*** recheck has joined #zuul | 15:15 | |
*** igordc has joined #zuul | 15:25 | |
*** igordc has quit IRC | 15:27 | |
*** igordc has joined #zuul | 15:27 | |
*** weshay|ruck has quit IRC | 15:31 | |
*** igordc has quit IRC | 15:32 | |
*** hashar has quit IRC | 15:36 | |
openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Retry container gets in upload-logs-swift https://review.opendev.org/682091 | 15:39 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: fetch-javascript-content-tarball: introduce zuul_use_fetch_output https://review.opendev.org/681903 | 16:01 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: fetch-sphinx-output: introduce zuul_use_fetch_output https://review.opendev.org/681905 | 16:01 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: fetch-coverage-output: introduce zuul_use_fetch_output https://review.opendev.org/681904 | 16:01 |
*** rlandy is now known as rlandy|brb | 16:02 | |
tristanC | sorry for all the zuul_use_fetch_output noise, the stack is now almost +Verified | 16:13 |
tristanC | i'll now configure a gertty to review the backlog, should i start with gerrit-checks corvus? | 16:14 |
*** recheck has quit IRC | 16:14 | |
*** recheck has joined #zuul | 16:14 | |
*** mattw4 has joined #zuul | 16:15 | |
openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Retry container gets in upload-logs-swift https://review.opendev.org/682091 | 16:17 |
corvus | tristanC: no worries, i'm excited about it! regarding the backlog -- we should take a look at the autohold stuff from Shrews first i think -- he very kindly rebased it after mhu's admin api changes merged -- "topic:autohold-revamp" | 16:22 |
jlk | pabelanger: gundalow: re push access from apps, when you use that you're not doing the "merge" API call, and instead just letting zuul merge the content locally and push directly to the target branch? | 16:37 |
pabelanger | jlk: no, this is still using the merge API | 16:38 |
jlk | hrm, I thought that was possible in the past to let Zuul do the merge | 16:41 |
*** rlandy|brb is now known as rlandy | 16:42 | |
pabelanger | IIRC, we want to add it, but didn't think we could right now | 16:42 |
pabelanger | for things like circular dependency? | 16:43 |
jlk | I guess I'm confused. I really really thought that I coded in the function for Zuul to use the API to do the merge. | 16:44 |
pabelanger | jlk: yah, you did, didn't you? today github does the merge commit for our repos in ansible-network | 16:44 |
*** jpena is now known as jpena|off | 16:49 | |
jlk | Looks like before we just granted the app "write" access to the repository | 16:50 |
jlk | maybe we had to have more permissive branch protections? | 16:50 |
jlk | yeah that must be it. Prior to this change we couldn't restrict WHO could write to the branch (merge) since that would exclude Zuul itself. Now we can. | 16:53 |
jlk | This bit of docs https://softwarefactory-project.io/docs/user/zuul_user.html#configure-branch-protection should make it into Zuul's GitHub docs section. | 16:53 |
Shrews | corvus: tristanC: yes please, on the autohold-revamp. that's been ready for 3 months and i'd like to see that go in before newer features | 16:55 |
jlk | How many of y'all will be at Ansiblefest ? | 16:57 |
openstackgerrit | James E. Blair proposed zuul/zuul master: WIP: Support HTTP-only Gerrit https://review.opendev.org/681936 | 16:57 |
openstackgerrit | James E. Blair proposed zuul/zuul master: Update gerrit pagination test fixtures https://review.opendev.org/682114 | 16:57 |
*** gtema_ has quit IRC | 17:00 | |
Shrews | jlk: not this year, unfortunately | 17:00 |
pabelanger | jlk: yah, that's why it is huge IMO. We can now drop write permissions for everybody, and just use triage role (haven't flipped that switch yet) | 17:01 |
fungi | jlk: clarkb and i plan to be at ansiblefest | 17:03 |
fungi | i think mordred does as well? | 17:03 |
fungi | not sure who else | 17:04 |
fungi | oh, jamesmcarthur is also going to be there | 17:04 |
jamesmcarthur | I am! | 17:04 |
fungi | and osf will have a zuul both | 17:04 |
fungi | mnaser might also be going? i can't remember | 17:05 |
mnaser | yes ill be there, im giving a zuul talk and vexxhost will have a booth presence there too :> | 17:05 |
fungi | right on! | 17:05 |
fungi | so, yes, should be at least some zuul representation on site | 17:06 |
pabelanger | will be there, and giving talk on zuul.a.c | 17:06 |
corvus | i'll be there too | 17:06 |
jlk | neat | 17:06 |
jlk | I'll be there, but I'm mostly going to be focused on AWX stuff, since that's my current project at work. | 17:07 |
pabelanger | I won't be at open infra summit however | 17:07 |
fungi | depending on how the entry visa process goes, i may not be either! ;) | 17:08 |
*** hwangbo has joined #zuul | 17:12 | |
*** noorul has joined #zuul | 17:37 | |
pabelanger | Yah, just confirmed, with help of dmellado. That new github triage role, only allows access to labels. Which means, you can now create a github repo with nobody that has commit access. And because of zuul (github app) is the only one allowed to merge code! | 17:42 |
gundalow | People attending AnsibleFest, we will have a "Community Central" room with tables and power which is good spade to chat and hack on stuff. | 17:42 |
fungi | gundalow: great to know, thanks! | 17:45 |
fungi | also if anybody has suggestions for stuff to do on thursday, i'll be around then too | 17:45 |
noorul | ofosos: hi | 17:45 |
fungi | i booked travel departing friday in case mordred's zuul workshop got approved for the thursday workshops, but based on the list of workshops i saw it did not | 17:46 |
jlk | I'm heading out late Wednesday, but arriving on Sunday evening. | 17:46 |
corvus | fungi: oh, i'm in the same boat -- leaving thurs evening | 17:46 |
fungi | yeah, i get in sunday evening too, since i'm signed up for contributor day on monday | 17:46 |
gundalow | Ace | 17:47 |
fungi | we could always do "zuul things" in trader vic's | 17:48 |
gundalow | `/join #ansible-community` ill be there Sat afternoon, though Thursday midday | 17:48 |
gundalow | I think we have a room for Thursday as well | 17:48 |
fungi | oh, cool | 17:48 |
fungi | but... does that room have mai thais? ;) | 17:49 |
fungi | er, mai tais i mean | 17:49 |
corvus | http://www.puppet.org/ is in atlanta | 17:50 |
pabelanger | fungi: +1 to trader vics. Enjoyed the last time we went | 17:50 |
jlk | I'm up for zuul merging some mai tais | 17:50 |
* gundalow is lost | 17:51 | |
corvus | i'm not sure if the center for puppetry arts should be visited before or after trader vic's | 17:51 |
pabelanger | I too leave thursday afternoon, was told nothing much happening then. | 17:51 |
gundalow | Which maybe because I'm ab English man that hasn't been to Atlanta (apart from the airport) | 17:51 |
gundalow | pabelanger: nothing official on Thursday, apart from workshops and staff meal, which I'll miss :( | 17:52 |
pabelanger | gundalow: ack, that's the same as I heard too | 17:54 |
fungi | puppetry arts sounds awesome too | 17:54 |
fungi | gundalow: trader vic's is a tiki bar in the conference hotel basement, known for its signature tropical mixed drink the "mai tai" (which they claim to have been the inventors of, to much debate) | 17:55 |
gundalow | fungi: ah, thanks for the info | 17:56 |
jlk | clearly we need to do some investigative research | 17:56 |
* fungi is always happy to provide cultural background on topics involving tiki bars ;) | 17:56 | |
pabelanger | there was also a yummy steak house there too | 17:57 |
clarkb | if anyone is wondering the drink didn't originate at the atlanta trader vics :) | 17:58 |
jlk | I'm planning to go to a rock gym at least one of the evenings before drinks are poured | 17:58 |
openstackgerrit | David Shrewsbury proposed zuul/nodepool master: DNM: Demonstrate image leak https://review.opendev.org/682127 | 17:58 |
fungi | clarkb: yeah, i figure it was a dubious claim to fame on their part | 17:58 |
openstackgerrit | David Shrewsbury proposed zuul/nodepool master: DNM: Demonstrate image leak https://review.opendev.org/682127 | 17:59 |
fungi | and yes, trader vic's is a chain of tiki bars, the one in the atlanta downtown hilton is merely on location of many | 17:59 |
clarkb | well the original trader vics does make that claim but they were in oakland in the 40s | 17:59 |
corvus | gundalow: there is a trader vic's in london if you want to do some advance prep work; apparently that's actually the oldest extant one (since the flagship moved) | 17:59 |
fungi | neat! | 17:59 |
fungi | clarkb: right, i didn't mean to suggest the atlanta location claimed to be the inventors, just the chain in general | 18:00 |
fungi | it's thoroughly kitsch though, which is my main source of enjoyment there | 18:00 |
clarkb | I've actually been trying for a while to get some of those mats they haev on the walls, but my parents say they aren't really made anymore because they are too time consuming and you can buy other "better" replacements | 18:02 |
fungi | also for those missing boston, there's a "legal seafoods" location in the atl airport as of a few years now | 18:02 |
corvus | clarkb: :( | 18:02 |
*** panda has quit IRC | 18:02 | |
fungi | clarkb: and that's how cultural heritage goes down the drain, i guess. make way for modern progress! | 18:02 |
clarkb | corvus: ya you have to dry out the pandanus leaves, then cut them into strips then spends hours weaving them together. :( | 18:03 |
*** panda has joined #zuul | 18:03 | |
*** nhicher has quit IRC | 18:15 | |
openstackgerrit | Mohammed Naser proposed zuul/nodepool master: k8s: make context optional https://review.opendev.org/682130 | 18:17 |
*** noorul has quit IRC | 18:24 | |
*** jamesmcarthur has quit IRC | 18:26 | |
*** hwangbo has quit IRC | 18:31 | |
tristanC | Shrews: found a few issues with autohold-revamp, but it looks great otherwise. I applied it locally to a real deployment and it works as expected | 18:40 |
Shrews | tristanC: many thanks! will get to those issues shortly | 18:41 |
tristanC | Shrews: is there a torture kind of test process i can use to validate the kazoo tree cache stuff? | 18:41 |
Shrews | tristanC: no. that was totally based off of the cache stuff tobiash added to nodepool, which has no such test either | 18:43 |
clarkb | kazoo itself may have tooling around that we could adapt? | 18:43 |
tristanC | on a side-node, i've been doing a lot of python type annotation lately... would be great to start using types in zuul/nodepool. what is preventing us from bumping min python version to >=3.6? | 18:43 |
*** saneax has quit IRC | 18:44 | |
clarkb | tristanC: support for ubuntu xenial (any idea what version of python3 will be in centos 7.7?) | 18:44 |
pabelanger | opendev is still on xenial for something, so no python 3.6 there | 18:44 |
tristanC | clarkb: centos 7.7 is py3.6 | 18:44 |
clarkb | iirc you can do type annotations on 3.5 though | 18:44 |
clarkb | it was 3.4 that you couldn't | 18:44 |
clarkb | https://docs.python.org/3.5/library/typing.html seems to confirm? | 18:45 |
pabelanger | I'm kinda shocked centos 7.7 added python3 support | 18:45 |
clarkb | in fact zuul already does type hints so ya I think its fine as is? | 18:47 |
clarkb | pabelanger: rhel 7 added it and centos consumed it from there. Seems like it would've helped a lot if they did it a couple years ago though :/ | 18:48 |
clarkb | in any case it is there now so yay | 18:48 |
clarkb | or will be when .7 releases | 18:48 |
pabelanger | clarkb: indeed, looking foward to trying it out | 18:49 |
tristanC | clarkb: variable annotations really benefits from https://www.python.org/dev/peps/pep-0526/ , and there are other things missing from 3.5 which makes it hard to annotate properly iirc | 18:51 |
clarkb | tristanC: "this pep is fully backward compatible" I parse that to mean you can run that under python3.5 you just might not get all the checking? | 18:53 |
clarkb | or maybe that is a bug in the pep | 18:53 |
clarkb | oh I see they added syntax and don't necessarily use the comments then ya that might not actually be backward comaptibile | 18:54 |
webknjaz | Interpreter never does type checks. It only populates a variable with that metadata | 18:55 |
tristanC | pep-526 doesn't undo pep-484, but 3.5 yield syntax error when using the new syntax | 18:55 |
corvus | feel free to add annotations if you think they would be useful using the current comment syntax. we have mypi checking them, so they get validated in testing. | 18:56 |
corvus | we have found them useful in some cases and a waste of time in others. | 18:56 |
corvus | so use them judiciously :) | 18:56 |
corvus | (please no one submit a patch that adds annotations everywhere) | 18:56 |
clarkb | tristanC: the new syntax doesn't seem to work with 3.5 at all | 18:56 |
clarkb | so you have to use the old syntax | 18:56 |
tristanC | webknjaz: wouldn't it be possible that the interpreter validate types in the future? | 18:58 |
webknjaz | That can be done by third party packages | 18:59 |
tristanC | corvus: i found that unless you use mypy --strict mode, then the annotations are often not being checked | 18:59 |
webknjaz | There's `enforce` if you want to do runtime checks | 18:59 |
webknjaz | But the common practice is to use mypy IN CI | 18:59 |
webknjaz | *in | 18:59 |
corvus | tristanC, clarkb: here's a non-comment annotation: https://opendev.org/zuul/zuul/src/branch/master/zuul/model.py#L2043 | 19:00 |
corvus | so we can natively annotate arguments and return values | 19:01 |
tristanC | corvus: yes, function annotation works in 3.5, but not types | 19:01 |
tristanC | not variables* | 19:01 |
clarkb | corvus: ya its the my_var: int ones that don't work | 19:01 |
clarkb | though the previous pep allowed for ^ in comments | 19:01 |
corvus | oh. i'm far less convinced of the utility of that | 19:01 |
clarkb | so I think you can use that syntax instead? | 19:01 |
webknjaz | There's also a PEP for annotation stubs if you prefer separate files | 19:02 |
tristanC | clarkb: yes you could, but i find those comment not very clean and prefer using the proper syntax supported in 3.6 | 19:03 |
clarkb | tristanC: it would be a fairly easy transition to the 3.6 syntax once we drop 3.5 if we already have the comments in place particularly if we use them judiciously as corvus suggest | 19:04 |
clarkb | tristanC: and you get the same utility out of them in the mean time | 19:04 |
corvus | i may have been mistaken about the commentts | 19:04 |
tristanC | corvus: i find typing very useful, but i wouldn't push hard to get zuul fully annotated as it can be annoying sometime | 19:04 |
corvus | we may have decided not to use them and limit just to the functions for now | 19:04 |
webknjaz | https://www.python.org/dev/peps/pep-0484/ | 19:04 |
* corvus lunches | 19:06 | |
tristanC | corvus: iirc mypy behavior, it won't check caller of https://opendev.org/zuul/zuul/src/branch/master/zuul/model.py#L2043 unless they are also annotated (or unless we use mypy --strict). | 19:07 |
clarkb | tristanC: what is it checking then? | 19:08 |
corvus | (easy way to test that :) | 19:08 |
tristanC | clarkb: the body of the function... | 19:08 |
clarkb | also aiui changing the syntax won't change the verification | 19:08 |
tristanC | clarkb: no it wont, and what bothered me with py3.5 (and actually 3.6 too as it's only introduced in 3.7) is https://www.python.org/dev/peps/pep-0563/ | 19:11 |
tristanC | where you can't reference the type of class from within the class | 19:11 |
tristanC | without pep-563 | 19:11 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: DNM: show that mypy doesn't check type for caller https://review.opendev.org/682142 | 19:16 |
tristanC | corvus: clarkb: ^ | 19:16 |
mnaser | i've been thinking about the best approach for solving a problem where you're running multiple zuuls but want to use the same github app.. | 19:21 |
mnaser | i _could_ use different tenants inside zuul but the problem is i can't have nodepool-per-tenant (cause each user could have their own different servers) | 19:22 |
mnaser | the only way would be somehow to make zuul-* services talk to a zookeeper server that is defined per tenant .. and i think that might do the trick but introduces other wild things | 19:22 |
tristanC | mnaser: why would you run multiple zuuls? | 19:23 |
mnaser | tristanC: because different tenants have different nodepools | 19:23 |
tristanC | mnaser: doesn't the allowed-labels enough to isolate nodepool per tenants? | 19:23 |
mnaser | to an extent, because now i have to come up with some weird label for every single user | 19:24 |
mnaser | i.e. user-a-ubuntu-bionic, user-b-ubuntu-bionicv | 19:24 |
mnaser | vs having native 'ubuntu-bionic' labels for example | 19:24 |
*** hashar has joined #zuul | 19:24 | |
mnaser | imagine a "bring your own credentials" use case here, so tenant A and tenant B don't know anything about each other (nor do they want to either :)) | 19:25 |
pabelanger | mnaser: I've recently found, multiple github apps is better. But only one can merge | 19:26 |
pabelanger | setup per tenant | 19:26 |
mnaser | so that implies many connections inside zuul as well? | 19:27 |
pabelanger | yup, https://github.com/ansible-network/windmill-config/blob/master/zuul/zuul.conf.j2#L80 | 19:27 |
pabelanger | now, I don't know how well that scales on network side | 19:27 |
pabelanger | but, so far, github driver seems okay | 19:27 |
mnaser | i mean i know this might sound crazy but i was kinda thinking of writing a very simple 'incoming webhook multiplexer' | 19:27 |
mnaser | because if i know for what repo the incoming change is, and i know what repo does each zuul have, i can send it to the right one | 19:28 |
mnaser | so more-or-less a proxy, that way i can maintain the same github app everywhere | 19:28 |
pabelanger | For me, I'd see how to maybe support multiple nodepools in a single zuul (given we do support multiple builders / launchers). We'd just need to deal with label issue | 19:30 |
pabelanger | running multiple zuul / nodepools, is a lot of overhead | 19:30 |
mnaser | i mean in this case, i just came up with a bunch of k8s manifests and its not _that_ much overhead right now (and this is a case where you're running jobs in k8s pods) | 19:32 |
mnaser | so to me that's a bit less of a concern at least | 19:32 |
pabelanger | more thinking on the base jobs side of things. Could start getting complicated, sharing the base resources over multiple zuuls | 19:32 |
mnaser | i dont think this is a scenario where a repo might be managed by different zuuls, its still a 1 zuul per repo type of thing | 19:33 |
clarkb | in you multi zuul setup its still one github app per zuul right? | 19:36 |
clarkb | is that an issue? | 19:36 |
mnaser | clarkb: no the idea is to actaully try and make it one github app for N zuuls | 19:36 |
mnaser | that way: "go add this app to your github org, add it to your zuul config, and you're golden" | 19:37 |
mnaser | rather than "to start, go and start creating app/installs keys/etc/etc" .. i do understand/feel this is pretty bespoke | 19:37 |
clarkb | how would you map events in your proxy? | 19:38 |
pabelanger | I think you atleast want 2 githubs, by default too. Some repos won't want zuul to merge code, but only run tests. eg: 3pci | 19:38 |
pabelanger | github apps* | 19:39 |
mnaser | the idea was because im dynamically configuring my zuuls (from k8s CRDs) then said proxy can watch for those changes | 19:39 |
pabelanger | clarkb: I think the issue is more, each tenant has their own ubuntu-bionic label in nodepool. But they want them to be different images | 19:40 |
pabelanger | nodepool would need to grow multi-tenant support for that | 19:40 |
clarkb | pabelanger: ya thats solvedby one zuul per tenant | 19:40 |
fungi | pabelanger: clarkb: the annoying thing is the centos 7.7 release has significantly delated the centos 8.0 release, since they prioritized 7.7 (understandably, but still aggravating) | 19:40 |
mnaser | or in other terms, there will be a db that generates zuul configs, and using that same db to 'proxy' | 19:40 |
mnaser | so if i get an event for 'foo', i already know that repo is configured by 'zuul-y' | 19:41 |
pabelanger | mnaser: clarkb: I think you could solve it today, but automating some of the label bits, to have <tenant>-ubuntu-bionic in nodepool. Then for the nodeset, for each tenant create ubuntu-bionic, but with <tenant>-ubuntu-bionic label | 19:41 |
pabelanger | and abstract so of that away from user | 19:41 |
pabelanger | we did that in rdoproject | 19:42 |
mnaser | sigh, but as I talk out loud about this, I realize that the risk of a user adding a project they don't own is a thing now | 19:42 |
pabelanger | for upstream / downstream images | 19:42 |
clarkb | mnaser: ya andcould be multiple zuuls you multicast the event to | 19:42 |
clarkb | mnaser: yes | 19:42 |
clarkb | which us why the one app per zuul makes sense ti me | 19:42 |
clarkb | then the github userhas to explicitly decide they want that zuul's result | 19:43 |
mnaser | yeah it doesn't seem like getting over the get-a-zuul-app-on-github hump is a not really posssible | 19:43 |
fungi | unless folks at github like jlk have ideas on how to improve that experience from the gh end | 19:44 |
SpamapS | I think a single github app that routes webhooks where they need to go is brilliant. | 19:46 |
SpamapS | Keeps things simple, very little change in Zuul.. just needs the proxy that maps repo->zuul instance | 19:47 |
SpamapS | But.. it would be better if it was just mapping repo->tenant | 19:47 |
mnaser | SpamapS: i think the concern is how do i make sure mnaser doesn't add SpamapS/my-secrets to their list of projects | 19:47 |
clarkb | if you are both otherwise usersof the same zuul | 19:48 |
pabelanger | mnaser: for me, the harder part, is not having users change repo admin settings behind zuuls back. A few times zuul has stopped merging code, due to those changes | 19:48 |
mnaser | not the same zuul, but through teh same "zuul proxy" | 19:48 |
clarkb | oya that | 19:48 |
pabelanger | I'm kinda on the fense now, if zuul isn't repo admin, only 3pci | 19:48 |
mnaser | i mean | 19:49 |
mnaser | the same proxy can have a very simple ui that uses github oauth | 19:49 |
mnaser | so no one can arbitrarily add projects | 19:49 |
mnaser | github has to let you add it | 19:50 |
clarkb | ya but that alsonisnt very different than using github auth to add a different app | 19:50 |
clarkb | in github directly | 19:50 |
mnaser | except you have to pre-provision all those apps for every single deployment which can probably become quite hectic .. i think | 19:50 |
mnaser | but yeah, thats true | 19:50 |
pabelanger | I do think there are 2 requirements though, for running tests on a github repo, and gating commit on a github repo. The first is much easier then 2nd | 19:51 |
mnaser | true | 19:52 |
clarkb | mnaser: you could provision it at the same time you provision the new zuul can't you? though mybe I shouldn't assume that is possible via the github api | 19:52 |
mnaser | thats a reasonable idea | 19:52 |
* mnaser checks | 19:52 | |
mnaser | oooOoOoo | 19:53 |
mnaser | https://developer.github.com/apps/building-github-apps/creating-github-apps-from-a-manifest/ | 19:53 |
openstackgerrit | Fabien Boucher proposed zuul/zuul master: Pagure - add support for git.tag.creation event https://review.opendev.org/679938 | 19:54 |
openstackgerrit | Fabien Boucher proposed zuul/zuul master: Pagure - add support for git.tag.creation event https://review.opendev.org/679938 | 19:55 |
clarkb | then all the user has to do is auth to github and say I allow this app to ci my project | 19:56 |
pabelanger | clarkb: +1 to per-project github apps | 19:58 |
corvus | mnaser, pabelanger, clarkb: i'd be behind a spec to extend tenancy to nodepool | 20:01 |
openstackgerrit | Fabien Boucher proposed zuul/zuul master: Pagure - handle Pull Request tags (labels) metadata https://review.opendev.org/681050 | 20:02 |
*** panda has quit IRC | 20:05 | |
*** panda has joined #zuul | 20:08 | |
*** igordc has joined #zuul | 20:10 | |
webknjaz | tristanC: `from __future__ import annotations` | 20:19 |
*** noorul has joined #zuul | 20:20 | |
jlk | I'm missing too much context to effectively weigh in on this discussion, re apps per project | 20:20 |
*** noorul has quit IRC | 20:25 | |
tristanC | webknjaz: iirc that only works on py3.7 | 20:29 |
openstackgerrit | James E. Blair proposed zuul/zuul master: WIP: Support HTTP-only Gerrit https://review.opendev.org/681936 | 20:31 |
webknjaz | tristanC: yes | 20:33 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: Add tox-py37 to Zuul check https://review.opendev.org/682158 | 20:36 |
*** roman_g has quit IRC | 20:42 | |
*** openstackgerrit has quit IRC | 20:51 | |
*** pcaruana has quit IRC | 21:03 | |
*** rf0lc0 has quit IRC | 21:12 | |
*** dkehn has quit IRC | 21:21 | |
*** avass has quit IRC | 21:22 | |
*** openstackgerrit has joined #zuul | 21:30 | |
openstackgerrit | James E. Blair proposed zuul/zuul master: Support HTTP-only Gerrit https://review.opendev.org/681936 | 21:30 |
*** EvilienM is now known as EmilienM | 21:52 | |
*** hashar has quit IRC | 22:01 | |
*** armstrongs has joined #zuul | 22:33 | |
*** rlandy has quit IRC | 22:38 | |
*** Goneri has quit IRC | 22:41 | |
*** armstrongs has quit IRC | 22:43 | |
*** mattw4 has quit IRC | 23:11 | |
*** tosky has quit IRC | 23:23 | |
corvus | i believe i have completed all the changes necessary to point a zuul at gerrit-review.googlesource.com. hopefully next week we can merge those, restart opendev's zuul, verify i didn't break talking to our own gerrit, and then get started on hooking up to gerrit's gerrit to test it out. | 23:47 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!