13:00:38 <bbezak> #startmeeting kolla
13:00:38 <opendevmeet> Meeting started Wed Jul 31 13:00:38 2024 UTC and is due to finish in 60 minutes.  The chair is bbezak. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:38 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:38 <opendevmeet> The meeting name has been set to 'kolla'
13:00:50 <bbezak> #topic rollcall
13:01:01 <SvenKieske> o/
13:01:07 <r-krcek> \o/
13:01:29 <mhiner> o/
13:02:20 <bbezak> not many of us, vacation period I guess ;)
13:02:22 <bbezak> #topic agenda
13:02:25 <mmalchuk> o/
13:02:27 <mattcrees> o/
13:02:29 <bbezak> * Roll-call
13:02:29 <bbezak> * Agenda
13:02:29 <bbezak> * Announcements
13:02:29 <bbezak> * Review action items from the last meeting
13:02:29 <bbezak> * CI status
13:02:30 <bbezak> * Release tasks
13:02:30 <bbezak> * Regular stable releases (first meeting in a month)
13:02:32 <bbezak> * Current cycle planning
13:02:32 <bbezak> * Additional agenda (from whiteboard)
13:02:34 <bbezak> * Open discussion
13:03:02 <bbezak> #topic CI status
13:03:39 <Fl1nt> Hi everyone
13:03:40 <bbezak> looks green
13:03:54 <Fl1nt> bbezak, The men I was looking for!
13:03:58 <bbezak> :)
13:04:18 <bbezak> we're on CI status topic btw :)
13:04:20 <SvenKieske> periodic pipeline looks not so green? https://bugs.launchpad.net/kolla-ansible/+bug/2075316
13:04:27 <SvenKieske> ah sorry, wrong link
13:04:32 <SvenKieske> https://zuul.openstack.org/builds?project=openstack%2Fkolla&pipeline=periodic&result=FAILURE&result=RETRY_LIMIT&result=POST_FAILURE&result=NODE_FAILURE&result=SKIPPED&skip=0
13:04:36 <Fl1nt> bbezak, just saw that np
13:04:41 <Fl1nt> I'll wait :D
13:05:30 <SvenKieske> periodic-weekly looks better
13:06:35 <SvenKieske> gateway timeout, probably infra related? https://zuul.openstack.org/build/9e07eb72ee3f44c3b00e13468bfe2e83 I still need to subscribe to the opendev infra ML. don't know if there was some expected outage
13:07:09 <bbezak> except arm64 it doesn't look bad
13:07:55 <Fl1nt> SvenKieske, OVH had a lot of trouble this week with various HW/Fiber incident.
13:08:09 <bbezak> last several days are ok
13:08:35 <bbezak> #topic Release tasks
13:09:00 <bbezak> we're r-9
13:09:04 <SvenKieske> Fl1nt: ah good to know
13:09:04 <bbezak> time flies ;)
13:09:48 <bbezak> not much to do now, next week there will be some tasks
13:09:55 <bbezak> #topic Regular stable releases
13:10:11 <bbezak> I've raised change to have a new minor releases
13:10:22 <bbezak> as we didn't do that for several months already
13:10:27 * frickler needs to review that one
13:10:36 <bbezak> https://review.opendev.org/c/openstack/releases/+/925182
13:10:39 <bbezak> yeap :)
13:11:13 <bbezak> #topic Current cycle planning
13:11:35 <bbezak> I was on vacation last couple of weeks, so I didn't progress much ;)
13:11:52 <bbezak> I'll check with darmach the ubuntu noble progress
13:12:06 <bbezak> oh, he is now. how is it doing darmach?
13:12:28 <bbezak> in any case, we need to finish that soon'ish
13:13:20 <bbezak> if you need anything around this cycle priorities, let us know - https://etherpad.opendev.org/p/KollaWhiteBoard#L227
13:14:53 <bbezak> #topic Additional agenda (from whiteboard)
13:14:55 <bbezak> https://etherpad.opendev.org/p/KollaWhiteBoard#L70
13:15:20 <bbezak> mhiner and r-krcek changes are there
13:16:14 <mhiner> yes, additionally on behalf of ihalomi and regarding failed tests in 908295:
13:16:27 <mhiner> Upgrade tests are failing because we use stable release for ansible-collection-kolla that doesn't include repository that contains docker 6.0.0 and during upgrade bootstrap-container role is called only once before first deploy, that means even we change later to correct ansible-collection-kolla it doesn't effect installed version of docker so test fails with cgroupns missing.
13:16:31 <SvenKieske> I +1 the question wrt to bandit from r-krcek as I still need to make myself more familiar with it. this is in the context of the kolla-ansible "binary" python rewrite.
13:16:42 <mhiner> My proposed solution is to cherrypick this commit to stable branch
13:16:42 <mhiner> https://github.com/openstack/ansible-collection-kolla/commit/42116ded107f99983ebdcb0c70e8a8c4cd6fdc52
13:17:18 <bbezak> so something that will be fixed when frickler will merge release change :)
13:17:44 <SvenKieske> ah right iahlomi asked me about that one a few days ago, I agree we need to fix the docker stuff
13:18:37 <SvenKieske> bbezak: mhm, wait, shouldn't we follow our own suggestions to the users and install from stable git branches instead of released artifacts? ;) (only half joking)
13:19:26 <bbezak> yeah, there is some inconsistency there
13:20:25 <bbezak> I'll look into the docker stuff mhiner - hopefully tomorrow
13:20:33 <mhiner> thanks
13:21:07 <bbezak> and to review some patches as well
13:22:11 <SvenKieske> good to know that was already fixed, I thought we had some error in our upgrade testing at first
13:23:06 <bbezak> ok, I'll book some time for those patches, let's move on
13:23:12 <bbezak> #topic Open discussion
13:23:48 <chembervint> Hi, may I up my patch and kindly ask to review it? https://review.opendev.org/c/openstack/kolla-ansible/+/920377.
13:24:16 <chembervint> and 1 more - it's already merged to master, but cherry-picks has stolen .. https://review.opendev.org/c/openstack/kolla-ansible/+/924322
13:24:38 <SvenKieske> well I hate to be "that guy", but I filed https://bugs.launchpad.net/kolla-ansible/+bug/2075316 because I think we are violating upstreams licence, I asked upstream if they can possibly relicence/dual-licence but I don't think our changes to their code are substantial, IANAL.
13:25:19 <SvenKieske> chembervint: I guess the backports will eventually be processed :)
13:26:06 <SvenKieske> the octavia stuff is annoying, I don't know if we can actually implement a better solution than what you proposed, but I guess mnasiadka is on vacation
13:26:15 <bbezak> yeah, will push those backports
13:26:36 <Fl1nt> bbezak, I really like the DON'T BE A DICK public license :D
13:26:52 <Fl1nt> Especially the share the love money :D
13:26:53 <bbezak> imho looks pretty permissive :)
13:26:57 <bbezak> just don't be a dick
13:27:00 <Fl1nt> yep
13:27:07 <chembervint> SvenKieske: ok, thank you! will wait mnasiadka
13:27:35 <SvenKieske> well, personally I think it's a "funny" licence (humor is subjective). professionally it's annoying because it's not OSI approved and I don't think we can just wrap it in ASL 2.0, so well, yeah.
13:28:22 <frickler> for octavia I still think configuring the interface statically is the better solution, just a bit more work
13:28:31 <Fl1nt> SvenKieske, I like introducing those license to my colleagues of the licensing department, they usually lol a lot and then send a simple: Approved because... Why not.
13:28:34 <SvenKieske> the TC guidelines are pretty clear on that, I also went around, there are multiple other jinja linters which are better maintained, maybe I can add one of those, but that would incur more overhead..
13:29:18 <SvenKieske> the original question why I looked at it came up in https://review.opendev.org/c/openstack/kolla-ansible/+/909912/comment/4108e5e2_ad15207a/
13:29:27 <chembervint> frickler: ok, but how to do it in a proper way? I've described my thoughts in a ticket. if you have some ideas - I'll be glad to try it
13:29:42 <SvenKieske> because I think we need to extend it, and we are also missing some commits from upstream which we might/might not want
13:29:57 <Fl1nt> Can't we use the one used by ansible?
13:31:31 <SvenKieske> afaik we already do and this is just an additional linter
13:31:31 <Fl1nt> Does this additional linter brings something special/desirable?
13:31:31 <SvenKieske> so we certainly use "ansible-lint". in python/ansible lint there is a ton of different linters with varying degrees of coverage..
13:31:31 <chembervint> frickler: I mean, first off all in any case it will be still a ovs port, so we have to wait OVS container is up and running, and handle it somehow in systemd. and then - we are support different linux distros with different network configuration staff
13:31:41 <SvenKieske> Fl1nt: I'm not certain; maybe I take some more minutes to investigate if we can just rip it out for good :)
13:32:03 <Fl1nt> Yeah, could be a much more simpler way to solve the issue :D
13:32:53 <SvenKieske> I guess the octavia discussion is more interesting/pressing and has more merit :)
13:33:32 <SvenKieske> so we would need a dedicated play I guess, which does the right thing with the ip config stuff depending on the distro (sounds like a thing ansible was basically invented for?)
13:33:54 <frickler> chembervint: maybe if you have so much trouble with ovs, you can use a vlan interface instead? anyway, yes, I was understating the effort when saying "a bit of work"
13:34:06 <SvenKieske> :D
13:34:13 <frickler> solving your questions would actually be part of that task
13:34:14 <Fl1nt> Octavia is an heavy used service, with very poor architectural design, we have deployed it on our clusters... I'm always having questions about it that I can't solve without having to extensively discuss with the Octavia guys.
13:34:57 <chembervint> One more question - one of our clients requires us to avoid storing passwords in plain-text in config files. We've tested oslo.config + Castellan stuff and already have a working prototype. And now working on non-openstack services as well. Could it be interesting to upstream such security stuff?
13:35:15 <Fl1nt> chembervint, yes, very much
13:35:53 <SvenKieske> chembervint: I think so, yes
13:36:00 <Fl1nt> I have a lot of our customers that are specifically asking us for such solution.
13:36:06 <frickler> I've started to look at using application credentials instead, but not sure whether the secret being used there still fits the same category
13:36:27 <Fl1nt> and end up implementing vault from hashicorp... which isn't really integrated.
13:36:59 <chembervint> Fl1nt: exactly. castellan + vault
13:37:01 <bbezak> castellan can also talk to hashi
13:37:03 <bbezak> yeap
13:37:08 <Fl1nt> yep
13:37:52 <SvenKieske> mhm, what do you guys think about castellan vs barbican, if it's not too off topic?
13:38:04 <Fl1nt> castellan is barbican :D
13:38:12 <Fl1nt> barbican leverage castellan lib
13:38:22 <chembervint> frickler: in the past we've used vlans, before it was automated in k-a to config tenant network for octavia :) but it a bit harder to automate in in common case ...
13:39:08 <mattcrees> Just to jump in for open discussion, we're getting close to rabbit being ready for slurp a->c. I'm looking for a second core review for merging this patch chain please: https://review.opendev.org/c/openstack/kolla/+/918974 then any reviews welcome here: https://review.opendev.org/c/openstack/kolla-ansible/+/918976
13:39:17 <chembervint> castellan in just a supported backend for oslo.config ... barbican also could use it as an option
13:40:04 <bbezak> we're using vlans via kayobe for octavia network - so automated there
13:41:01 <bbezak> thx mattcrees, we need second core outside of stackhpc kevko frickler please take a look
13:41:22 <Fl1nt> using vlans with Octavia really is the easiest way to go BUT it bring a bit of an issue as it add another L2 on infrastructure that doesn't really need that.
13:41:48 <Fl1nt> on the underlay I mean
13:42:02 <bbezak> yeah, unnecessary complexity, but vlans are cheap
13:42:18 <chembervint> bbezak: but in case of VLANs we are depends on L2 for computes aggregate for amphoras ...
13:42:27 <SvenKieske> well if you want to have a "pure" L3 network it might not work
13:43:51 <bbezak> chembervint: true, amphorae needs this vlan. additional vlan on physnet for vms indeed
13:43:57 <chembervint> I agree. l2 could be an option. but in common case we have to support "pure" l3
13:44:17 <bbezak> some people even can't mix those traffics
13:44:21 <bbezak> (security)
13:44:25 <bbezak> I meant fabrics
13:44:59 <Fl1nt> yep
13:45:20 <SvenKieske> soo..maybe not that simple? what deployment scenarios do we want to "support"/care about? ;)
13:45:31 <Fl1nt> and Octavia teams just keep repeating everyone  pure L3 is supported so it's a bit hard to fight in a meeting about that.
13:45:49 <SvenKieske> we could of course start with l2 vlan and add more stuff later, maybe.
13:47:01 <Fl1nt> yes, L2 scenario then L3 then mix ?
13:47:12 <chembervint> I suggest to start with merging my patch, which will fix current logic and current deployments ;) and continue to investigate on it
13:47:35 <Fl1nt> Of course
13:49:52 <bbezak> ok, let's continue outside of the meeting, thank you all!
13:49:55 <bbezak> #endmeeting