| *** jamesmcarthur has joined #zuul | 00:03 | |
| *** jamesmcarthur has quit IRC | 00:08 | |
| openstackgerrit | Merged zuul/zuul-storage-proxy master: Use opendev base docker image and add jobs https://review.opendev.org/c/zuul/zuul-storage-proxy/+/774998 | 00:08 |
|---|---|---|
| corvus | https://hub.docker.com/r/zuul/zuul-storage-proxy/tags exists | 00:20 |
| corvus | i'll approve the rest | 00:20 |
| openstackgerrit | Merged zuul/zuul-storage-proxy master: Make container name prefix more generic https://review.opendev.org/c/zuul/zuul-storage-proxy/+/775243 | 00:32 |
| openstackgerrit | Merged zuul/zuul-storage-proxy master: Log at info level https://review.opendev.org/c/zuul/zuul-storage-proxy/+/775247 | 00:32 |
| openstackgerrit | Merged zuul/zuul-storage-proxy master: Just use CLOUD_NAMES as env variable https://review.opendev.org/c/zuul/zuul-storage-proxy/+/775248 | 00:32 |
| openstackgerrit | Merged zuul/zuul-storage-proxy master: Switch to uwsgi https://review.opendev.org/c/zuul/zuul-storage-proxy/+/775294 | 00:35 |
| *** tosky has quit IRC | 00:36 | |
| *** jamesmcarthur has joined #zuul | 01:05 | |
| *** jamesmcarthur has quit IRC | 01:37 | |
| *** jamesmcarthur has joined #zuul | 01:39 | |
| *** ikhan has joined #zuul | 02:45 | |
| *** ikhan has quit IRC | 02:49 | |
| *** jamesmcarthur has quit IRC | 03:37 | |
| *** jamesmcarthur has joined #zuul | 03:45 | |
| *** jamesmcarthur has quit IRC | 03:49 | |
| *** jamesmcarthur has joined #zuul | 03:50 | |
| *** jamesmcarthur has quit IRC | 04:18 | |
| *** jamesmcarthur has joined #zuul | 04:22 | |
| *** jamesmcarthur has quit IRC | 04:27 | |
| *** jamesmcarthur has joined #zuul | 04:28 | |
| *** jamesmcarthur has quit IRC | 04:33 | |
| *** ykarel_ has joined #zuul | 04:51 | |
| *** jamesmcarthur has joined #zuul | 04:55 | |
| *** jamesmcarthur has quit IRC | 04:59 | |
| *** jamesmcarthur has joined #zuul | 05:07 | |
| *** evrardjp has quit IRC | 05:33 | |
| *** evrardjp has joined #zuul | 05:33 | |
| *** jamesmcarthur has quit IRC | 05:34 | |
| *** jamesmcarthur has joined #zuul | 05:36 | |
| *** jamesmcarthur has quit IRC | 05:38 | |
| *** jamesmcarthur has joined #zuul | 05:42 | |
| *** jamesmcarthur has quit IRC | 05:45 | |
| *** jfoufas1 has joined #zuul | 05:50 | |
| *** jamesmcarthur has joined #zuul | 05:52 | |
| *** ykarel_ is now known as ykarel | 05:59 | |
| *** jamesmcarthur has quit IRC | 05:59 | |
| *** jamesmcarthur has joined #zuul | 06:01 | |
| *** jamesmcarthur has quit IRC | 06:13 | |
| openstackgerrit | Ron Izraeli proposed zuul/zuul master: Linkify BuildOutput https://review.opendev.org/c/zuul/zuul/+/775109 | 07:13 |
| *** ykarel_ has joined #zuul | 07:47 | |
| icey | am I correct that I can backup the /var/lib/zuul/keys/secrets/project/ directory on a zuul-scheduler to backup the secrets used for encrypting project secrets? | 07:48 |
| *** ykarel has quit IRC | 07:50 | |
| icey | looks like it, found https://docs.opendev.org/opendev/system-config/latest/zuul.html#secrets :) | 07:52 |
| *** hashar has joined #zuul | 07:54 | |
| *** rpittau|afk is now known as rpittau | 08:02 | |
| *** jamesmcarthur has joined #zuul | 08:14 | |
| *** jamesmcarthur has quit IRC | 08:18 | |
| *** tosky has joined #zuul | 08:24 | |
| *** harrymichal has joined #zuul | 08:32 | |
| fungi | that path will depend on how you've deployed things, so at least double-check there's something in there | 08:34 |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Gracefully handle non-existent label on unlabel https://review.opendev.org/c/zuul/zuul/+/775329 | 08:41 |
| avass | oh a merge conflict in a .gitmodules file causes problems with executors because it can't run 'git fetch', I guess the executors doesn't reset the repos before working on the next job? | 08:42 |
| avass | I geuss they can't easily do that because they're in a detached head | 08:46 |
| *** saneax has joined #zuul | 08:47 | |
| *** jpena|off is now known as jpena | 08:56 | |
| openstackgerrit | Albin Vass proposed zuul/zuul master: Reset repo to previouos head on .gitmodules error https://review.opendev.org/c/zuul/zuul/+/775334 | 09:17 |
| openstackgerrit | Albin Vass proposed zuul/zuul master: Reset repo to previouos head on .gitmodules error https://review.opendev.org/c/zuul/zuul/+/775334 | 09:19 |
| openstackgerrit | Albin Vass proposed zuul/zuul master: Reset repo to previous head on .gitmodules error https://review.opendev.org/c/zuul/zuul/+/775334 | 09:21 |
| openstackgerrit | Albin Vass proposed zuul/zuul master: Reset repo to previous head on .gitmodules error https://review.opendev.org/c/zuul/zuul/+/775334 | 09:30 |
| *** nils has joined #zuul | 09:44 | |
| openstackgerrit | Albin Vass proposed zuul/zuul master: Reset repo to previous head on .gitmodules error https://review.opendev.org/c/zuul/zuul/+/775334 | 10:08 |
| avass | 775334 should fix errors from committing broken .gitmodules file | 10:10 |
| *** andy-ladjadj has joined #zuul | 10:13 | |
| andy-ladjadj | Hello Zuul community, i have a review with +2 but in merge conflict for the second time, what is the process to resolve the conflict and start the gate in the "same time" (https://review.opendev.org/c/zuul/zuul/+/755929)? Thx | 10:20 |
| avass | andy-ladjadj: you can't | 10:23 |
| *** ykarel_ is now known as ykarel | 10:37 | |
| openstackgerrit | Albin Vass proposed zuul/zuul master: Reset repo to previous head on .gitmodules error https://review.opendev.org/c/zuul/zuul/+/775334 | 10:52 |
| andy-ladjadj | Avass: I wanted to say humain process to avoid to reproduce "merge conflict" before workflow +1 | 10:55 |
| *** jamesmcarthur has joined #zuul | 11:20 | |
| *** jamesmcarthur has quit IRC | 11:20 | |
| *** sshnaidm|afk has quit IRC | 11:41 | |
| *** sshnaidm|afk has joined #zuul | 11:49 | |
| *** sshnaidm|afk is now known as sshnaidm|off | 11:50 | |
| *** andy-ladjadj has quit IRC | 11:51 | |
| *** hashar has quit IRC | 12:03 | |
| *** andy-ladjadj has joined #zuul | 12:22 | |
| *** andy-ladjadj has quit IRC | 12:24 | |
| openstackgerrit | Albin Vass proposed zuul/nodepool master: WIP: Add shell-type config https://review.opendev.org/c/zuul/nodepool/+/775371 | 12:29 |
| avass | tobiash: before I continue on this, you don't happen to already have a patch available for that ^ ? :) | 12:30 |
| *** jpena is now known as jpena|lunch | 12:31 | |
| openstackgerrit | Sorin Sbârnea proposed zuul/zuul-jobs master: update-json-file: avoid failure when destination does not exists https://review.opendev.org/c/zuul/zuul-jobs/+/775373 | 12:33 |
| avass | zbr: does that need to run as sudo? | 12:36 |
| zbr | avass: valid question, or should it be become: '{{ update_json_file_become }}' ? | 12:38 |
| *** rlandy has joined #zuul | 12:38 | |
| zbr | if I put owner/group for the folder too, will it mess /etc too or will apply them only when needing to create folder? | 12:39 |
| avass | oh, I don't know | 12:40 |
| *** hashar has joined #zuul | 12:42 | |
| * zbr goes back to testing | 12:42 | |
| openstackgerrit | Albin Vass proposed zuul/zuul master: Reset repo to previous head on .gitmodules error https://review.opendev.org/c/zuul/zuul/+/775334 | 12:48 |
| *** andy-ladjadj has joined #zuul | 12:49 | |
| *** andy-ladjadj has quit IRC | 12:51 | |
| *** jamesmcarthur has joined #zuul | 13:21 | |
| openstackgerrit | Sorin Sbârnea proposed zuul/zuul-jobs master: update-json-file: avoid failure when destination does not exists https://review.opendev.org/c/zuul/zuul-jobs/+/775373 | 13:22 |
| *** jamesmcarthur has quit IRC | 13:25 | |
| openstackgerrit | Sorin Sbârnea proposed zuul/zuul-jobs master: update-json-file: avoid failure when destination does not exists https://review.opendev.org/c/zuul/zuul-jobs/+/775373 | 13:26 |
| *** jpena|lunch is now known as jpena | 13:30 | |
| openstackgerrit | Albin Vass proposed zuul/zuul master: Use shell-type config from nodepool https://review.opendev.org/c/zuul/zuul/+/775382 | 13:32 |
| avass | zbr: I guess that stat task is there so ansible doesn't change change owner/mode if it already exists? | 13:45 |
| zbr | avass: exactly | 13:46 |
| *** rlandy has quit IRC | 14:07 | |
| *** rlandy has joined #zuul | 14:07 | |
| *** rpittau is now known as rpittau|afk | 15:03 | |
| openstackgerrit | James E. Blair proposed zuul/zuul master: Prepare Zookeeper for scale-out scheduler https://review.opendev.org/c/zuul/zuul/+/717269 | 15:14 |
| corvus | swest: ^ just updated the commit msg to remove the part about the test time | 15:15 |
| swest | corvus: oh, ok. I think felixedel is still working on it | 15:15 |
| corvus | swest, felixedel: oh? i thought everything was addressed in that one? | 15:16 |
| swest | he wanted to cleanup the connection creation AFAIK | 15:16 |
| corvus | hrm; and here i am wanting to merge it... | 15:17 |
| felixedel | corvus: Yes, I wanted to clean up the connection creation and this seems to be scattered across multiple changes | 15:17 |
| corvus | what needs cleaning up? | 15:17 |
| felixedel | If you are fine with that change, we could also merge it and I move my cleanup parts into https://review.opendev.org/c/zuul/zuul/+/754360/26 | 15:19 |
| felixedel | While I was doing that I discovered that I could also directly channge it in the initial change of the stack, but I'm also fine to do it in the "Merge ZooKeeper connection methods" change | 15:20 |
| corvus | felixedel: i think i would like to do the minimum required in order to "require zk connections" so we can get 4.0 released :) | 15:21 |
| corvus | felixedel: so let's merge it as-is and refactor later? | 15:23 |
| felixedel | ok, so I will implement my cleanups in https://review.opendev.org/c/zuul/zuul/+/754360/26 and we could go ahead and merge https://review.opendev.org/c/zuul/zuul/+/717269/61 and https://review.opendev.org/c/zuul/zuul/+/721254/55 | 15:24 |
| felixedel | (the first two patches of the stack) | 15:24 |
| felixedel | corvus: Would that be ok for you? | 15:28 |
| corvus | well, i'm looking at 360 now since we're all here.... | 15:29 |
| felixedel | The cleanup is mainly about merging the ZooKeeperClient and the ZooKeeperConnection (which was introduced in that change), so we don't have to use one or the other in certain conditions, but only have one kind of "entry point" to ZooKeeper. | 15:33 |
| felixedel | As I did this cleanup originally further up in the stack and rebase dit down this would now also affect other patches (like the connect xyz to ZooKeeper) which it didn't before. | 15:34 |
| corvus | felixedel: i left a comment on 360 | 15:34 |
| corvus | felixedel: sorry i misspoke on that comment; i should have said nothing uses it as a connection manager | 15:38 |
| felixedel | corvus: I've replied | 15:40 |
| *** ykarel has quit IRC | 15:42 | |
| *** ykarel has joined #zuul | 15:42 | |
| corvus | felixedel: okay, i'm having trouble understanding what you want the end product to look like; it feels like the same thing is being refactored in three sequential changes. is it possible for us to just look at 721254, 716221, 716575, 716262? and defer the refactoring until later? | 15:46 |
| corvus | felixedel: either that, or i could wait a day or 2 for you to straighten out the refactor idea? | 15:54 |
| corvus | but based on what i see, i don't think we should merge anything until we have a plan to get to 716262 | 15:54 |
| *** harrymichal has quit IRC | 15:57 | |
| felixedel | We could also do the refactoring later, I just thought we don't need to introduce e.g. the ZooKeeperConnection and throw it away X patches afterwards. | 15:58 |
| felixedel | Maybe we can discuss this on Monday. | 15:59 |
| corvus | felixedel: i agree, that's why i was suggesting we drop 360 from the stack too (basically, i'm looking at dropping 360 and 442) | 15:59 |
| corvus | felixedel: sure. i'll mark 717269 as WIP. | 16:01 |
| felixedel | Hmm, I will check on Monday if the refactoring might not even be necessary when we don't introduce the connection in the first place. Like I said, originally I did that later on where it was necessary | 16:02 |
| corvus | okay. i may look at that a little bit today. i'll let you know what i find. | 16:02 |
| felixedel | ok | 16:02 |
| corvus | felixedel: have a good weekend :) | 16:02 |
| avass | corvus: if you got time later could you take a look at: https://review.opendev.org/c/zuul/zuul/+/775334 ? It's pretty straight forward. | 16:07 |
| *** EmilienM has quit IRC | 16:07 | |
| avass | But I guess there could be a better way to get out of that situation than a 'git reset --hard HEAD^' | 16:07 |
| *** EmilienM has joined #zuul | 16:16 | |
| zbr | corvus: any chance to help with https://review.opendev.org/c/zuul/zuul-jobs/+/775373 ? | 16:18 |
| *** rlandy is now known as rlandy|mtg | 16:22 | |
| *** ykarel is now known as ykarel|away | 16:54 | |
| *** jamesmcarthur has joined #zuul | 16:58 | |
| *** ykarel|away has quit IRC | 17:06 | |
| *** rlandy|mtg is now known as rlandy | 17:12 | |
| *** jpena is now known as jpena|brb | 17:13 | |
| *** hashar has quit IRC | 17:18 | |
| corvus | avass: if someone commits 2 broken .gitmodules in a row, would that fix fail (by essentially doing what we're doing today?) | 17:26 |
| avass | corvus: that would most probably happen yep | 17:27 |
| avass | I wish there was a 'git --ignore-submodules <command>' since zuul doesn't care about them anyway really | 17:28 |
| corvus | avass: hrm. let me think about this a bit more. | 17:28 |
| avass | would there be a problem if the executor just deletes the .gitmodules and commits that so it then can continue working as normal? | 17:31 |
| avass | I guess that would be gc'd eventually anyway | 17:31 |
| corvus | avass: another option might be to just delete the repo | 17:31 |
| avass | yeah but that's a bit too much when the repo is a couple of GB | 17:32 |
| corvus | avass: this doesn't happen often, right? :) | 17:32 |
| avass | no :) | 17:32 |
| avass | it happened when we moved a gerrit instance to azure and had to update the remote url | 17:32 |
| corvus | avass: i think maybe we can just delete the .gitmodules file and not commit it | 17:33 |
| avass | someone accidentally commited a .gitmodule with a merge conflict and that broke that repo on executor completely | 17:33 |
| corvus | i think git uses the copy in the working tree? | 17:33 |
| avass | I think I tried that and still got some error. but I was trying to get it working again so I didn't spend much time investigating why | 17:34 |
| avass | wait I might have saved a copy of the repo, let me check | 17:35 |
| avass | oh, it throws an error but actually does a fetch | 17:36 |
| corvus | what's the error? i don't see one in my local testing | 17:37 |
| avass | "error: bad config line 9 in blob :.gitmodules" | 17:37 |
| avass | but errorcode is 0 so I guess that should work? | 17:37 |
| corvus | hrm. i dunno; i don't like that error message :/ | 17:38 |
| corvus | avass: was the problematic commit actually merged into master (or a development branch)? like -- it wasn't just a change? | 17:39 |
| avass | it was just a change | 17:39 |
| avass | deleting the file and committing that works afaik however | 17:39 |
| *** gmann is now known as gmann_afk | 17:40 | |
| avass | and that wouldn't be any problem just in case there isn't a HEAD^ or HEAD^ is also faulty | 17:40 |
| *** nils has quit IRC | 17:51 | |
| *** jamesmcarthur has quit IRC | 17:59 | |
| *** jamesmcarthur has joined #zuul | 18:00 | |
| corvus | avass: i don't like that 'bad config in blob' error because it seems like git is reading something other than the current working tree... i don't know what commits it's looking at | 18:00 |
| avass | that only appears when the file is only deleted and not committed | 18:01 |
| corvus | right; i can't reproduce that | 18:01 |
| avass | oh weird | 18:01 |
| corvus | in my test, git is only looking at the current working tree; in yours it seems to be looking at blobs. and i don't know what the difference is. | 18:02 |
| avass | are you doing that locally? the executors are always working in a detached head state so that might have something to do with it | 18:02 |
| *** jpena|brb is now known as jpena | 18:03 | |
| corvus | good idea; i checkout out a commit sha and still see the same behavior | 18:03 |
| *** jamesmcarthur_ has joined #zuul | 18:03 | |
| *** jamesmcarthur has quit IRC | 18:04 | |
| corvus | hrm, i think i just found a code path where we could miss a repo reset | 18:14 |
| tobiash | corvus: do you happen to know if having many threads waiting for a signal is as bad as having many active threads or do you think that's less of a problem | 18:17 |
| corvus | tobiash: you mean waiting for a mutex (not a signal -- only one thread can wait for signals) | 18:17 |
| corvus | right? | 18:17 |
| corvus | (signals like sigint, etc) | 18:18 |
| tobiash | corvus: I mean the thread events | 18:18 |
| tobiash | the transition could be easier by some sort of future the thread waits for and there is one thread that does the server list processing and signals the waiting-for-deletion thread | 18:19 |
| tobiash | the NodeDeleter thread calls manager.waitForNodeCleanup(node.external_id) which currently queries the server list | 18:20 |
| corvus | tobiash: i don't remember the particulars right now, but i want to say that some mutex constructs in python can end up doing a bit of busy-waiting so it could be bad. it's worth looking into either the implementation or running a test program with strace. | 18:21 |
| tobiash | what if we change that in the provider to register the thread in the manager and then just sleep until the manager notifies the thread | 18:21 |
| corvus | avass: i think i'd prefer to delete the repo in this case; i know that's not great, but it's such an edge case and i'd like this code to be really robust | 18:23 |
| corvus | avass: maybe if we get a second config error after the reset, delete. so we keep the special case handling for when the cleanup is easy, and then delete after that. | 18:23 |
| corvus | avass: i'm open to the "commit a fix" method, but i'd like to convince myself we'd never see that commit again, and i'm uncomfortable with the fact that we would leave that method with the fixup commit as HEAD. | 18:24 |
| avass | corvus: we could also commit a fix, reset and delete the fix-commit | 18:26 |
| corvus | reset to what? | 18:26 |
| avass | I mean, fetch | 18:26 |
| avass | but then we'd need to keep track of a commit that should be deleted later | 18:26 |
| corvus | commit fix, fetch, then reset to the known broken commit | 18:27 |
| *** harrymichal_ has joined #zuul | 18:27 | |
| avass | doesn't the 'reset' method technically checkout a specific commit? might have gotten that wrong | 18:27 |
| avass | probably got that confused earlier | 18:32 |
| avass | corvus: we could _technically_ do a check here https://opendev.org/zuul/zuul/src/branch/master/zuul/merger/merger.py#L343 to make sure we reset to a ref the executor can work from. | 18:34 |
| avass | but I don't like it | 18:34 |
| corvus | avass: honestly, i'm not sure. there are a lot of code paths in there; it's always been complex, and now there's approximately 2x the options since the executors and mergers now behave differently. i guess what i'm saying is that deleting the repo is something i'm comfortable with as it's not a significant change. maybe the fixup commit idea is better (as it would handle this and the existing special | 18:36 |
| corvus | case), but i think we need to understand the full call stack for all of the different ways it's used. that's worthwhile work, but it's not straightforward. | 18:36 |
| *** hamalq has joined #zuul | 18:36 | |
| corvus | to be clear, i'd love to page all of that stuff back in and improve it; i'm just trying to balance that with the idea that you wanted a quick fix :) | 18:37 |
| avass | tbh the best fix here would be to get git to just not read the .gitmodules file | 18:37 |
| avass | corvus: yeah :) | 18:37 |
| *** jfoufas1 has quit IRC | 18:38 | |
| corvus | avass: and i dunno, maybe it's okay to come out of the _git_fetch method on a random commit, as long as it's valid | 18:39 |
| corvus | avass: if so, it's probably pretty straightforward to do the fixup commit; we just need to make sure that's the case | 18:39 |
| corvus | (because it's certainly a behavior change) | 18:39 |
| avass | corvus: what would happen that if instead of deleting the repo it's cloned locally, deleted and replaced? | 18:40 |
| corvus | avass: it'll clone with HEAD as a bad commit | 18:40 |
| avass | oh we have no heads in those repos either | 18:44 |
| corvus | avass: if you really don't want to delete the repo, then i think pursuing the fixup approach is worthwhile, just make sure that every code path that calls fetch does something that will get the repo to a known state without the fixup commit, since we may be changing an assumption about the side effects of that method. | 18:45 |
| avass | yeah I'm just concerned about someone commiting a broken .gitmodules file in a big repo, trying to recheck that multiple times, breaks the same repo on multiple executors so it gets stuck cloning that repo | 18:47 |
| avass | wHowever we've not seen this happen until now so it might just be good enough | 18:50 |
| corvus | that's a fair concern. it may be worth the time to do the fixup approach. | 18:52 |
| *** gmann_afk is now known as gmann | 18:52 | |
| *** jpena is now known as jpena|off | 18:58 | |
| *** harrymichal_ has quit IRC | 19:03 | |
| corvus | tobiash: it looks like a threading.Event should be mostly outside of the GIL while waiting -- https://github.com/python/cpython/blob/master/Modules/_threadmodule.c#L97 | 19:04 |
| tobiash | so should be ok? | 19:04 |
| tobiash | I'll throw it into my testenv and see how it performs | 19:05 |
| tobiash | if that works, waiting for active instances could be also optimized relatively easy | 19:05 |
| corvus | tobiash: i think so; it's probably still worth a quick test program to see if there's any load with 1k threads waiting | 19:05 |
| tobiash | ++ | 19:05 |
| corvus | but to me, that looks like it's as good as it gets | 19:06 |
| openstackgerrit | Tobias Henkel proposed zuul/nodepool master: WIP: Optimize node deletion https://review.opendev.org/c/zuul/nodepool/+/775438 | 19:13 |
| tobiash | that at least works with a local unit test ^ | 19:13 |
| tobiash | trying now in test env | 19:13 |
| tobiash | if that improves things it probably could be adapted to handle most of wait-for-server as well | 19:14 |
| tobiash | at least the part of waiting for the instance to be active | 19:14 |
| *** jamesmcarthur_ has quit IRC | 19:24 | |
| *** jamesmcarthur has joined #zuul | 19:25 | |
| *** jamesmcarthur has quit IRC | 19:30 | |
| tobiash | corvus: confirmed under mac: 1000 threads waiting for an event cause 0 load | 19:41 |
| tobiash | linux as well | 19:45 |
| *** jamesmcarthur has joined #zuul | 19:51 | |
| *** jamesmcarthur has quit IRC | 19:58 | |
| *** jamesmcarthur has joined #zuul | 20:01 | |
| *** jamesmcarthur has quit IRC | 20:01 | |
| *** jamesmcarthur has joined #zuul | 20:02 | |
| *** jamesmcarthur has quit IRC | 20:03 | |
| *** hashar has joined #zuul | 20:19 | |
| *** jamesmcarthur has joined #zuul | 20:22 | |
| *** jamesmcarthur has quit IRC | 20:24 | |
| *** jamesmcarthur has joined #zuul | 20:24 | |
| *** harrymichal_ has joined #zuul | 20:25 | |
| mnaser | corvus, tobiash: thoughts on https://review.opendev.org/c/zuul/zuul-jobs/+/774650 ? | 20:37 |
| corvus | mnaser: yep, it's on my list for this afternoon now that we've got the server side nailed down | 20:37 |
| mnaser | corvus: awesome, we're pretty excited about driving that and getting that landed so we can have fully multi-tenanted environments for the vexxhost ci :) | 20:38 |
| *** jamesmcarthur has quit IRC | 20:43 | |
| *** jamesmcarthur has joined #zuul | 20:44 | |
| *** hashar has quit IRC | 20:46 | |
| *** jamesmcarthur has quit IRC | 20:49 | |
| tobiash | mnaser, corvus: I've posted a comment and question on that | 20:59 |
| *** jamesmcarthur has joined #zuul | 21:14 | |
| corvus | mnaser: not sure if you saw, but with tobiash's help, mordred, fungi, and i wrote and merged about 5 changes yesterday on the server side to make that hopefully production ready for the general case; so one of the things on my checklist is to make sure the job side matches any changes there. | 21:18 |
| *** jamesmcarthur has quit IRC | 21:18 | |
| *** jamesmcarthur has joined #zuul | 21:18 | |
| *** andy-ladjadj has joined #zuul | 21:29 | |
| *** jamesmcarthur has quit IRC | 21:36 | |
| *** andy-ladjadj has quit IRC | 21:36 | |
| *** jamesmcarthur has joined #zuul | 21:38 | |
| *** jamesmcarthur has quit IRC | 21:43 | |
| *** jamesmcarthur has joined #zuul | 21:44 | |
| openstackgerrit | Adam Richter proposed zuul/zuul master: Linkify BuildOutput in the Task Summary view https://review.opendev.org/c/zuul/zuul/+/775109 | 21:47 |
| *** rlandy has quit IRC | 22:05 | |
| *** sduthil has quit IRC | 22:07 | |
| *** jamesmcarthur has quit IRC | 22:12 | |
| *** jamesmcarthur has joined #zuul | 22:17 | |
| *** jamesmcarthur has quit IRC | 22:33 | |
| fungi | zuul-maint: (and anyone else interested) 775109 is a simple change to make any urls which appear in the build summary content clickable, i was hesitant to approve without a bit of consensus on whether others think doing that is a good idea, but it does seem to be working at least | 23:17 |
| fungi | also i'm not super comfortable with my level of js/jsx knowledge | 23:19 |
| fungi | and i expect if it is something we want, we'll also want to be consistent with it across other tabs like the log viewer and console | 23:22 |
| fungi | but those could presumably be implemented in separate changes | 23:22 |
| corvus | fungi: just like the ansi thing it needs to be performance tested on large data | 23:41 |
| fungi | corvus: this is an excellent point. i suppose with the current implementation only affecting the summary view, getting large data in there may be a challenge? | 23:44 |
| corvus | fungi: yes (though only because we truncate to a small number of lines by default); but if we want to be consistent in other views it would be an issue | 23:45 |
| fungi | yep, i wonder if there's a good way to test that short of implementing it for the other tabs | 23:46 |
| tristanC | it seems like react comes with a profiler, it should be possible to measure the render performance in a test | 23:49 |
| corvus | well, i'd start by just adding it to the log veiewer, and loading up a 10mb file. if it doesn't bomb, then do something more sophisticated. i expect it to bomb. | 23:51 |
| corvus | so i would not put a lot of effort into it before doing that smoke test. | 23:51 |
| *** hamalq has quit IRC | 23:51 | |
| corvus | but i dunno -- we have the severity regexes in there, maybe it'd be ok | 23:52 |
| openstackgerrit | James E. Blair proposed zuul/zuul master: Mandatory Zookeeper connection for ZuulWeb in tests https://review.opendev.org/c/zuul/zuul/+/775459 | 23:57 |
| openstackgerrit | James E. Blair proposed zuul/zuul master: Connect executor to Zookeeper https://review.opendev.org/c/zuul/zuul/+/775460 | 23:57 |
| openstackgerrit | James E. Blair proposed zuul/zuul master: Connect merger to Zookeeper https://review.opendev.org/c/zuul/zuul/+/775461 | 23:57 |
| openstackgerrit | James E. Blair proposed zuul/zuul master: Update component doc re ZooKeeper https://review.opendev.org/c/zuul/zuul/+/775462 | 23:57 |
| corvus | that's an alternative stack where i *think* i've sorted out all the conflicts/issues to just get that merged; need to see the test results from each of those | 23:58 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!