Monday, 2023-02-27

opendevreviewIury Gregory Melo Ferreira proposed openstack/sushy master: Handle non-default language for registries  https://review.opendev.org/c/openstack/sushy/+/87204903:20
vanougood morning ironic04:24
opendevreviewVerification of a change to openstack/ironic master failed: Get conductor metric data  https://review.opendev.org/c/openstack/ironic/+/86544707:09
opendevreviewMohammed Boukhalfa proposed openstack/sushy-tools master: Add fake_ipa to fake system  https://review.opendev.org/c/openstack/sushy-tools/+/87536607:53
opendevreviewMohammed Boukhalfa proposed openstack/sushy-tools master: Add fake_ipa to fake system  https://review.opendev.org/c/openstack/sushy-tools/+/87536608:11
opendevreviewMohammed Boukhalfa proposed openstack/sushy-tools master: Add fake_ipa to fake system  https://review.opendev.org/c/openstack/sushy-tools/+/87536608:14
opendevreviewMohammed Boukhalfa proposed openstack/sushy-tools master: Add fake_ipa to fake system  https://review.opendev.org/c/openstack/sushy-tools/+/87536608:16
kubajjGood morning vanou and everyone 09:07
dtantsurJayF: auto-TLS was about conductor->IPA connection, not the other way around09:20
dtantsuriurygregory: good morning! the project submission deadline has been extended for outreachy, we have this week still.09:49
rpittaugood morning ironic! o/10:00
vanouhi kubajj10:30
rpittauiurygregory: which patches are we waiting for to release ipe and ngs ?10:59
opendevreviewVerification of a change to openstack/ironic master failed: Get conductor metric data  https://review.opendev.org/c/openstack/ironic/+/86544711:10
iurygregorydtantsur, ack11:16
iurygregoryrpittau, there is TheJulia patch to include ironic metrics (IPE) and ngs I saw some patches from mgoddard I think...11:17
iurygregorygood morning Ironic11:17
TheJuliagood morning13:55
TheJuliaso many mirror downloads13:57
TheJuliawell, download failures13:58
rpittauiurygregory: thanks14:00
rpittauTheJulia mgoddard correct me if I'm wrong, are those the patches missing for the releases? https://review.opendev.org/c/openstack/ironic-prometheus-exporter/+/869509 https://review.opendev.org/c/openstack/networking-generic-switch/+/874789 https://review.opendev.org/c/openstack/networking-generic-switch/+/874793 https://review.opendev.org/c/openstack/networking-generic-switch/+/873098 14:02
rpittauhttps://review.opendev.org/c/openstack/networking-generic-switch/+/74328314:02
TheJuliaiurygregory: can you clarify your comments w/r/t https://review.opendev.org/c/openstack/ironic-prometheus-exporter/+/869509 ?14:03
TheJuliaIf we have to cut today... most likely. The challenge at hand is CI is misbehaving14:08
TheJuliamgoddard: any opinions?14:08
iurygregoryTheJulia, most of the comments I added would be some nits I would say (nothing that would really hurt to be done in a follow-up), I removed the +2 because we changed the config options in the ironic side (so we likely need to change https://review.opendev.org/c/openstack/ironic-prometheus-exporter/+/869509/9/devstack/plugin.sh )14:25
TheJuliaahh, right14:25
TheJuliayeah, that would be good to change, although it should still work14:25
TheJuliastill don't understand one of your other comments, but that is aside from the config atm14:26
TheJuliaoh14:27
TheJuliano, the direct names are used, not the old ones14:27
opendevreviewJulia Kreger proposed openstack/ironic-prometheus-exporter master: Support extraction of ironic internal metrics  https://review.opendev.org/c/openstack/ironic-prometheus-exporter/+/86950914:27
iurygregoryTheJulia, the comment you said you don't understand is https://review.opendev.org/c/openstack/ironic-prometheus-exporter/+/869509/9/ironic_prometheus_exporter/parsers/header.py ?14:36
TheJuliaI guess https://review.opendev.org/c/openstack/ironic-prometheus-exporter/+/869509/9/ironic_prometheus_exporter/parsers/ironic.py are you saying we need to try to consturct more verbose descriptions? I guess the idea is frustrating because reference wise it is in examples, but practical usage I rarely see such in sample payloads14:38
iurygregoryno, the descriptions are good, it would be more to keep the same logic we had for other parsers (ipmi/redfish) where we have the json file that would map what is the description for each key14:39
TheJuliaahh, that makes sense to do if we know the description14:40
iurygregorydon't worry with this for now, it's like a low-hanging-fruit bug =) 14:41
*** dansmith_ is now known as dansmith14:44
JayFhey everyone o/15:00
JayF#startmeeting ironic15:00
opendevmeetMeeting started Mon Feb 27 15:00:58 2023 UTC and is due to finish in 60 minutes.  The chair is JayF. 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 'ironic'15:00
JayFWho all is around?15:01
vanouo/15:01
matfechnero/15:01
TheJulia o/15:01
JayF#topic Announcements/Reminder15:01
JayFTag your patches #ironic-week-prio if they need review... if you want them in Antelope release that should be ~nowish :D 15:02
JayFAlso, if you haven't seen, OIS schedule is out (not forum; just summit). Please check it out15:02
JayF#link https://vancouver2023.openinfra.dev/a/schedule15:02
JayFany other announcements15:02
rpittauo/15:03
JayF#note TheJulia had an action to get python-ironic-inspector-client CI happy; how did that go?15:03
TheJuliarequires a fix to be landed in insepcctor sine it imports the code directly15:04
TheJuliaone moment15:04
TheJuliamerged, so upon next inspector release the world should be happier for that job15:04
TheJuliazed inspector release to be specific15:04
JayFperfect15:04
JayFthat was the only action item last week, moving on15:04
TheJuliaerr, maybe/maybe not, since it is not constrained15:04
TheJuliaeither way, the patch needed has merged at this point15:05
JayFwell that fits right into15:05
JayF#topic Ironic CI status15:05
JayFhow are things? any concerning issues seen over the last week15:05
rpittaubifrost ci still kaput, fix is under review15:05
JayFlink?15:06
rpittauhttps://review.opendev.org/c/openstack/bifrost/+/87465015:06
JayFthat's open here now; I'll have a look post-meeting15:06
rpittaufailures are inconsistents, so not easy to fixx all of them at the same time15:07
JayFCI is V-1 right now on that :( 15:07
rpittauyeah15:07
rpittaugoing to recheck15:07
JayFyeah that's always our battle15:07
JayFokay15:07
JayF#topic VirtualPDU15:07
JayFanything new on getting us access?15:07
rpittauwell waiting for fungi I guess15:08
* iurygregory is late o/15:08
rpittauno answers from cores15:08
rpittauso last chance is on opendev team15:08
JayFalright; I know they were all offsite last week so hopefully that moves more now15:09
JayFare we on a timer for that?15:09
JayFdo we need to get it flipped before A is cut?15:09
rpittauI think we're good if we move things forward this week15:09
JayFalright15:09
JayF#topic Release countdown: 3 weeks15:09
JayFI owe a revision to cycle highlights; https://review.opendev.org/c/openstack/releases/+/874338 -- I'll do that as soon as this meeting is over15:10
JayFhttps://etherpad.opendev.org/p/IronicWorkstreams2023.1 looking at this now for anything we can land before A hits15:10
JayFI think we're nearing the point of things being in that are gonna git in, in terms of larger workstreams15:10
JayFmoving on since there's no further input15:12
JayF#topic open discussion15:13
JayFvanou: had two items in here 15:13
vanouYes.15:13
vanouFirst item is about acceptability of backport patch on iRMC driver (sorry for iRMC driver specific)15:13
vanouThis backport patch adds logic of logging warning, when it catches incompatible behavior of iRM server firmware15:14
TheJuliathrough use of a verify step yes?15:15
JayFCan you link the specific patch for context?15:15
vanouJust adds warning, but it adds verify step. So in discussion with TheJulia, we need to ask community if it's backportable15:15
vanouSoryy. This one https://review.opendev.org/c/openstack/ironic/+/87088015:15
vanouTheJulia: yes15:16
JayFCan we be explicit about the behavior if we don't backport this to Zed?15:16
JayFOn the surface I'm in agreement that it's a little much to backport15:16
TheJuliamy concern in this case is we're adding basically a feature in the form of a step an operator would need to invoke15:16
vanouIf we don't backport this, ironic operator lose chanse to notice iRMC incompatible behavior through ironic log15:16
JayFYeah; this change reads more like a feature than a bugfix -- even if it is working around/with new firmware behavior15:17
JayFIf all we're giving up is an operator getting a logging message; I don't think it should be backported. Instead, could we write a document for how users in these situations can figure out + fix it, outside of Ironic?15:17
vanouJayF: notify user with doc is another reasonable option15:18
JayFI think that's preferable15:18
JayFIs there anyone stable core here who disagrees and wants to fight for #870880? 15:18
TheJuliaI do not disagree, but I'm also the one who sort of forced this discussion to take place15:19
TheJuliavanou: thank you for being up very late/very early for this meeting15:19
JayF#note https://review.opendev.org/c/openstack/ironic/+/870880 is not permitted to be backported to Zed; instead we will focus on a documentation-based solution for operators in this case.15:19
JayFvanou: I think you also had an item up about the vuln management docs I put a review on15:19
JayFvanou: looking at your agenda item: to clarify my comments; Ironic can only set policy for Ironic-managed projects in the openstack/ namespace15:20
vanouRegarding first item, thanks for feedback :) I'll take that doc way15:20
JayFso vendor tools under x/ like x/proliantutils -- we don't have the authority to set policy for these15:20
JayFone question I've had: why don't we just follow OpenStack VMT standard?15:20
JayFis there a historical reason we're not/15:20
vanouI felt the need the recommended way to handle vendor library, if that vul is also affect ironic code.15:22
TheJuliaJayF: so historical reason I believe was a lack of capacity, but it goes back to the days of Aeva15:23
TheJuliaand I think in part it is because of the duality nature at play with things like x/proliantutils being totally out side of our control and we just consume it15:24
JayFDo we have any ironic contributors who'd oppose me syncing up with security group in OpenStack to get us in the VMT?15:24
JayFThat will not prevent us from being a 301-redirect for vendor-tools-related security bugs if they come in15:24
JayFI suspect we can talk to the folks involved and they'll deal with us reasonably15:24
JayFand if not, we would then have a specific reason to be different rather than "we just are" :) 15:24
TheJulia++15:24
vanouI agree with following OpenStack VMT regarding Ironic specific code problem15:25
JayF#action JayF to engage VMT (probably mailing list post) to inquire about getting Ironic in it.15:25
JayFvanou: I think for the non-openstack ironic based code issues; we have two potential paths: 1) the vendor that primarily maintains it discovers and issue, fixes it in the library, and discloses it to us so we can bump versions or15:26
JayF2) someone external, who uses Ironic, discovers it and reports it through our systems, and we responsibly pass it on to the vendor15:26
JayFboth of those things are stuff I would expect/hope would happen just by common sense by folks running things15:26
vanouYes. These 2 are good option regarding vulnerability on vendor library code.15:27
vanouBut I feel we need another guide if that vulnerability needs fix on both ironic and vendor library15:27
JayFIn those cases, VMT policy generally allows disclosure to trusted developers/cores needed to fix an issue15:28
JayFin the case of those coordinations, I'd expect/hope people to work together without needing a document on exactly how to do it15:28
JayFbut maybe that's wishful thinking?15:28
TheJuliaI think the issue is when there is disagreement15:29
TheJuliaor a difference of view/opinion15:29
JayFDisagreement about if something is a bug? Or how to fix it?15:29
TheJuliawhich we've seen recently like with the glance report that has been revised a few times, inherently it is a feature, but the reporter wants it deemed a vulnerability15:29
TheJuliaso the challenge is who holds the power to say yes or no in the entire sequence of trying to work through a thing.15:30
JayFI don't see how that problem exists any more or less in Ironic+vendor tools than it does with OpenStack+any-other-non-openstack-library15:31
TheJuliaAnd then codifying such a dynamic in a doc seems to be what is desired, which I think is reasonable, but then not every case is the same...15:31
JayFI default to preferring to not document every single case, because each document comes with a maintenance cost15:31
TheJuliaI guess the challenge is there is nuance in all situations15:31
JayFand I don't trust us to do a good job of updating it as things change15:31
JayF++ I do not want to remove any nuance15:32
JayFLets go down the path with the VMT15:32
JayFand mention this in the thread15:32
JayFand see how it goes15:32
JayFthe folks who do security in openstack-proper might already have some strategies for managing this kind of problem15:32
JayFthere's no reason for Ironic to discuss or try to solve it in a vacuum15:32
vanouIf we don't write guide on ironic+vendor vul, we need written policy on that because reporter don't know how ironic handle this situation.15:34
vanou^ just my comment.15:34
JayFI'm saying lets get that question inside the larger conversation aorund Ironic joining VMT15:34
JayFIt's extremely possible openstack already has a policy that we can point to aorund that15:34
vanouAh. I understand15:34
JayFI'll own making that thread on the list today15:35
JayF#action JayF to email list about Ironic joining VMT; will be sure to mention potential vendor:Ironic complications15:35
JayFIs there any other items we'd like to talk about in open discussion?15:35
JayFOh, I wanted to mention15:36
JayFdtantsur found an issue with api-ref, he mentioned it in channel a couple of times15:36
JayFwell, good job there, the issue was found + is pending review to fix it in the theme for all openstack projects15:36
dtantsura fix has been proposed against openstackdocstheme15:36
JayFhttps://review.opendev.org/c/openstack/openstackdocstheme/+/87495715:36
JayF#link https://review.opendev.org/c/openstack/openstackdocstheme/+/87495715:36
JayFour api-ref looks infinitely better with the change15:37
JayFso thank you dtantsur for not letting that sit \o/ 15:37
dtantsur:)15:37
JayFWe should probably also mention https://review.opendev.org/c/openstack/releases/+/87539615:37
JayF#note dtantsur is no longer going to be an Ironic release liason 15:38
JayFThank you for all the things you have done/do/are continuing to do for ironic15:38
dtantsuralas! too much stuff on my shoulders already15:38
JayFhappy to lighten the burden a bit :)15:38
arne_wiebalckthanks dtantsur for doing it for so long!15:38
vanouthanks dtantsur!15:39
JayFAlso, I need a volunteer to run the meeting 3/13 (meeting-after-next)15:39
JayFI'll be in Southern California presenting at SCALE (with TheJulia) 15:40
iurygregoryo/15:40
JayFif anyone is in that area and wants to recieve a high-five and/or have lunch, please reach out15:40
iurygregoryI can run the meeting15:40
JayF#action iurygregory to run the meeting 3/13 (2 weeks from today)15:40
JayFLast call for open discussion before I shut it down15:40
JayF#endmeeting15:42
opendevmeetMeeting ended Mon Feb 27 15:42:26 2023 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:42
opendevmeetMinutes:        https://meetings.opendev.org/meetings/ironic/2023/ironic.2023-02-27-15.00.html15:42
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/ironic/2023/ironic.2023-02-27-15.00.txt15:42
opendevmeetLog:            https://meetings.opendev.org/meetings/ironic/2023/ironic.2023-02-27-15.00.log.html15:42
JayFthanks everyone; monday time \o/ 15:42
arne_wiebalckthanks JayF 15:42
vanouThanks TheJulia JayF and all! Good night15:43
fungirpittau: i'm going to bring the virtualpdu plan up with the other opendev sysadmins in tomorrow's meeting (19:00 utc in #opendev-meeting)15:47
rpittaufungi: thanks!15:47
JayFhttps://review.opendev.org/c/openstack/releases/+/874338 is updated; I'm happy with them as they sit. More reviews won't hurt :D 15:50
opendevreviewMark Goddard proposed openstack/networking-generic-switch master: Support batching up commands  https://review.opendev.org/c/openstack/networking-generic-switch/+/74328315:51
* TheJulia feels like she needs to hold her breath for the CI gate15:55
opendevreviewMark Goddard proposed openstack/networking-generic-switch master: Add ngs-stress test script  https://review.opendev.org/c/openstack/networking-generic-switch/+/87478916:04
JayFmgoddard: I believe we're going to use sharding to help the case in #74328316:10
JayFmgoddard: hmm, or actually might make it worse16:11
JayFif we had N ngs processes split across N shards, it might *add* a complication for you there of having >1 process making switch changes16:11
TheJuliadisjointed problems16:26
TheJuliaand yeah, switch internal locking is sometimes problematic16:26
rpittaugood night! o/16:28
JayFI'm glad to have thought of that though; it's something to avoid when implmenting sharding16:28
TheJuliaJayF: different point in the pipelines too16:29
TheJulian-g-s gets commands based upon port bind sequences16:29
TheJulianetworking-baremetal reads ironic's api to seed/sync physnet info16:30
rpittauactually before I leave, JayF TheJulia if you have a moment the bifrost CI fix is finally green! https://review.opendev.org/c/openstack/bifrost/+/87465016:30
rpittaugoing for real now o/16:30
TheJuliabatching is to address the already present issue of the existing locking + >1 thing trying to do something at any given time16:30
TheJuliao/16:30
JayFack16:34
JayFrpittau:  +A16:34
opendevreviewMerged openstack/ironic master: Get conductor metric data  https://review.opendev.org/c/openstack/ironic/+/86544717:24
TheJulia\o/17:29
dtantsur\o/17:51
-opendevstatus- NOTICE: The Gerrit service on review.opendev.org experienced severe performance degradation between 17:50 and 19:45 due to excessive API query activity; the addresses involved are now blocked but any changes missing job results from that timeframe should be rechecked19:55
iurygregorynice...20:04
iurygregory=(20:05
sschmittI asked this the other day, but wanted to see what the difference is now between NGS and networking-baremetal. It seems like they both now have functionality to interact with network switches. If I wanted to extend functionality in this area, which project makes sense as a starting point?20:50
JayFsschmitt: gonna be honest; I'm not sure I know hte answer to that either; if you don't get a response here (again), please post it to the openstack-discuss list with [ironic] prefix in the subject20:52
JayFand folks from other timezones can maybe help you out20:52
sschmittgot it, thanks!20:52
opendevreviewJulia Kreger proposed openstack/ironic-prometheus-exporter master: Support extraction of ironic internal metrics  https://review.opendev.org/c/openstack/ironic-prometheus-exporter/+/86950920:53
TheJuliasschmitt: so Networking-baremetal is where I think we would *love* to see stuff like this evolving, but networking-generic-switch is kind of like the "do the needful" via ssh solution21:41
TheJuliawhere as networking-baremetal is looking more at netconf21:42
JayFTheJulia: netconf?21:42
TheJuliasschmitt: the person we should likely chat with is hjensas21:42
TheJuliaI might be thinking of the wrong word21:42
sschmittopenconf21:42
TheJuliabut basically there is an xml standard for network configuration interchanges21:42
JayFI'm not sure I'd know the right word :)21:42
TheJuliayeah, thats it!21:42
JayFyep, haven't heard of that either but it sounds cool21:42
jrossernetconf is all well and good but top of the docs for my switches say they dont support netconf RBAC RFC 6536 so it's anything-goes config wise over that interface21:48
jrosseron the other hand with n-g-s its completely trivial to configure a limited user on the switch which can only issue a subset of commands against a subset of ports, so thats a total no-brainer for me21:49
TheJuliajrosser: that is a very valid data point22:05
TheJuliaI think there is a "these things will mature as time moves forward" sort of consideration22:05
TheJulia... and most network infra admins I've chatted with over the years highly prefer restricted access as opposed to "just give full access to it all"22:06
jrosserthats exactly how i allow n-g-s to work, with a special user on the switch thats deny-all/allow-as-needed control on what it can do22:08
jrosseri wouldnt dare have it different as the attack surface is gigantic especially if you collapse many logical things into the same network hardware22:08
iurygregoryhumm bifrost CI seems a bit unhappy in the IPE change .-.22:13
TheJuliajrosser: excellent22:19
opendevreviewMerged openstack/ironic master: Add configurable delays to the fake drivers  https://review.opendev.org/c/openstack/ironic/+/86112723:39

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