| opendevreview | Merged openstack/api-site master: Fix docs builds for current Ubuntu versions https://review.opendev.org/c/openstack/api-site/+/933901 | 01:53 |
|---|---|---|
| *** elodilles_pto is now known as elodilles | 07:33 | |
| fungi | openinfra board of directors meeting starts in one hour (15:00 utc) | 14:00 |
| fungi | underway now: https://board.openinfra.dev/meetings/2024-11-12 | 15:00 |
| sean-k-mooney | i folks i started a thread about adding myself and https://launchpad.net/~openstack-admins as admins fo https://launchpad.net/~watcher-drivers | 18:24 |
| sean-k-mooney | https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/QLHS64DL7QJR725CEKGAVKCOEKXBE36Z/ | 18:24 |
| sean-k-mooney | i just got postmaster bounch responces for the listed email for the two current admins | 18:25 |
| fungi | that's not a good first sign | 18:25 |
| sean-k-mooney | hopefully they are still on teh list under a diffent email and would find it | 18:25 |
| sean-k-mooney | but if they dont respond how woudl we proceed? | 18:25 |
| fungi | yeah, otherwise we probably need to get launchpad's managers involved | 18:25 |
| gouthamr | :/ its possible chenker may still have some contact with li-canwei | 18:25 |
| gmann | sean-k-mooney: +1, not sure if they will be active on ML | 18:26 |
| fungi | basically we file a support request with launchpad staff and then wait | 18:26 |
| sean-k-mooney | that or perhaps we woudl need to create a new openstack-watcher proejct on launchpad? | 18:26 |
| fungi | we could also do that, though it would leave old bug history behind | 18:26 |
| fungi | and might sow confusion as to which one people need to report bugs for | 18:27 |
| sean-k-mooney | we dont need to rush, i just sent the mail and they are unlikely to be online now | 18:27 |
| gmann | seems li-canwei was active long back https://review.opendev.org/q/owner:li.canwei2@zte.com.cn | 18:27 |
| sean-k-mooney | but if i dont see any movement in a week or so we may need to explore the launchpad staff route | 18:27 |
| gmann | mainly we need to change the owner. just adding admin right still not enough in case future changes are needed or so | 18:28 |
| gouthamr | yes, and that's https://www.linkedin.com/in/david-tardivel-7418484/ :) | 18:28 |
| gouthamr | ^ so, one option is to send them a message via linkedin | 18:28 |
| sean-k-mooney | hum ya thats an option. i have 2 more linkedin accounts then i would like to have | 18:29 |
| gouthamr | sorry you've to take non-public routes to go about this.. i can do it if you'd like.. | 18:30 |
| gmann | sean-k-mooney: did you also receive mail undelivered to "David.TARDIVEL@b-com.com," ? | 18:30 |
| gmann | when I replied to your email, it did not get delivered to david | 18:30 |
| gouthamr | ... since an ownership change is all we need, fungi/gmann can do the rest | 18:31 |
| sean-k-mooney | yes | 18:31 |
| gmann | yeah, once owner is changed then we can handle rest | 18:31 |
| fungi | right | 18:31 |
| fungi | happy to handle that part once ~openstack-admins is owner | 18:31 |
| JayF | sean-k-mooney: thank you for digging into that | 18:32 |
| sean-k-mooney | https://imgur.com/a/tagMcVa | 18:32 |
| sean-k-mooney | those are the two responces i got | 18:32 |
| gmann | yeah, same I got. | 18:32 |
| sean-k-mooney | for now its not a blocker but just wanted to keep peopel in the loop | 18:33 |
| sean-k-mooney | since htere is no coresec team or public bug team | 18:34 |
| sean-k-mooney | we cant triage either type of bug report currently outside of the current member of the watcher-drivers group | 18:34 |
| sean-k-mooney | gmann: since we are on this topic should i set drviers to so-vif drivers ? https://launchpad.net/os-vif | 18:36 |
| * gouthamr reached out to David on LinkedIn.. will report back if they respond.. | 18:37 | |
| gmann | sean-k-mooney: +1 | 18:37 |
| sean-k-mooney | ok ill update that. its set directly to me for legacy reasons but os-vif drivers is properly owned by openstack administors | 18:38 |
| gmann | sean-k-mooney: yeah, ownership is all right there. | 18:38 |
| sean-k-mooney | cool fixed | 18:38 |
| gmann | perfect | 18:39 |
| gouthamr | a while ago tkajinam asked me to update https://launchpad.net/~manila-drivers.. i got hold of the account and changed it just now to openstack-admins | 18:40 |
| * gouthamr doesn't yet have a response from the original owner of https://launchpad.net/~manila-ui-drivers :| | 18:41 | |
| gouthamr | ooh, this one was reassigned to me too: https://launchpad.net/~manila-bug-supervisors ; openstack-admins has control of it now.. | 18:42 |
| gouthamr | sorry for the email spam; but good to get this done :D | 18:43 |
| fungi | thanks gouthamr. i'll remove openstack-admins as a member since it only needs to own the groups | 18:43 |
| gouthamr | (and https://launchpad.net/~manila-coresec) | 18:43 |
| fungi | as the owner, it can add itself as a member any time that's needed anyway | 18:43 |
| gouthamr | ++ | 18:43 |
| sean-k-mooney | ah i was wonderign why that was doen that way for os-vif | 18:44 |
| sean-k-mooney | but that makes sense that the ownere dose not need to be a member | 18:44 |
| gmann | yeah, it is kept as owner only and not admin/member rights as explicitly. | 18:44 |
| fungi | mainly that's to keep the volume of e-mail notifications received by openstack-admins members to a minimum since we don't want to know about everything the per-project groups are subscribed to | 18:45 |
| fungi | but it also provides a useful audit trail in some cases | 18:45 |
| gmann | specially considering the admin/member activities member/bugs/BPs handling are done by project team only not the openstack admin | 18:45 |
| gouthamr | there's a number of groups on launchpad and its confusing :) i wonder if there was some material that original project owners used to share to maintain these | 18:46 |
| sean-k-mooney | ya. so the two followup items for watcher were 1 create a public bugs team so anyone can join and do triage, 2 create a watcher-coresec team and add the security liasion | 18:46 |
| sean-k-mooney | i dont fully recall the outcome of the PTG session but did we converge on "all offical service project, shoudl fall under teh VMT processs"? | 18:48 |
| gouthamr | ^ we did | 18:48 |
| JayF | should is an ugly word though | 18:48 |
| gouthamr | i'll write up that resolution | 18:48 |
| JayF | is there going to be more folks volunteering for VMT? | 18:48 |
| JayF | We only have 3 active openstackers, very busy people including me, in that group right now | 18:48 |
| fungi | i hope so, but by the same token i don't foresee it increasing the vmt's workload (and if project teams would maintain their coresec rosters and become more responsive, that would actually reduce the vmt's workload) | 18:49 |
| sean-k-mooney | im not sure, i guess have at least a secirty liason in the watcher case (dan smith) could help with a point of contact for potential issues | 18:49 |
| JayF | fungi: I don't just see it as a "more hands to do the work" problem, I also see it as a coverage problem | 18:50 |
| JayF | three people starts getting to a rough number when you think about holidays, vacations, etc | 18:50 |
| JayF | and I don't want anyone (e.g. you) missing out on something during time off because a security bug got filed :) | 18:51 |
| fungi | right now we end up effectively triaging every private security bug reported against any openstack project, but at least in some cases the vmt has been able to say "we can help on a best-effort basis, though officially we don't oversee this repo" | 18:51 |
| fungi | effectively all our work is best-effort though, so... | 18:51 |
| gmann | ++ | 18:52 |
| fungi | which is not to say that we don't need additional active participants on the vmt, but i think what we need even more is an increase in activity within many of the per-project coresec teams | 18:52 |
| fungi | and also that tc escalation path so we can have some help chasing down project representatives who aren't looking at those bugs | 18:53 |
| gmann | agree, if we do not have project specific members to look into the sec bugs then we are stuck there. I think that is the main problem to solve here | 18:53 |
| fungi | JayF: more vmt coverage would be great too yes, but also we don't provide any guarantee/sla currently (that could change with upcoming regulatory pressures, but it won't happen overnight and we can address those challenges as they come up) | 18:55 |
| gmann | adding VMT liaison as mandatory requirement for all existing as well as new projects is right first step but how well it will go to find the volunteer, we need to see. | 18:55 |
| JayF | fungi: Honestly, I struggle judging stuff like this by what we say we're responsible for vs what people's expectations might be. And I think folks would expect a pretty good turnaround on notification of a security bug for a project of our size. I guess that's what's on my mind. Tapping the sign that says we didn't promise anything doesn't help any reputational harm that could be gotten if we were slow. | 18:56 |
| JayF | One of those things where you're right; but I think we should strive further than the minimum, to put it another way | 18:56 |
| fungi | yes, but by the same token, tapping a sign that says "sure it's an openstack project but *technically* we're not responsible for handling the security bugs reported for it" doesn't help either | 18:58 |
| fungi | of the two options (status quo: we provide quicker turnaround for a subset of openstack, vs we provide maybe slower turnaround but for all of openstack) i think i'd slightly prefer the latter. either one could be improved with additional people though | 19:00 |
| fungi | and regardless, significant delays on handling those bugs are almost never due to vmt bandwidth (though sure things do fall through the cracks, it's much more often the case that we have to keep reminding project representatives over and over that there's a bug they haven't looked at yet) | 19:05 |
| JayF | fungi: good point re: us basically doing the same thing with scoping | 19:29 |
| *** bauzas_ is now known as bauzas | 22:15 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!