| mnaser | does the executor do anything funky that can result in a big increase in disk space usage? | 00:15 |
|---|---|---|
| mnaser | (reported in df -h)( | 00:15 |
| mnaser | it seems like when jobs are running, the disk usage is increasing significantly on this node to the point of hitting 85%+ which makes k8s decide to evacuate it | 00:16 |
| clarkb | mnaser: yes each job has the repos oncifugred in it. if that is a shared fs it will hardlink though. also log collection happens on the executor | 00:18 |
| mnaser | clarkb: yeah in this case these are very lightweight jobs | 00:19 |
| clarkb | how big are tge repos? | 00:19 |
| clarkb | you might not be hardlinking | 00:19 |
| mnaser | du says 18 megabytes | 00:20 |
| *** rfolco|bbl has joined #zuul | 00:21 | |
| mnaser | oh | 00:21 |
| mnaser | i think this might be totally unrelated | 00:21 |
| mnaser | i think nginx is buffering uploads on disk instead of sending straight through so its filling up the disk | 00:21 |
| mnaser | gah | 00:21 |
| *** jamesmcarthur has joined #zuul | 00:22 | |
| *** mattw4 has quit IRC | 00:23 | |
| *** jamesmcarthur has quit IRC | 00:27 | |
| *** jamesmcarthur has joined #zuul | 00:32 | |
| *** jamesmcarthur has quit IRC | 00:35 | |
| *** jamesmcarthur has joined #zuul | 00:50 | |
| *** jamesmcarthur has quit IRC | 00:54 | |
| *** sgw has quit IRC | 01:02 | |
| *** jamesmcarthur has joined #zuul | 01:22 | |
| *** jamesmcarthur has quit IRC | 01:27 | |
| *** jamesmcarthur has joined #zuul | 01:28 | |
| *** jamesmcarthur has quit IRC | 01:30 | |
| *** Goneri has quit IRC | 01:36 | |
| *** Goneri has joined #zuul | 01:38 | |
| *** avass has quit IRC | 01:39 | |
| *** rlandy has quit IRC | 01:51 | |
| *** sgw has joined #zuul | 02:28 | |
| *** jamesmcarthur has joined #zuul | 02:33 | |
| *** jamesmcarthur has quit IRC | 02:38 | |
| *** bhavikdbavishi has joined #zuul | 03:12 | |
| *** bhavikdbavishi1 has joined #zuul | 03:15 | |
| *** jamesmcarthur has joined #zuul | 03:16 | |
| *** bhavikdbavishi has quit IRC | 03:16 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 03:16 | |
| *** jamesmcarthur has quit IRC | 03:18 | |
| *** rfolco|bbl has quit IRC | 03:31 | |
| *** rfolco|bbl has joined #zuul | 03:32 | |
| *** rfolco|bbl has quit IRC | 03:42 | |
| *** decimuscorvinus has quit IRC | 05:05 | |
| *** decimuscorvinus has joined #zuul | 05:06 | |
| *** pabelanger has quit IRC | 05:19 | |
| *** pcaruana has joined #zuul | 05:52 | |
| *** jamesmcarthur has joined #zuul | 06:01 | |
| *** jamesmcarthur has quit IRC | 06:06 | |
| *** avass has joined #zuul | 07:07 | |
| *** themroc has joined #zuul | 07:20 | |
| *** saneax has joined #zuul | 07:48 | |
| *** jcapitao has joined #zuul | 07:58 | |
| *** avass has quit IRC | 08:06 | |
| *** tosky has joined #zuul | 08:19 | |
| *** themroc has quit IRC | 08:42 | |
| *** coldtom has joined #zuul | 08:51 | |
| *** jpena|off is now known as jpena | 08:57 | |
| *** yolanda has quit IRC | 09:10 | |
| *** mhu has joined #zuul | 09:27 | |
| mhu | all I want for christmas is this change to be merged :) https://review.opendev.org/#/c/642408/ | 09:27 |
| *** yolanda has joined #zuul | 09:28 | |
| *** hashar has joined #zuul | 10:14 | |
| *** bhavikdbavishi has quit IRC | 10:24 | |
| *** avass has joined #zuul | 11:19 | |
| *** hashar has quit IRC | 11:56 | |
| *** rfolco|bbl has joined #zuul | 12:11 | |
| *** rfolco|bbl is now known as rfolco | 12:12 | |
| *** jcapitao is now known as jcapitao|afk | 12:13 | |
| *** hashar has joined #zuul | 12:37 | |
| *** jpena is now known as jpena|lunch | 12:38 | |
| *** rlandy has joined #zuul | 12:58 | |
| *** jcapitao|afk is now known as jcapitao | 13:01 | |
| *** armstrongs has joined #zuul | 13:24 | |
| *** armstrongs has quit IRC | 13:33 | |
| *** jpena|lunch is now known as jpena | 13:36 | |
| openstackgerrit | Mohammed Naser proposed zuul/zuul master: Fix documentation typo https://review.opendev.org/700178 | 14:18 |
| *** mhu has quit IRC | 14:50 | |
| *** EmilienM is now known as EvilienM | 15:16 | |
| *** pcaruana has quit IRC | 15:25 | |
| *** hashar has quit IRC | 15:55 | |
| *** jcapitao is now known as jcapitao|afk | 16:23 | |
| *** mattw4 has joined #zuul | 16:26 | |
| *** jcapitao|afk is now known as jcapitao | 16:32 | |
| *** Goneri has quit IRC | 16:41 | |
| corvus | https://gerrit-review.googlesource.com/admin/repos/q/filter:zuul | 17:19 |
| corvus | the gerrit admins creates some repos for gerrit's upcoming zuul instance | 17:19 |
| corvus | created | 17:20 |
| clarkb | corvus: and sounds like in the new year there will be gcp resources for hosting things? | 17:21 |
| corvus | i think they're available now | 17:21 |
| corvus | there's one existing project; they're looking into making a second one (so we can have the same control/data plane separation we have in opendev) | 17:22 |
| corvus | but since that's not strictly necessary, i think we can proceed | 17:22 |
| corvus | the only real blocker is a gerrit account | 17:22 |
| corvus | but i think i can create a k8s cluster and start spinning up an idle zuul | 17:23 |
| corvus | now i have to pick a google cloud region | 17:23 |
| SpamapS | Pick brazil! | 17:28 |
| SpamapS | Oo or maybe Singapore | 17:28 |
| corvus | the default is iowa | 17:28 |
| *** jcapitao has quit IRC | 17:29 | |
| clarkb | corvus: I see | 17:35 |
| *** Goneri has joined #zuul | 17:37 | |
| corvus | mnaser: do you have your helm charts published anywhere (even to a temp location?) | 17:41 |
| * SpamapS is down to collaborate on helm charts.. even more than operators | 17:44 | |
| corvus | SpamapS: do you have some? | 17:45 |
| clarkb | corvus: the issue with a gerrit account being google credentials, cla, and privs? | 17:45 |
| clarkb | do they issue system accounts to bypass that google account business? | 17:45 |
| corvus | no, the opendev zuul is a "regular" google account that i made with our root email address, and confirmed using a mint mobile sim :| | 17:46 |
| corvus | so i'd like to personally avoid doing that for the gerrit project's zuul account; if that is what google and/or the maintainers want to do, that's fine, but i do think it should be at least one of the maintainers doing it in that case, not me | 17:47 |
| clarkb | ++ | 17:47 |
| corvus | re helm, i figure if someone has some helm charts, i can probably scale that down real quick to a minimial zuul install. doesn't even need to work all that well, but if that's the first content we put in the zuul/ops repo, it'll be easier to collab going forward. | 17:48 |
| *** jpena is now known as jpena|off | 17:51 | |
| *** jpena|off has quit IRC | 17:52 | |
| clarkb | corvus: gcp publishes cpu platforms available and defaults for their various regions | 17:52 |
| clarkb | central has some of the oldest available. Other regions might be more performant (though I have no real world evidence for that) | 17:53 |
| corvus | clarkb: oh interesting...well i went ahead and created a cluster in central, but it's easy to migrate or destroy/recreate if we want | 17:55 |
| corvus | it looks like i get to bootstrap perms on the repos too. i'm in the "zuul-maintainers" group, which is self-owned and has the "owner" perm, but that's it. the rest is greenfield. | 17:56 |
| mnaser | corvus: i have not yet unfortunately, i need to "de-clutter" them a bit because they have some secrets embedded right now | 17:57 |
| mnaser | so maybe i could get that done by monday? | 17:57 |
| corvus | mnaser: no rush; i'll see if i can learn enough helm to say "create a scheduler pod" | 17:57 |
| mnaser | corvus: if you want to create zuul/zuul-helm or zuul/helm -- i can have something there by monday | 17:58 |
| mnaser | there are a few tight dependencies to some operators we use (i.e. mysql) that might need to be cleaned up | 17:58 |
| corvus | mnaser: good idea, i'll push up a repo creation change soon | 17:58 |
| clarkb | you'll probably want to use https://cloud.google.com/sql/docs/ for that install | 17:59 |
| clarkb | at least I expect that will be the most googly version of the thing | 17:59 |
| mnaser | ya we use presslabs/mysql-operator to run databases | 17:59 |
| mnaser | it's been nice, has backups and stuff built in, can upload to swift | 17:59 |
| corvus | clarkb: oh good point; though i might need to ask for a new service account for that. | 18:00 |
| *** jamesmcarthur has joined #zuul | 18:05 | |
| mnaser | ok, i have a python script that can now entirely go through a charts folder, look at all the requirements, check if the exist in the designated repos, if they do, pass, if they don't, check if they exist in the local charts folder, if they exist and the requested version *matches* the one stored locally, build *the local one*, publish it to the helm registry, and then update the dependencies to point towards the helm | 18:09 |
| mnaser | registry with the locally-built version | 18:09 |
| mnaser | the only bits that aren't done are the actual "build" bits, its mostly a print statement, but the logic is there | 18:09 |
| mnaser | which means we can actually do speculative testing of helm charts with a buildset repo, which is proven to be WAY too complicated but the helm ecosystem has some questionable things wrt versioning | 18:09 |
| mnaser | now i just need to make it actaully build things and then make it an ansible module, then we can have a buildset helm repo that other jobs can use | 18:10 |
| mnaser | and some code to munge the requirements.yaml to point towards that repo *only* for the stuff we built locally | 18:11 |
| corvus | mnaser: do you need a repository to use helm? | 18:13 |
| mnaser | corvus: technically you could run it locally, but for dependencies, you need to point towards a repo (or there is a very 'frowned upon' way of pointing to things via file:///) | 18:13 |
| mnaser | i guess its similar to requirements.txt pointing at things which exist in pypi | 18:14 |
| corvus | mnaser: gotcha | 18:14 |
| mnaser | except its possible for a git repo to have multiple charts, which depend on each other -- which is why it becomes tricky | 18:14 |
| mnaser | if you say: split your work into two commits, one that bumps chart A version, then one that bumps chart B dependency, your chart A bump could effectively break chart B without you knowing | 18:15 |
| corvus | mnaser: i was batting around the idea of having zuul run argo to do the helm apply | 18:15 |
| mnaser | if you try and merge a change that bumps chart A version and dependency of chart B at the same time, helm will complain because it cant find chart A version :< | 18:16 |
| mnaser | corvus: https://fosdem.org/2020/schedule/event/safe_gated_and_integrated_gitops_for_kubernetes/ | 18:16 |
| mnaser | i know someone who's doing it :p | 18:16 |
| corvus | mnaser: \o/ | 18:17 |
| mnaser | and argocd has some cool concept which is 'application of applications' | 18:18 |
| clarkb | mnaser: doesn't that sort of defeat the purpose of having versioning? (not being able to make new versions) | 18:18 |
| mnaser | https://argoproj.github.io/argo-cd/operator-manual/declarative-setup/ | 18:18 |
| mnaser | clarkb: so 'chart-tesing', the helm linters for the big helm/charts repo implies that you must bump version on every single change to a chart | 18:19 |
| *** saneax has quit IRC | 18:20 | |
| mnaser | so assuming i have these 3 charts: keystone 1.0.0, nova 1.0.0, openstack 3.0.0 (which requires keystone 1.0.0 and nova 1.0.0). if i make a change to keystone, i'd bump it to keystone 1.0.1 -- however, i'm deploying openstack 3.0.0 -- so i need to bump openstack dependency to keystone 1.0.1 and then bump openstack version to 3.0.1) | 18:20 |
| *** rfolco is now known as rfolco|dentist | 18:21 | |
| mnaser | i risk releasing a keystone 1.0.1 that is *not* properly integrated with openstack 3.0.0 and i'll only find that out after i bump the requirement/dependency | 18:21 |
| clarkb | and when you create keystone 1.0.1 that breaks the existing openstack 3.0.0 | 18:21 |
| clarkb | I guess the issue here is that 1.0.0 isn't findable by the tooling even though it exists in some form in the git repo history | 18:22 |
| mnaser | no because the 1.0.0 artifact still exists in the repo somewehre | 18:22 |
| clarkb | right, that is how I would expect it to work but you said "helm will complain because it cant find chart A version" | 18:22 |
| mnaser | right -- that is if i tried to bump both at the same time | 18:22 |
| mnaser | "will keystone 1.0.1 work with openstack 3.0.0" is not something that i can answer when testing 1.0.1 | 18:23 |
| clarkb | beacuse you must create a 3.0.1 ? | 18:23 |
| clarkb | fun | 18:23 |
| mnaser | yep, because you must bump version when you make changes in helm (or at least that's what their linter wants) | 18:24 |
| corvus | so either speculative registries, or don't use their linter? | 18:24 |
| mnaser | yeah, that's pretty much where i'm at right now | 18:24 |
| clarkb | do they allow you to specify version dep ranges? | 18:25 |
| clarkb | you could reserve the last set of point versions for speculative testing if so | 18:25 |
| mnaser | hmm, they do, i think they try to enforce semver for the version field | 18:26 |
| mnaser | hmm | 18:26 |
| mnaser | as silly as it sounds, i could also go ahead and update the repo path to be relative file paths when running an 'integration' test | 18:27 |
| mnaser | and not touch it when running the linter | 18:27 |
| mnaser | and just set version to 0.0.0 for all charts | 18:27 |
| mnaser | none of it feels clean really | 18:27 |
| corvus | mnaser: i don't think that's a bad idea; i think similar ideas have come up wrt to rust, go, etc. | 18:28 |
| corvus | (also, not all that different from python siblings) | 18:28 |
| mnaser | oo | 18:30 |
| mnaser | so they use https://github.com/Masterminds/semver to do semver vhrvkd | 18:30 |
| mnaser | checks* | 18:30 |
| mnaser | which seems like it might be happy accepting something like .beta | 18:31 |
| corvus | i guess that's an option as long as it doesn't conflict with an actual '.beta'? | 18:32 |
| corvus | \o/ https://gerrit-review.googlesource.com/c/zuul/ops/+/249133 | 18:32 |
| corvus | paladox: ^ | 18:32 |
| clarkb | semver needs a .speculative | 18:33 |
| clarkb | whcih should only ever show up in a Ci system :) | 18:34 |
| *** jamesmcarthur has quit IRC | 18:34 | |
| corvus | ++ | 18:35 |
| corvus | clarkb: what's the status of the wikipedia page? | 18:35 |
| *** jamesmcarthur has joined #zuul | 18:36 | |
| clarkb | corvus: I trailed off on the etherpad I started after realizing how difficult it is to write encyclopedia articles | 18:36 |
| clarkb | I think what I had was a reasonable enough outline but actually writing that type of material is not easy | 18:36 |
| corvus | clarkb: i think your outline was good, and probably had enough content for a starter article... | 18:37 |
| clarkb | perhaps. https://etherpad.openstack.org/p/zuul-wikipedia is that content | 18:38 |
| clarkb | jimmy isn't here but I can ask him if he wants to update his draft article request with that | 18:38 |
| corvus | clarkb, jamesmcarthur: i think it would be better to work from clarkb's outline rather than starting from the wikimedia one... i think it would be best to go ahead and drop the wikimedia copy, and start fresh with that. i think then the main question is, is that enough to go ahead and request review, or do we want to fill it out more. | 18:38 |
| openstackgerrit | Mohammed Naser proposed zuul/zuul-jobs master: Add basic Helm jobs https://review.opendev.org/700222 | 18:38 |
| clarkb | oh jimmy is here | 18:38 |
| mnaser | ^ so that basic job is working for me for now in terms of running basic linting | 18:39 |
| clarkb | corvus: jamesmcarthur: I know the OSUOSL article got delisted recently as it was deemd not noteworthy enough. The editors seemed to base that on the articles cited. We may want to include news articles about zuul or other external docs as much as possible. However looking at the content I have there again I think it probably is complete enough as is if we add those citations | 18:41 |
| *** jamesmcarthur has quit IRC | 18:41 | |
| corvus | clarkb: that sounds important. i started a todo at the top so we'll remember to do that | 18:42 |
| clarkb | ++ | 18:42 |
| *** tosky has quit IRC | 18:45 | |
| corvus | remote: https://review.opendev.org/700224 Add zuul-helm repo | 18:46 |
| corvus | mnaser, clarkb: ^ | 18:46 |
| clarkb | I went ahead and approved that since it seems likely no one else will be around before monday to do so | 18:47 |
| corvus | sounds reasonable, thx | 18:47 |
| mnaser | ok great, i'll push up small bits | 18:47 |
| clarkb | and I won't be here monday :) | 18:47 |
| mnaser | you can point argocd towards a git repo so we don't have to publish charts | 18:48 |
| mnaser | but for better user experience we should probably publish them somewhere | 18:48 |
| paladox | Corvus :O | 18:52 |
| paladox | Awesome! | 18:52 |
| *** jamesmcarthur has joined #zuul | 18:59 | |
| clarkb | corvus: I put a couple links under the todo lost. The first is definitely a good one I think | 18:59 |
| mnaser | corvus: how do you feel about a reconfigure_on_tenant_config_change option in zuul? | 18:59 |
| mnaser | right now these charts restart the entire world if the tenant config file changes | 19:00 |
| mnaser | i can write a small sidecar, or i can implement this right into zuul.. both work.. | 19:00 |
| clarkb | mnaser: why not trigger the config update within zuul as per usual? | 19:01 |
| clarkb | or maybe that is what you mean | 19:01 |
| corvus | mnaser: did you see the smart reconfig option that just landed? | 19:01 |
| mnaser | clarkb: yeah, i am currently restaring the entire pod on change instead of triggering a config update | 19:01 |
| corvus | mnaser: https://zuul-ci.org/docs/zuul/releasenotes.html#new-features | 19:02 |
| mnaser | corvus: yeah, something still needs to trigger it though afaik | 19:02 |
| mnaser | and with helm, there isn't an easy way of saying "run X on every time value Y changes" -- we can write a job but it can get pretty iffy | 19:02 |
| corvus | mnaser: ah, so like inotify on the file in zuul and run smart-reconfigure when it changes? | 19:02 |
| mnaser | yep | 19:02 |
| corvus | mnaser: i think that is a fine thing to do (with an enable or disable option; i guess it should be disabled by default, at least at first). we could also have an api endpoint for that (if we don't already). those options are not exclusive. :) | 19:03 |
| mnaser | ok cool, i can try and work on something inside zuul for autoreload, because that's a big drawback right now, a full restart of $world everytime the tenant config changes | 19:04 |
| mnaser | btw if anyone wants to pad stats = https://review.opendev.org/#/c/700178/ | 19:05 |
| corvus | gibbidygubbidy. | 19:06 |
| clarkb | mnaser: could you say "always run X" then have X decide if Z action should be taken based on Y state? | 19:07 |
| clarkb | that said having an inotify watch in zuul for its configs is probably fine | 19:07 |
| clarkb | (inotify gets slow when watching many files but zuul's tenant config tends to not be many files) | 19:07 |
| mnaser | clarkb: yeah, that would be a sidecar that watches the configmap and it can do things after, but it would also involve writing code | 19:07 |
| mnaser | matter of "do we want it to live in-tree or not" :p | 19:08 |
| mnaser | well that turned out to be simpler/easier than expected | 19:23 |
| mnaser | i just have to write up the tests | 19:23 |
| *** jamesmcarthur has quit IRC | 19:25 | |
| *** openstackgerrit has quit IRC | 19:27 | |
| *** openstackgerrit has joined #zuul | 19:41 | |
| openstackgerrit | Merged zuul/zuul master: authentication config: add optional max_validity_time, skew https://review.opendev.org/642408 | 19:41 |
| corvus | i hope mhu has a merry christmas ^ :) | 19:41 |
| *** rfolco|dentist has quit IRC | 19:48 | |
| *** rfolco has joined #zuul | 19:49 | |
| openstackgerrit | Mohammed Naser proposed zuul/zuul master: Add auto reconfigure option https://review.opendev.org/700235 | 19:50 |
| mnaser | ^ i need some help in figuring out how/where to test this best | 19:51 |
| * mnaser was quickly overwhelmed inside test_scheduler.py :\ | 19:51 | |
| corvus | it's a bit of a catch-all | 19:53 |
| clarkb | test_live_reconfiguration and the other ~2 tests like it are probably closest | 19:54 |
| mnaser | the zuultestcase seems to setup fixtures in advance but isn't exactly meant for having a config file fixture swept under it | 19:54 |
| clarkb | but it drives that directly via sched.reconfigure | 19:55 |
| mnaser | right but to properly test this, i would have to modify the fixture file and ensure that reconfigure is being called | 19:57 |
| corvus | mnaser: see TestSchedulerSmartReconfiguration | 19:57 |
| corvus | mnaser: it uses newTenantConfig to swap out the tenant config file | 19:57 |
| openstackgerrit | Merged zuul/zuul master: Fix documentation typo https://review.opendev.org/700178 | 19:58 |
| corvus | mnaser: and the "config_file" class attribute can be used to specify a different zuul.ini file (with the auto_reconfigure option set to true | 19:59 |
| mnaser | corvus: hm, swapping out the file would probably still not hit a "modify" event though with inotify, would it | 19:59 |
| mnaser | newTenantConfig seem to write things in a new namedtemporaryfile | 20:00 |
| corvus | mnaser: oh you're write, that method changes the yep that | 20:00 |
| mnaser | i guess the only thing would be create my own fixture file, and edit it during tests, then restore it in a clean up | 20:01 |
| mnaser | i guess the only alternative would be to manually fire an inotify event with a mock | 20:02 |
| mnaser | and make sure i ran config there | 20:02 |
| clarkb | mnaser: testtools has a tmpfile fixture | 20:04 |
| clarkb | I would use that, splat a zuul config into it and use it. | 20:04 |
| clarkb | and you might use a generic config fixture to start, copy the contents of that file to tmpfile, switch config file to the tmpfile, then edit tmpfile | 20:05 |
| corvus | ++ | 20:05 |
| corvus | i think you could probably just copy the first part of the code in newtenantconfig for that | 20:05 |
| corvus | that's step 1, then step 2 is just copy without creating the new tmpfile | 20:06 |
| mnaser | so actually i technically could use newtenantconfig right off the bat | 20:06 |
| mnaser | manipulate the file which is in self.config (which is a temp path) | 20:06 |
| mnaser | and then it will clean up after me | 20:06 |
| corvus | oh yep | 20:07 |
| mnaser | i guess ill just have to test this in gate | 20:27 |
| mnaser | i guess ill just have to test this in gate | 20:27 |
| mnaser | cause it seems to want zookeeper running | 20:27 |
| clarkb | mnaser: ya you need a zk. I run it out of the tarball they publish | 20:27 |
| clarkb | zookeeper/bin/zkServer.sh start|stop | 20:28 |
| openstackgerrit | Mohammed Naser proposed zuul/zuul master: Add auto reconfigure option https://review.opendev.org/700235 | 20:29 |
| mnaser | i have to run but i guess i can throw that up and we'll see how it all pans out.. | 20:29 |
| clarkb | that also works | 20:29 |
| openstackgerrit | Mohammed Naser proposed zuul/zuul master: Add auto reconfigure option https://review.opendev.org/700235 | 20:30 |
| openstackgerrit | Mohammed Naser proposed zuul/zuul master: Add auto reconfigure option https://review.opendev.org/700235 | 20:31 |
| *** armstrongs has joined #zuul | 20:32 | |
| *** armstrongs has quit IRC | 20:41 | |
| *** rlandy has quit IRC | 21:13 | |
| openstackgerrit | James E. Blair proposed zuul/zuul master: WIP: auto reconfig updates https://review.opendev.org/700249 | 21:49 |
| corvus | mnaser: that causes the full option to work | 21:49 |
| corvus | mnaser: smart needs a slightly different method of testing (since it noops on just adding a blank line) | 21:50 |
| corvus | mnaser: but also, i think we need to change it to watch the whole directory and pick out the files it needs -- since an in place atomic rename ("mv old new") doesn't show up as a MODIFY, but rather a MOVED_TO | 21:51 |
| corvus | mnaser: (also, we should actually use MODIFY_CLOSE rather than MODIFY) | 21:51 |
| *** dustinc is now known as dustinc_inandout | 22:17 | |
| corvus | oh, we might be able to watch the file for DELETE_SELF to catch that case | 22:30 |
| *** EvilienM is now known as EmilienM | 22:36 | |
| *** avass has quit IRC | 22:42 | |
| *** jamesmcarthur has joined #zuul | 23:03 | |
| *** mattw4 has quit IRC | 23:10 | |
| openstackgerrit | James E. Blair proposed zuul/zuul master: Add auto reconfigure option https://review.opendev.org/700235 | 23:13 |
| openstackgerrit | James E. Blair proposed zuul/zuul master: Add auto reconfigure option https://review.opendev.org/700235 | 23:17 |
| corvus | mnaser: ^ i think that should be gtg. let me know what you think. | 23:18 |
| *** jamesmcarthur has quit IRC | 23:39 | |
| *** Goneri has quit IRC | 23:40 | |
| *** nhicher has quit IRC | 23:42 | |
| clarkb | corvus: mnaser left some comments on ^ | 23:43 |
| clarkb | I think there is a small race | 23:43 |
| clarkb | chances of hitting it in the real world seem slim particularly since we are talking about IO here, but... | 23:44 |
| clarkb | seems I've learned that if they exist we will eventually hit them | 23:44 |
| corvus | clarkb: well, we need to account for the file path changing | 23:45 |
| *** jamesmcarthur has joined #zuul | 23:45 | |
| clarkb | ah so we need to check the old watch against the new one? | 23:46 |
| clarkb | seems we can still do that in an add first rm after order. We may have to track more state though | 23:46 |
| corvus | clarkb: yep | 23:47 |
| corvus | clarkb: if you want to handle that, you should go ahead and leave a -1 on that, i won't be able to fix that immediately (maybe mnaser can when he returns) | 23:48 |
| clarkb | I can't either. I'm about to pop out to go visit the parents | 23:48 |
| clarkb | and I expect next week to be very slow | 23:49 |
| clarkb | If I have chunk of time to poke at it I'll try | 23:49 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!