| *** bhavikdbavishi has joined #zuul | 03:02 | |
| *** sshnaidm is now known as sshnaidm|afk | 04:07 | |
| *** chkumar has joined #zuul | 04:34 | |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul-jobs master: Add a markdownlint job and role https://review.openstack.org/607691 | 04:37 |
|---|---|---|
| *** bjackman has joined #zuul | 05:22 | |
| *** chkumar is now known as chkumar|ruck | 05:27 | |
| *** chkumar has joined #zuul | 05:44 | |
| *** chkumar|ruck has quit IRC | 05:47 | |
| *** chkumar has quit IRC | 05:48 | |
| *** chkumar246 has joined #zuul | 06:03 | |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul-jobs master: Add a markdownlint job and role https://review.openstack.org/607691 | 06:04 |
| *** bhavikdbavishi1 has joined #zuul | 06:17 | |
| *** bhavikdbavishi has quit IRC | 06:18 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 06:19 | |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul-jobs master: Add a markdownlint job and role https://review.openstack.org/607691 | 06:36 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul-jobs master: Add a markdownlint job and role https://review.openstack.org/607691 | 06:39 |
| *** chkumar246 is now known as chkumar|ruck | 06:44 | |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul-jobs master: Add a markdownlint job and role https://review.openstack.org/607691 | 06:46 |
| SpamapS | Seeing how we're testing the markdownlint job by poking a recheck in sandbox makes me think we may actually want that to be a feature in Zuul | 06:46 |
| SpamapS | Would be cool if one could put a in a pipeline on zuul-jobs that basically says "hey, when this job runs, actually run that project's job, as a depends-on for this change" | 06:50 |
| SpamapS | s/a in a/a thing in a/ | 06:51 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul-jobs master: Add a markdownlint job and role https://review.openstack.org/607691 | 06:58 |
| *** bjackman has quit IRC | 06:59 | |
| *** quiquell|off is now known as quiquell | 07:11 | |
| *** bjackman has joined #zuul | 07:29 | |
| bjackman | Oh BTW I subbed to Zuul-discuss but when I sent a mail I still got "Post by non-member to a members-only list" - if I just wait will it get approved? | 07:42 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul-jobs master: Add a markdownlint job and role https://review.openstack.org/607691 | 07:49 |
| quiquell | Good morning, is possible to call zuul's rpc listener with curl ? | 08:24 |
| tobiash | quiquell: zuul's rpc listener uses gearman so no curl | 08:32 |
| quiquell | tobiash: I see we have a ansible-role-gearman https://github.com/openstack/ansible-role-gearman | 08:32 |
| quiquell | tobiash: just want to call get_tenants to check that zuul is up | 08:32 |
| tobiash | quiquell: the list of tenants can be queried from zuul-web (which uses rpc listener) | 08:33 |
| quiquell | tobiash: And to do it command line ? | 08:33 |
| quiquell | tobiash: Humm ahh I can call zuul-web interface with curl :-) silly me | 08:34 |
| tobiash | yes :) | 08:34 |
| quiquell | tobiash: chanks btw, is this any good ? https://review.openstack.org/#/c/618484/ | 08:34 |
| quiquell | tobiash: was not sure about it | 08:34 |
| tobiash | quiquell: I think it's better than displaying the loading..., but maybe we want finally an error message in the web ui in that case | 08:36 |
| SpamapS | quiquell: note that the zuul web UI does exactly that. :) | 08:38 |
| quiquell | SpamapS: yep, I was stubborn with gearman, just forgot about cool zuul API you have there, | 08:39 |
| SpamapS | API's, they're all the rage with the kids these days. | 08:39 |
| quiquell | SpamapS: I want to be a kid to forbot about my age that's why I always APIs | 08:39 |
| quiquell | s/forbot/forget/g | 08:40 |
| quiquell | SpamapS: What's the best api endpoint to check scheduler is up and running ? | 08:40 |
| quiquell | SpamapS: api/tenants or sapi/status ? | 08:40 |
| SpamapS | probably status | 08:42 |
| SpamapS | since that one is tailored for white label vs. multi-tenant | 08:42 |
| quiquell | SpamapS: cool cool | 08:43 |
| SpamapS | actually /api/info might be better | 08:43 |
| *** jpena|off is now known as jpena | 08:49 | |
| *** hashar has joined #zuul | 08:53 | |
| *** themroc has joined #zuul | 08:57 | |
| quiquell | SpamapS: working thanks !! btw do you control how much do you hit gerrit ? | 09:07 |
| *** kklimonda_ has joined #zuul | 09:17 | |
| *** TheJulia_ has joined #zuul | 09:17 | |
| *** spsurya_ has joined #zuul | 09:17 | |
| *** bhavikdbavishi has quit IRC | 09:21 | |
| *** mgagne_ has joined #zuul | 09:23 | |
| *** spsurya has quit IRC | 09:25 | |
| *** zigo has quit IRC | 09:25 | |
| *** samccann has quit IRC | 09:25 | |
| *** EmilienM has quit IRC | 09:25 | |
| *** mgagne has quit IRC | 09:25 | |
| *** TheJulia has quit IRC | 09:25 | |
| *** kklimonda has quit IRC | 09:25 | |
| *** spsurya_ is now known as spsurya | 09:25 | |
| *** kklimonda_ is now known as kklimonda | 09:25 | |
| *** TheJulia_ is now known as TheJulia | 09:25 | |
| *** chkumar|ruck has quit IRC | 09:29 | |
| *** chkumar246 has joined #zuul | 09:31 | |
| *** chkumar246 is now known as chkumar|ruck | 09:31 | |
| quiquell | SpamapS: best way I found was status and check zuul_status inside it, it also tell you if tenant is not ready | 09:39 |
| openstackgerrit | Quique Llorente proposed openstack-infra/zuul master: Do a proper wait for zuul at quickstart https://review.openstack.org/619993 | 09:45 |
| bjackman | (The reason my Zuul-discuss wasn't working turned out to be because there's a confirmation request, and it was going into my junk folder. I honestly thought spam filter false positives were a thing of the past!) | 09:45 |
| quiquell | tobiash, SpamapS: ^ imeplemented a proper wait for zuul for the quickstart | 09:45 |
| quiquell | SpamapS: also this to have the model before sql connection is ready https://review.openstack.org/#/c/618484/ | 09:52 |
| *** nilashishc has joined #zuul | 09:52 | |
| *** gtema has joined #zuul | 09:56 | |
| *** sshnaidm|afk is now known as sshnaidm | 10:07 | |
| *** zxiiro has joined #zuul | 10:12 | |
| bjackman | So, the thing I was going to propose last week (where we only put a change into a pipeline once the whole Gerrit stack has been approved), it is not quite as simple as I thought | 10:26 |
| bjackman | Having looked a bit more at the Zuul code I realise that the idea of 1 "change" == 1 job is baked pretty deeply in, and for Gerrit 1 change == 1 commit | 10:27 |
| bjackman | So I think to get a situation where 1 job tests multiple commits I need to break one of those equivalences | 10:28 |
| bjackman | Does that sound correct? | 10:29 |
| tobiash | bjackman: yes, the pipelines are change centric so we might need a virtual change as a container for more changes | 10:34 |
| bjackman | tobiash, OK | 10:42 |
| bjackman | Oh BTW, is the word "item" a special piece of Zuul jargon? | 10:52 |
| *** electrofelix has joined #zuul | 10:59 | |
| tobiash | bjackman: you mean the item in a pipeline? I would be more precise and name it QueueItem ;) | 11:08 |
| tobiash | bjackman: a queue item contains the change and the buildset which holds the current state of the running and planned job executions of the queue item | 11:09 |
| bjackman | OK yeah that's probably the thing I'm thinking of | 11:11 |
| bjackman | tobiash, E.g. the "item" passed to *Reporter.report | 11:11 |
| tobiash | bjackman: yes, that should be the queue item | 11:22 |
| *** gtema has quit IRC | 11:25 | |
| *** bhavikdbavishi has joined #zuul | 11:32 | |
| *** dkehn has quit IRC | 11:39 | |
| *** rfolco has joined #zuul | 11:54 | |
| *** hashar has quit IRC | 12:10 | |
| openstackgerrit | Fabien Boucher proposed openstack-infra/zuul-jobs master: Propose to move submit-log-processor-jobs and submit-logstash-jobs in zuul-jobs https://review.openstack.org/537847 | 12:16 |
| SpamapS | quiquell: I use Github actually. | 12:28 |
| quiquell | SpamapS: what do you mean ? | 12:28 |
| SpamapS | You asked if I control how much I hit gerrit. | 12:29 |
| quiquell | SpamapS: ahh ok, no problem was a red herring | 12:29 |
| *** gtema has joined #zuul | 12:29 | |
| SpamapS | bjackman: For your situation, you should juse use merge commits. | 12:29 |
| SpamapS | bjackman: You can have 1 change in gerrit be a merge from another branch that has multiple commits stacked. | 12:30 |
| SpamapS | That's not how OpenStack does things, because merge commits can be a real PITA, but if you want that more atomic unit of many commits.. that's the way to go. | 12:30 |
| SpamapS | It's actually not a bad way to test syncs from an upstream open source repo all at once. | 12:31 |
| *** jpena is now known as jpena|lunch | 12:38 | |
| *** bhavikdbavishi has quit IRC | 12:41 | |
| tobiash | SpamapS: grouping changes together would solve the circular dependencies use case too (I know that's a bad habit but in some cases there is no way around it) | 12:45 |
| bjackman | SpamapS, won't the commits that show up in the merge commit show up in the needs_changes anyway?\ | 12:47 |
| tobiash | I don't think so | 12:48 |
| *** bjackman_ has joined #zuul | 12:53 | |
| bjackman_ | tobiash, SpamapS: Yeah that's interesting, Zuul consideres the merge commit as a single change | 12:54 |
| bjackman_ | However Gerrit won't let it merge the merge commit if the commits that it merges haven't already got the requried approvals | 12:54 |
| bjackman_ | So you'd still have to run each of those commits through the pipeline | 12:55 |
| *** hashar has joined #zuul | 12:55 | |
| bjackman_ | Unless you play funny games with Gerrit's submittability predicates | 12:56 |
| *** EmilienM has joined #zuul | 12:57 | |
| *** rlandy has joined #zuul | 12:57 | |
| *** bjackman has quit IRC | 13:03 | |
| *** bjackman_ has quit IRC | 13:04 | |
| *** bjackman has joined #zuul | 13:04 | |
| SpamapS | no | 13:13 |
| SpamapS | You don't vote on commits | 13:13 |
| SpamapS | you vote on changes | 13:13 |
| SpamapS | The problem is that you're doing ff merges | 13:13 |
| SpamapS | bjackman: git merge --no-ff should get the job done. | 13:13 |
| bjackman | SpamapS, I used --no-ff | 13:14 |
| SpamapS | Hm, that's super weird then. | 13:14 |
| SpamapS | Because Gerrit's model just treats that as one "change" | 13:14 |
| bjackman | SpamapS, the merged commits are showing up in the UI in the "Relation chain" bit | 13:14 |
| SpamapS | It's possible zuul has assumptions around commit:change 1:1 ... but it shouldn't. | 13:15 |
| bjackman | SpamapS, I have 3 changes in gerrit | 13:15 |
| SpamapS | bjackman: that's weird, but my experience on this is now 2 years old so it's possible there are just weird gerrit things that I don't understand. | 13:15 |
| bjackman | SpamapS, Git log looks like this: https://paste.gnome.org/pf6aehdqj | 13:16 |
| SpamapS | doh.. I forgot to go to sleep last night I was having so much fun automating stuff w/ zuul :-P | 13:16 |
| bjackman | SpamapS, they all have Change-Ids | 13:16 |
| SpamapS | bjackman: yeah, I'd expect only one "Change" to matter. | 13:16 |
| SpamapS | having lots of change-id's should be fine, because Gerrit is looking at refs on top of branches... and that is one ref, the merge commit, on top of one branch, master. | 13:17 |
| bjackman | SpamapS, TBH I wouldn't want Gerrit to let me merge a merge commit without having the necessary approvals on the commits that it merges | 13:17 |
| SpamapS | it likely just picked them up as related and there may be a way to make your gerrit not apply rules to related changes like that. I dunno. | 13:18 |
| bjackman | (Sorry, on the changes corresponding to the commits that it merges) | 13:18 |
| SpamapS | bjackman: it's entirely possible I don't actually understand. ;) | 13:18 |
| bjackman | SpamapS, Haha OK | 13:19 |
| bjackman | I'm gona go ahead with my attempt to design a zuul "change" that encapsulates multiple Gerrit changes | 13:19 |
| bjackman | (Unfortunate that zuul and Gerrit will still be using the same word "change" though) | 13:20 |
| *** hashar has quit IRC | 13:22 | |
| *** hashar has joined #zuul | 13:25 | |
| *** jpena|lunch is now known as jpena | 13:29 | |
| *** gouthamr has quit IRC | 13:34 | |
| openstackgerrit | Fabien Boucher proposed openstack-infra/zuul-jobs master: Propose to move submit-log-processor-jobs and submit-logstash-jobs in zuul-jobs https://review.openstack.org/537847 | 13:37 |
| *** gouthamr has joined #zuul | 13:40 | |
| *** dkehn has joined #zuul | 13:41 | |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool master: Fix docstring on test_node_executor_zone test https://review.openstack.org/620056 | 13:49 |
| pabelanger | clarkb: follow up to your nodepool review the other day^ | 13:50 |
| *** dmellado has quit IRC | 13:51 | |
| *** bjackman has quit IRC | 13:52 | |
| *** dmellado has joined #zuul | 13:53 | |
| *** chkumar|ruck has quit IRC | 14:14 | |
| *** hashar has quit IRC | 14:23 | |
| *** hashar has joined #zuul | 14:30 | |
| *** nilashishc has quit IRC | 14:30 | |
| *** bhavikdbavishi has joined #zuul | 14:30 | |
| *** gtema has quit IRC | 14:37 | |
| * Shrews waves from the other side of a 2 week rest period | 14:42 | |
| * tobiash hands Shrews a welcome back cake | 14:47 | |
| *** bhavikdbavishi has quit IRC | 14:56 | |
| *** quiquell is now known as quiquell|off | 14:58 | |
| * corvus cuts a piece of cake | 15:05 | |
| tobiash | corvus, Shrews: I think the cache stack (ends at 619589) is ready for review | 15:12 |
| tobiash | it also includes cache driven stats updating :) | 15:12 |
| Shrews | tobiash: oh, i thought i +2'd at least a portion of that stack before i left. will look again shortly | 15:13 |
| tobiash | Shrews: yes the first three still have your +2 :) | 15:13 |
| Shrews | oh good | 15:14 |
| *** chkumar|away has joined #zuul | 15:14 | |
| tobiash | Shrews, corvus: maybe we also should decide if we want a release note or not on 616262 | 15:15 |
| Shrews | tobiash: corvus: my thinking on that release note was mainly for folks closely following the changes and noticed that schema changes usually result in headaches (i had clarkb specifically in mind :) and thought it would be good to have something that said "yes, we considered this" | 15:19 |
| Shrews | i mostly wanted it there in case we needed a restart while I was away, but now that i'm back, i can go either way on having it or not | 15:20 |
| corvus | Shrews: yeah.... if we could find a way to do that without suggesting that people might be interested in using data in zookeeper, i'd be more keen. also, i like the idea of reserving release notes for when action is required or suggested, so that there aren't too many of them, so people might read them :) | 15:22 |
| tobiash | Shrews, corvus: so as there is no action required shall I just remove it? | 15:22 |
| tobiash | now re-reading it the category 'features' is wring anyway | 15:23 |
| tobiash | s/wring/wrong | 15:23 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool master: Add resource metadata to nodes https://review.openstack.org/616262 | 15:23 |
| tobiash | removed it ^ | 15:24 |
| *** dmsimard has quit IRC | 15:35 | |
| *** dmsimard has joined #zuul | 15:36 | |
| *** chkumar|away has quit IRC | 16:11 | |
| *** rlandy_ has joined #zuul | 16:25 | |
| *** rlandy has quit IRC | 16:27 | |
| *** themroc has quit IRC | 16:42 | |
| *** caphrim007_ has quit IRC | 16:42 | |
| *** hashar has quit IRC | 16:42 | |
| *** caphrim007_ has joined #zuul | 16:42 | |
| *** rlandy_ is now known as rlandy | 16:49 | |
| *** quiquell|off has quit IRC | 16:59 | |
| Shrews | corvus: GKE == Google K8S Engine? | 17:12 |
| corvus | Shrews: yep | 17:12 |
| Shrews | that seems easier to use than minikube :) | 17:13 |
| Shrews | how long is the trial period? | 17:13 |
| corvus | Shrews: well, up until they start charging you money. :) i just used it to verify their default behavior (since it was a question of what policies they implement) | 17:13 |
| corvus | Shrews: $300 worth over a year i believe | 17:14 |
| *** samccann has joined #zuul | 17:22 | |
| corvus | tobiash, Shrews: can you take a look at my comment on https://review.openstack.org/619025 ? | 17:46 |
| Shrews | corvus: no, but only because it does not exist | 17:47 |
| corvus | oh, ha. i guess gerrit is slow. i have 75 items in my gertty sync queue. | 17:48 |
| tobiash | must be a huge comment | 17:57 |
| corvus | Shrews, tobiash: it's there now | 17:59 |
| tobiash | corvus: yes, the reason was that the delayed event might change the already locked node | 18:03 |
| Shrews | corvus: tobiash: hrm, good point on the version numbers. I was wondering if/when we'd ever need to use those. Might make sense here. | 18:04 |
| tobiash | yes, that could probably work | 18:04 |
| openstackgerrit | Merged openstack-infra/nodepool master: Add resource metadata to nodes https://review.openstack.org/616262 | 18:05 |
| tobiash | corvus, Shrews: maybe we should also check the lock attribute to be safe? | 18:10 |
| *** jpena is now known as jpena|off | 18:13 | |
| *** manjeets has joined #zuul | 18:14 | |
| *** electrofelix has quit IRC | 18:16 | |
| corvus | tobiash: yes, good idea. we probably shouldn't only rely on that though, so that we don't update with old data after we release the lock. | 18:19 |
| openstackgerrit | Merged openstack-infra/nodepool master: Support node caching in the nodeIterator https://review.openstack.org/604648 | 18:19 |
| pabelanger | corvus: Shrews: if you don't mind adding https://review.openstack.org/618622/ to your review queue, that is required for zone support for zuul-executors: https://review.openstack.org/549197/ I believe it is in good shape to maybe land this week | 18:21 |
| corvus | pabelanger: will do | 18:25 |
| tobiash | hrm, need to rebase the whole stack to fix merge conflicts :/ | 18:32 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool master: Update node during lockNode https://review.openstack.org/616450 | 18:36 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool master: Update node during lockNode https://review.openstack.org/616450 | 18:37 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool master: Add extra safety belt when reusing a node https://review.openstack.org/616465 | 18:39 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool master: Cache node request zNodes https://review.openstack.org/618806 | 18:39 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool master: Update node request during locking https://review.openstack.org/618807 | 18:39 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool master: Update node request during locking https://review.openstack.org/618807 | 18:40 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool master: Add second level cache of nodes https://review.openstack.org/619025 | 18:43 |
| *** bjackman has joined #zuul | 18:44 | |
| *** sshnaidm is now known as sshnaidm|afk | 18:48 | |
| openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool master: Add second level cache of nodes https://review.openstack.org/619025 | 18:56 |
| tobiash | corvus, Shrews: this updates the nodes in-place as suggested ^ | 18:57 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool master: Add second level cache of nodes https://review.openstack.org/619025 | 19:04 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool master: Add second level cache to node requests https://review.openstack.org/619069 | 19:06 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool master: Only setup zNode caches in launcher https://review.openstack.org/619440 | 19:06 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool master: Asynchronously update node statistics https://review.openstack.org/619589 | 19:06 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool master: Add second level cache to node requests https://review.openstack.org/619069 | 19:12 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool master: Only setup zNode caches in launcher https://review.openstack.org/619440 | 19:13 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool master: Asynchronously update node statistics https://review.openstack.org/619589 | 19:13 |
| tobiash | sorry for spamming, I tried to separate rebasing from updating due to comments | 19:14 |
| fungi | separating rebase conflict resolution from other more substantial modifications is very much appreciated, so no need to apologize | 19:16 |
| *** hashar has joined #zuul | 19:28 | |
| *** bjackman has quit IRC | 19:49 | |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: Report tenant and project specific resource usage stats https://review.openstack.org/616306 | 20:04 |
| Shrews | pabelanger: can you walk me through what is supposed to happen with the use of executor-zone? Where is that attribute used? | 20:14 |
| pabelanger | Shrews: sure, https://review.openstack.org/549197/ is the zuul change which will use it. By itself, nodepool won't actually use that setting for anything | 20:15 |
| Shrews | pabelanger: ah, that's what i was looking for. thx | 20:15 |
| pabelanger | np! | 20:15 |
| Shrews | topic was different | 20:15 |
| pabelanger | hopefully admin/components.rst will explain, if not we can add the missing info | 20:15 |
| pabelanger | ah, we should make them the same | 20:15 |
| pabelanger | I can do that now | 20:15 |
| Shrews | pabelanger: You'll probably want to consider the case of someone upgrading and moving everything into zones. That would leave pre-existing, unassigned nodes laying around unused. Probably deserves an upgrade comment at the very least. | 20:23 |
| pabelanger | Shrews: on the nodepool side? | 21:01 |
| pabelanger | yah, maybe we should add something about the version of zuul that will actually support it | 21:01 |
| Shrews | pabelanger: I'm not sure which would be the best place to document it. This is the first nodepool config option that specifically mentions affecting zuul functionality. Maybe both? | 21:03 |
| pabelanger | yah, I don't think we've specifically stated a min version of each before | 21:04 |
| pabelanger | what do we think the next version of nodepool is, 3.4.0? | 21:05 |
| pabelanger | and 3.4.0 for zuul? | 21:06 |
| corvus | Shrews: i don't think we'll end up with unused node | 21:06 |
| pabelanger | if so, that lines up pretty well actuallyt | 21:06 |
| corvus | if a node doesn't have a zone, any executor can run jobs on it | 21:06 |
| corvus | i'm in favor of cross-documenting and having upgrade notes -- just wanted to point out that i don't think there's a big risk of wedging the upgrade | 21:07 |
| Shrews | corvus: i don't think the proposed code does that. lemme check again | 21:08 |
| corvus | Shrews: i haven't finished reviewing it; it may not :) | 21:08 |
| Shrews | corvus: oh, i think it does, actually | 21:08 |
| Shrews | but will let pabelanger confirm. if so, that solves that | 21:09 |
| corvus | well, it looks like the executor only registers "executor:execute:zone" if a zone is enabled | 21:10 |
| Shrews | yeah. i didn't review it closely enough | 21:10 |
| pabelanger | yah, on the nodepool side, there isn't any extra logic, we just write the executor_zone into zk, so if that is setup and old zuul is used, should be a noop | 21:10 |
| corvus | Shrews: so i think your concern is validated. we either need an upgrade note that discusses the possibility of wedging if there are zoneless nodes and no zoneless executors. or we need to have executors register both functions. | 21:11 |
| corvus | pabelanger: yeah, i think the risk is that zuul is upgraded and all executors have zones assigned and either nodepool is not upgraded, or existing ready nodes stick around and can't be used. | 21:12 |
| pabelanger | ah, right | 21:12 |
| pabelanger | so maybe a note on nodepool side to purge ready nodes is a good idea | 21:13 |
| pabelanger | on upgrade | 21:13 |
| Shrews | corvus: pabelanger: I'm starting to wonder if we should consider an arbitrary node.metadata attribute that can contain any data defined in the config (say in a pool.node_metadata config option). Then we could be out of the business of modifying the zk schema for functionality needed by any user of nodepool | 21:14 |
| corvus | i don't know whether it would be better to have executors register "executor:execute" and "executor:execute:zone", so that any executor is automatically able to run jobs for any zone-less nodes. or whether we should just leave that up to the user to run extra zone-less executors. | 21:14 |
| corvus | Shrews: i don't think this is necessarily zuul-specific. it's basically a way to indicate the topology of a node so that the consumer knows "where" it is. | 21:15 |
| pabelanger | my first thought is to leave it up to the user to define a zone-less executor | 21:15 |
| pabelanger | but, I can see the value in having one of your zoned executors also register executor:execute, if it is able to still reach all other providers | 21:16 |
| corvus | Shrews: (still, nodepool is part of zuul, so if we need something for zuul, i think we should add it. it's just that, in this case, i think we're adding a pretty generic piece of information in a generically useful way. which is how i'd prefer to do things) | 21:16 |
| Shrews | corvus: that's what i was (poorly) trying to say. generic stuff could go in the easily changed metadata attribute (without code changes in np). | 21:17 |
| corvus | Shrews: but looking past that -- if you think adding zones as part of a generic metadata framework is better, i could see that. | 21:17 |
| corvus | Shrews: yeah, i'm starting to grok | 21:17 |
| Shrews | i can see more such requests for this type of data as we add more drivers | 21:18 |
| corvus | pabelanger: let's keep things simple for now and just put in the upgrade note, and leave it to the user to create zone-less executors if needed. maybe we can add an option to also register zoneless-execute if folks want. | 21:19 |
| pabelanger | wfm | 21:20 |
| corvus | Shrews: oh, i see the field is called "executor-zone" in nodepool. that does make it sound a bit zuulish doesn't it? :) | 21:21 |
| Shrews | corvus: yes :) | 21:21 |
| Shrews | the genesis of my brain itch | 21:22 |
| corvus | i was imagining it was called 'zone'; i guess that's to disambiguate it from 'availability-zone' | 21:22 |
| corvus | Shrews: i'm digging your idea. i like the use of 'executor-zone' more in that context too. so the config value would be 'provider.pool.metadata.executor-zone' and that sets node.metadata.executor-zone | 21:27 |
| corvus | pabelanger: what do you think about one more round on the nodepool side? ^ | 21:27 |
| pabelanger | corvus: sure, I don't mind updating | 21:28 |
| Shrews | corvus: exactly (while gesturing hand wavily) | 21:29 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool master: Add release note for executor-zone setting https://review.openstack.org/620164 | 21:31 |
| pabelanger | okay, that is the release note, but obviously things have changed a little | 21:31 |
| pabelanger | need to step away for food shortly, but can update the patches for new metadata structure | 21:31 |
| corvus | Shrews: you want to leave a -1 for that? | 21:34 |
| Shrews | i can, sure | 21:35 |
| Shrews | i think i captured the discussion in my review comment | 21:42 |
| corvus | Shrews: i left a followup comment | 21:50 |
| Shrews | corvus: oh, yeah | 21:52 |
| Shrews | corvus: my brain is obviously still ramping up | 21:52 |
| corvus | Shrews: i know the feeling. and now it's time to ramp down for the day :) | 21:52 |
| *** jlvillal has joined #zuul | 22:00 | |
| pabelanger | corvus: Shrews: also left comment | 22:05 |
| ianw | pabelanger: mind an eye on the f27 cleanup in nodepool @ https://review.openstack.org/#/c/618416/ and then then the mirroring change @ https://review.openstack.org/614375 if you have a minute? | 22:26 |
| ianw | oh, i think they're backwards, but that's the two changes | 22:27 |
| openstackgerrit | Merged openstack-infra/zuul master: Do a proper wait for zuul at quickstart https://review.openstack.org/619993 | 22:28 |
| ianw | i wonder what "waiting" means in the zuul job queue graph -> http://grafana.openstack.org/d/T6vSHcSik/zuul-status?panelId=18&fullscreen&orgId=1 | 22:54 |
| ianw | i guess this is not the same a "queued" | 22:54 |
| ianw | stats.gauges.zuul.geard.queue.waiting | 22:55 |
| corvus | ianw: yeah, it's all gearman jobs. | 22:56 |
| corvus | ianw: it's not as interesting as the individual executor queue or merger queue graphs | 22:56 |
| corvus | ianw: (which break out the overall queue by function) | 22:56 |
| hashar | hello! I know I am inactive, but if you plan to upgrade Gerrit from 2.13 Zuul might have a ton of corner case bugs. I have a few hotfix on our old Zuul 2.5, will eventually check whether Zuul 3 is affected :) | 22:57 |
| corvus | hashar: thanks! i know i've seen some post 2.13 changes go by, and we just got a 2.16 patch (to support the new change url syntax) | 22:58 |
| hashar | corvus: hopefully I will have some time to write a quick report for the gotchas I found | 22:58 |
| ianw | corvus: hrm, you mean http://grafana.openstack.org/d/T6vSHcSik/zuul-status?panelId=24&fullscreen&orgId=1 ? | 22:58 |
| corvus | hashar: great, thanks! | 22:58 |
| corvus | ianw: yes and http://grafana.openstack.org/d/T6vSHcSik/zuul-status?panelId=31&fullscreen&orgId=1 | 22:59 |
| hashar | corvus: then next, I will try to setup a quick Zuul v3 poc for Wikimedia .Not sure whether we will retain Zuul though :-\ | 22:59 |
| corvus | hashar: have you seen https://zuul-ci.org/start | 22:59 |
| corvus | hashar: that may help you get a v3 POC up quickly | 23:00 |
| hashar | corvus: I have tried docker compose up from the example directory and got something running :) | 23:01 |
| hashar | ah yeah that is the tutorial I have been following. Congratulations for that documentation | 23:01 |
| ianw | corvus: hrm, but the queued jobs is currently zero? do we only really track the backlog in the outstanding node requests? | 23:02 |
| corvus | hogepodge: \o/ | 23:02 |
| openstackgerrit | Merged openstack-infra/zuul master: Add config parameters for WinRM timeouts https://review.openstack.org/619630 | 23:02 |
| corvus | ianw: yes and yes. those metrics really represent zuul health. for example: if executor queue is >0 for a sustained time, add more executors. | 23:02 |
| ianw | ok, cool | 23:03 |
| openstackgerrit | Merged openstack-infra/zuul master: Setup model before connection https://review.openstack.org/618484 | 23:05 |
| openstackgerrit | Merged openstack-infra/zuul master: Include executor variables in initial setup call https://review.openstack.org/601036 | 23:06 |
| openstackgerrit | Merged openstack-infra/zuul master: python3: Can't have unbuffered non-binary I/O https://review.openstack.org/601037 | 23:09 |
| *** hashar has quit IRC | 23:26 | |
| *** rlandy has quit IRC | 23:30 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!