| spotz[m] | Deployment docs are the most likely to be updated | 00:03 |
|---|---|---|
| opendevreview | Tony Breeds proposed openstack/election master: [templates] Update links https://review.opendev.org/c/openstack/election/+/911387 | 01:28 |
| *** promethe- is now known as prometheanfire | 01:30 | |
| opendevreview | Tony Breeds proposed openstack/election master: Simplify and update-governance https://review.opendev.org/c/openstack/election/+/888209 | 04:05 |
| frickler | avanzaghi: please check the vwx-eom release patch https://review.opendev.org/c/openstack/releases/+/910392 | 07:23 |
| frickler | noonedeadpunk: please check the vwx-eom release patch https://review.opendev.org/c/openstack/releases/+/910430 | 09:51 |
| noonedeadpunk | thanks for the ping | 09:54 |
| noonedeadpunk | I'm falling bahind duties for last month, but hopefully be back up to speed starting April | 09:55 |
| frickler | noonedeadpunk: np, thanks for the update | 10:01 |
| noonedeadpunk | I actually also need to take care of osa's eom patch... | 10:02 |
| noonedeadpunk | but it's slightly more complex | 10:02 |
| frickler | noonedeadpunk: I pinged elodilles about that, not sure if it can be autogenerated? | 11:33 |
| noonedeadpunk | I think it used to be at least for branching | 11:34 |
| noonedeadpunk | as I saw generated proposals for these | 11:35 |
| noonedeadpunk | I'm talking about this now: https://opendev.org/openstack/releases/src/branch/master/deliverables/yoga/openstack-ansible-roles.yaml | 11:35 |
| frickler | noonedeadpunk: yes, I think there was something that because it doesn't appear in governance directly, the script needs some explicit kick in order to generate that for vwx, too | 11:37 |
| elodilles | well, i don't know off top of my head whether i did it with standard tooling or had to do it with some minimal scripting myself o:) so i have to check | 11:37 |
| noonedeadpunk | well, all these repos are under governance jsut in case | 11:38 |
| elodilles | nevertheless, the 'official' transition_series.sh script cannot handle it | 11:39 |
| elodilles | hence we miss it all the time :S | 11:39 |
| elodilles | new-release command does not work. give a minute and i'll create a patch for xwv-unmaintain then | 11:44 |
| elodilles | noonedeadpunk: there it is https://review.opendev.org/c/openstack/releases/+/911509 | 12:01 |
| fungi | frickler: moving discussion here, as i said in the tc meeting a few weeks ago i'll gladly subscribe any tc members to that murano bug if they express interest in either trying to help fix it or deciding to switch it to public. murano hasn't opted into granting that authority to the vmt but as a part of openstack i can see an argument for tc members to make that choice on behalf of the | 13:48 |
| fungi | project | 13:48 |
| *** tosky_ is now known as tosky | 13:57 | |
| frickler | fungi: ok, I would offer myself to look strictly only at the latter option, but let's wait for JayF first | 14:06 |
| fungi | i mainly just don't want to overstep my authority in this case, since up to now it's been granted to the vmt by each individual team (though implicitly in the case of the earliest projects, they could still decide to opt out of it at any time) | 14:09 |
| fungi | the problem comes, as we've seen in other areas, when there's nobody active enough in the team to grant that authority | 14:10 |
| frickler | fungi: yes, in my understanding the authority then falls back to the TC like in the case when there is no PTL candidate, but maybe others have different opinions | 14:11 |
| frickler | tc-members: ^^ I guess that's interesting enough a topic to ping you all | 14:12 |
| JayF | I am +1 to opening up that bug. I'm unsure how to express that in any official way | 14:16 |
| fungi | i can subscribe you to the bug, and then you can switch the bug type in launchpad from private security to public security along with a sentence or two comment about why you're doing it | 14:22 |
| fungi | though if you want to gather more (formal or informal) consensus from the rest of the tc first, i understand | 14:23 |
| fungi | unrelated, on the subject of openstack-wide architectural issues, the uwsgi entrypoint script discussion is heating back up again. seems package maintainers and deployment developers are looking for some official decision on the path forward | 14:37 |
| fungi | i suppose it could be summarized and communicated with an official goal | 14:38 |
| JayF | There is a goal that's been issued. It's technically gotten enough votes to be merged, but there hasn't been any real engagement on it to the point where I'm convinced that merging it actually solidifies it as a goal | 14:59 |
| JayF | I'd say in general we have a review bandwidth problem with longer form governance changes right now, which doesn't really make sense to me | 15:00 |
| fungi | oh, i had forgotten there was one proposed already. i suppose it's worth me linking it in that thread and encouraging participants to review | 15:01 |
| fungi | thanks for the reminder! | 15:01 |
| dansmith_ | JayF: I hate to say this, but you probably need to beat the drum more | 15:02 |
| *** dansmith_ is now known as dansmith | 15:02 | |
| dansmith | gmann was insanely good about "reminding" about reviews | 15:02 |
| dansmith | it sucks, I'm not proud of myself, but with so many things in the air, I'm pretty event-driven | 15:02 |
| JayF | Honestly, I'm pretty event driven at this point too which is where I have not done a good job of this kind of periodic reminder stuff lol | 15:03 |
| dansmith | code changes get my attention regularly because of other reviews, test results, rechecks, etc but gov stuff not so much | 15:03 |
| frickler | tc-members: the release team has discovered some issues during the unmaintained migration, I've tried to list them at https://etherpad.opendev.org/p/unmaintained-release-issues , feedback welcome especially where noted | 15:41 |
| frickler | elodilles: ttx: hberaud_: ^^ fyi | 15:42 |
| frickler | (there you got your event to drive you ;) | 15:42 |
| frickler | JayF: sorry for more pinging, but regarding the PTG: do you intend to continue to use zoom sessions? because then I wouldn't need to worry about the actual scheduling of sessions | 15:46 |
| JayF | The PTG, generally, is being held in meetpad this year. | 15:46 |
| JayF | I do not have any personal desire to upend the default, same as last PTG. | 15:46 |
| JayF | If someone cares deeply, they're welcome to advocate for change. | 15:46 |
| frickler | oh, that's news to me | 15:46 |
| JayF | I'll note it's also possible that there will be a new chair by then | 15:46 |
| JayF | so anything I say about PTG planning should be considered tentative :) | 15:47 |
| JayF | btw frickler I never am bothered by the ping. I manage my notifications around working hours and all, if you ever bother me when I don't wanna be bothered it's my (or Android's) fault :D | 15:47 |
| frickler | but then the mentioning of "Ocata room" in the ptg etherpad is misleading | 15:47 |
| frickler | JayF: just wanted to show some sign of politeness ;) | 15:48 |
| frickler | also ack regarding the tentativeness | 15:48 |
| JayF | frickler: click the os-tc links to ocata room :) | 15:48 |
| JayF | it takes you to meetpad | 15:49 |
| JayF | the API stays the same, we just changed drivers ;) | 15:49 |
| frickler | maybe time to drop this legacy "room" concept then | 15:49 |
| frickler | so, no zoom at all? was that announced somewhere? | 15:50 |
| JayF | I am happy to keep that level of PTG planning outta scope of me-personally as much as possible. I have a full plate already :D | 15:50 |
| JayF | frickler: I know last year when we were talking about if it should be zoom or meetpad, they said meetpad would be default next ptg, that's part of why I was ... choosing to not fight that battle then | 15:50 |
| fungi | redoing the schedule design is the plan but it would take a larger rework of the software, so for this time around it was decided to just explicitly override the track urls when creating them, since that could be done easily without any changes to the code (only to the track creation process) | 15:51 |
| frickler | JayF: ok, then just one issue: the etherpad says Apr 8 for the first session, which would be Monday, but the ptg page shows the slot reserved on Tuesday? | 15:53 |
| JayF | frickler: I need you to look away for about 30 seconds while I perform some irc-bot slight of hand ;) | 15:53 |
| frickler | I can do that, ok | 15:54 |
| JayF | what are you talking about? | 15:54 |
| JayF | the website is accurate | 15:54 |
| JayF | and was accurate before 30 seconds ago :P | 15:54 |
| JayF | lol | 15:54 |
| JayF | (I fixed it) | 15:54 |
| frickler | fungi: thanks for the technical background. I'm just wondering (once again) whether that decision and the process behind it could (have been/be) made more public | 15:56 |
| frickler | JayF: thx, seems I was somehow looking the wrong way earlier ;) | 15:57 |
| JayF | It happens. SO easy to just swap out a Tuesday for a Monday without even noticing ;) | 15:57 |
| fungi | frickler: yeah, i thought diablo_rojo had announced that publicly after the discussion we had at the last ptg, but it's possible those details only made it into the communications to team leads and in non-textual places like foundation board meetings and openinfra.live episodes | 15:58 |
| fungi | frickler: anyway, the background is that teams can, as always, override the videoconference url for their track to whatever they want (a specific zoom room they also use for other meetings, bluejeans, google meet, whatever). if a team does decide they need zoom instead of using meetpad but doesn't have a zoom room to use, the ptg organizers can get one allocated for them. the overhead of | 16:03 |
| fungi | setting up a slew of zoom rooms most of which sat unused was time-consuming and the licensing was quite costly, so with opendev already maintaining meetpad (we designed it specifically for the ptg use case after all), it seems like a good default option | 16:03 |
| fungi | probably the biggest feature difference with meetpad is that we only have its recording option set up for client-initiated recordings. someone will need to remember to start the recording and there is a size limit which practically means teams need to take a break at least once an hour and stop the recording, starting a new recording at the end of the break | 16:05 |
| frickler | fungi: I couldn't agree more, I've been saying that for some time now, but a lot of teams seemed to either actively prefer zoom or were too lazy to change the default. so the zoom option will still be there | 16:05 |
| fungi | the organizers observed that on average about 2% of ptg sessions have recordings requested, so if a team really needs zoom's feature where the account holder can automatically upload a recording to youtube or something, then that can be accommodated on a case-by-case basis | 16:06 |
| frickler | enforcing breaks that way is a side-effect I also don't object to ;) but then I don't think recording those sessions is a good idea in the first place | 16:07 |
| JayF | I used to feel that way, feeling less that way after the recent magnum disputes. | 16:07 |
| fungi | the magnum team had the option of recording that session. they could have also just more clearly documented the discussion in their notes and/or discussed it on the mailing list afterward. i don't know that a recording would have been much help anyway since the party who objected to the outcome didn't participate in the session | 16:09 |
| fungi | would they have watched the recording if it existed? it seems like they didn't read the notes from the session until linked during the latest debate | 16:10 |
| frickler | recording a session isn't a substitute for proper note taking, I agree | 16:11 |
| *** clarkb1 is now known as clarkb | 16:55 | |
| clarkb | I think it is also important to note that just because a decision was made $time ago doesn't mean project teams can't make newer decisions | 16:56 |
| clarkb | So even if we had a recording and notes that say we're going to do things in X way instead of Y way it is entirely possible Y happens and X doesn't for reasons due to the passage of time (different team members now, or maybe problems discovered in X in that were unanticipated) | 16:57 |
| clarkb | these aren't binding decisions we can never change course on. Intead events like the PTG are aimed at helping build consensus and direction. But it isn't the end all decider of these things | 16:58 |
| clarkb | major exaple: OpenDev tried to move container image hosting into quay. Then discovered that docker can only have "mirrors" of docker hub and not other registries whcih breaks speculative container hosting for anything hosted outside of dockerhub | 17:08 |
| clarkb | this led us to moving everything back to docker hub | 17:08 |
| clarkb | unexpected problems, life, priorities, people all change over time and as a result decisions we make may have to accomodate | 17:09 |
| frickler | also decisions made exclusively at a PTG would exclude anyone that for whatever reasons wasn't able to participate directly | 17:10 |
| frickler | so whereever possible/applicable something like specs or RFEs that can be tracked in gerrit or elsewhere should be used | 17:12 |
| * frickler wonders whether we have some docs location where one could write these things up for a bit | 17:13 | |
| frickler | ok, two more things that might require some escalation sooner or later, I'm simply mentioning them here for now | 17:44 |
| frickler | a) python-aodhclient is blocking the current oslo.db version in its requirements, so they are not co-installable, creating an issue for distros. I've proposed a patch at https://review.opendev.org/c/openstack/python-aodhclient/+/910865 that could possibly solve this | 17:46 |
| frickler | b) similarly some other projects might be broken (again) by that oslo.db release https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/Z6ZWJRC32EPM4TJUZHTLTDFGQRLNRWP4/ | 17:51 |
| SvenKieske | it looks like there is a workaround in place wrt bcrypt? | 17:56 |
| SvenKieske | 2024-03-05 16:06:22.664213 2024-03-05 16:06:22.663 1012 DEBUG passlib.handlers.bcrypt [None req-65773efd-6242-43ac-9a44-8144861c0726 - - - - - -] 'bcrypt' backend lacks $2$ support, enabling workaround _finalize_backend_mixin /var/lib/kolla/venv/lib/python3.10/site-packages/passlib/handlers/bcrypt.py:406\x1b[00m | 17:56 |
| SvenKieske | ah my bad, wrong channel | 17:57 |
| frickler | tc-members: one final thing from me for today: we are unsure in the release team how to best handle python-muranoclient, for which a release has already been made for this cycle, please comment on https://review.opendev.org/c/openstack/releases/+/911415 if you have some opinion | 19:58 |
| JayF | I +1'd it, seems like a sensible compromise | 19:59 |
| gmann | yeah, it is more of not doing any further release in this cycle if any already released we cannot undo that anyways | 20:00 |
| spotz[m] | Yeah we discussed Murano this morning in the RDO meeting as it was breaking CI so it's removed there as well, we were leaving things another cycle for people to move off provided an inactive project passed CI | 20:36 |
| fungi | it's a shame the reported vulnerability for it is still set private, or we'd have something to point to in order to tell deployers they should basically be disabling or uninstalling it | 20:58 |
| spotz[m] | Knowing it had an issue plus failing CI was an easy decision for us | 21:08 |
| fungi | yeah, at the moment my concerns in order are 1. making sure people don't keep installing it, and 2. making sure people who already have it installed have sufficient information to know to disable the impacted functionality | 21:09 |
| spotz[m] | Removing it helps with 1 but not knowing the fullinformation makes doing 2 hard | 21:10 |
| fungi | exactly | 21:12 |
| JayF | tc-members: if there is no objection stated by this time tomorrow, I'm going to ask fungi to assign the murano closed bug to me and I will open it on behalf of the TC | 21:12 |
| spotz[m] | None from me | 21:13 |
| JayF | The bug is set to private for obvious reasons; we are unlikely to ever fix it so we need to shine a light | 21:13 |
| dansmith | I'm not sure if I've seen it so I don't know how big the vulnerability is | 21:13 |
| JayF | fungi: ^ I'll get you outta the pinch tomorrow unless someone screams no at me :) | 21:13 |
| JayF | dansmith: I've not seen it either; but murano devs don't exist to fix it, unless someone is going to volunteer to fix it we need to at least be transparent about the vulnerability | 21:13 |
| dansmith | not asking to see it, but if your estimation is that it's not a 10/10 sort of end of the world thing, I see no better resolution than opening it | 21:13 |
| JayF | dansmith: and fungi indicated in here and elsewhere that experienced murano deployers have indicated their workaround is to disable a large % of the service's capabilitiies | 21:14 |
| dansmith | JayF: well, the reason I say that is that if it's so bad that anyone running murano will be exposing a root shell to the world in five minutes after disclosure it might be better to handle it differently | 21:14 |
| JayF | fungi: ^ Can you address that question? | 21:14 |
| JayF | although from another perspective: unless we're going to fix it, we have an obligation to open it IMO | 21:14 |
| dansmith | JayF: right I know I just want to make an educated decision.. if it's something that could jeopardize all the current public clouds, "who is going to fix this" might be different | 21:15 |
| dansmith | I'm totally on the side of "just open it and tell people to uninstall" | 21:15 |
| spotz[m] | It's definitely a we don't know what we don't know situation | 21:15 |
| dansmith | I'm just saying... | 21:15 |
| fungi | dansmith: yeah, i'm not a murano user so the best gauge i have is that one of the operators subscribed to it said their approach in production was likely going to be just disabling a significant portion of its functionality | 21:15 |
| JayF | that's why I redirected that question to someone who has seen the bug :) | 21:15 |
| fungi | whether disabling that makes it entirely useless to some deployments, i'm not certain, but i'd wager yes in many cases | 21:16 |
| dansmith | fungi: to be clear, I'm sure that's the only real solution, and not actually fixing it.. what I mean is if the vuln is "poke this special url and you get a root shell" we might want to handle it differently, like do a release where the code is replaced with 'return 1' | 21:17 |
| dansmith | and tell people to disable it before we tell them why | 21:17 |
| fungi | i also don't know how frequently murano is installed, maybe the user survey has data on that | 21:17 |
| dansmith | if it's less severe than that, then I doubt it matters | 21:17 |
| fungi | it's normal authenticated users able to run things as murano's service account | 21:18 |
| fungi | on the control plane | 21:18 |
| dansmith | run things like spawn an executable? | 21:18 |
| JayF | oh my | 21:18 |
| spotz[m] | eeep | 21:19 |
| dansmith | how about you add JayF and me and we can have a quick chat about it being in the know | 21:19 |
| fungi | yes, run arbitrary commands on the server where the murano service is installed, it looks like | 21:19 |
| JayF | that is almost as bad as dansmith's fake worst case | 21:19 |
| JayF | well, that *is* the worst case | 21:19 |
| dansmith | JayF: yeah, that's pretty bad | 21:19 |
| JayF | gah | 21:19 |
| dansmith | JayF: it leads to the worst case pretty much, at least | 21:19 |
| dansmith | I dunno if murano uses rootwrap or privsep, but if so there's probably a path to root there | 21:19 |
| spotz[m] | I think just from that much info we need to tell folks to disable and uninstall | 21:19 |
| fungi | hence why i've been trying to raise the alarm when the only active volunteer for murano said there was probably nobody to fix it | 21:19 |
| JayF | spotz[m]: dansmith's suggestion of "do a release that makes the service nonfunctional" is not a terrible idea if it is that's bad | 21:20 |
| JayF | add a config option of "i accept the security risk" or else sys.exit(1) immediately (this started as a joke but maybe isn't a terrible idea) | 21:20 |
| dansmith | yeah my thought was just that a release is maybe our best mechanism to communicate something that will get attentuion | 21:20 |
| spotz[m] | JayF: I's not IF we can get it to pass CI | 21:21 |
| dansmith | nah we can do a release with no CI | 21:21 |
| JayF | ++ | 21:21 |
| JayF | to no ci | 21:21 |
| JayF | "confirmed not working" ✅ | 21:21 |
| fungi | JayF: dansmith: i believe i've subscribed your typically-used lp accounts to https://launchpad.net/bugs/2048114 | 21:21 |
| dansmith | fungi: ack thanks | 21:22 |
| dansmith | fungi: JayF: video chat in a few minutes to scheme? | 21:22 |
| fungi | i can audio, if that's sufficient. don't have my camera hooked up | 21:22 |
| spotz[m] | Let me know if you need me, I'm free for a but | 21:23 |
| dansmith | fungi: I figured, you never have video | 21:23 |
| dansmith | afaik you're no longer three dimensional | 21:23 |
| * fungi is 11-dimensional | 21:23 | |
| spotz[m] | hehe | 21:23 |
| fungi | take that in whatever numeric base you prefer | 21:24 |
| dansmith | looks like boring old 3-dimensional in my binary view | 21:24 |
| fungi | (classical quantum string theory uses 11 dimensions decimal, fwiw) | 21:25 |
| JayF | sorry it took me a while to join, laptop decided to die as you asked that :D | 21:46 |
| JayF | tc-members: the plan is: fungi will draft a redacted OSSN, urging OpenStack users to disable/uninstall their Murano services and information that we'll be opening the bug and providing details in a week. After that week passes, we'll unredact the OSSN and open the bug and really, really hope that users were listening. | 21:54 |
| JayF | tc-members: if you object to this plan, you have probably about a day to say so before we'll execute it | 21:54 |
| rosmaita | JayF: plan sounds good to me | 22:15 |
| fungi | yeah, i'd prefer to send it out tomorrow. we try to avoid communicating security issues on fridays, weekends, mondays or major holidays, for visibility reasons, so if we miss tomorrow then tuesday the 12th is the next opportunity | 22:24 |
| spotz[m] | +1 | 22:25 |
| rosmaita | fungi: lmk if you need reviewing/proofreading assistance | 22:25 |
| dansmith | ++ | 22:26 |
| JayF | rosmaita: Heads up; I'll be PTO the first week of April. It's unlikely we'll have a new Chair/VC by then, so you'll need to run that meeting. I'm also going to make a more concerted effort than usual to stay outta IRC/chat/etc | 22:26 |
| rosmaita | JayF: ok, though i may no longer be on the TC at that point (though, nothing says anywhere that the TC meetings must be chaired by a TC member) | 22:27 |
| JayF | oh, that's a good point | 22:27 |
| JayF | you aren't even running, are you? | 22:27 |
| JayF | so you're guaranteed not on TC by then | 22:27 |
| rosmaita | no, decided to step aside so that red hat would not force a diversity requirement exception | 22:28 |
| rosmaita | plus, i have done enough damage | 22:28 |
| JayF | heh | 22:28 |
| JayF | I do not intend to run again | 22:28 |
| fungi | i'll just post a link to the draft in here once i have it. there won't be any sensitive information in it anyway with the current plan | 22:28 |
| rosmaita | fungi: ack | 22:28 |
| fungi | JayF: dansmith: rosmaita: i haven't added it to the ossn index yet, but https://wiki.openstack.org/wiki/OSSN/OSSN-0093 | 22:41 |
| JayF | > any deployments with Murano functionality accessible to untrusted users | 22:42 |
| JayF | is almost weakening the message too much | 22:42 |
| JayF | I would just remove "accessible to untrusted users" | 22:43 |
| JayF | because trust is a strange concept, and I doubt people would connect how much trust they need to have for it to be Ok in that case | 22:43 |
| gmann | JayF: rosmaita: let me know if you need help, I can volunteer to chair meeting. | 22:43 |
| fungi | sure. i mean, there are openstack deployments where the only users are also administrators, but meh. they know what they're doing i guess | 22:43 |
| JayF | gmann: I was likely going to ask you :) | 22:43 |
| rosmaita | gmann: you are my first choice! | 22:44 |
| JayF | gmann: so sure, I'll have you pencil'd in if we don't get a new chair by then | 22:44 |
| gmann | :) | 22:44 |
| fungi | also i suppose clouds where all users are admins probably have limited use for services like murano anyway | 22:44 |
| gmann | JayF: sounds good. | 22:44 |
| fungi | JayF: that read any better? | 22:45 |
| JayF | fungi: pretty much exactly what I was thinknig ++ | 22:46 |
| rosmaita | fungi: my only suggestion would be to s/There is currently no fix/Given that the Murano project is inactive, there is currently no fix/ | 22:47 |
| fungi | oh, good point, it's officially listed as inactive now | 22:48 |
| gmann | also, we should merge this as we are mentioning about its status as Inactive https://review.opendev.org/c/openstack/governance/+/908859 | 22:48 |
| gmann | JayF: ^^ | 22:48 |
| JayF | I can't land it, I'm the only vote on it | 22:49 |
| gmann | is it? I see 5 votes there | 22:49 |
| JayF | post-rebase I am the only vote | 22:49 |
| JayF | patchset 4 is me only | 22:49 |
| JayF | you should at least vote on it too while here | 22:49 |
| *** kopecmartin_ is now known as kopecmartin | 22:50 | |
| gmann | JayF: I think i observed the same sometime but have no evidence exactly how it goes in gerrit. | 22:50 |
| rosmaita | i see 5 +1s on that patch | 22:50 |
| gmann | JayF: but I see all previous votes are carry forward in this, at least i see in my gerrit Rollcall-Vote button at top | 22:50 |
| JayF | the script doesn't agree, let me look | 22:50 |
| gmann | JayF: can you refresh it or so | 22:50 |
| JayF | I'm happy to land it if it's good to land | 22:50 |
| gmann | ohk | 22:50 |
| gmann | I voted though | 22:51 |
| JayF | yep, comment from > Mar 05 9:53 AM | 22:51 |
| JayF | indicates the votes were carried over | 22:51 |
| JayF | UI for rollcall votes is tough | 22:51 |
| JayF | landing it | 22:52 |
| gmann | I think it is little weird view on gerrit | 22:52 |
| rosmaita | \o/ | 22:52 |
| fungi | rosmaita: how's the current rewrite look wrt mentioning murano's inactive? | 22:52 |
| rosmaita | sorry, saw a squirrel | 22:53 |
| clarkb | if you hover over the votes you get a listing of who made them | 22:53 |
| rosmaita | looks good ... only suggestion would be to put all occurrences of "Thursday, March 14, 2024" in bold font | 22:53 |
| rosmaita | but the content LGTM | 22:54 |
| rosmaita | fungi: ^^ | 22:54 |
| fungi | rosmaita: i will get out my bold pen | 22:54 |
| rosmaita | :D | 22:54 |
| fungi | though it likely won't come across very well in plaintext e-mail to mailing lists ;) | 22:54 |
| fungi | rosmaita: bold applied. took me a few minutes to remember mediawiki markup for that (wrap in tripled apostrophes) | 22:59 |
| rosmaita | looks good! | 22:59 |
| opendevreview | Merged openstack/governance master: Mark Murano project inactive https://review.opendev.org/c/openstack/governance/+/908859 | 23:00 |
| JayF | clarkb: I don't see RC votes show up anywhere in zuul UI except for on the comments | 23:01 |
| JayF | clarkb: and when those comments are tied to an older patchset, AFAICT, the only way to know it carried over is to find the comment saying so | 23:01 |
| JayF | clarkb: please tell me I'm wrong and there's a better way I've missed :) | 23:02 |
| clarkb | JayF: I assume you mean gerrit not zuul. On https://review.opendev.org/c/openstack/governance/+/908859 it says Rollcall-Vote +1 under Trigger votes. Hover your mouse on that and you get all of the votes made to that label | 23:02 |
| JayF | clarkb: that is the better way I didn't know existed until now() | 23:03 |
| JayF | thank you | 23:03 |
| fungi | though it looks like that's still only reflecting the latest patchset | 23:03 |
| clarkb | you can hover submit requirements votes for a similar pop up view but that one will also show you the conditions that satisfy the requirement | 23:03 |
| fungi | even if you switch patchsets the trigger votes box shows the most recent patchset | 23:04 |
| clarkb | fungi: all votes on the change summary section are for the current patchset | 23:04 |
| clarkb | s/current/most recent/ | 23:04 |
| fungi | exactly, that's what i was saying | 23:04 |
| clarkb | I think gerrit has done that since like 2.8 | 23:04 |
| clarkb | whenever they changed from the old old change screen to the new old one | 23:04 |
| fungi | so it doesn't cover JayF's point about being unable to get an easy list of which votes were made on a prior patchset, but yes that hasn't been possible for a long time | 23:05 |
| JayF | Can't we just run Gerrit Train forever and keep all the UI exactly like I'm used to it /s | 23:05 |
| JayF | fungi: No, my problem was more, identifying if older votes are still relevant, clark solved that for me | 23:05 |
| fungi | aha | 23:05 |
| JayF | fungi: I don't have a real need to know if a non-current patchset was approved | 23:05 |
| rosmaita | fungi: clarkb: while you are both here, is there a way to tell gerrit UI to sort this list in dependency order? https://review.opendev.org/q/topic:%22fujitsu-driver-update%22-is:abandoned+after:2023-1-1 | 23:06 |
| gmann | I tried to make Rollcall-Vote as 'Submit Requirements' but that did not seems working https://review.opendev.org/c/openstack/project-config/+/868512 | 23:07 |
| clarkb | rosmaita: no sorting is always done by most recently updated in the change listing pages | 23:07 |
| fungi | rosmaita: what is dependency order? | 23:07 |
| clarkb | rosmaita: if you open a change though it should show a list of changes in relationship order | 23:07 |
| rosmaita | right, what clarkb said | 23:07 |
| clarkb | for example on https://review.opendev.org/c/openstack/cinder/+/907777 top right under "relation chain" click show all | 23:07 |
| gmann | yeah click SHOW ALL, otherwise it was confusing | 23:08 |
| rosmaita | clarkb: thanks ... i knew about that one, but wondered if there was a more convenient display | 23:08 |
| fungi | gertty ;) | 23:08 |
| rosmaita | glad to know there isn't, so i won't try to figure it out | 23:08 |
| fungi | gertty "threads" the change list | 23:09 |
| clarkb | in older gerrit you could reverse the order (oldest first) but now you can't even do that | 23:09 |
| clarkb | fungi: rosmaita: reading that notice one thing I wonder about is what happens to applications deployed by murano. I don't know that any of us know the answer to that | 23:17 |
| clarkb | but we may get the question | 23:17 |
| clarkb | In theory you can manually manage the underlying resources deployed by it? And shutting down services won't remove resources from the cloud | 23:18 |
| JayF | clarkb: from the chat dansmith, fungi and I had in video chat; we basically don't have enough knowledge/information about murano to address it to that degree. That's why we're suggesting to shut it down. | 23:19 |
| clarkb | right but if shutting it down means your applications get deleted that isn't good either | 23:19 |
| JayF | If I, personally, fielded such a question; I'd tell people to not trust *anything* deployed with Murano unless they've personally validated it. | 23:19 |
| clarkb | I don't think that is the case fwiw | 23:20 |
| fungi | yeah, it probably doesn't do anything to the virtual machines that had apps deployed onto them already, but i can't say that with 100% certainty | 23:22 |
| fungi | we could have dropped murano back when we retired the app catalog, but some people wanted to keep developing it at the time | 23:23 |
| clarkb | I guess the distinction is that peopel can manage their own independent app catalogs with murano in local deployments? | 23:24 |
| dansmith | tbh I think "uninstall murano" is the only reasonable course of action from what I saw | 23:25 |
| JayF | ++++++++++ | 23:28 |
| dansmith | I've typed about five "unless I did this" or "maybe if I jailed it like that" but kept deleting them and thinking, nope, I can't really see doing any of that | 23:30 |
| fungi | JayF: dansmith: see latest bug comment, clarkb saw the initial report because the project config in lp at the time cc'd it to ~openstack-admins, and he brought up some related concerns about similar projects, we might want to push out the disclosure timeline slightly to give folks from those projects an opportunity to look it over and determine if they need to make any changes | 23:50 |
| JayF | I am +1 to disclosing the issue to PTLs/their designates in those projects | 23:51 |
| fungi | yeah, just looking them up now | 23:53 |
| JayF | tkajinam is the heat ptl | 23:54 |
| JayF | IIRC | 23:54 |
| fungi | i'll subscribe him directly for now since heat's using storyboard (we can open a separate private heat story for this if it is deemed relevant) | 23:55 |
| fungi | the other project mentioned i'll also just subscribe the ptl. they use launchpad but don't have a coresec team and their drivers team has only one person who i know is not active in openstack any longer | 23:56 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!