| *** frenzyfriday|PTO is now known as frenzyfriday | 05:20 | |
| *** ysandeep|out is now known as ysandeep | 06:01 | |
| *** ysandeep is now known as ysandeep|lunch | 07:20 | |
| *** ykarel is now known as ykarel|LUNCH | 08:16 | |
| *** jpena|off is now known as jpena | 08:38 | |
| *** ysandeep|lunch is now known as ysandeep | 08:47 | |
| *** odyssey4me|away is now known as odyssey4me | 09:00 | |
| *** odyssey4me is now known as odyssey4me|away | 09:00 | |
| *** odyssey4me|away is now known as odyssey4me | 09:02 | |
| *** odyssey4me is now known as odyssey4me|away | 09:25 | |
| *** odyssey4me|away is now known as odyssey4me | 09:25 | |
| *** ykarel|LUNCH is now known as ykarel | 09:36 | |
| *** arxcruz is now known as arxcruz|lunch | 11:04 | |
| *** dviroel is now known as dviroel|ruck | 11:14 | |
| *** arxcruz|lunch is now known as arxcruz | 12:04 | |
| *** odyssey4me is now known as odyssey4me|away | 12:18 | |
| *** odyssey4me|away is now known as odyssey4me | 12:18 | |
| *** odyssey4me is now known as odyssey4me|away | 12:33 | |
| frickler | odyssey4me|away: any chance you could stop this |away nick toggling? | 12:40 |
|---|---|---|
| *** odyssey4me|away is now known as odyssey4me | 12:45 | |
| *** odyssey4me is now known as odyssey4me|away | 12:46 | |
| *** odyssey4me|away is now known as odyssey4me | 12:50 | |
| *** odyssey4me is now known as odyssey4me|away | 12:50 | |
| *** odyssey4me|away is now known as odyssey4me | 13:00 | |
| *** ysandeep is now known as ysandeep|break | 13:20 | |
| odyssey4me | frickler my bad, lemme figure out what's doing that | 13:35 |
| *** ysandeep|break is now known as ysandeep | 13:58 | |
| *** pojadhav is now known as pojadhav|afk | 15:08 | |
| *** marios is now known as marios|call | 15:31 | |
| *** dviroel|ruck is now known as dviroel|ruck|lunch | 15:36 | |
| clarkb | anything important I should be catching up on today/this week now that I am back? | 15:41 |
| clarkb | Looks like one of the backup servers needs pruning | 15:43 |
| fungi | yeah, i haven't gotten to that yet. i was also going to switch our openstackid ssl check entry over to openinfraid now that we don't run anything depending on the former | 15:48 |
| fungi | and there's a dns change requested for the ci-log-processing systems | 15:49 |
| fungi | i'll get to that in a bit | 15:49 |
| fungi | there was some disruption over the weekend where boot attempts in ovh-bhs1 were consistently failing. i haven't looked to see if that's still occurring | 15:49 |
| fungi | and we got some maintenance notices in french about gra1 api availability for 19:00-01:00 tomorrow (starting roughly 27 hours from now) but i'm inclined to just let nodepool complain | 15:50 |
| clarkb | ++ to letting nodepool complain | 15:58 |
| clarkb | sounds like I can mostly catch up via reviews then. I'll try to start there | 15:59 |
| *** marios|call is now known as marios | 16:02 | |
| clarkb | fungi: grafana shows we have in use nodes in ovh bhs1 | 16:03 |
| clarkb | I suspect nodepool is happy there again | 16:04 |
| clarkb | I'd like to make progress on the gitea 1.16 upgrade this week, but have noticed that we're very much into openstack's release period and not disrupting git hosting for a bit may be a good idea. Do others have opinions on that? | 16:04 |
| clarkb | if it was a 1.15.x update I think I'd be fine with it | 16:05 |
| *** ysandeep is now known as ysandeep|out | 16:12 | |
| *** melwitt_ is now known as melwitt | 16:14 | |
| *** dviroel|ruck|lunch is now known as dviroel|ruck | 16:22 | |
| mnasiadka | good afternoon, any DIB core can help merging https://review.opendev.org/c/openstack/diskimage-builder/+/832630 ? | 16:25 |
| clarkb | mnasiadka: thats the first time I've seen : used to assign a default value to a var. I'm a bit confused on how that works since : is supposed to be a noop? | 16:29 |
| clarkb | I guess I'm used to FOO=${FOO:=foo} | 16:30 |
| clarkb | oh I see its the := that is important here | 16:30 |
| clarkb | and then : chumps the substitution | 16:30 |
| mnasiadka | yes, that's what I found out googling over the mighty internet | 16:31 |
| clarkb | mnasiadka: I'm just used to the construct in devstack whcih is the other one. Both seem to work and I understand this one now :) | 16:32 |
| mnasiadka | clarkb: fine by me, it seems you can learn something new every day :) | 16:32 |
| fungi | clarkb: i doubt gitea upgrades will be all that disruptive so long as we're testing its basic functionality. it's gerrit upgrades i'd be more concerned with at this time | 16:33 |
| mnasiadka | ianw: can you create a release after https://review.opendev.org/c/openstack/diskimage-builder/+/832630 merges? | 16:37 |
| clarkb | fungi: ok, I don't think that is a today item, but maybe midweek I'll have time to land that and cross it off my list. For today trying to catch up on reviews and prepare for the meeting tomorrow etc etc | 16:40 |
| fungi | sounds great! | 16:46 |
| *** marios is now known as marios|out | 16:54 | |
| *** jpena is now known as jpena|off | 17:35 | |
| fungi | headed out to an appointment, should be back in an hour-ish | 17:41 |
| *** arxcruz is now known as arxcruz|off | 17:54 | |
| opendevreview | Merged openstack/diskimage-builder master: containerfile: add support for Docker https://review.opendev.org/c/openstack/diskimage-builder/+/832630 | 18:10 |
| opendevreview | Neil Hanlon proposed opendev/base-jobs master: Add rockylinux nodeset https://review.opendev.org/c/opendev/base-jobs/+/828436 | 18:28 |
| opendevreview | Merged openstack/diskimage-builder master: Handle btrfs root subvolume for fedora extract-image https://review.opendev.org/c/openstack/diskimage-builder/+/833216 | 18:54 |
| iurygregory | diablo_rojo_phone, quick question regarding PTG rooms, by any chance there a chance to have a new room on Tuesday so the ironic team can have a session from 14 to 17 UTC? (not sure if this would be the right channel to ask you this question =) ) | 19:45 |
| diablo_rojo_phone | iurygregory: Like we add a Newton or wherever in the alphabet we are in that ethercalc because the rest of that time window is full? | 19:48 |
| iurygregory | diablo_rojo_phone, yup =) | 19:51 |
| diablo_rojo_phone | I thiiiiink we can make that work, but I will double check with the powers that be and have to get back to you. | 19:51 |
| iurygregory | diablo_rojo_phone, sure, thank you for checking! it would be only on Tuesday April 5 | 19:52 |
| clarkb | This reminds me we should do more testing of meetpad and the sound issues we've observed. | 19:52 |
| * clarkb made a note to try and debug it more this week | 19:52 | |
| fungi | happy to help test | 19:55 |
| fungi | now that i've worked out the nuances of sound on my workstation | 19:55 |
| clarkb | fungi: cool maybe tomorrow morning? | 19:56 |
| clarkb | mostly just need to see if we reliably get working audio when connecting from various browsers with sound pre muted and pre unmuted in pavucontrol | 19:57 |
| fungi | i've got stuff on my schedule from 13:30 to 16:00, but open between then and the opendev meeting | 19:58 |
| clarkb | sounds good | 19:58 |
| fungi | i guess that's 9am your time, so morning enough hopefully | 19:58 |
| clarkb | yup thats perfect actually | 20:01 |
| corvus | https://review.opendev.org/833676 is the fix in zuul for full-reconfigure not correcting the branch cache after the missed event. it doesn't seem like a high priority right now since frickler re-created the one branch we saw a problem with. that change should help the next time it happens though. | 20:03 |
| diablo_rojo_phone | clarkb: yeah let me know if you need help testing. I can try to help too since I have the app on my phone now etc. | 20:04 |
| fungi | thanks corvus! | 20:04 |
| ianw | mnasiadka: yes, can do a release | 20:08 |
| ianw | i'll make it 3.20 because we have this change to containerfile, and a bigger one for the boot/efi partitions in incoming images | 20:27 |
| *** dviroel|ruck is now known as dviroel|ruck|afjk | 20:50 | |
| *** dviroel|ruck|afjk is now known as dviroel|ruck|afk | 20:50 | |
| ianw | corvus: as someone recently playing with dashboards, series https://review.opendev.org/q/topic:grafana-json may be of interest. we've had the json import for a while, but this is the first time i've really attempted to use it. editing locally via the UI is quite good | 20:58 |
| ianw | they have deprecated the old graph panel time for a new "time series" panel, which grafyaml doesn't have the schema for | 20:59 |
| ianw | it's of course very different data structures; afaics it's not really defined anywhere, apart from the actual ts files. reverse engineering it isn't really on my todo list | 21:00 |
| ianw | i think they keep it quite backwards compatible, so you can import old dashboards. but i don't think they explicitly export the panel types as an api, as such | 21:01 |
| mnaser | hi folks -- i'm wondering if it's okay to publish non-released versions of things to tarballs.opendev.org -- mainly thinking/looking of having an ansible collection build of each commit published there (or is there a better 'scratch' space location?) | 21:07 |
| mnaser | it's just a bunch of yaml file(tm) so i cannot imagine it taking up much space | 21:07 |
| clarkb | mnaser: we have asked that you not publish a new file for each commit but rather update a single file in the past | 21:08 |
| clarkb | eg the master tarball gets updated each time master updates | 21:08 |
| mnaser | oh that's also a perfectly reasonable request | 21:08 |
| mnaser | that covers the "get the latest package" which is really what is wanted here | 21:08 |
| clarkb | there should be examples of that for openstack python sdists | 21:09 |
| mnaser | it's an ansible collection, so i think we can just build it using the pbr version, and then after that the file with the same name | 21:10 |
| mnaser | okay, that sounds pretty reasonable, i'll work off of that then | 21:10 |
| corvus | ianw: the value i get from grafyaml isn't the schema validation, it's the yaml->json conversion... can we just drop the schema validation and keep storing our panels in yaml? i don't really consider json to be human-editable, so i don't feel like i can edit or create a new graph easily with json. but that's exactly what i do with the yaml. | 21:14 |
| corvus | ianw: when i made the zuul performance metrics dashboard, i did develop it with local grafana installation, but only enough to get one graph the way i wanted, then i used grafyaml to make 30 similar graphs with different metrics. that was a lot more convenient than the alternatives. | 21:19 |
| mnaser | is there a reason why this job doesn't have the secret attached to it directly? https://opendev.org/opendev/base-jobs/src/branch/master/zuul.d/jobs.yaml#L421 | 21:43 |
| clarkb | mnaser: the docstring points to it. Each tenant will have different secrets | 21:43 |
| mnaser | the secrets that are attached to it is the same, i'm looking to publish an ansible collection (.tar.gz file) and the options aren't really usable | 21:43 |
| clarkb | they should be different per tenant iirc. Eg zuul's is different than openstacks. | 21:44 |
| mnaser | ah, we've been mostly using/relying on opendev infra (so publish to docs.opendev.org, etc) | 21:44 |
| ianw | corvus: it's not written that way, but it could be. honestly if you're developing the graph using the ui, then there might be better ways to have similar graphs, such as template variables | 21:44 |
| clarkb | ya zuul publishes to a zuul specific dir in afs and openstack to an openstack specific dir. I think if you use the opendev root then ya it can be shared? | 21:44 |
| clarkb | but that isn't true for all tenants/usages | 21:44 |
| mnaser | yeah my thought process didnt think of that part | 21:45 |
| corvus | ianw: i did use template variables; that serves a very different function than graph repitition. | 21:46 |
| mnaser | i guess i can use the `opendev-promote-python` job as a parent and then override the vars.. | 21:46 |
| corvus | ianw: my point was that most of what grafyaml does is translating yaml to json, and i think that's valuable. we obviously could have just stored the graphs as json to start with, but we chose not to, and we chose to implement grafyaml instead to make it easier to maintain | 21:47 |
| corvus | ianw: i still feel that grafyaml *does* make it easier to maintain than just checking in json blobs. | 21:47 |
| corvus | ianw: so, as an opendev contributor, that's my feedback: grafyaml makes that work easier to do, and i think it's worth keeping the graphs in yaml for that purpose. my recent dashboard contribution was directly facilitated by that, and i do not think that i would have made the same contribution without it because the alternative is so tedious and error-prone. | 21:51 |
| clarkb | corvus: ianw: wasn't one of the ideas that you could build the dashboard in grafana then export the json? So you aren't editing json directly, but you also arent' editing yaml and instuead clicking in a browser which may also not be desireable? | 21:55 |
| ianw | ok. i think that telling a new contributor -- no you edit it using the GUI locally, but then you open up the json, and you figure out using undocumented rules, mostly cargo-cult copying from previous graphs, what are the important bits to extract into YAML, then put it in the tool -- which will schema validate some of it, and turn it back into json, that we will re-import ... is not an encouraging workflow. | 21:55 |
| corvus | clarkb: well, that's what ianw is proposing we do -- basically just use grafyaml as a json importer. i'm saying that json is not human-editable nor is it human-reviewable, so from my perspective, we're just checking in blobs. | 21:56 |
| ianw | clarkb: yes, that is my idea, in a nutshell, https://review.opendev.org/q/topic:grafana-json would be the first example of it | 21:56 |
| corvus | ianw: we've had great success with new contributors adding new dashboards with grafyaml. what you describe is not at all the actual process. | 21:57 |
| clarkb | corvus: got it, I think that was the context I was missing | 21:58 |
| corvus | (except the cargo-cult part -- that is, very much, intentionally the process, and that's the best thing about it) | 21:58 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Update Gitea to 1.16.4 https://review.opendev.org/c/opendev/system-config/+/828184 | 21:59 |
| opendevreview | Clark Boylan proposed opendev/system-config master: DNM change to test and hold gitea 1.16 https://review.opendev.org/c/opendev/system-config/+/828586 | 21:59 |
| ianw | except if you want anything that grafana has added outside what is already cargo-culted, you have to reverse engineer the undocumented grafana json behind it | 21:59 |
| clarkb | I've put an autohold in place for https://review.opendev.org/c/opendev/system-config/+/828586 to grab the gitea and we can check it | 22:00 |
| clarkb | ianw: is the yaml grafyaml accepts a 1:1 yamlification of the json that grafana outputs? | 22:01 |
| clarkb | ianw: I wonder if we can send it through ruamel or similar | 22:01 |
| corvus | yeah, that's the unfortunate part. but that is what we decided to do when we wrote grafyaml, and that's the investment that makes it worthwhile. it sounds like there is a new feature in grafana you want to use that would require some more investment in grafyaml and you don't want to make that investment. that's understandable, but let's be clear about what you're suggesting: we stop using yaml altogether (essentially only using grafyaml as a | 22:02 |
| corvus | json blob importer). | 22:02 |
| corvus | rather than stop using grafyaml, i would rather we 1) invest in adding support to grafyaml for the new feature, or 2) don't use the new feature. i think the benefits grafyaml bring are that important. | 22:02 |
| clarkb | corvus: what is the new feature? | 22:03 |
| corvus | clarkb: grafyaml is an extremely thin yaml->json converter (it is so thin it looks like it does almost nothing, but it does enough that apparently the new feature ianw wants to use requires changes) | 22:03 |
| corvus | clarkb: i don't know | 22:04 |
| clarkb | got it | 22:04 |
| ianw | grafana has changed the default to a "time series" panel | 22:05 |
| ianw | https://grafana.com/blog/2021/02/10/how-the-new-time-series-panel-brings-major-performance-improvements-and-new-visualization-features-to-grafana-7.4/ | 22:05 |
| ianw | grafyaml does not have the schema validation for this | 22:05 |
| ianw | you'll get a warning in the UI that the old panel type is deprecated, and they have a button to "upgrade" it to the new panel type | 22:06 |
| clarkb | I guess that means we need to update grafyaml to output the new type from the existing yaml inputs? and I guess validate that this is valid | 22:06 |
| ianw | well, yes, i guess that would be the equivalent of writing the upgrade tool that grafana provides that moves graph panels -> timeseries panels | 22:07 |
| corvus | or change grafyaml to grok the timeseries schema and then "upgrade" our yaml by hand | 22:08 |
| corvus | (i think that makes more sense than encoding a translation layer in grafyaml; i like it being a thin layer) | 22:08 |
| *** rlandy is now known as rlandy|bbl | 22:14 | |
| mnaser | ok cool, so going to use zuul artifacts to publish per-commit collections (which i dont care about being long lived), and then i will take those and promote them later into tarballs.opendev.org pointing to specific branch | 22:18 |
| clarkb | mnaser: ya the zuul artifacts will live for 30 days if written to the log servers (which most artifacts are though not all) | 22:19 |
| mnaser | yeah, it's good enough for the use case of "i want to try pulling this recent build" | 22:20 |
| mnaser | and then the published to tarballs.o.o will be the static "gimme latest" | 22:20 |
| ianw | it's not just the time series, though. https://review.opendev.org/c/openstack/project-config/+/833213/1/grafana/infra-prod-deployment.json#183 you can see everything goes in a "fieldConfig" dict now. the closest i've found to documentaiton of what this is, is https://grafana.com/docs/grafana/latest/packages_api/data/fieldconfig/ | 22:24 |
| ianw | which is pretty much just fairly useless autogenerated fluff | 22:24 |
| ianw | that has a "custom" field where it seems actual things that affect the graph display are put. | 22:25 |
| corvus | if the json is not comprehensible then we can't review it either. | 22:27 |
| clarkb | is it possible to take the json from a change and put it into a grafana and validate it that way? I suppose that doesn't mitigate against risks if there is some sort of flaw in the input though | 22:33 |
| ianw | I feel a better way to review than having people try to be human grafana undocumented api converters would probably be to pull the change, and start up a grafana using something like https://review.opendev.org/c/openstack/project-config/+/833214 and view the dashboard in-situ. at this point we could even have CI do screenshots | 22:33 |
| ianw | but i understand you have a fundamentally different view, if we don't want to support both paths, then ok, we have what we have until we figure out how to update grafyaml | 22:34 |
| clarkb | ya I think that could verify it generates graphs we like, but not that there isn't some hidden nefarious functionality. Though that may not be a possibility with grafana at all | 22:34 |
| ianw | the json really isn't *that* bad to parse. https://review.opendev.org/c/openstack/project-config/+/833213/1/grafana/infra-prod-deployment.json is a concrete example | 22:35 |
| ianw | anyway, i'm out afk for now | 22:41 |
| clarkb | fungi: on the project retirement side of things we retired all the repos and abandoned their changes right? We should be good to land https://review.opendev.org/c/openstack/project-config/+/831837 now? | 22:59 |
| clarkb | infra-root if you can double check that there isn't anything else to add to the meeting agenda I'll get that sent out soon | 23:03 |
| fungi | clarkb: yes, for all the retirement changes set to your chosen topic, i approved them all and then abandoned every other open change for those same repos | 23:11 |
| clarkb | fungi: excellent then I think that change is ready | 23:13 |
| fungi | i concur | 23:14 |
| clarkb | I'm going to send out the agenda now. We can always edit it later if something important comes up | 23:15 |
| fungi | thanks! | 23:17 |
| clarkb | I remembered to add a note about the DST change in my email too :) | 23:17 |
| clarkb | https://104.239.143.159:3081/opendev/system-config here is the held gitea server. Maybe we can land that upgrade tomorrow? Reviews and double checking with the test node very much welcome | 23:20 |
| clarkb | At first glance it seems fine | 23:20 |
| *** dviroel|ruck|afk is now known as dviroel|ruck | 23:49 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!