15:00:08 <gmann> #startmeeting tc
15:00:08 <opendevmeet> Meeting started Thu Aug 12 15:00:08 2021 UTC and is due to finish in 60 minutes.  The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:08 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:08 <opendevmeet> The meeting name has been set to 'tc'
15:00:11 <gmann> #topic Roll call
15:00:12 <mnaser> o/
15:00:13 <yoctozepto> o/
15:00:13 <gmann> o/
15:00:13 <ricolin> o/
15:00:18 <dansmith> cripes, it seems like this meeting happens every week!
15:00:21 <diablo_rojo> o/
15:00:29 <mnaser> who came up with the idea of doing this once a week
15:00:34 <mnaser> :)
15:00:41 <gmann> dansmith: :)
15:00:43 <ricolin> mnaser, nice session in openinfra live
15:00:50 <gmann> mnaser: :P
15:00:50 <mnaser> thanks ricolin :)
15:01:05 <gmann> Jay Bryant (jungleboyj) -- Out on PTO
15:01:07 <gmann> Belmiro Moreira (belmoreira) -- Out on PT
15:01:17 <gmann> let's start
15:01:28 <gmann> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions
15:01:31 <gmann> today agenda ^^
15:01:42 <gmann> #topic Follow up on past action items
15:01:48 <gmann> no action item from previous meeting
15:02:01 <gmann> #topic Required things/steps to push Project Skyline(dashboard) proposal (diablo_rojo)
15:02:13 <gmann> i changed the topic for this item.
15:02:37 <spotz_> o/
15:02:38 <gmann> diablo_rojo: sent it on ML also #link http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024088.html
15:02:56 <gmann> so this is kind of pre-step for project proposal
15:03:21 <diablo_rojo> Yep. No updates here just wanted to see if there way anything else we needed them to do before proposing them.
15:03:32 <diablo_rojo> They are working on zuul + devstack stuff
15:03:42 <mnaser> heh, we've been writing a dashboard for a while now after trying to change horizon
15:03:42 <gmann> +1
15:03:46 <diablo_rojo> Which I think should put them in a good place to draft the proposal
15:04:23 <mnaser> we're pretty far down the line in this but it'd be interesting to see what its like
15:05:01 <gmann> pinged horizon team members also on this and are discussing in their meeting too at least after proposal they will input their feedback or so
15:05:33 <mnaser> im glad this is moving
15:05:34 <gmann> yeah, dashboard plugins are my one of the concern.
15:05:50 <mnaser> i think it's time to just.. build new ones
15:05:58 <gmann> humm
15:06:11 <mnaser> i think horizon is pretty far behind that it's better to not stick to the older stuff
15:06:11 <mnaser> imho
15:06:30 <diablo_rojo> Agreed.
15:06:52 <diablo_rojo> Anywho, that's all I had on this topic if there are no other major things they need to do before being proposed.
15:06:53 <gmann> building new one need a lot of effort at least on dashbaord and all project plugins
15:07:05 <fungi> the "horizon's team can't manage all these plugins, the individual projects will have to do it" model we eventually wound up with was also ultimately down to horizon maintenance bandwidth (or lack thereof) so might be worth revisiting
15:07:23 <gmann> diablo_rojo: yeah, i think we are good on pre-proposal things
15:07:41 <spotz_> +1
15:07:42 <fungi> also the new dashboard doesn't need immediate feature parity with horizon, and could probably even be deployed side-by-side with it
15:07:44 <gmann> anyways let's wait for proposal.
15:08:33 <gmann> should we continue this in agenda or add it when we see proposal and after some discussion on ML?
15:08:47 <mnaser> i should probably share what we've built here so far at vexxhost :\
15:08:54 <mnaser> but some of it is pretty opiniated
15:09:16 <mnaser> but it's kinda the same idea, no backend, talking straight to openstack api via cors, but we've got some vexxhost-specific thing like auth using openid connect, etc
15:09:21 <gmann> mnaser: on top of horizon as plugin or new dashbaord?
15:09:27 <gmann> k
15:09:29 <mnaser> nope, brand new reactjs based thing
15:09:34 <gmann> i see
15:09:56 <mnaser> (for those who have vexxhost accounts -- https://console.vexxhost.net -- but happy to see if people are interested in joining efforts)
15:10:18 <mnaser> it's just that my previous efforts at doing this upstream were met with 'but my packaging will be hard and impossible' so /shrug
15:11:39 <yoctozepto> mnaser: skyline has a backend
15:12:11 <yoctozepto> they have a proxying apiserver as far as I understand the docs
15:12:36 <yoctozepto> so I guess they process requests before sending them further
15:12:42 <yoctozepto> but I might be wrong here
15:12:46 <yoctozepto> diablo_rojo to the rescue :-)
15:13:12 <diablo_rojo> That matches my understanding but I havent dug into it much either
15:13:40 <yoctozepto> so it's 2:1; who gives more? :-)
15:13:53 <gmann> ok, let's wait for the details and some demo or so in proposal
15:14:23 <gmann> diablo_rojo: do you want to continue this topic in next week agenda or ok to add later when proposal is ready?
15:14:36 <yoctozepto> mnaser: I would prefer the approach you mention - calling APIs directly and having an openid integration builtin
15:14:36 <diablo_rojo> I think we can drop it for now
15:14:39 <diablo_rojo> and add it back later
15:14:47 <gmann> ok.
15:14:49 <dansmith> yeah, I would think having a required backend might put some people off
15:15:08 <gmann> #action gmann to drop skyline pre-check topic from agenda
15:15:10 <dansmith> if it's the only option, then that's the only option, but that makes it a little less of a drop-in replacement for folks I bet
15:15:45 <yoctozepto> diablo_rojo, mnaser: yup, they are reimplementing the API frontends: https://opendev.org/skyline/skyline-apiserver/src/branch/master/docs/api/swagger.json
15:15:54 <yoctozepto> love--
15:16:06 <yoctozepto> but likely still better than horizon (tm)
15:16:15 <fungi> horizon has a backend too though, no?
15:16:24 <yoctozepto> fungi: yes
15:16:32 <yoctozepto> the comparison was to vexxhost
15:16:36 <gmann> fungi: yes
15:16:36 <yoctozepto> 's
15:17:49 <gmann> anything else on this?
15:18:21 <gmann> #topic Wallaby testing runtime for centos8 vs centos8-stream
15:18:32 <gmann> this we discussed in last week meeting too
15:18:39 <yoctozepto> not this again (-:
15:18:51 <gmann> :) we can conclude today
15:19:02 <yoctozepto> ok, concluded :-)
15:19:43 <ykarel> From run time perspective both c8 and c8-stream are same, just delivered differently, not sure what's blocking switching to c8-stream?
15:19:43 <gmann> so my proposal was/is- 1. no update in defined wallaby testing runtime 2. devstack or any project can test centos8-stream in wallaby as extra thing. 3. no guarantee of testing in centos8 or centos8-stream in wallaby as per current situation in platofrm
15:20:14 <gmann> ykarel: in stable branch. master we switched
15:20:47 <ykarel> but considering run time same, c8-stream replacement for c8 why can't be changed in stable?
15:21:14 <gmann> for stable branch, it is extra effort. and usually we do not update the distro version on stable
15:21:41 <yoctozepto> I am pretty convinced it's an academic discussion and switching the stable to stream is possibly most pragmatic; as we have the migration code on master
15:21:49 <yoctozepto> I would put it on a simple vote
15:21:59 <yoctozepto> I am fine with whatever end result
15:22:09 <ykarel> i can help in adding the needed support in wallaby for c8-stream
15:22:11 <fungi> however, usually we also don't keep images around in opendev's ci system past eol, so once centos 8 reaches eol, the choice will be between dropping the jobs which use it, or switching them to run on centos 8 stream
15:23:01 <gmann> yeah and switching it back is always an extra effort not redefining the testing runtime
15:23:29 <gmann> and we are not saying do not test c8-stream in stable, we can do when someone push patches,
15:24:07 <gmann> I am just saying let's not redefine the testing runtime and as ykarel mentioned he can help in adding testing in wallaby so no blocking for that
15:24:09 <yoctozepto> may we just add clarifications to those docs?
15:24:18 <yoctozepto> saying that was the chosen platform
15:24:34 <yoctozepto> but it's going eol so the community accepts stream as a sane alternative?
15:25:03 <yoctozepto> then we aren't changing the original runtime definition
15:25:09 <gmann> sure but we do not need to explicitly tell that as testing runtime is min testing thing and anyone can do any platform testing at any extend
15:25:36 <yoctozepto> ok, then we can do nothing from TC side and be happy; and on QA side promise to merge support for stream
15:25:41 <fungi> might be worth revisiting what we actually mean by "tested runtime" (because we went out of our way to not imply that those are necessarily the only platforms openstack works on)
15:26:02 <gmann> yoctozepto: yes, ok for me
15:26:09 <yoctozepto> fungi: good point; also, for most purposes, ubuntu is tested more
15:26:19 <yoctozepto> so it might give a wrong impression at first
15:26:25 <fungi> we tested wallaby on centos 8, but after it was discontinued we switched to testing further wallaby patches on centos 8 stream, it's a fairly straightforward message
15:26:44 <ykarel> yes correct
15:27:10 <yoctozepto> fungi: yeah, that was my point
15:27:22 <yoctozepto> but we can treat it as historical info and not update as well
15:27:25 <yoctozepto> whatever :-)
15:27:30 <fungi> saying "this is what we tested/are testing on" isn't the same as saying "this is what you can/can't deploy on" it's just a statement of fact
15:27:30 <gmann> yeah
15:27:54 <yoctozepto> so
15:27:56 <yoctozepto> tc-members
15:28:00 <yoctozepto> more voices please
15:28:07 <gmann> ykarel:  we can continue on your fix backprot to wallaby and with c8-stream and drop 8 job
15:28:19 <yoctozepto> your chairs prefer less paperwork ;p
15:28:22 <ykarel> gmann, ack
15:28:39 <gmann> yoctozepto: that is on qa thing to progress :)
15:29:00 <mnaser> yoctozepto I wanted to leave all the fun for you.
15:29:02 <gmann> for TC thing, anyone can object here for 'not updating the testing runtime'
15:29:26 <spotz_> I’m for whatever is easiest but know we’re going to need to switch to stream at some point
15:29:33 <mnaser> I think it’s two distinct things: I agree with retroactively adding c8 stream and putting a note
15:29:35 <gmann> and if triplo or other CI want to do c8-stream on wallaby it is all good.
15:30:21 <mnaser> realistically though I think there’s a whole conversation to be had about the tested operating systems
15:30:57 <mnaser> and what it really means for the user especially if most users are getting openstack through a deployment tool
15:31:09 <fungi> (which was a watered down replacement for what we used to refer to as "supported" distros)
15:31:11 <yoctozepto> agreed, most projects don't test on centos anyhow
15:31:41 <yoctozepto> deployment projects actually do
15:32:01 <fungi> and people using rhel/centos are likely to use a packaged distribution (rdo)
15:32:07 <mnaser> exactly, so maybe it makes sense to let deployment projects use a similar document
15:32:10 <gmann> yeah. and my earlier question was 'how existing production deployment on c8s going to work after c8 eol' move to c8-stream as old thing stop working?
15:32:11 <fungi> which isn't explicitly what we're testing
15:32:32 <yoctozepto> honestly, the only "mandatory testing" is happening on ubuntu
15:32:50 <mnaser> gmann: right, that is going to depend on the openstack distro you use imho
15:32:50 <fungi> remember the goals of our multi-platform testing, to attempt to avoid breaking the software for the deployment tools and downstream distributions targeting those platforms
15:32:53 <yoctozepto> and it's what we are trying to keep green at all costs
15:32:55 <gmann> yoctozepto: true as we so not test distro but openstack code more or less
15:33:00 <gmann> so/do
15:33:34 <mnaser> in theory i think maybe this should be a project-level thing, and focus on the applicationsneeded in the platform
15:33:43 <mnaser> i.e. something nova already does "We require libvirt 4.5.0 or above"
15:34:09 <mnaser> how you get libvirt 4.5.0 through your distro or built from source or whatever is.. your problem
15:34:13 <yoctozepto> mnaser: yeah, nova is probably the most distro-dependent project due to high reliance on libvirt
15:34:28 <mnaser> yep, vs things like magnum that are pure api services that never interact with the OS
15:34:31 <mnaser> they can run anywhere
15:34:39 <mnaser> or even stronger example is keystone
15:34:43 <yoctozepto> yeah
15:34:48 <mnaser> maybe this could be a pretty good ptg discussion topic
15:34:56 <fungi> the challenge which comes from project-specific testing choices however is that openstack has a lot of its own interdependencies, and nova testing on a platform which oslo.config can't work on isn't going to go anywhere
15:35:01 <yoctozepto> ironic depends on the distro but more on the agent side than the ironic api/conductor
15:35:14 <mnaser> but for the meantime, add a note that centos 8 stream instead of centos 8 and we can follow this up as a ptg discussion
15:35:32 <gmann> ykarel: yoctozepto for devstack, we need to put it on ML also for other project centos devstack-based job to tell devstack wallaby can not support c8 either remove c8 job or move to c8-stream
15:35:54 <fungi> similarly, oslo and neutron disagreeing on which operating systems they'll work on to the point where there is no intersection wouldn't be good for anyone
15:36:02 <fungi> or nova and neutron, i mean
15:36:12 <mnaser> i don't want to tell folks to do work but at the very least we should get running c8-stream jobs going if we're going to update the tc doc
15:36:23 <gmann> mnaser: good idea. let's discuss it in PTG as it might be more old stable also face similar issue what wallaby is facing (when c8 is completely eol)
15:36:26 <mnaser> unless we consider tripleo as enough of a signal to prove that it works
15:36:27 <ykarel> gmann, ack
15:36:44 <mnaser> (but even then, tripleo runs things in containers, so is it even really using the base os... :P)
15:37:33 <dansmith> there are lots of ties to the base kernel and other libs
15:37:35 <fungi> and deploys packages from rdo
15:37:38 <dansmith> lots of stuff gets passed through
15:38:00 <dansmith> lots more than ... you might think :)
15:38:18 <yoctozepto> yeah, but we are discussing about the message here
15:38:34 <mnaser> probably, don't know much about tripleo's containers but yeah
15:38:38 <dansmith> I was addressing mnaser's comment about "does the base even matter" :)
15:38:40 <yoctozepto> the fact that we are saying "centos 8 is tested" does not mean that everything gets tested on it
15:38:46 <fungi> swift is particular about which filesystem driver modules you load, for another example
15:38:57 <mnaser> really if devstack jobs aren't running passing centos 8 stream jobs, then we need to decide if tripleo is enough of a signal to say "it works"
15:39:08 <gmann> ykarel:  yoctozepto: can you add it in PTG etherpad to discuss there and after that we can update TC doc #link https://etherpad.opendev.org/p/tc-yoga-ptg
15:39:11 <gmann> yeah
15:39:36 <yoctozepto> I'll leave it to ykarel to own the discussion :-)
15:39:54 <ykarel> sure will add
15:39:58 <gmann> thanks
15:40:00 <gmann> #action ykarel to add centos8 vs centos8-stream testing for old stable in PTG etherpad
15:40:26 <gmann> moving next, if nothing more on this ?
15:40:50 <gmann> #topic Murano project health (gmann)
15:41:05 <gmann> murano seems not active now a days (in Xena)
15:41:05 <gmann> No code change in Xena cycle last patch merged 4 months ago: https://review.opendev.org/c/openstack/murano/+/783446
15:41:14 <gmann> gmann tried to reach out to PTL via direct email but no response
15:41:42 <gmann> i checked in release team also and past release in wallaby or so were without PTL ack
15:41:55 <mnaser> seems like some things are still being contributed though
15:42:13 <gmann> and in Xena cycle it is clear that no functional code change happening and CI/CD, goal patches are not being reviewed
15:42:36 <gmann> #link https://review.opendev.org/q/project:openstack%252Fmurano
15:42:55 <gmann> mnaser: except CI/CD, goal patches ?
15:43:24 <mnaser> unit test fix patches give me a vibe that 'someone is writing something for this that had to run tests which broke' :p
15:43:54 <yoctozepto> in kolla, folks tend to report that murano is not too usable, to say it politely
15:44:03 <gmann> the only patch merged in Xena is bot patch for unit test update
15:44:03 <yoctozepto> anyone from TC actually using murano?
15:44:36 <mnaser> personally
15:44:37 <spotz_> Not I
15:44:47 <mnaser> i think murano is a bit past it's time with what we have nowadays
15:45:17 <mnaser> (k8s, container world, etc)
15:45:18 <fungi> we've been having trouble finding reviewers to approve basic infrastructure fixes, and are contending with needing to bypass their review team to do that for them
15:45:38 <gmann> yeah
15:46:18 <spotz_> Should we maybe check the User Survey and see if anyone said they use it?
15:46:24 <yoctozepto> mnaser: I share your perspective
15:46:52 <mnaser> i'd argue that seeing the pace of patches coming in says a whole lot about the # of users
15:47:05 <yoctozepto> spotz_: I know some folks tried with kolla but with humble success (-:
15:47:13 <mnaser> no bug fixes in the past few years in the murano-agent
15:47:30 <mnaser> and i kinda doubt that it hasn't immensely bitrotted
15:48:06 <yoctozepto> I think it did
15:48:18 <yoctozepto> https://www.openstack.org/analytics
15:48:20 <mnaser> this is the most recent 'actual bugfix' change - https://opendev.org/openstack/murano-agent/commit/6ea51f46786f4c407b6c356bb805328349bc2c04
15:48:25 <yoctozepto> less adoption than Masakari
15:48:36 <mnaser> and thats.... C# code?!
15:48:57 <yoctozepto> mnaser: yeah, I just got heart attack :-)
15:49:08 <fungi> we also retired the community app catalog service in 2017
15:49:15 <mnaser> so most recent fix was 4 years ago by some mirantis folks (which i think were big drivers of murano)
15:49:21 <fungi> which met similar use cases
15:49:23 <mnaser> and i dont think they are too focused about it
15:49:31 <yoctozepto> mnaser: that's only contrib/ so hardly a fix
15:49:57 <mnaser> https://opendev.org/openstack/murano-agent/commit/2468fb59395e04f5f06ab14e64834a4c1ae46984 there, here's a nactual bug fix
15:50:05 <mnaser> not to go about this for too long, i think murano should be retired
15:50:11 <yoctozepto> ++
15:50:19 <gmann> yeah, i feel the same.
15:50:35 <mnaser> and i think as a community we should suggest using something like magnum to get a k8s cluster and deploy all your workloads with helm or whatever
15:50:38 <gmann> and we should decide it before m-3 so that release team and other Xena work can be saved
15:50:44 <yoctozepto> mnaser: ++
15:51:02 <yoctozepto> gmann: ++
15:51:13 <yoctozepto> what is the procedure? voting first?
15:51:24 <yoctozepto> gmann to the rescue :-)
15:51:30 <gmann> we will put it on ML first before voting
15:51:30 <spotz_> Hehe
15:52:03 <yoctozepto> ok
15:52:13 <gmann> if no objection from anyone, let's propose it to retire on ML and then we move to next step
15:52:14 <fungi> or openstack-charms
15:52:22 <fungi> which fills similar use cases
15:52:38 <yoctozepto> fungi: they deploy openstack with juju
15:52:51 <yoctozepto> but yeah, charms for juju exist for many more apps
15:53:00 <fungi> rather, juju charms i suppose (openstack-charms is specifically for deploying openstack, yeah)
15:53:01 <yoctozepto> and likely more reliable than murano tbh ;-)
15:53:13 <mnaser> seems liek we've got an action item for this
15:53:23 <gmann> yeah
15:53:24 <yoctozepto> who's the driver?
15:53:38 <gmann> yeah about to ask, who will volunteer for this?
15:53:45 <yoctozepto> gmann proposed the topic, gmann wants to continue?
15:53:52 <mnaser> i can send an ML thingamajig shortly
15:53:53 <gmann> sure i can.
15:53:56 <yoctozepto> ah, looking for volunteers
15:54:09 <yoctozepto> ok, mnaser volunteered first
15:54:16 <gmann> mnaser: +1. I can help on next
15:54:43 <gmann> #action mnaser to send the murano retirement proposal n openstack-discuss ML
15:54:56 <gmann> thanks mnaser
15:55:09 <yoctozepto> ++
15:55:18 <gmann> #topic PTG Planning
15:55:21 <gmann> #link https://etherpad.opendev.org/p/tc-yoga-ptg
15:55:39 <gmann> it just a reminder to keep adding topic in etherpad for PTG discussion
15:56:02 <gmann> or anyone has anything for PTG, feel free to bring it now
15:56:48 <gmann> #topic Open Reviews
15:56:50 <gmann> #link https://review.opendev.org/c/openstack/governance/+/803783
15:57:06 <gmann> I am proposing to select RBAC goal for Yoga, you can vote there
15:57:29 <mnaser> fwiw
15:57:33 <mnaser> not an open review but
15:57:48 <mnaser> how would y'all feel about a video/voice call for weekly meetings?
15:58:19 <TheJulia> notes would be need to be created and distributed, fwiw
15:58:31 <mnaser> some of the other communities i've seen do this
15:58:33 <mnaser> will actually #startmeeting
15:58:38 <mnaser> and then #info #link etc throughout it
15:58:40 <TheJulia> or at least kept in maybe a shared collaborative document
15:58:46 <TheJulia> that too
15:59:00 <mnaser> and then you end up with meeting notes with all the action items, info, points brought up by specific folks, etc
15:59:04 <gmann> +1, i am ok, much easer than typing :)
15:59:26 <spotz_> We do it once a month for RDO, notes aren’t the best but we try
15:59:32 <gmann> and in TC weekly summary we anyways summarize the key things and frm meeting too
15:59:33 <fungi> i fnid typing much easier than talking, but i'm not currently on the tc anyway
15:59:45 <fungi> (typo for effect)
15:59:50 <yoctozepto> lol
15:59:52 <mnaser> :P
16:00:01 <gmann> fungi: I am finding difficult time in typing especially when hosting :)
16:00:03 <mnaser> id like for us to give it a shot at least and see hwo we feel 'bout it
16:00:15 <yoctozepto> I would welcome having alternating weeks with text and voice
16:00:29 <gmann> and can we store the recording in meeting log like irc ?
16:00:32 <yoctozepto> gmann: yeah, we would need a scribe
16:00:40 <fungi> it would have the effect of me only following along in irc though, since i already have two other meetings i attend at the same time, one of which is also a videoconference call
16:00:55 <mnaser> gmann: maybe we can put the link at the end with the recording/whatever, and then the meeting notes will have everything
16:01:29 <mnaser> here is an example ofa nother community i've seen that does this
16:01:30 <mnaser> https://ircbot.wl.linuxfoundation.org/meetings/fdio-meeting/2021/fd_io_csit_project_meeting/fdio-meeting-fd_io_csit_project_meeting.2021-08-11-14.02.log.html
16:02:20 <yoctozepto> let's wrap up for today
16:02:23 <gmann> yeah,
16:02:37 <gmann> anyways let's continue on meetng thing in next meeting
16:02:43 <yoctozepto> ++
16:02:44 <mnaser> cool
16:02:46 <gmann> mnaser: I will add topic in next meeitng
16:02:50 <gmann> thanks
16:03:10 <gmann> thanks all for joining.
16:03:12 <mnaser> no problem
16:03:15 <spotz_> Thanks for leading granny!
16:03:16 <gmann> #endmeeting