Thursday, 2021-08-12

*** ykarel|away is now known as ykarel04:57
*** akekane_ is now known as abhishekk06:03
*** rpittau|afk is now known as rpittau06:22
*** ykarel is now known as ykarel|lunch08:27
*** akekane_ is now known as abhishekk09:08
*** ykarel|lunch is now known as ykarel09:46
*** diablo_rojo__ is now known as diablo_rojo14:54
gmanntc-members: meeting time.  15:00
mnasero/15:00
gmann#startmeeting tc 15:00
opendevmeetMeeting 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:00
opendevmeetThe meeting name has been set to 'tc'15:00
gmann#topic Roll call15:00
mnasero/15:00
yoctozeptoo/15:00
gmanno/15:00
ricolino/15:00
dansmithcripes, it seems like this meeting happens every week!15:00
diablo_rojoo/15:00
mnaserwho came up with the idea of doing this once a week15:00
mnaser:)15:00
gmanndansmith: :)15:00
ricolinmnaser, nice session in openinfra live15:00
gmannmnaser: :P15:00
mnaserthanks ricolin :)15:00
gmannJay Bryant (jungleboyj) -- Out on PTO15:01
gmannBelmiro Moreira (belmoreira) -- Out on PT15:01
gmannlet's start15:01
gmann#link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions15:01
gmanntoday agenda ^^15:01
gmann#topic Follow up on past action items15:01
gmannno action item from previous meeting 15:01
gmann#topic Required things/steps to push Project Skyline(dashboard) proposal (diablo_rojo)15:02
gmanni changed the topic for this item. 15:02
spotz_o/15:02
gmanndiablo_rojo: sent it on ML also #link http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024088.html15:02
gmannso this is kind of pre-step for project proposal 15:02
diablo_rojoYep. No updates here just wanted to see if there way anything else we needed them to do before proposing them. 15:03
diablo_rojoThey are working on zuul + devstack stuff15:03
mnaserheh, we've been writing a dashboard for a while now after trying to change horizon15:03
gmann+115:03
diablo_rojoWhich I think should put them in a good place to draft the proposal15:03
mnaserwe're pretty far down the line in this but it'd be interesting to see what its like15:04
gmannpinged horizon team members also on this and are discussing in their meeting too at least after proposal they will input their feedback or so15:05
mnaserim glad this is moving15:05
gmannyeah, dashboard plugins are my one of the concern. 15:05
mnaseri think it's time to just.. build new ones15:05
gmannhumm15:05
mnaseri think horizon is pretty far behind that it's better to not stick to the older stuff15:06
mnaserimho15:06
diablo_rojoAgreed. 15:06
diablo_rojoAnywho, that's all I had on this topic if there are no other major things they need to do before being proposed. 15:06
gmannbuilding new one need a lot of effort at least on dashbaord and all project plugins 15:06
fungithe "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 revisiting15:07
gmanndiablo_rojo: yeah, i think we are good on pre-proposal things15:07
spotz_+115:07
fungialso the new dashboard doesn't need immediate feature parity with horizon, and could probably even be deployed side-by-side with it15:07
gmannanyways let's wait for proposal.15:07
gmannshould we continue this in agenda or add it when we see proposal and after some discussion on ML?15:08
mnaseri should probably share what we've built here so far at vexxhost :\15:08
mnaserbut some of it is pretty opiniated15:08
mnaserbut 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, etc15:09
gmannmnaser: on top of horizon as plugin or new dashbaord?15:09
gmannk15:09
mnasernope, brand new reactjs based thing15:09
gmanni see15:09
mnaser(for those who have vexxhost accounts -- https://console.vexxhost.net -- but happy to see if people are interested in joining efforts)15:09
mnaserit's just that my previous efforts at doing this upstream were met with 'but my packaging will be hard and impossible' so /shrug15:10
yoctozeptomnaser: skyline has a backend15:11
yoctozeptothey have a proxying apiserver as far as I understand the docs15:12
yoctozeptoso I guess they process requests before sending them further15:12
yoctozeptobut I might be wrong here15:12
yoctozeptodiablo_rojo to the rescue :-)15:12
diablo_rojoThat matches my understanding but I havent dug into it much either15:13
yoctozeptoso it's 2:1; who gives more? :-)15:13
gmannok, let's wait for the details and some demo or so in proposal15:13
gmanndiablo_rojo: do you want to continue this topic in next week agenda or ok to add later when proposal is ready?15:14
yoctozeptomnaser: I would prefer the approach you mention - calling APIs directly and having an openid integration builtin15:14
diablo_rojoI think we can drop it for now15:14
diablo_rojoand add it back later15:14
gmannok.15:14
dansmithyeah, I would think having a required backend might put some people off15:14
gmann#action gmann to drop skyline pre-check topic from agenda15:15
dansmithif 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 bet15:15
yoctozeptodiablo_rojo, mnaser: yup, they are reimplementing the API frontends: https://opendev.org/skyline/skyline-apiserver/src/branch/master/docs/api/swagger.json15:15
yoctozeptolove--15:15
yoctozeptobut likely still better than horizon (tm)15:16
fungihorizon has a backend too though, no?15:16
yoctozeptofungi: yes15:16
yoctozeptothe comparison was to vexxhost15:16
gmannfungi: yes15:16
yoctozepto's15:16
gmannanything else on this? 15:17
gmann#topic Wallaby testing runtime for centos8 vs centos8-stream15:18
gmannthis we discussed in last week meeting too15:18
yoctozeptonot this again (-:15:18
gmann:) we can conclude today15:18
yoctozeptook, concluded :-)15:19
ykarelFrom run time perspective both c8 and c8-stream are same, just delivered differently, not sure what's blocking switching to c8-stream?15:19
gmannso 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 platofrm15:19
gmannykarel: in stable branch. master we switched 15:20
ykarelbut considering run time same, c8-stream replacement for c8 why can't be changed in stable?15:20
gmannfor stable branch, it is extra effort. and usually we do not update the distro version on stable15:21
yoctozeptoI 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 master15:21
yoctozeptoI would put it on a simple vote15:21
yoctozeptoI am fine with whatever end result15:21
ykareli can help in adding the needed support in wallaby for c8-stream15:22
fungihowever, 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 stream15:22
gmannyeah and switching it back is always an extra effort not redefining the testing runtime 15:23
gmannand we are not saying do not test c8-stream in stable, we can do when someone push patches, 15:23
gmannI 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 that15:24
yoctozeptomay we just add clarifications to those docs?15:24
yoctozeptosaying that was the chosen platform15:24
yoctozeptobut it's going eol so the community accepts stream as a sane alternative?15:24
yoctozeptothen we aren't changing the original runtime definition15:25
gmannsure 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
yoctozeptook, then we can do nothing from TC side and be happy; and on QA side promise to merge support for stream15:25
fungimight 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:25
gmannyoctozepto: yes, ok for me15:26
yoctozeptofungi: good point; also, for most purposes, ubuntu is tested more15:26
yoctozeptoso it might give a wrong impression at first15:26
fungiwe 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 message15:26
ykarelyes correct15:26
yoctozeptofungi: yeah, that was my point15:27
yoctozeptobut we can treat it as historical info and not update as well15:27
yoctozeptowhatever :-)15:27
fungisaying "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 fact15:27
gmannyeah15:27
yoctozeptoso15:27
yoctozeptotc-members15:27
yoctozeptomore voices please15:28
gmannykarel:  we can continue on your fix backprot to wallaby and with c8-stream and drop 8 job15:28
yoctozeptoyour chairs prefer less paperwork ;p15:28
ykarelgmann, ack15:28
gmannyoctozepto: that is on qa thing to progress :)15:28
mnaseryoctozepto I wanted to leave all the fun for you.15:29
gmannfor TC thing, anyone can object here for 'not updating the testing runtime'15:29
spotz_I’m for whatever is easiest but know we’re going to need to switch to stream at some point15:29
mnaserI think it’s two distinct things: I agree with retroactively adding c8 stream and putting a note15:29
gmannand if triplo or other CI want to do c8-stream on wallaby it is all good. 15:29
mnaserrealistically though I think there’s a whole conversation to be had about the tested operating systems15:30
mnaserand what it really means for the user especially if most users are getting openstack through a deployment tool15:30
fungi(which was a watered down replacement for what we used to refer to as "supported" distros)15:31
yoctozeptoagreed, most projects don't test on centos anyhow15:31
*** rpittau is now known as rpittau|afk15:31
yoctozeptodeployment projects actually do15:31
fungiand people using rhel/centos are likely to use a packaged distribution (rdo)15:32
mnaserexactly, so maybe it makes sense to let deployment projects use a similar document15:32
gmannyeah. 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
fungiwhich isn't explicitly what we're testing15:32
yoctozeptohonestly, the only "mandatory testing" is happening on ubuntu15:32
mnasergmann: right, that is going to depend on the openstack distro you use imho15:32
fungiremember the goals of our multi-platform testing, to attempt to avoid breaking the software for the deployment tools and downstream distributions targeting those platforms15:32
yoctozeptoand it's what we are trying to keep green at all costs15:32
gmannyoctozepto: true as we so not test distro but openstack code more or less15:32
gmannso/do15:33
mnaserin theory i think maybe this should be a project-level thing, and focus on the applicationsneeded in the platform15:33
mnaseri.e. something nova already does "We require libvirt 4.5.0 or above"15:33
mnaserhow you get libvirt 4.5.0 through your distro or built from source or whatever is.. your problem15:34
yoctozeptomnaser: yeah, nova is probably the most distro-dependent project due to high reliance on libvirt15:34
mnaseryep, vs things like magnum that are pure api services that never interact with the OS15:34
mnaserthey can run anywhere15:34
mnaseror even stronger example is keystone15:34
yoctozeptoyeah15:34
mnasermaybe this could be a pretty good ptg discussion topic15:34
fungithe 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 anywhere15:34
yoctozeptoironic depends on the distro but more on the agent side than the ironic api/conductor15:35
mnaserbut for the meantime, add a note that centos 8 stream instead of centos 8 and we can follow this up as a ptg discussion15:35
gmannykarel: 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-stream15:35
fungisimilarly, 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 anyone15:35
fungior nova and neutron, i mean15:36
mnaseri 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 doc15:36
gmannmnaser: 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
mnaserunless we consider tripleo as enough of a signal to prove that it works15:36
ykarelgmann, ack15:36
mnaser(but even then, tripleo runs things in containers, so is it even really using the base os... :P)15:36
dansmiththere are lots of ties to the base kernel and other libs15:37
fungiand deploys packages from rdo15:37
dansmithlots of stuff gets passed through15:37
dansmithlots more than ... you might think :)15:38
yoctozeptoyeah, but we are discussing about the message here15:38
mnaserprobably, don't know much about tripleo's containers but yeah15:38
dansmithI was addressing mnaser's comment about "does the base even matter" :)15:38
yoctozeptothe fact that we are saying "centos 8 is tested" does not mean that everything gets tested on it15:38
fungiswift is particular about which filesystem driver modules you load, for another example15:38
mnaserreally 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:38
gmannykarel:  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
gmannyeah15:39
yoctozeptoI'll leave it to ykarel to own the discussion :-)15:39
ykarelsure will add15:39
gmannthanks 15:39
gmann#action ykarel to add centos8 vs centos8-stream testing for old stable in PTG etherpad    15:40
gmannmoving next, if nothing more on this ?15:40
gmann#topic Murano project health (gmann)15:40
gmannmurano seems not active now a days (in Xena)15:41
gmannNo code change in Xena cycle last patch merged 4 months ago: https://review.opendev.org/c/openstack/murano/+/78344615:41
gmanngmann tried to reach out to PTL via direct email but no response15:41
gmanni checked in release team also and past release in wallaby or so were without PTL ack15:41
mnaserseems like some things are still being contributed though15:41
gmannand in Xena cycle it is clear that no functional code change happening and CI/CD, goal patches are not being reviewed 15:42
gmann#link https://review.opendev.org/q/project:openstack%252Fmurano15:42
gmannmnaser: except CI/CD, goal patches ?15:42
mnaserunit test fix patches give me a vibe that 'someone is writing something for this that had to run tests which broke' :p15:43
yoctozeptoin kolla, folks tend to report that murano is not too usable, to say it politely15:43
gmannthe only patch merged in Xena is bot patch for unit test update15:44
yoctozeptoanyone from TC actually using murano?15:44
mnaserpersonally15:44
spotz_       Not I 15:44
mnaseri think murano is a bit past it's time with what we have nowadays15:44
mnaser(k8s, container world, etc)15:45
fungiwe'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 them15:45
gmannyeah15:45
spotz_Should we maybe check the User Survey and see if anyone said they use it?15:46
yoctozeptomnaser: I share your perspective15:46
mnaseri'd argue that seeing the pace of patches coming in says a whole lot about the # of users15:46
yoctozeptospotz_: I know some folks tried with kolla but with humble success (-:15:47
mnaserno bug fixes in the past few years in the murano-agent15:47
mnaserand i kinda doubt that it hasn't immensely bitrotted15:47
yoctozeptoI think it did15:48
yoctozeptohttps://www.openstack.org/analytics15:48
mnaserthis is the most recent 'actual bugfix' change - https://opendev.org/openstack/murano-agent/commit/6ea51f46786f4c407b6c356bb805328349bc2c0415:48
yoctozeptoless adoption than Masakari15:48
mnaserand thats.... C# code?!15:48
yoctozeptomnaser: yeah, I just got heart attack :-)15:48
fungiwe also retired the community app catalog service in 201715:49
mnaserso most recent fix was 4 years ago by some mirantis folks (which i think were big drivers of murano)15:49
fungiwhich met similar use cases15:49
mnaserand i dont think they are too focused about it15:49
yoctozeptomnaser: that's only contrib/ so hardly a fix15:49
mnaserhttps://opendev.org/openstack/murano-agent/commit/2468fb59395e04f5f06ab14e64834a4c1ae46984 there, here's a nactual bug fix15:49
mnasernot to go about this for too long, i think murano should be retired15:50
yoctozepto++15:50
gmannyeah, i feel the same.15:50
mnaserand 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 whatever15:50
gmannand we should decide it before m-3 so that release team and other Xena work can be saved 15:50
yoctozeptomnaser: ++15:50
yoctozeptogmann: ++15:51
yoctozeptowhat is the procedure? voting first?15:51
yoctozeptogmann to the rescue :-)15:51
gmannwe will put it on ML first before voting15:51
spotz_Hehe15:51
yoctozeptook15:52
gmannif no objection from anyone, let's propose it to retire on ML and then we move to next step 15:52
fungior openstack-charms15:52
fungiwhich fills similar use cases15:52
yoctozeptofungi: they deploy openstack with juju15:52
yoctozeptobut yeah, charms for juju exist for many more apps15:52
fungirather, juju charms i suppose (openstack-charms is specifically for deploying openstack, yeah)15:53
yoctozeptoand likely more reliable than murano tbh ;-)15:53
mnaserseems liek we've got an action item for this15:53
gmannyeah15:53
yoctozeptowho's the driver?15:53
gmannyeah about to ask, who will volunteer for this?15:53
yoctozeptogmann proposed the topic, gmann wants to continue?15:53
mnaseri can send an ML thingamajig shortly15:53
gmannsure i can.15:53
yoctozeptoah, looking for volunteers15:53
yoctozeptook, mnaser volunteered first15:54
gmannmnaser: +1. I can help on next15:54
gmann#action mnaser to send the murano retirement proposal n openstack-discuss ML15:54
gmannthanks mnaser 15:54
yoctozepto++15:55
gmann#topic PTG Planning15:55
gmann#link https://etherpad.opendev.org/p/tc-yoga-ptg15:55
gmannit just a reminder to keep adding topic in etherpad for PTG discussion15:55
gmannor anyone has anything for PTG, feel free to bring it now15:56
gmann#topic Open Reviews15:56
gmann#link https://review.opendev.org/c/openstack/governance/+/80378315:56
gmannI am proposing to select RBAC goal for Yoga, you can vote there15:57
mnaserfwiw15:57
mnasernot an open review but15:57
mnaserhow would y'all feel about a video/voice call for weekly meetings?15:57
TheJulianotes would be need to be created and distributed, fwiw15:58
mnasersome of the other communities i've seen do this15:58
mnaserwill actually #startmeeting15:58
mnaserand then #info #link etc throughout it15:58
TheJuliaor at least kept in maybe a shared collaborative document15:58
TheJuliathat too15:58
mnaserand then you end up with meeting notes with all the action items, info, points brought up by specific folks, etc15:59
gmann+1, i am ok, much easer than typing :)15:59
spotz_We do it once a month for RDO, notes aren’t the best but we try15:59
gmannand in TC weekly summary we anyways summarize the key things and frm meeting too15:59
fungii fnid typing much easier than talking, but i'm not currently on the tc anyway15:59
fungi(typo for effect)15:59
yoctozeptolol15:59
mnaser:P15:59
gmannfungi: I am finding difficult time in typing especially when hosting :)16:00
mnaserid like for us to give it a shot at least and see hwo we feel 'bout it16:00
yoctozeptoI would welcome having alternating weeks with text and voice16:00
gmannand can we store the recording in meeting log like irc ?16:00
yoctozeptogmann: yeah, we would need a scribe16:00
fungiit 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 call16:00
mnasergmann: maybe we can put the link at the end with the recording/whatever, and then the meeting notes will have everything16:00
mnaserhere is an example ofa nother community i've seen that does this16:01
mnaserhttps://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.html16:01
yoctozeptolet's wrap up for today16:02
gmannyeah, 16:02
gmannanyways let's continue on meetng thing in next meeting16:02
yoctozepto++16:02
mnasercool16:02
gmannmnaser: I will add topic in next meeitng16:02
gmannthanks16:02
gmannthanks all for joining.16:03
mnaserno problem16:03
spotz_Thanks for leading granny!16:03
gmann#endmeeting16:03
opendevmeetMeeting ended Thu Aug 12 16:03:16 2021 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:03
opendevmeetMinutes:        https://meetings.opendev.org/meetings/tc/2021/tc.2021-08-12-15.00.html16:03
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/tc/2021/tc.2021-08-12-15.00.txt16:03
opendevmeetLog:            https://meetings.opendev.org/meetings/tc/2021/tc.2021-08-12-15.00.log.html16:03
mnasergranny :P16:03
mnaserautocorrect doing funky things16:03
gmann:P16:09
yoctozeptodon't judge family relations! :P16:15
*** ykarel is now known as ykarel|away16:31

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