Friday, 2025-02-21

opendevreviewsuzhengwei proposed openstack/election master: Add Suzhengwei candidancy for Masakari PTL  https://review.opendev.org/c/openstack/election/+/94240801:13
opendevreviewOpenStack Proposal Bot proposed openstack/openstack-manuals master: Imported Translations from Zanata  https://review.opendev.org/c/openstack/openstack-manuals/+/94205004:09
cardoeSomething I notice a lot in the docs. Confusion around service accounts. e.g. https://docs.openstack.org/neutron/latest/install/controller-install-option2-ubuntu.html communications to neutron use that user while communicating to nova uses the nova account. Should we not really encourage each service to use its respective account?05:07
cardoeWith secure rbac being a goal it seems like something we should clarify05:12
opendevreviewMerged openstack/openstack-manuals master: Imported Translations from Zanata  https://review.opendev.org/c/openstack/openstack-manuals/+/94205007:35
opendevreviewOpenStack Proposal Bot proposed openstack/security-doc master: Updated from openstack-manuals  https://review.opendev.org/c/openstack/security-doc/+/94241807:44
fricklercardoe: yes, very much so. next step should be switching to app creds everywhere08:11
cardoeSo in the context of that doc I linked. The keystone_authtoken section would have a neutron user using an app credential? And the nova section would as well? But different ones?12:23
cardoefrickler: just want to be clear cause I do want to maybe make a doc for projects to understand how they should describe defaults. I still see current docs saying to create service accounts with admin role only12:24
fricklercardoe: the first step IMO would be just to switch to neutron.conf only using the neutron user, nova.conf only the nova user etc. adding or replacing by app creds would be a second step, which a) should be implemented/tested in devstack first and b) where I'm also not sure yet whether it will actually work for all services currently13:00
fricklerfor a) I did some initial things in https://review.opendev.org/c/openstack/devstack/+/923944 , but it needs more wotk. b) might need to become a community goal one day13:01
cardoefrickler: since we're ping ponging back and forth... I'd happily work with you on a goal like that cause I think it'd be good to get this cleaned up and more clear.13:22
cardoeI'm actually fighting some stuff in OpenStack Helm right now and its centered around the fact that services (like nova) use the auth creds of each thing (e.g. ironic, neutron, glance). But ownership (creation and password rotation) is from the actual service (e.g. neutron's deployment creates the neutron service user/pass). And I've felt like that's wrong but been pushed at the docs for most of the projects which show things 13:24
cardoethat way.13:24
fricklercardoe: I don't have much time to actually work on this right now, but I'd certainly support you updating docs by approving changes. we could also make this a community goal on its own. and password/creds rotation is exactly the use case is why I want to move to app creds in the long run, because currenty there is no way to do that without downtime13:29
cardoefrickler: Oh me too. But what would be helpful would be reviews and support, like +1ing proposals and review of the approach and +1 / support of it to the projects at large.14:08
fricklercardoe: that I can certainly do14:10
opendevreviewMerged openstack/security-doc master: Updated from openstack-manuals  https://review.opendev.org/c/openstack/security-doc/+/94241814:40
mnasiadkafrickler, cardoe: happy to help with this :)15:15
opendevreviewLajos Katona proposed openstack/openstack-manuals master: Add networking-odl to_RETIRED_REPOS  https://review.opendev.org/c/openstack/openstack-manuals/+/94247216:23
opendevreviewMerged openstack/openstack-manuals master: Add networking-ovn to _RETIRED_REPOS  https://review.opendev.org/c/openstack/openstack-manuals/+/94238018:16
opendevreviewMerged openstack/openstack-manuals master: Add networking-odl to_RETIRED_REPOS  https://review.opendev.org/c/openstack/openstack-manuals/+/94247218:21
fungii'm hoping to congratulate the winners of the current tc and ptl elections in next week's openinfra newsletter, assuming some announcement is made of the results. anybody have anything else they can think of we should highlight in this issue of the newsletter?20:24
gmannfungi: ++ on same topic, i would have highlights the leaderless projects (in RED) and call for users/org (using those projects) to come forward and help in maintaining code/leadership level.20:27
JayFIt might be wise to filter that list for projects that already have DPL waiting in the wings (Ironic) or projects that had a late PTL nomination. 20:29
JayFSince those teams don't need a leader to step up, and it will save some face20:30
gmannyeah, IMO ironic is not leaderless where we know its just change in leadership model20:30
fungiwhat was the final list of teams lacking a ptl candidate (minus ironic obviously)?20:31
gmanncurrent leaderless projects are: Barbican, Masakari, OpenStack_Charms, Oslo.  ( Zaqar -  late nomination, Ironic - change in ledership model only20:31
fungiokay, i can put in a call for ptl volunteers for the first four, and amend it closer to publication if more show up between now and then20:32
gmannI will put these in etherpad for quick ref and we should not include ironic there when we knew that it is just leadership model change and not that project is leaderless20:32
fricklerBarbican has a candidate also, just late in getting a fresh review merged20:32
gmannohk20:33
fungiokay, so Masakari, OpenStack_Charms and Oslo at this point20:33
gmanndouble checking if there is any late nomination for those20:33
fungiand i guess Oslo is on the list due to not having enough volunteers for the required dpl liaison positions?20:33
gmannyes20:34
gmannmasakari also have late nomination https://review.opendev.org/c/openstack/election/+/94240820:34
frickleractually for charms, maybe check with jamespage or other canonical people whether it might be close to getting retired in favor of sunbeam?20:34
fungihemanthn is already on for sunbeam, so probably worth checking with him on the plan for that yeah20:35
fungier, hemanth-n20:35
frickleror that, yes20:36
fungiso sounds like we have late volunteers for every team except those two which are both in special circumstances20:36
fricklerwhat volunteers were there for oslo? I think I missed that20:37
fungioslo is one of the two20:37
fungioslo (failed to meet dpl requirements) and charms (possibly supplanted by sunbeam or there's maybe a transition plan)20:38
gmannI am not finding where exactly but I remember damani[m] did mention about raising hand for PTL but no candidacy yet 20:39
fricklerthe difference being that oslo dearly needs contributors, in particular in view of the eventlet situation, while charms might be on a path to retirement anyway, although we don't know for sure yet20:39
frickleroh, another possible topic given the amount of people that use the matrix bridge, maybe mention https://matrix.org/blog/2025/02/crossroads/ ? both fungi and gouthamr for the TC newsletter20:41
fungioslo is and has always been openstack's "junk drawer" of assorted widgets, so it's hard to find one person with a strong interest in all the random things that have been dumped into it20:41
fungilike, there are some of us who contribute to pbr but don't touch anything else in oslo, and i'm sure other oslo deliverables are in a similar situation20:42
gmannmost of them yes20:43
fungifrickler: the matrix thing might make more sense going in the opendev section since it's not just openstack relying on it20:43
fungii'll mention it to clarkb20:43
gmanncreated the etherpad to discuss about the charms and olso or late candidacy projects https://etherpad.opendev.org/p/2025.2-leaderless20:53
gmanngouthamr: added this topic in meeting agenda also. 20:54
gouthamrthanks gmann21:10
cardoemnasiadka: awesome. I’ll ping you when we get started.23:42

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!