| adamcarthur5 | Thanks JayF! I will check it all out tonight | 00:03 |
|---|---|---|
| opendevreview | Merged openstack/ironic-python-agent-builder master: [codespell] Fixing Spelling Mistakes https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/906780 | 00:44 |
| opendevreview | Merged openstack/ironic-python-agent-builder master: [codespell] Adding Tox Target for Codespell https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/906781 | 00:44 |
| opendevreview | Merged openstack/ironic-python-agent-builder master: [codespell] Adding CI target for Tox Codespell https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/906782 | 00:44 |
| opendevreview | OpenStack Proposal Bot proposed openstack/ironic-inspector master: Imported Translations from Zanata https://review.opendev.org/c/openstack/ironic-inspector/+/906935 | 02:15 |
| opendevreview | Merged openstack/python-ironic-inspector-client master: add pyproject.toml to support pip 23.1 https://review.opendev.org/c/openstack/python-ironic-inspector-client/+/906079 | 04:13 |
| opendevreview | Takashi Kajinami proposed openstack/ironic-inspector master: Remove commenct lines for old openstackdocstheme https://review.opendev.org/c/openstack/ironic-inspector/+/907378 | 04:15 |
| opendevreview | Merged openstack/ironic master: Fix service role support https://review.opendev.org/c/openstack/ironic/+/907148 | 04:23 |
| opendevreview | Steve Baker proposed openstack/sushy-tools master: Handle nova instance having no image https://review.opendev.org/c/openstack/sushy-tools/+/906767 | 05:08 |
| opendevreview | Steve Baker proposed openstack/sushy-tools master: [WIP] add virtual-media-boot to openstack driver https://review.opendev.org/c/openstack/sushy-tools/+/906768 | 05:08 |
| rpittau | good morning ironic! o/ | 08:20 |
| opendevreview | Merged openstack/sushy-tools master: Handle nova instance having no image https://review.opendev.org/c/openstack/sushy-tools/+/906767 | 08:52 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic master: Online migration for inspect_interface inspector->agent https://review.opendev.org/c/openstack/ironic/+/907398 | 09:41 |
| *** ravlew is now known as Guest1201 | 10:42 | |
| *** ravlew1 is now known as ravlew | 10:43 | |
| opendevreview | OpenStack Release Bot proposed openstack/ironic-python-agent bugfix/9.9: Update .gitreview for bugfix/9.9 https://review.opendev.org/c/openstack/ironic-python-agent/+/907404 | 10:58 |
| opendevreview | Merged openstack/python-ironic-inspector-client master: [codespell] Adding Tox Target for Codespell https://review.opendev.org/c/openstack/python-ironic-inspector-client/+/907116 | 11:16 |
| opendevreview | Merged openstack/ironic-inspector master: Remove commenct lines for old openstackdocstheme https://review.opendev.org/c/openstack/ironic-inspector/+/907378 | 11:16 |
| opendevreview | OpenStack Release Bot proposed openstack/ironic bugfix/24.0: Update .gitreview for bugfix/24.0 https://review.opendev.org/c/openstack/ironic/+/907410 | 11:20 |
| opendevreview | Merged openstack/ironic-python-agent bugfix/9.9: Update .gitreview for bugfix/9.9 https://review.opendev.org/c/openstack/ironic-python-agent/+/907404 | 11:24 |
| iurygregory | good morning Ironic | 11:44 |
| opendevreview | Merged openstack/python-ironic-inspector-client master: [codespell] Adding CI target for Tox Codespell https://review.opendev.org/c/openstack/python-ironic-inspector-client/+/907117 | 12:00 |
| arne_wiebalck | Good morning, Ironic! | 13:26 |
| arne_wiebalck | Please note https://indico.cern.ch/event/1378171/ (and https://indico.cern.ch/event/1376907/) | 13:28 |
| opendevreview | Jake Hutchinson proposed openstack/bifrost master: Bifrost NTP configuration https://review.opendev.org/c/openstack/bifrost/+/895691 | 13:34 |
| dtantsur | thanks arne_wiebalck! | 13:46 |
| rpittau | thanks arne_wiebalck :) | 13:51 |
| opendevreview | Dmitry Tantsur proposed openstack/bifrost master: Deprecate ironic-inspector support https://review.opendev.org/c/openstack/bifrost/+/905192 | 13:51 |
| opendevreview | Julia Kreger proposed openstack/ironic stable/2023.2: Fix service role support https://review.opendev.org/c/openstack/ironic/+/907268 | 14:44 |
| opendevreview | Julia Kreger proposed openstack/ironic stable/2023.1: Fix service role support https://review.opendev.org/c/openstack/ironic/+/907269 | 14:45 |
| TheJulia | i love it when things cleanly backport just by using the button in the gui | 14:45 |
| TheJulia | dtantsur: you should likely push a reno into ironic to advise of status in advance of our next release to signal to operators and further refine expectations moving forward | 14:47 |
| arne_wiebalck | dtantsur: rpittau: np, would be great if you can make it! | 15:33 |
| dtantsur | TheJulia: you mean, about inspection? | 16:04 |
| dtantsur | good morning | 16:04 |
| TheJulia | dtantsur: yes! | 16:05 |
| TheJulia | and Good morning to you as well! | 16:05 |
| dtantsur | TheJulia: that was my thought, I just don't know the status yet :) I believe this work will also be prelude-worthy | 16:05 |
| TheJulia | ++ | 16:05 |
| TheJulia | strong preludes are always good! | 16:05 |
| TheJulia | "It was a dark and stormy night, and the ironic contributors plotted and schemed! They determined we needed <insert stuff here>. | 16:06 |
| dtantsur | !! | 16:06 |
| opendevmeet | dtantsur: Error: "!" is not a valid command. | 16:06 |
| dtantsur | c'mon | 16:07 |
| dtantsur | TheJulia: btw, I wanted to ask you if you think https://review.opendev.org/c/openstack/ironic/+/907398 is a good idea at all | 16:07 |
| TheJulia | dtantsur: I'm not entirely sure, but I think it makes sense to also in the same commit to upgrade the status check to return a warning if nodes are set with the deprecated interface | 16:09 |
| TheJulia | That warning could also include "set this field" and "here is why" and all that pertinant stuff to make it self-correcting | 16:10 |
| dtantsur | TheJulia: can we have warnings in the status check? | 16:10 |
| TheJulia | yes! | 16:10 |
| dtantsur | nice! I'll make a mental note (if you don't mind not squeezing it in the same change) | 16:11 |
| TheJulia | https://github.com/openstack/ironic/blob/master/ironic/cmd/status.py#L93 | 16:11 |
| dtantsur | ah, you said the same commit | 16:11 |
| * dtantsur should learn to read | 16:11 | |
| dtantsur | remind me please, if I add something today, it will issue the warning on the upgrade TO or FROM 2023.2? | 16:12 |
| TheJulia | we just want to make sure we leave that migration around until the interface is removed or maybe sometime after "just" so people have an easy path | 16:12 |
| dtantsur | ehmmm 2024.1 | 16:12 |
| TheJulia | so, your supposed to run the new version's status check *before* completing an upgrade | 16:12 |
| * dtantsur is curious if we do it in bifrost | 16:12 | |
| TheJulia | .... I don't remember | 16:13 |
| TheJulia | devstack runs it but I think only errors if the result code is "error" | 16:13 |
| dtantsur | we don't seem to document the command in https://docs.openstack.org/ironic/latest/admin/upgrade-guide.html? | 16:13 |
| TheJulia | ugh, we should fix that indepedently | 16:13 |
| TheJulia | it came from the openstack wide effort to add it | 16:14 |
| dtantsur | yep. otherwise, I don't expect a lot of admin to run it, especially with standalone ironic | 16:14 |
| dtantsur | the upgrade checks run after online_data_migrations, right? | 16:15 |
| * dtantsur hasn't paid attention to this work, sorry | 16:15 | |
| TheJulia | take a look at our upgrade.sh | 16:15 |
| dtantsur | fair | 16:15 |
| TheJulia | I just don't remember at this point | 16:15 |
| TheJulia | upgrade status checking/preflight warning stuff was back around wallaby | 16:16 |
| TheJulia | but definitely comes in handy! | 16:16 |
| * dtantsur is confused by upgrade.sh | 16:16 | |
| dtantsur | We run 'upgrade check' before and after upgrade, ignoring failures in the former. Which makes zero sense to me, to be honest | 16:18 |
| dtantsur | Anyway, TheJulia, upgrade checks run before online_data_migrations, so we need to include any warnings or errors in the next release, not this one. | 16:18 |
| TheJulia | there is a madness to | 16:19 |
| TheJulia | you can include a warning, fwiw | 16:19 |
| TheJulia | you can then elevate it to an error when the interface is removed | 16:19 |
| TheJulia | in order to block any forward progress | 16:19 |
| TheJulia | "oh, you have a big problem, fix it before proceeding" | 16:19 |
| TheJulia | keep in mind most of that is in the context of devstack and to help us navigate some of the issues with grenade, since in theory you should be able to run online_data_migrations with the deployment still | 16:20 |
| TheJulia | just, if you have a error, the migration can also fix it | 16:20 |
| TheJulia | we had a case where we hit that with something I don't remember at this point | 16:20 |
| TheJulia | (we're talking 2+ years ago) | 16:20 |
| dtantsur | Let's maybe generalize it: we should have a validation that no nodes have interfaces that are not enabled? I'd put it in a separate patch at this point. | 16:21 |
| TheJulia | (or make it a warning as a result, and we did have a legitimate case of this which is why the pattern is in the upgrade.sh | 16:21 |
| TheJulia | dtantsur: likely! | 16:21 |
| TheJulia | actually, that is a good check to also backport | 16:22 |
| TheJulia | *but* if there are specific things we know are going away, we *should* likely also provide specific direction on correcting the issue | 16:22 |
| TheJulia | could be as simple of a data structure of "known_interface_removals" to map to an entry with "inspector" with some extra help text | 16:22 |
| dtantsur | Note: inspector is not deprecated yet. I'm only putting deprecation in Bifrost. We cannot deprecate it for the general case. | 16:22 |
| dtantsur | So "please stop using inspector" is not something I can say yet. | 16:23 |
| TheJulia | true, not quite yet | 16:23 |
| TheJulia | soon, maybe :) | 16:23 |
| TheJulia | I'm going to go get a shower and dig into a painful support case which needs my eyes | 16:23 |
| dtantsur | The online migration I'm adding addresses are more narrow case: someone (e.g. bifrost) removing 'inspector' from the enabled list before all nodes are updated | 16:23 |
| dtantsur | sure, thanks for the sanity check and ideas | 16:24 |
| TheJulia | and that is a totally reasonable generic error, I'm only suggesting it could be extended later for a list of known interface removals from deprecations | 16:24 |
| * dtantsur nods | 16:24 | |
| TheJulia | so we can provide specific case by case guidance | 16:24 |
| dtantsur | I'll write a short RFE to track these ideas | 16:24 |
| TheJulia | eh, if you hammer it out in code faster, that would also be acceptable ;) | 16:25 |
| TheJulia | Realistically, just a generic error for "config to db mismatch" is *definitely* something I would backport | 16:25 |
| dtantsur | I need to collect the thoughts anyway, why not in writing :) | 16:25 |
| TheJulia | :) | 16:25 |
| * dtantsur takes off compression gloves to finish typing before tomorrow.. | 16:26 | |
| dtantsur | https://bugs.launchpad.net/ironic/+bug/2051954 | 16:33 |
| opendevreview | Merged openstack/ironic stable/2023.2: [Backport] Fixes Raid creation in iLO6 and other BMC with latest schema https://review.opendev.org/c/openstack/ironic/+/904070 | 16:38 |
| dtantsur | Folks, what do you think, should we maybe detect time skew between ironic and IPA? I.e. send the current agent time with lookup and blow up if it diverges significantly? | 16:47 |
| dtantsur | I have 2 customer cases just this week..... | 16:48 |
| JayF | We already sync time on IPA startup? | 16:48 |
| dtantsur | We can do it if there is NTP | 16:49 |
| JayF | This is infrastructural issues where someone was not syncing time to their conductors, I assume? | 16:49 |
| dtantsur | It is. I'm just looking for a better way to detect that than "Dmitry looking at your logs and telling you to set your hardware clock to UTC" | 16:49 |
| JayF | in a TLS-secured Ironic, that connection wouldn't ever even happen | 16:49 |
| dtantsur | Not exactly. Lookups will work, heartbeats will fail. | 16:50 |
| JayF | so sending time with IPA lookup would not help unless traffic between IPA<>Ironic were insecure (?) | 16:50 |
| JayF | Lookups are permitted to have invalid certificates? | 16:50 |
| JayF | The lookup that returns the agent token (!?) ... that seems wrong? | 16:50 |
| dtantsur | It's not necessarily invalid: the Ironic's certificate will probably be generated long ago. | 16:50 |
| JayF | Am I crazy to think that basic https used to fail if your clock was skewed? | 16:51 |
| dtantsur | I'm not sure that's the case, but I'm not the biggest expert | 16:51 |
| dtantsur | I know you cannot have Kerberos working | 16:51 |
| JayF | Let me ask it this way: how does the IPA<>Ironic communication fail if not due to SSL issues in the HTTPS connection? | 16:52 |
| dtantsur | The IPA certificate is generated on fly. Heartbeats start coming seconds-to-minutes after it's generated. | 16:53 |
| dtantsur | The Ironic's certificate may be generated days or months ago. | 16:53 |
| dtantsur | But you're right, it's not bullet-proof. | 16:53 |
| JayF | Hmm. | 16:53 |
| TheJulia | I feel like it might make sense for maybe the conductor to emit a "our time is" field and maybe the agent can go "I have no ntp, uhhh... this feels like rdate, but okay!" | 16:53 |
| TheJulia | to at least sort of resolve it into the same ballpark | 16:54 |
| JayF | So I'm just thinking through the possibilities | 16:54 |
| TheJulia | else, I wonder how will it detect, since the lookup client time shouldn't trigger a failure to be recorded by the conductor | 16:54 |
| JayF | and anything we do to *fix it* proactively that is not "sync time with NTP" is likely opening a security vulnerability | 16:54 |
| TheJulia | possibly, or at least a path we need to be very mindful of potentials | 16:55 |
| JayF | so the best case we can get likely is changing "dtantsur looking through your logs" to "Ironic knows that things are likely broken" | 16:55 |
| JayF | which I get the feeling we could *probably* derive from the failure cases, if it's failing in ways I'd expect | 16:55 |
| dtantsur | Note: I don't insisting on fixing it, a clear and loud warning will work for me | 16:55 |
| JayF | e.g. Ironic sees a cert that the time is radically off on, and emits a new, unique error | 16:55 |
| dtantsur | In this case, it will be noticed by field folks without escalating the whole thing to me | 16:55 |
| TheJulia | ... I'd really prefer people just to use ntp, but even I had a case.... last week where someone had the clock configured to UTC but in their case UTC was actually AEST | 16:55 |
| JayF | At some point, we will have Ironic see a cert with a radically screwed up time | 16:55 |
| JayF | and we can use that as the canary to improve the error, perhaps (?) | 16:56 |
| JayF | That's why I was asking about where/how the error bubbles | 16:56 |
| dtantsur | mmm, you mean, if we get a TLS error, ironic tries to do some investigation on the cert? | 16:56 |
| JayF | exactly | 16:56 |
| TheJulia | I like that idea | 16:56 |
| dtantsur | an interesting thought, I like it too | 16:56 |
| TheJulia | and could also be semi-backporting | 16:56 |
| TheJulia | or, backportable | 16:56 |
| TheJulia | since we're just making things more operator visible in that case | 16:56 |
| JayF | "IPA presented a certificate created NN minutes in the future" -> node.last_error | 16:57 |
| JayF | or something similar | 16:57 |
| dtantsur | in the 2nd case I have SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired (_ssl.c:1129)')) | 16:57 |
| dtantsur | I wonder what made them asking questions.... | 16:57 |
| dtantsur | Maybe we need to augment that with a short explanation | 16:58 |
| JayF | So we can dig deeper there, get the expiry time, and improve the error | 16:58 |
| TheJulia | jay.suggestion += ". Please consult the system clock. Ensure it is set to UTC and contains the time in UTC." | 16:58 |
| JayF | getting the time in the error is key: because if you are in UTC-5 and you see "it was 5 hours expired" | 16:58 |
| TheJulia | dtantsur: in my case "not valid yet" was the error last week | 16:58 |
| dtantsur | yeah, depends on the direction :) | 16:58 |
| JayF | just try to give the information to the error field then ops docs/automation can operate on it | 16:58 |
| TheJulia | yup, and just exactly what is wrong | 16:58 |
| JayF | I'm thinking if this happened in most envs I worked in, we'd probably look for that error in last error and run some kinda automation to fix the time | 16:59 |
| TheJulia | ... I honestly think the customer had an internal ntp server offering the wrong time since folks swore they synced it to an internal clock source | 16:59 |
| JayF | :-| | 16:59 |
| TheJulia | or it was offering local time and advertising it as utc | 16:59 |
| JayF | this is why you have 3+ NTP servers (but never 2) | 16:59 |
| TheJulia | well, for continious, yes | 16:59 |
| dtantsur | it's not helping that IPA starts showing the not really helpful "ssl.SSLError: [SSL: SSLV3_ALERT_BAD_CERTIFICATE] sslv3 alert bad certificate" | 16:59 |
| dtantsur | in my first case, the customers got fixated on that | 17:00 |
| JayF | one of the first conference talks was listening to David Mills (RIP :C) talk about NTP, and he dedicated a good 15 minutes to "never use two ntp servers" | 17:00 |
| TheJulia | ahh, yes, the classical mistake | 17:00 |
| JayF | We can do the "dig into what the error is" ssl code in ironic-lib and put it in IPA and Ironic | 17:01 |
| JayF | (and un-libify it for backporting purposes) | 17:01 |
| JayF | that way if you see a log about an ssl error, we'll always give you enough breadcrumbs to know what is going on, and maybe make an extra loud scream if we see a time that is +-24H | 17:01 |
| TheJulia | At one job we ran two remote and let the time critical nodes also use each other. Although, it meant some unplanned "oh no, need to update ntpd!" | 17:01 |
| TheJulia | and we had external monitoring keeping an eye on our remotes | 17:02 |
| dtantsur | The problem with the IPA side is that the traceback in entirely in eventlet | 17:02 |
| JayF | I'm surprised external GPS-based first-party time units aren't more popular :) | 17:02 |
| JayF | I know how to fix THAT problem LOL | 17:02 |
| TheJulia | JayF: we actually considered it... just couldn't get budget to make a stratum 2 clock | 17:02 |
| JayF | adamcarthur5 is going to rip eventlet outta IPA someday ;) | 17:02 |
| TheJulia | (or am I thinking of stratum 1) | 17:03 |
| * TheJulia doesn't remember the levels much anymore | 17:03 | |
| dtantsur | Yeah. It's actually pretty cool that we can detect TLS problems on the server side, but we need a better error message.. | 17:03 |
| JayF | we can detect it both sides, to be clear | 17:03 |
| JayF | and print a better error to the logs + node.last_error when it happens | 17:03 |
| JayF | that solves the whole problem, doesn't it | 17:03 |
| TheJulia | we had an private SONET circuit to two central offices, we "almost" went the route of doing the ticker clock source off the rack's DS-3 clock source plug.... That was the least expensive option that didn't involve putting an antenna on the roof | 17:04 |
| dtantsur | this is how it looks https://paste.opendev.org/show/bnJ33PtnYx0wv4RMBdci/ | 17:04 |
| dtantsur | maybe we can override handle() | 17:04 |
| dtantsur | or process_request | 17:05 |
| * TheJulia realizes she dated herself mentioning DS-3 hardware | 17:05 | |
| JayF | except ssl.SSLError as e:\n ironic_lib.find_ssl_error(request, e) | 17:05 |
| JayF | Is that not just an SSLError we catch at a higher level and do something with? | 17:05 |
| dtantsur | JayF: well, we'll need to override something inside eventlet. Otherwise there is no place for us to catch it. | 17:06 |
| JayF | I'm not even saying inspect the sslerror itself even, but we have the remote host, we can connect to it, look at the cert, and pick the top 3 likely problems and give better errs for them | 17:06 |
| MarcSchoechlin[m] | I am using supermicro ARM servers with the ARS-110M-NR board. That board runs OpenBMC. | 17:06 |
| MarcSchoechlin[m] | Is there a api endpoint or other mechanism to backup and restore the entire configuration of the bmc? | 17:06 |
| MarcSchoechlin[m] | (very useful for development purposes....) | 17:06 |
| dtantsur | In this case, the remote host is us :) | 17:06 |
| dtantsur | MarcSchoechlin[m]: not in Ironic. Check their docs, sometimes similar functionality is provided. | 17:06 |
| JayF | MarcSchoechlin[m]: AFAIK such a command is not part of the redfish spec | 17:06 |
| dtantsur | yeah, Dell did it via an OEM call | 17:07 |
| JayF | dtantsur: I'm looking at code and trying to understand. Am I wrong to think adding an 'except SSLError' here would catch the case? https://github.com/openstack/ironic-python-agent/blob/master/ironic_python_agent/ironic_api_client.py#L90 | 17:08 |
| TheJulia | Firmware settings are visible, but it is not any level of backup/restore, and at least the earlier Supermicro gear with their inhouse redfish service was an entirely oem mechanism if memory serves | 17:08 |
| opendevreview | Riccardo Pittau proposed openstack/sushy master: Force constraints when installing a package during tox test https://review.opendev.org/c/openstack/sushy/+/907461 | 17:09 |
| dtantsur | JayF: wrong direction. It's not from IPA to Ironic, it's the other way around. | 17:09 |
| JayF | is the exception you pasted from ironic logs or ipa logs? | 17:09 |
| dtantsur | The WSGI server in eventlet shows a TLS error when a *client* fails. I don't know how it works, to be hoenst. | 17:09 |
| JayF | oh what the hell | 17:09 |
| JayF | okay | 17:09 |
| dtantsur | yep | 17:09 |
| JayF | I'd rather focus on the other half of it | 17:09 |
| dtantsur | True | 17:10 |
| JayF | as I'd honestly be crushed if IPA had eventlet after next cycle | 17:10 |
| JayF | also I can upstream a fix to eventlet, I guess, if we find a way to do it sanely | 17:10 |
| JayF | we do have an upstream there now | 17:10 |
| * TheJulia fires up massive attack and goes and digs into a customer case | 17:11 | |
| rpittau | fun fact: we've been using unconstrained requirements in pep8 tests since forever :D | 17:12 |
| dtantsur | for some definition of "fun" certainly :D | 17:12 |
| JayF | hmm dtantsur gonna DM you | 17:12 |
| TheJulia | "for a fun time, run tox -epep8!" | 17:12 |
| * TheJulia expects this in a rest room at some point | 17:13 | |
| rpittau | :D | 17:13 |
| rpittau | my brain needs air, see you tomorrow o/ | 17:13 |
| TheJulia | Brew Dog in Berlin had some interesting things scribbled on the wall the last time I was there, one thing was actually a programming joke in english | 17:14 |
| dtantsur | and some ironic stickers | 17:20 |
| TheJulia | +++++++ | 17:35 |
| TheJulia | At least one Cinder sticker as well | 17:35 |
| JayF | TheJulia: https://github.com/eventlet/eventlet/blob/master/eventlet/wsgi.py#L1025 ... think about what might happen if get_errno() no longer works or if the errors themselves from ACCEPT_ERRNO moved/changed | 18:16 |
| JayF | TheJulia: this is what dtantsur and I were talking about, going to push a fix to eventlet and likely to oslo service as well | 18:16 |
| JayF | dtantsur: Talked to fungi as well, think we're going to fix this one in the open. I'm going to work on an eventlet fix for moving-forward, but am also going to see if there's something backportable I can do in oslo.service | 18:18 |
| JayF | I'll note during this conversation, it came up that we've had discussions about Ironic being technically under VMT, but we never got added to the list. I'm happy to push the change, and I think security sig is happy to accept, but just wanted to get a 'core review' on it in IRC first :D | 18:20 |
| fungi | yep, just need to push a change to add whatever repos to https://opendev.org/openstack/ossa/src/branch/master/doc/source/repos-overseen.rst and it's on you to make sure that list of requirements immediately below is met | 18:21 |
| fungi | and reach out to me directly or to the denizens of the #openstack-security more generally if you have any questions | 18:22 |
| JayF | ah that was it | 18:24 |
| JayF | last time we went to do this, we were halfway between LP and Storyboard | 18:24 |
| JayF | so "configure things for VMT access only/immedaitely" was not possible | 18:24 |
| fungi | well, it is also possible on storyboard, we have teams using it overseen by the vmt | 18:25 |
| JayF | I think the problem was more the answer to "what bug tracker are you using right now" was "uhhh" moreso than a solid answer | 18:26 |
| JayF | (now it's clearly LP everywhere, and we actually look at the danged bugs LOL) | 18:26 |
| fungi | storyboard has the ability to auto-add access for specific associated "teams" per project when someone opens a private story and marks it as security-related | 18:26 |
| fungi | so we set those projects to have the vmt auto-added in those situations | 18:26 |
| fungi | and then a vmt member adds the project-specific security team's access once intake is done | 18:27 |
| fungi | fairly similar to how lp works in that regard | 18:27 |
| fungi | i'd also be open to softening requirement #4 to "The defect tracker for each overseen repository must be configured to initially provide access for the VMT..." (striking out the "only"), since some of the projects grandparented into that list never got around to removing their initial access to those reports | 18:29 |
| fungi | only having the vmt members see them at first helps reduce the circle of people who are aware of a private report in cases where it's initially reported against the wrong project | 18:30 |
| JayF | I think that is unlikely to happen in Ironic | 18:30 |
| JayF | or unlikely to happen in Ironic where we don't have to be the ones to peel back the onion :) | 18:30 |
| fungi | so it's still preferable. and we aim for having the right project's security reviewers added to any report within 72 hours regardless | 18:31 |
| fungi | (usually it happens within hours, but depends on when the report comes in if there are weekends/holidays involved) | 18:31 |
| TheJulia | So I'm thinking we need an "Onion Peeler 5000" | 20:59 |
| TheJulia | anyone know anyone openstacky in the LA/SoCal area who does public speaking? | 22:21 |
| TheJulia | or might be interested in giving it a try? | 22:21 |
| JayF | TheJulia: can I steal your brain for 5m? | 22:22 |
| JayF | TheJulia: pretty sure RBAC enablement made some of our contributor docs invalid | 22:22 |
| JayF | and I'm trying to get adamcarthur5 working, we have all the stuff done but clients can't see nodes with devstack admin or demo projects it seems (?) | 22:23 |
| JayF | which I think is sorta what you were trying to communicate to me yesterday | 22:23 |
| JayF | but I need a happy path | 22:23 |
| JayF | (we are in a zoom or answer here) | 22:23 |
| TheJulia | givey the linky | 22:23 |
| JayF | https://us06web.zoom.us/j/87639022870?pwd=Jnpb1YEk7xxW7UftDiQSby27YZ3CwK.1 | 22:24 |
| *** tosky_ is now known as tosky | 23:14 | |
| opendevreview | Verification of a change to openstack/ironic stable/wallaby failed: [iRMC] Fix parse_driver_info bug enforcing SNMP v3 under FIPS mode https://review.opendev.org/c/openstack/ironic/+/885246 | 23:33 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!