| ianw | is there any way for, say, https://zuul.opendev.org/t/openstack/job/puppet-openstack-integration-5-scenario003-tempest-debian-stable to tell where the job was defined? | 00:25 |
|---|---|---|
| corvus | ianw: check the inheritance path in the inventory.yaml file | 00:59 |
| ianw | yeah, this is an odd case where the job definitions were accidentally left in on a branch -> https://review.opendev.org/c/openstack/puppet-openstack-integration/+/804310 | 01:00 |
| *** rpittau|afk is now known as rpittau | 06:22 | |
| *** dpawlik6 is now known as dpawlik | 07:07 | |
| opendevreview | Benjamin Schanzel proposed zuul/zuul master: Add tenant name on NodeRequests for Nodepool https://review.opendev.org/c/zuul/zuul/+/788680 | 07:32 |
| *** holser is now known as holser_ | 07:32 | |
| *** jpena|off is now known as jpena | 07:33 | |
| opendevreview | Dong Zhang proposed zuul/zuul master: Disable aliases in inventory.yaml for better readibility https://review.opendev.org/c/zuul/zuul/+/802674 | 07:42 |
| *** sshnaidm|afk is now known as sshnaidm | 08:55 | |
| opendevreview | Benjamin Schanzel proposed zuul/nodepool master: Add Tenant-Scoped Resource Quota https://review.opendev.org/c/zuul/nodepool/+/800765 | 11:09 |
| *** jcapitao is now known as jcapitao_lunch | 11:10 | |
| *** dviroel|ruck|out is now known as dviroel|ruck | 11:24 | |
| *** jpena is now known as jpena|lunch | 11:33 | |
| *** jcapitao_lunch is now known as jcapitao | 11:56 | |
| *** jpena|lunch is now known as jpena | 12:24 | |
| *** jpena is now known as jpena|off | 12:33 | |
| *** ysandeep|PTO is now known as ysandeep | 13:26 | |
| *** holser is now known as holser_ | 14:11 | |
| opendevreview | James E. Blair proposed zuul/zuul master: Add delete-state command to delete everything from ZK https://review.opendev.org/c/zuul/zuul/+/804304 | 14:16 |
| *** dmellado_ is now known as dmellado | 14:24 | |
| *** jpena|off is now known as jpena | 14:43 | |
| *** rpittau is now known as rpittau|afk | 15:31 | |
| *** jpena is now known as jpena|off | 15:34 | |
| pabelanger[m] | I'm thinking about creating a new 'manual enqueue' pipeline in zuul. Where the job only triggers via zuul CLI enqueue command or other none git event. It would run much like periodic timer pipelines do today. Curious if anyone else is using a pipeline like that? | 15:40 |
| fungi | in opendev we have "manually triggered" pipelines which only enqueue changes where someone leaves a particular review comment, but no we don't have anything which only gets items enqueued via rpc/api | 15:42 |
| fungi | we're very much about avoiding "manual" anything though, so unlikely to have a use case for it | 15:43 |
| pabelanger[m] | my first thought is create a new timer trigger pipeline, but only triggers in the year 2050 :) | 15:43 |
| pabelanger[m] | then we can still use enqueue command for it | 15:43 |
| fungi | yeah, that's what i expected would be the simplest solution, but seems like longer term a "null" trigger might be easy enough to add | 15:43 |
| pabelanger[m] | yah, in this case we don't have a direct connection to the downstream system to 'trigger' properly via git | 15:44 |
| pabelanger[m] | because of firewalls | 15:44 |
| pabelanger[m] | but would like a way to periodic run something, on our nodepool infrastructure | 15:44 |
| pabelanger[m] | otherwise, we have to duplicate it all | 15:44 |
| pabelanger[m] | long term, we'll move everything back behind the firewall and setup proper integration, but looking to do a minimal POC first to show the jobs working | 15:45 |
| Clark[m] | If your zuul can clone the repo wouldnt the normal git driver work then you can trigger on ref updates | 15:54 |
| tristanC | pabelanger[m]: you mean share a single nodepool with two zuul? | 15:54 |
| MaheshBarai[m] | hello... is this room active for zuul technical discussion | 16:00 |
| fungi | MaheshBarai[m]: yes, absolutely | 16:01 |
| MaheshBarai[m] | Thanks fungi | 16:02 |
| pabelanger[m] | tristanC: more nodepool to allow for triggers other then zuul | 16:07 |
| pabelanger[m] | basically, we have a complicated image requirements for network appliances, I really don't want to duplicate that | 16:08 |
| *** marios is now known as marios|out | 16:08 | |
| pabelanger[m] | so for now, we can write a zuul jobs that only runs an something outside of git enqueing the change into the pipeline | 16:08 |
| pabelanger[m] | for some manual testing | 16:08 |
| clarkb | pabelanger[m]: but how does the content of the change end up in the node in your manual enqueue scneario? | 16:22 |
| clarkb | is that also completely manual and you just set an ssh key or similar credentials and let $random thing take over? | 16:26 |
| pabelanger[m] | clarkb: it is all self contained in a container | 16:54 |
| pabelanger[m] | that we pull from a registry | 16:54 |
| clarkb | pabelanger[m]: I would probably do a job on a repo that does that then. Then you can modify the file that looks for the container image or whatever | 16:55 |
| clarkb | pabelanger[m]: opendev does similar with the docker images we consume from upstreams | 16:55 |
| clarkb | where we can run and test them with an update to system-config but we don't directly trigger on updates to the image or code | 16:55 |
| pabelanger[m] | right, that is a way too. We mostly don't way github users creating a PR to trigger it right now so it would be a different source | 16:56 |
| pabelanger[m] | why I was thinking of manually enqueue to start | 16:56 |
| clarkb | on openstack-discuss there is an email about sqlalchemy's pending 2.0 release which is expected to cause problems | 17:26 |
| clarkb | "virtually anyone that uses sqlalchemy will need to make changes" to paraphrase | 17:27 |
| fungi | yeah, i wondered what the impact might be for zuul's testing | 17:28 |
| clarkb | and for zuul itself | 17:28 |
| fungi | do we still test with sqla at all, or only with service-based rdbms | 17:28 |
| clarkb | sqlalchemy is used in testing | 17:29 |
| clarkb | There is apparently a way to turn on deprecation warnings to point out things that need updating. Also we don't use slqalchmeny migrate so are fine on that end | 17:29 |
| clarkb | https://docs.sqlalchemy.org/en/14/changelog/migration_20.html | 17:31 |
| corvus | fungi: you may be thinking of sqlite | 17:31 |
| fungi | er, yes sqlite, sorry | 17:32 |
| fungi | sqlalchemy is the topic | 17:32 |
| fungi | and zuul definitely uses that | 17:32 |
| fungi | for some reason when i read stephenfin's e-mail i had sqlite in my head the entire time | 17:32 |
| clarkb | I can get a change up that tries to run on the warnings | 17:33 |
| pabelanger[m] | do we have any examples of encrypting binary data (eg: zipfile) as a zuul secret? | 17:33 |
| pabelanger[m] | someone asked me downstream about it, and figured it would work | 17:33 |
| fungi | pabelanger[m]: it's designed to work, yes. the data is treated as raw binary | 17:33 |
| pabelanger[m] | cool | 17:34 |
| corvus | pabelanger: afs tokens are an example | 17:34 |
| pabelanger[m] | great | 17:34 |
| fungi | at one point i used it to encrypt gnupg keyrings as well | 17:34 |
| pabelanger[m] | I forgot about afs tokens | 17:34 |
| clarkb | hrm does stestr not expose python flags? that makes this sort of testing much more difficult when you need to set env vars and python -w always::DeprecationWarning | 17:37 |
| clarkb | fungi: ^ I seem to recall you do python testing with warnings as errors. Do you use stestr with that? | 17:38 |
| fungi | i set testenv.setenv in tox.ini | 17:41 |
| fungi | adding PYTHONWARNINGS = whatever | 17:41 |
| fungi | there is a fairly extensive language for the PYTHONWARNINGS envvar to be able to express what you do or don't want treated as errors | 17:42 |
| clarkb | ya I think that is what always::DeprecationWarning does | 17:42 |
| clarkb | or it exposes that warning always but not as an error | 17:42 |
| clarkb | ya ok I can change that toe error::DeprecationWarning then it will error | 17:43 |
| *** holser_ is now known as holser | 17:44 | |
| fungi | yes, error::DeprecationWarning will cause all deprecation warnings to be raised as exceptions | 17:45 |
| fungi | for one project i do something like this: | 17:46 |
| fungi | PYTHONWARNINGS = error, ignore::FutureWarning:Cython.Compiler.Main, ignore::DeprecationWarning:setuptools.config, ignore::DeprecationWarning:distutils.command.install, ignore::ImportWarning:importlib._bootstrap, ignore::DeprecationWarning:pip._vendor.urllib3.connection, ignore::DeprecationWarning:pip._vendor.urllib3.util.ssl_, ignore:The "license_file" option is deprecated. Use "license_files" | 17:46 |
| fungi | instead.:DeprecationWarning:wheel.bdist_wheel, ignore:The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives:DeprecationWarning, ignore:Creating a LegacyVersion has been deprecated and will be removed in the next major release:DeprecationWarning | 17:46 |
| fungi | sorry, should have used a paste service | 17:46 |
| fungi | that's all one line, btw | 17:46 |
| clarkb | thanks | 17:46 |
| clarkb | I'm making all DepreactionWarnings an error to start and will see what breaks | 17:46 |
| clarkb | then once I've got a config that makes sense I can psuh that up | 17:47 |
| fungi | i note that basically all the ignores i have in there are for DeprecationWarning (one lonesome ImportWarning) | 17:48 |
| clarkb | oh I guess the issue is that this is likely to catching things outside of sqlalchemy | 17:49 |
| fungi | the newer the python you run it on though, the more you're going to find fundamental bits of the packaging ecosystem, or your dependencies, are using deprecations | 17:49 |
| clarkb | so I need to scope it to sqlalchemy better | 17:49 |
| clarkb | yup immediately hit a deprecation warning in pip trying to install deps. Need to scope this better | 17:50 |
| fungi | and like i said, the python interpreter version you're running on will influence what comes up too | 17:50 |
| fungi | not just because of things deprecated in stdlib, but also because of vendored libs in things like ensurepip | 17:51 |
| fungi | or in venv's seed modules | 17:51 |
| clarkb | I'm trying error::DeprecationWarning:sqlalchemy | 17:51 |
| fungi | yeah, that may help | 17:52 |
| fungi | though it might need sqlalchemy.* there | 17:52 |
| fungi | if you don't hit anything without the .* try adding | 17:52 |
| clarkb | will do | 17:53 |
| clarkb | I also worry that the env vars aren't making it to the child processes of stestr. looking /proc for that info now | 17:55 |
| *** sshnaidm is now known as sshnaidm|afk | 17:55 | |
| clarkb | nevermind seems they get passed through properly | 17:56 |
| fungi | it would be odd if they weren't. i mean, they make it through to cython compiler subshells in my projects | 17:57 |
| fungi | (that's for pyyaml, btw) | 17:57 |
| clarkb | ya I was worried that stestr would be filtering them | 17:58 |
| clarkb | but it seems to use multiprocessing and that handles it implicitly | 17:59 |
| clarkb | if even seems to rewrite the PYTHONWARNINGS var to -w on the python args list | 17:59 |
| fungi | also some of the complexity of my example above is from testing with python 3.10 | 17:59 |
| clarkb | and so far everything is succeeding which makes me suspect that .* is necessary | 18:00 |
| fungi | unsurprisingly, a lot of released tooling hasn't removed stuff which 3.10 deprecates, and also nobody publishes wheels for 3.10 so i get to see any which arise from exercising build from sdist of my deps | 18:01 |
| fungi | but yeah, the module matching is very explicit from what i've seen (also a bit fiddly) | 18:02 |
| fungi | part of why i went with the approach of erroring on everything and then finding ways to filter out the things i can't fix | 18:03 |
| *** holser is now known as holser_ | 18:04 | |
| fungi | otherwise i'm afraid it will silently skip things i want it to complain about | 18:04 |
| clarkb | I expect that error on any sqlalchemy deprecation warnings is sufficient based on the doc I linked above | 18:05 |
| fungi | yeah, maybe try introducing something you know should be deprecated and see if it gets caught? | 18:05 |
| fungi | i mean, it's possible zuul will work as-is with sqlalchemy v2, but it's more likely that there's something subtly wrong in checking | 18:06 |
| clarkb | good point | 18:06 |
| clarkb | error:::mymodule[.*] that actually seems to be the format? | 18:07 |
| clarkb | I need the brackets I guess | 18:07 |
| fungi | oh, i missed the brackets, maybe that's been part of my problem | 18:08 |
| fungi | i thought the [] were indicating "optional" | 18:08 |
| fungi | like in a manpage | 18:08 |
| clarkb | fungi: https://docs.python.org/3/library/warnings.html#describing-warning-filters | 18:08 |
| clarkb | it isn't super clear | 18:09 |
| fungi | yeah | 18:09 |
| clarkb | btu it does say in module and any submodules | 18:09 |
| clarkb | but even that doesn't seem to be working. Or we're fine and have no warnings | 18:15 |
| clarkb | ya switching to always and forcing a failure in the mysql test_migration test gives me a bunch of warnings | 18:18 |
| fungi | so good news! | 18:20 |
| fungi | zuul apparently designed for it without even realizing | 18:20 |
| clarkb | well we have warnings but I can't make them error for some reason | 18:21 |
| opendevreview | James E. Blair proposed zuul/zuul master: Use branchesForRepoState in all cases https://review.opendev.org/c/zuul/zuul/+/804178 | 18:21 |
| clarkb | fungi: wow it is like the module matching just doesn't work at all | 18:30 |
| fungi | ahh, yeah that was some of my takeaway. i'm able to get it to match very specific modules, but have been unable to figure out the wildcarding it supposedly supports | 18:31 |
| clarkb | fungi: are you matching the module of the warning class or the module of the location the warning is raise? | 18:31 |
| fungi | "yes" ;) | 18:32 |
| fungi | i think my intent was to match the module where it's raised, but that didn't always work and sometimes i had to go back one or more steps in the stacktrace | 18:32 |
| fungi | mind you, i've been taking a subtractive approach rather than an additive one, so no clue if that changes the equation either | 18:33 |
| clarkb | in my case I want to match every instance of a specific type of warning | 18:33 |
| clarkb | but expressing that doesn't seem to be possible? | 18:33 |
| clarkb | also I don't seem to get a traceback just a string? | 18:34 |
| fungi | is stestr stuffing the traceback into the subunit stream? | 18:35 |
| fungi | that's where i'd expect to find it at least, so presumably where you're looking | 18:36 |
| fungi | therefore the answer is presumably no | 18:36 |
| clarkb | ya I'ev forced a failure in the test so that we capture the logging | 18:37 |
| clarkb | and that is what I seem to get out when always::DeprecationWarning is used | 18:37 |
| fungi | tried error::DeprecationWarning instead? | 18:37 |
| clarkb | ya that just breaks beacuse of other errors. Ineed to filter to sqlalchemy. However, I think I may be making progress it filters where the code triggers the warning based on some testing | 18:38 |
| fungi | right, and yeah "breaking" is the only way i know to get it to provide a traceback, if that makes sense | 18:39 |
| fungi | (only way i know via the warnings feature anyway) | 18:39 |
| clarkb | I see | 18:40 |
| clarkb | also now that I was able to make it work specifying a specific path I am trying to make the globbing work one level up from that without an luck at all | 18:40 |
| fungi | which of course turns it into a game of whack-a-mole since you can only see the first one it hits | 18:40 |
| clarkb | I've tried .* [.*] * etc | 18:40 |
| clarkb | I think the docs must just be wrong | 18:41 |
| fungi | i've almost reached the point of digging into the python source code to see what it actually expects for wildcarding | 18:41 |
| fungi | i agree it's frustrating, and the envvar has plenty of other shortcomings too (like lack of escaping, so no way to match an exception string which contains a comma because that's the field separator for its language) | 18:42 |
| fungi | apparently the cli option isn't much better | 18:43 |
| fungi | if you diddle the global for it at runtime you get much more flexibility, but that's the hardest to do as a sort of test wrapper | 18:43 |
| clarkb | PYTHONWARNINGS=default::DeprecationWarning:zuul.driver.sql.sqlconnection works but PYTHONWARNINGS=default::DeprecationWarning:zuul.driver.sql.sqlconnectio. does not and the docs say it is a regex | 18:43 |
| clarkb | That is the most trivial regex I can think of which makes me think they aren't actually using a regex filter | 18:44 |
| fungi | yes, if you look at the python/cpython issues on github you'll find a fair number about the warnings module | 18:44 |
| clarkb | module = re.escape(module) + r'\Z' | 18:46 |
| clarkb | I think they may be escaping all the . and * | 18:46 |
| fungi | hah | 18:46 |
| clarkb | https://github.com/python/cpython/blob/3.9/Lib/warnings.py#L227-L228 | 18:47 |
| fungi | so far from accepting a regex, it's treating every regex as a literal | 18:47 |
| clarkb | it is a regex with all the useful bits escaped out | 18:47 |
| fungi | or rather, turning everything which might make it into an actual regex into just a string | 18:47 |
| fungi | and main (future 3.10) is no better | 18:48 |
| fungi | looks like that escape for the module string was introduced by the fix for https://bugs.python.org/issue39056 in 3.9 | 18:52 |
| fungi | does it work for you under 3.8? | 18:52 |
| fungi | first appeared in v3.9.0a3 but i guess it may have also been backported | 18:52 |
| fungi | ahh, yep helpfully backported to 3.8 and 3.7 | 18:53 |
| clarkb | ya I'm on 3.8 | 18:53 |
| clarkb | fungi: I'm not completelysure that the code path flows through there for the env var settings but it certainly seems like they do given the function name | 18:54 |
| clarkb | I wonder if we should file a bug | 18:54 |
| fungi | i compile my own interpreters from source, so easy enough for me to test | 18:59 |
| fungi | i'll revert that line from "module = re.escape(module) + r'\Z'" to "module = module + '$'" and see what happens | 19:01 |
| fungi | basically undoing just that part of https://github.com/python/cpython/commit/41ec17e | 19:01 |
| clarkb | that sould confirm it | 19:06 |
| fungi | i'll know in a little while | 19:07 |
| clarkb | I need to eat lunch but I've made progress fixing deprecation warnings that test_migration trips over. I've been focusing on the mysql side though and need to get postgres running next. But I think this chagne is actually pretty minimal since it seems that it is largely the test tooling that hits problems and not the sql driver in zuul | 19:12 |
| clarkb | That said, transaction semantics change so would be good to review for that being wrong too | 19:12 |
| fungi | i found https://bugs.python.org/issue34624 and https://github.com/python/cpython/pull/9358 mentioned therein | 19:16 |
| fungi | module = r'\A(' + module + r')\Z' | 19:16 |
| fungi | which seems to confirm our observations | 19:16 |
| fungi | in "awaiting core review" since 2018 | 19:17 |
| fungi | (and people complain about how long it takes to get things reviewed in our projects!) | 19:18 |
| clarkb | maybe we should push a change to update the docs | 19:19 |
| clarkb | then at least people won't be so confused | 19:19 |
| fungi | i found one of those too | 19:20 |
| corvus | clarkb: thanks! any time you want to push up a wip change and get another hand, let me know. otherwise i'll stay out of your way for now. :) | 19:20 |
| corvus | fungi: thank you too :) | 19:20 |
| clarkb | corvus: will do shouldn't be long after lunch | 19:20 |
| clarkb | fungi: hahahahaha that just made my day | 19:20 |
| fungi | shouldn't be all that surprising, python has the infinite monkeys thing going on... "Pull requests: 1.4k" | 19:33 |
| fungi | i didn't even know github started abbreviating counts | 19:33 |
| fungi | but anyway, https://github.com/python/cpython/commit/62ec638 looks like will be in 3.10 when it releases and tries (albeit not all that well) to indicate that you need to manipulate warnings.filterwarnings() if you want to use a regex | 19:40 |
| fungi | vstinner also started a python-dev ml thread back in april about it and related topics: https://mail.python.org/archives/list/python-dev@python.org/thread/JMKLA4RUJLTORBPPTM4BWL76VNNMKYVG/ | 19:43 |
| opendevreview | Clark Boylan proposed zuul/zuul master: Prepare for SQLAlchemy 2.0 https://review.opendev.org/c/zuul/zuul/+/804456 | 20:00 |
| clarkb | corvus: ^ I don't know that that needs to be WIP. thest db migration tests pass locally for me but I haven't run a full suite | 20:00 |
| clarkb | corvus: I confirmed that setting future=True on the orm objects seems to also raise errors if we do old style stuff so that should catch a lot of stuff | 20:01 |
| fungi | that's probably a safer and more manageable approach anyway | 20:02 |
| corvus | clarkb: you say sa2.0 will not support executing strings, but you change to using execdriversql -- is execdriversql considered "not sqlalchemy" (ie, just a pass through?) | 20:04 |
| clarkb | corvus: I wasn't super clear you can't use execute('sql here') | 20:05 |
| clarkb | you can use execute(sqlalchemy.text('sql here')) or exec_driver_sql | 20:05 |
| corvus | gotcha, thx | 20:05 |
| clarkb | I suspect that if you are doing production work with it that text() is probably best and does safety escaping | 20:05 |
| clarkb | but for what the tests are doing it was simple to use exec_driver_sql | 20:05 |
| clarkb | corvus: https://docs.sqlalchemy.org/en/14/core/connections.html#sqlalchemy.engine.Connection.exec_driver_sql there is a "here be dragons" block there and seems that exec_driver_sql doesn't trigger certain events? For testing I think that is fine | 21:05 |
| clarkb | but if you'd prefer execute(text('sql here')) I can rewrite it | 21:05 |
| corvus | clarkb: those don't seem important for testing | 21:06 |
| dmsimard | lol, I like that there is an actual "here be dragons" block | 21:08 |
| corvus | yeah, almost makes you actually want to read 'em | 21:09 |
| opendevreview | James E. Blair proposed zuul/zuul-operator master: Fix wait for scheduler to settle in tests https://review.opendev.org/c/zuul/zuul-operator/+/804462 | 21:11 |
| opendevreview | James E. Blair proposed zuul/zuul master: Move sigterm_method to zuul.conf https://review.opendev.org/c/zuul/zuul/+/804464 | 21:23 |
| corvus | fungi, clarkb, tristanC, tobiash: ^ I was about to approve https://review.opendev.org/800284 (since i made the 4.8.0 release) and suddenly had the thought that it felt inconsistent, and I couldn't really think of a good reason to use an env var instead of zuul.conf for that; can you take a look at the followup in https://review.opendev.org/804464 and let me know if you agree? | 21:25 |
| clarkb | thats a good point. The env var would've been read fresh every time so if you could somehow hack it via /proc then you could chnge it while it was running? that said I'm not sure we would want peopel to rely on that | 21:27 |
| corvus | i think we just ended up at env var because of the way the idea started; env vars are sometimes easier to deal with in k8s, but the executor requires a zuul.conf anyway, so it's no big deal. | 21:27 |
| clarkb | the sqlalchemy 2.0 change passed python 3.8 unittesting but timed out on the 3.6 unittesting. I have rechecked it | 21:33 |
| corvus | clarkb: so you're saying there's a chance? :) | 21:37 |
| clarkb | yes | 21:37 |
| clarkb | I think the core bits in sqlconnection.py were already largely new sqlalchemy clean because they use the context manager stuff | 21:38 |
| clarkb | corvus: it looks like zuul's release notes didn't update for 4.8.0? | 21:42 |
| clarkb | https://zuul-ci.org/docs/zuul/reference/releasenotes.html that page specifically | 21:43 |
| corvus | clarkb: need to merge a change to master for that | 21:43 |
| clarkb | aha | 21:43 |
| clarkb | we only run the publish when we land changes not on tags. got it | 21:43 |
| corvus | clarkb: https://zuul-ci.org/docs/zuul/4.8.0/reference/releasenotes.html exists though, and that's what the announcement links to | 21:43 |
| clarkb | https://review.opendev.org/c/zuul/zuul/+/800121/ should do it then as it is in the gate | 21:43 |
| fungi | i'm perfectly fine with putting the toggle in the config, i wondered about it but assumed envvars were a "this is how you container" choice | 21:49 |
| fungi | corvus: related to the release, we said after zuul released with the gear pin, we could revisit tagging new gear. are we to that point yet, or should there be some additional buffer time? to make sure people on releases have upgraded? | 21:50 |
| corvus | fungi: i think it's fine; i think only ppl doing new installs of old releases might be affected (and we don't actually think it's a problem anyway) | 21:51 |
| *** dviroel|ruck is now known as dviroel|ruck|out | 21:51 | |
| fungi | yeah, i don't expect any gear-induced regressions, this was more belt-and-braces | 21:53 |
| fungi | i'll stick the gear release on my reminders for next week in that case | 21:53 |
| fungi | my dance card is pretty full up to the weekend | 21:53 |
| clarkb | in the time since about lunch the sky outside has turned brown and the air is less good for you say the internet sensor aggregation map | 21:54 |
| clarkb | kind of amazing how quickly that happens | 21:54 |
| fungi | yeah, the government is trying to convince me that the sun wants to kill me today, and that i should hide indoors. pfft | 22:00 |
| opendevreview | Merged zuul/zuul master: Remove some unused methods in sql reporter https://review.opendev.org/c/zuul/zuul/+/800121 | 22:27 |
| ianw | a bit of a hail-mary, but does anyone have any insight into "A state mutation was detected inside a dispatch, in the path: `job.jobs`. Take a look at the reducer(s) handling the action {"type":"JOB_FETCH_SUCCESS" | 23:06 |
| ianw | i just wanted to update the job page which i spent quite a lot of time looking at yesterday finding debian-stable jobs | 23:07 |
| clarkb | tristanC: ^ is probably the best person to ask? | 23:08 |
| clarkb | woot https://review.opendev.org/c/zuul/zuul/+/804456 got a +1 from zuul. Maybe the sqlalchemy 2.0 prep is that simple | 23:08 |
| corvus | ianw: that probably means something in store.js didn't update the state dictionary right (you can't mutate it directly, you have to return a copy; the weird functions in that file do that) | 23:41 |
| corvus | though as someone pointed out on the list recently, the ... operator can actually be used as a simpler version of that | 23:42 |
| ianw | yeah, i'm trying to rewrite it with that now | 23:42 |
| ianw | we seem to use it in some places, and others use $merge (which i think comes form some libray) | 23:43 |
| corvus | yeah $merge is the "weird function" i was thinking of :) | 23:43 |
| fungi | clarkb: zzzeek just followed up to the openstack-discuss thread with a link to the sqla v2 migration docs too | 23:58 |
| fungi | not sure if you found those in your research | 23:59 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!