| opendevreview | Merged openstack/bifrost master: Remove questionable defaults from the network configuration https://review.opendev.org/c/openstack/bifrost/+/829754 | 00:32 |
|---|---|---|
| opendevreview | Jacob Anders proposed openstack/ironic-python-agent master: Improve efficiency of storage cleaning in mixed media envs https://review.opendev.org/c/openstack/ironic-python-agent/+/818712 | 05:23 |
| janders | arne_wiebalck when you're online I'd welcome your thoughts on the hybrid-cleaning discussion here: https://review.opendev.org/c/openstack/ironic-python-agent/+/818712/23/ironic_python_agent/hardware.py#791 | 05:24 |
| janders | thanks in advance! | 05:25 |
| opendevreview | Merged openstack/ironic-python-agent bugfix/8.4: Use utf-16-le if BOM not present https://review.opendev.org/c/openstack/ironic-python-agent/+/831583 | 06:36 |
| arne_wiebalck | Good morning, Ironic! | 07:13 |
| rpittau | good morning ironic! o/ | 07:37 |
| dtantsur | happy Monday folks | 07:56 |
| arne_wiebalck | hey rpittau dtantsur o/ | 08:04 |
| rpittau | hey arne_wiebalck :) | 08:15 |
| janders | hey arne_wiebalck rpittau dtantsur and Ironic o/ | 08:21 |
| arne_wiebalck | hey janders o/ | 08:21 |
| opendevreview | Verification of a change to openstack/ironic stable/wallaby failed: Build the new cirros image even when netboot is the default https://review.opendev.org/c/openstack/ironic/+/830353 | 08:26 |
| arne_wiebalck | janders: on the hybrid cleaning, as an operator what I would like to avoid is to a) have long cleaning when I ask for short, and b) to configure this on a per disk model basis, so I would be leaning to option 1) | 08:32 |
| arne_wiebalck | janders: do you have any preferences? | 08:32 |
| arne_wiebalck | janders: or an option to enable option 1) in case case 2) is encountered | 08:33 |
| arne_wiebalck | janders: that may be another option | 08:33 |
| janders | arne_wiebalck yeah I think I am also slightly leaning towards 1) | 08:50 |
| janders | arne_wiebalck do you have much SATA-SSD storage deployed in hybrid SSD-HDD configuration? | 08:50 |
| arne_wiebalck | janders: we have some, but not the majority | 08:55 |
| arne_wiebalck | janders: the compute parts is non-hybrid, i.e. SSD only | 08:56 |
| arne_wiebalck | janders: the Ceph servers and the bulk storage are hybrid | 08:56 |
| janders | arne_wiebalck noted. With ceph/bulkstorage is that NVMe+HDD (no SATA SSD)? | 09:01 |
| janders | arne_wiebalck also do you have any SATA drives that support secure erase but do the long-running kind? | 09:03 |
| arne_wiebalck | janders: Ceph is different from databases is different from bulk storage :) | 09:05 |
| arne_wiebalck | janders: I would need to dig out the details, but there are all sorts of combinations I think | 09:05 |
| arne_wiebalck | janders: even within a service, i.e. there are Ceph servers with SSD+HDD, others with NVMe + SSD ... | 09:06 |
| arne_wiebalck | janders: I can't answer if we have the long-running secure erase type of hardware | 09:07 |
| rpittau | janders: just my 2 cents from old time operator days, option 1 seems the most sensible for the express option, also avoid false advertising :) | 09:07 |
| rpittau | For the future, maybe making that configurable could be an option | 09:07 |
| arne_wiebalck | janders: cannot since I don't know :) | 09:07 |
| arne_wiebalck | rpittau: ++ | 09:08 |
| janders | thank you arne_wiebalck and rpittau | 09:08 |
| janders | here is an idea: | 09:08 |
| janders | https://review.opendev.org/c/openstack/ironic-python-agent/+/818712/23/ironic_python_agent/hardware.py#1427 | 09:09 |
| janders | even as it stands, agent_enable_ata_secure_erase should allow controlling this | 09:09 |
| janders | let me check whether this is something we confiugure in conductor, or is it baked into the ramdisk or something | 09:10 |
| janders | it's in config | 09:16 |
| janders | arne_wiebalck I wonder if operators will realistically want ata secure erase in erase_devices but not in erase_devices_express (cause then we need a separate option) | 09:17 |
| janders | arne_wiebalck rpittau I also wonder - with information coming from driver_internal_info (like here https://review.opendev.org/c/openstack/ironic-python-agent/+/818712/23/ironic_python_agent/hardware.py#1427) can this be easily overriden on per-node basis? | 09:18 |
| janders | (cause the initial value would come from [agent] section in ironic.conf - at least this is how I've done it for original NVMe cleaning) | 09:18 |
| janders | thinking how to balance flexibility and simplicity and not having excess configuration for a relatively simple feature | 09:19 |
| arne_wiebalck | janders: a global configuration with a per-node override option is something we use for some of our nodes (to configure the IPMI protocol version IIRC), so this approach seems practical to me from an operations pov | 09:33 |
| janders | arne_wiebalck so - if you run into nodes that have the slow-secure-erase, can you set agent_enable_ata_secure_erase=False just on these nodes by updating driver_internal_info, correct? | 09:40 |
| janders | (trying to get the hang of how it all links together) | 09:40 |
| arne_wiebalck | janders: erm ... I usually use driver_info (rather than driver_internal_info) to pass options ... not sure if driver_internal_info is a one-way or two-way street tbh ... dtantsur would certainly know | 09:46 |
| dtantsur | driver_internal_info is not settable by a user (nor IPA), if that's your question | 09:52 |
| dtantsur | also: I'd like driver_internal_info to shrink down significantly | 09:52 |
| janders | thank you dtantsur | 09:55 |
| janders | is there another way to do a node-specific override of agent_enable_ata_secure_erase in the context of https://review.opendev.org/c/openstack/ironic-python-agent/+/818712/23/ironic_python_agent/hardware.py#1427 ? | 09:56 |
| dtantsur | janders: we actually have a way to pass configuration from ironic to IPA: https://opendev.org/openstack/ironic/src/branch/master/ironic/api/controllers/v1/ramdisk.py#L41-L66 | 09:56 |
| dtantsur | we just don't always use it, nor do we have a way to pass this config from a driver | 09:56 |
| dtantsur | (a potential enhancement!) | 09:56 |
| janders | right! dtantsur to give you full context, we got to talking about driver_(internal_)info while discussing how to go about the potential ata secure issue that TheJulia raised w/r/t hybrid cleaning patch: https://review.opendev.org/c/openstack/ironic-python-agent/+/818712/22..23/ironic_python_agent/hardware.py#b791 | 10:00 |
| janders | if you have time I would be curious to hear your thoughts on how best to go about this | 10:01 |
| janders | do we just remove ATA secure erase from erase_devices_express? | 10:01 |
| janders | do we make it configurable whether it's run or not? | 10:02 |
| dtantsur | sorry, I don't have brainpower to dive into this.. | 10:11 |
| dtantsur | I'd suggest you sync with TheJulia in your morning. She has much more experience in this area than me. | 10:11 |
| janders | no worries, thank you for your inputs so far dtantsur, much appreciated. | 10:11 |
| janders | arne_wiebalck how exactly do you do the per-node override for IPMI protocol version? | 10:19 |
| janders | I just edited the hybrid cleaning patch to see what it would look like without ata_erase, will try to come up with a version with a dedicated config option controlling this | 10:20 |
| arne_wiebalck | janders: I think there are explicit options to do this ... let me see if I can find a corresponding node ... | 10:24 |
| arne_wiebalck | janders: I pass ipmi_protocol_version ... is this a local patch? checking ... | 10:31 |
| arne_wiebalck | janders: no, it is not | 10:31 |
| arne_wiebalck | janders: set in driver_info (https://docs.openstack.org/ironic/latest/admin/drivers/ipmitool.html) | 10:33 |
| janders | arne_wiebalck ACK. So this works well because we're updating driver_info. NVMe/SATA secure erase enable/disable are in driver_internal_info, so this approach won't work, right? | 10:35 |
| arne_wiebalck | janders: not sure if internal info is for the node to report what it used/found, or if the configuration is put there for the IPA to consume, or both | 10:38 |
| janders | arne_wiebalck based on Dmitry's comment above: "driver_internal_info is not settable by a user (nor IPA)" | 10:40 |
| janders | arne_wiebalck do we currently have any support for customising cleaning on per-node level, do you know? | 10:41 |
| arne_wiebalck | janders: not in general, I think ... downstream we use either driver_info or --extra to pass information to the IPA | 10:43 |
| janders | right | 10:44 |
| iurygregory | good morning Ironic | 11:22 |
| opendevreview | Merged openstack/ironic stable/wallaby: Build the new cirros image even when netboot is the default https://review.opendev.org/c/openstack/ironic/+/830353 | 11:24 |
| janders | hey iurygregory | 11:24 |
| opendevreview | Riccardo Pittau proposed openstack/ironic master: Use pycdlib to extract deploy iso https://review.opendev.org/c/openstack/ironic/+/819121 | 11:29 |
| opendevreview | Verification of a change to openstack/ironic bugfix/19.0 failed: More fixes for anaconda deploy interface https://review.opendev.org/c/openstack/ironic/+/831867 | 11:30 |
| opendevreview | Riccardo Pittau proposed openstack/ironic master: Use pycdlib to extract deploy iso https://review.opendev.org/c/openstack/ironic/+/819121 | 11:30 |
| janders | see you tomorrow Ironic o/ | 12:04 |
| iurygregory | bye o/ | 12:05 |
| dtantsur | morning iurygregory | 12:10 |
| iurygregory | hey dtantsur | 12:10 |
| iurygregory | I've added a -1 in the release patches to create stable/yoga for ironic,inspector,ipa, ipa-b, bifrost | 12:20 |
| dtantsur | why do we even have them? Oo | 12:21 |
| iurygregory | for ironic-tempest-plugin we probably want to include https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/829665 wondering if we are ok where the test is being added and if the copyright line is necessary (thinking face) | 12:21 |
| dtantsur | the copyright line is meaningless, but some companies require it nonetheless | 12:22 |
| iurygregory | dtantsur, i would say that the release team is reading our mind (since I was planing in cut the release this week) | 12:22 |
| dtantsur | heh | 12:22 |
| iurygregory | I really want this type of crystal ball :D | 12:23 |
| *** Swapnil is now known as Guest2104 | 13:25 | |
| TheJulia | good morning | 13:44 |
| MahnoorAsghar | Good morning o/ | 13:45 |
| TheJulia | iurygregory: tempest is not a versioned release | 13:45 |
| TheJulia | so there is no need to rush to include it at any time | 13:45 |
| opendevreview | Ruby Loo proposed openstack/ironic bugfix/20.0: Anaconda deploy handles configdrive correctly https://review.opendev.org/c/openstack/ironic/+/833420 | 13:45 |
| * TheJulia is absurdly tired this morning | 13:48 | |
| * MahnoorAsghar Coffee++? | 13:49 | |
| TheJulia | Indeed | 13:49 |
| rpittau | good morning TheJulia :) | 13:58 |
| dtantsur | morning TheJulia | 13:59 |
| iurygregory | good morning TheJulia =) | 14:10 |
| iurygregory | yeah I know the plugin is not versioned with branches =) | 14:10 |
| iurygregory | but releases requested a release of the plugin =) | 14:10 |
| opendevreview | Merged openstack/ironic bugfix/19.0: More fixes for anaconda deploy interface https://review.opendev.org/c/openstack/ironic/+/831867 | 14:11 |
| opendevreview | Ruby Loo proposed openstack/ironic stable/xena: Fix rebuilds using anaconda deploy interface https://review.opendev.org/c/openstack/ironic/+/833558 | 14:11 |
| opendevreview | Tadeas Kot proposed openstack/ironic-specs master: WIP: Merge introspection into ironic https://review.opendev.org/c/openstack/ironic-specs/+/833632 | 14:17 |
| TheJulia | soo many emails | 14:47 |
| TheJulia | iurygregory: doesn't mean it has to ship right now, we can always merge in a few weeks and then that is the latest version to be used | 14:48 |
| iurygregory | yup I agree =) | 14:53 |
| dtantsur | I *think* they somehow tag (?) the compatible version\ | 14:56 |
| TheJulia | they don't really | 15:06 |
| dtantsur | yeah, I guess I confused it with the tag that is created when a branch enters EM | 15:07 |
| TheJulia | for in-tree and "approved plugins" they tag the test UUIDs to the "stable release name" | 15:07 |
| TheJulia | but that is for things like the certification stuffs | 15:08 |
| opendevreview | Harald Jensås proposed openstack/networking-baremetal master: WIP - OpenConfig YANG and Netconf https://review.opendev.org/c/openstack/networking-baremetal/+/832268 | 15:34 |
| JayF | ~>. | 15:42 |
| arne_wiebalck | mraineri: from what I see redfish_utilities do not allow to override the boot mode (only the boot target) ... or am I missing something? | 15:42 |
| JayF | whoops, sorry, was disconnected from screen no the client | 15:42 |
| mraineri | What boot mode are you looking for specifically? | 15:43 |
| arne_wiebalck | mraineri: I have a UEFI machine I would like to boot in BIOS mode | 15:43 |
| mraineri | Ah, I see | 15:43 |
| mraineri | Let me check | 15:43 |
| arne_wiebalck | mraineri: thank you! | 15:43 |
| dtantsur | arne_wiebalck: I'm quite sure Ironic does it | 15:44 |
| mraineri | Yeah, the intent for the script was to keep it simplistic; I imagined most users wouldn't care and just want to control the target | 15:44 |
| mraineri | If you need to control UEFI vs Legacy mode, we'd need to add that | 15:44 |
| mraineri | But that's a pretty simple addition to the script | 15:45 |
| arne_wiebalck | dtantsur: the Ironic way would be to set it on the node and let Ironic change it (via Redfish) upon the next boot? | 15:47 |
| arne_wiebalck | dtantsur: mraineri: it is sth I would need to give users access to, so via redfish_utilities would be pretty simple | 15:49 |
| dtantsur | arne_wiebalck: yep, via the boot_mode capability | 15:49 |
| arne_wiebalck | but via the API and some policy would also be doable I guess | 15:49 |
| mraineri | There's a "Boot-Mode" branch and a pull request in Tacklebox that add "--mode" to the script | 15:59 |
| *** Swapnil is now known as Guest2120 | 15:59 | |
| iurygregory | #startmeeting ironic | 16:00 |
| opendevmeet | Meeting started Mon Mar 14 16:00:00 2022 UTC and is due to finish in 60 minutes. The chair is iurygregory. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'ironic' | 16:00 |
| TheJulia | o/ | 16:00 |
| iurygregory | Hello ironicers, welcome to our weekly meeting o/ | 16:00 |
| dtantsur | o/ | 16:00 |
| ameya49 | o/ | 16:00 |
| rpittau | o/ | 16:00 |
| kamlesh6808c | o/ | 16:00 |
| ajya | o/ | 16:00 |
| rloo | o/ | 16:00 |
| MahnoorAsghar | o/ | 16:00 |
| iurygregory | The agenda for our meeting can be found in the wiki | 16:00 |
| iurygregory | #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting | 16:00 |
| iurygregory | #topic Announcements / Reminder | 16:01 |
| arne_wiebalck | o/ | 16:01 |
| iurygregory | #info Yoga final release is March 30th, we will be trying to release the rest of the projects during this week. | 16:01 |
| rpioso | \o | 16:02 |
| iurygregory | #info Zed PTG April 4 - 8 | 16:02 |
| iurygregory | we already have an etherpad, feel free to add topics you would like to discuss during the PTG | 16:02 |
| iurygregory | #link https://etherpad.opendev.org/p/ironic-zed-ptg | 16:02 |
| iurygregory | Does anyone have anything else to announce/remind us of ? | 16:03 |
| iurygregory | ok, moving on because we have a big agenda for today's meeting =) | 16:04 |
| MahnoorAsghar | Perhaps I should add that this is my last week with Outreachy | 16:04 |
| iurygregory | wow time flies =) | 16:04 |
| MahnoorAsghar | It does! Will come back in Open discussion ^-^ | 16:05 |
| iurygregory | awesome =D | 16:05 |
| iurygregory | #topic Review action items from previous meeting | 16:05 |
| rpioso | MahnoorAsghar: Congrats! | 16:05 |
| MahnoorAsghar | Thank you :D | 16:06 |
| iurygregory | skipping since we don't have any action items | 16:06 |
| iurygregory | #topic Review subteam status reports | 16:06 |
| iurygregory | #link https://etherpad.opendev.org/p/IronicWhiteBoard | 16:06 |
| iurygregory | starting around L62 | 16:06 |
| rpittau | I believe the support for CS9 in bifrost and ipa-builder is completed | 16:08 |
| iurygregory | agree | 16:08 |
| iurygregory | I've updated the items I had info already, should we wait a bit more or we can move on? | 16:11 |
| TheJulia | Likely proceed | 16:13 |
| iurygregory | moving on =) | 16:13 |
| iurygregory | #topic Deciding on priorities for the coming week | 16:13 |
| *** melwitt_ is now known as melwitt | 16:14 | |
| iurygregory | ok, since we will be trying to create stable/yoga for ironic,inspector,ipa,ipa-b,bifrost this week we will focus on patches for this 5 projects =) | 16:14 |
| TheJulia | sounds reasonable | 16:14 |
| iurygregory | any outstanding patches we think would be good to have in Yoga? | 16:15 |
| dtantsur | the Jacob's cleaning patch, I assume? | 16:16 |
| arne_wiebalck | yes, it is on the discussion list for today | 16:16 |
| iurygregory | ++, we will have a discussion regarding the patch today | 16:16 |
| iurygregory | yeah, tks arne_wiebalck =) | 16:16 |
| iurygregory | I will be checking the projects that don't have open patches and submitting a DNM just to check if the CI is fine before cutting the release for it | 16:17 |
| dtantsur | ++ | 16:19 |
| iurygregory | ok, moving to our next topic, if anyone has patches that will need attention please add the hashtag to it =) | 16:19 |
| iurygregory | #topic Discussion | 16:19 |
| iurygregory | okay first topic for our discussion is mine =) | 16:20 |
| iurygregory | #topic Zed PTG slots | 16:21 |
| iurygregory | #link http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027647.html | 16:21 |
| iurygregory | based on the feedback I got last week from some people we would go with option A or C | 16:21 |
| TheJulia | either work for me | 16:22 |
| iurygregory | if we want to go with option C I would need to know who would be responsible for starting the meeting etc =) | 16:23 |
| arne_wiebalck | A minimises the overlap with the TC | 16:23 |
| rloo | iurygregory: given that you're the PTL, I'd prefer A | 16:23 |
| iurygregory | arne_wiebalck, yup | 16:24 |
| rpittau | A also for me | 16:24 |
| rloo | or D? -- is 17:00-18:00 late for people? | 16:24 |
| arne_wiebalck | for A: if we work hard during the week, we get Friday off :-D | 16:24 |
| iurygregory | keep in mind that the 2hrs on Friday will be only in case *we really need* | 16:25 |
| rloo | let's just decide now that we won't need Friday ;) | 16:25 |
| iurygregory | yeah =) | 16:25 |
| rloo | 3 hours T, W, Th is ... a lot. Did we do that before? I'd think 2 hours would be sufficient? | 16:26 |
| rpittau | I doubt we will get to Friday with enough brain power left :) | 16:26 |
| iurygregory | rloo, yup we had this in the past | 16:26 |
| rloo | ah. ok. then let's try to work hard and be more concise, ha ha. | 16:26 |
| iurygregory | we did two breaks I think *10-15min each* | 16:27 |
| arne_wiebalck | :-D | 16:27 |
| iurygregory | just a heads-up the 14-17 for Tue is all booked so we will probably use something else to have the meeting | 16:27 |
| iurygregory | I will figure this out and let everyone knows =) | 16:28 |
| rloo | how can things be 'all booked' if this is virtual? | 16:28 |
| TheJulia | limited number of zoom rooms | 16:28 |
| iurygregory | ^ this =) | 16:28 |
| iurygregory | from A to N (I think) | 16:28 |
| arne_wiebalck | how come we have less rooms than registered projects? | 16:29 |
| rloo | arne_wiebalck: maybe you can ask that question at the tc level? heh | 16:29 |
| iurygregory | ops XD | 16:29 |
| arne_wiebalck | rloo: heh | 16:29 |
| iurygregory | I will talk with the organizers, just to check if they are able to add another or not | 16:29 |
| iurygregory | it would be amazing if they can =) | 16:30 |
| iurygregory | maybe is related to $$$$ | 16:30 |
| iurygregory | ok, moving to our next topic, rpittau the mic is yours | 16:31 |
| iurygregory | #topic March 27th time change in EU, move the meeting 1 hour earlier? | 16:31 |
| TheJulia | I thought we already reached consensus on this | 16:31 |
| iurygregory | he sent an email to the ML and we would wait to see (at least I understood that way...) | 16:32 |
| rloo | the email sez 'if there are no objections'... | 16:33 |
| rpittau | well, noone replied so I guess we're ok with moving the meeting one hour earlier starting from march 28 ? | 16:33 |
| TheJulia | Lazy Consensus :) | 16:33 |
| arne_wiebalck | rpittau: !! | 16:33 |
| * arne_wiebalck has a lazy finger it seems | 16:34 | |
| arne_wiebalck | rpittau: ++ | 16:34 |
| rpittau | :D | 16:34 |
| rloo | yes, please move it! Anyway, you can always wait til after next meeting. it starts Mon Mar 28 :) | 16:34 |
| iurygregory | yeah | 16:35 |
| iurygregory | ok, moving to our next topic with kamlesh6808c | 16:35 |
| iurygregory | #topic usage of DRACClient in ironic-tempest-plugin for raid cleaning tempest test for physical baremetal servers | 16:35 |
| TheJulia | Why? | 16:35 |
| kamlesh6808c | Hi, Ironic Team ! | 16:35 |
| iurygregory | kamlesh6808c, feel free to provide details so people can understand | 16:35 |
| TheJulia | The *intent* of tempest plugins are that they are to be executed extenrally from a cloud, with no anormal level of context or access to the backend infrastucture | 16:35 |
| TheJulia | No client libraries are permitted under Tempest command ment T102 | 16:36 |
| kamlesh6808c | I am part of Dell team where we are working on improving the test coverage in its third-party CI. | 16:36 |
| TheJulia | commandment | 16:36 |
| dtantsur | I have hard feelings about "no client libraries", but I do agree that dracclient may be a bit excessive.. | 16:37 |
| kamlesh6808c | Currently I am working raid cleaning step tempest implementation , This execution we are performing and testing on physical baremetal servers . | 16:37 |
| kamlesh6808c | In order to leverage build_raid_and_verify_node method (https://github.com/openstack/ironic-tempest-plugin/blob/37d61a4acf34040c3f4af63a3b2142bfe59d81a1/ironic_tempest_plugin/tests/scenario/baremetal_standalone_manager.py#L580 ) in test cleaning, we are planning to use root device hint as " by path" in order to deploy node (present hint as “name” doesn’t work on physical BareMetal). | 16:37 |
| TheJulia | dtantsur: well, its an an independent api contract test above all else, so... *shrugs* | 16:37 |
| TheJulia | kamlesh6808c: so your requiring an elevated level of access and insight to perform the test | 16:38 |
| kamlesh6808c | Query or concern i would say how can we use DRACClient in ironic-tempest-plugin to grab virtual disk information which will get generated during runtime of raid create configuration on Servers ? | 16:38 |
| TheJulia | That seems to be counter to https://docs.openstack.org/tempest/latest/HACKING.html#test-data-configuration | 16:38 |
| dtantsur | TheJulia: I wish we could use keystoneauth at least | 16:38 |
| TheJulia | dtantsur: that would be glorious | 16:39 |
| * rpioso requests folks listen to the problem statement. | 16:39 | |
| TheJulia | kamlesh6808c: Realistically, from my point of view, it would need to be supplied configuration outside of the test job, and thus can't be in the test itself. So, a configuration parameter in which such data can be supplied | 16:39 |
| TheJulia | It would be a violation of the tempest use model to use a client library to go get data from the drac card directly | 16:40 |
| TheJulia | that implies *elevated* and *private* infrastucture access, both which are contrary to the use and meaning of tempest | 16:40 |
| TheJulia | Because, the use is "as a user of a cloud from outside that cloud" | 16:40 |
| dtantsur | I wonder if the test can be combined with inspection to get the necessary data... | 16:41 |
| TheJulia | dtantsur: that seems reasonable | 16:41 |
| kamlesh6808c | ohh any suggestion of way ahead? | 16:41 |
| rpioso | dtantsur: Unfortunately, it can't. | 16:42 |
| dtantsur | rpioso: even in-band, via inspector? | 16:42 |
| rpioso | dtantsur: Nope, again. | 16:42 |
| TheJulia | API surface access to existing services should be entirely doable | 16:42 |
| dtantsur | sad | 16:42 |
| rpioso | Information about the virtual disk is needed to construct the by_path root device hint. The iDRAC's OOB APIs offer that. | 16:43 |
| dtantsur | I'm not a tempest purist, to be honest. Given what we do in the n-g-s tempest plugin, using dracclient doesn't sound too bad to me. | 16:43 |
| dtantsur | But then again, if you ask me, I'd burn tempest with fire :) | 16:43 |
| TheJulia | dtantsur: link to what your referring to? | 16:44 |
| rpioso | We might be able to use sushy, instead of dracclient. Our downstream JetPack scripts use dracclient, so that's more straightforward for us. | 16:44 |
| TheJulia | that would still be external elevated access to the backend | 16:44 |
| dtantsur | TheJulia: n-g-s literally accesses local network interfaces: https://opendev.org/openstack/networking-generic-switch/src/branch/master/tempest_plugin/tests/scenario/test_ngs_basic_ops.py#L51 | 16:44 |
| dtantsur | not n-g-s, its "tempest" plugin | 16:44 |
| TheJulia | dtantsur: eww, yeah | 16:45 |
| TheJulia | that is really bad since it means that test can only ever be run in devstack locally | 16:45 |
| TheJulia | that should be fixed... | 16:45 |
| dtantsur | rpioso: sushy would be slightly better from the requirements perspective | 16:45 |
| dtantsur | I think dracclient is not in global-requirements | 16:45 |
| rpioso | dtantsur: Could that be a follow-on thing? | 16:46 |
| dtantsur | rpioso: well.. you'll have hard time making the requirements job accept adding dracclient? | 16:46 |
| dtantsur | (unless I've forgotten how the requirements processes work) | 16:46 |
| TheJulia | And it is likely to trigger a T102 check | 16:46 |
| rpioso | dtantsur, TheJulia: Gotcha :) We'll investigate using sushy. | 16:47 |
| TheJulia | https://opendev.org/openstack/patrole/src/branch/master/patrole_tempest_plugin/hacking/checks.py#L24-L54 is not too horrible | 16:48 |
| rpioso | dtantsur: We'll also double check your introspection suggestion. Seems like that would require yet another reboot of the physical server. | 16:48 |
| kamlesh6808c | yes.thanks richard ,TheJulia,dtansur, Iury | 16:48 |
| iurygregory | np | 16:48 |
| dtantsur | TheJulia: ha, we can use keystoneauth! :) | 16:48 |
| dtantsur | rpioso++ | 16:48 |
| iurygregory | moving to our next topic | 16:49 |
| TheJulia | https://opendev.org/openstack/tempest/src/branch/master/tempest/hacking/checks.py#L43 lifted directly from tempest's code | 16:49 |
| iurygregory | arne_wiebalck, the mic is yours =) | 16:49 |
| arne_wiebalck | This is about the hybrid cleaning patch from janders mentioned earlier. | 16:49 |
| iurygregory | #topic Hybrid Cleaning Patch - how to go about the concern about potentially long-running ata_erase? | 16:49 |
| iurygregory | #link https://review.opendev.org/c/openstack/ironic-python-agent/+/818712 | 16:49 |
| arne_wiebalck | After TheJulia has raised some concerns he laid 3 options how to move forward and would like to get some input. | 16:50 |
| TheJulia | My preference would be to mirror the pattern, use a thread pool | 16:50 |
| arne_wiebalck | parallelism? | 16:51 |
| TheJulia | Every operator who has enabled that with cleaning has come back and expressed gratitude cleaning is way faster | 16:51 |
| TheJulia | yes | 16:51 |
| TheJulia | well, gratitude that cleaning... | 16:51 |
| dtantsur | it still can take long? | 16:51 |
| TheJulia | Secure erase suffers from a similar conunddrum just as using shred against the filesystem | 16:52 |
| arne_wiebalck | yes | 16:52 |
| dtantsur | if we call something "express", we should make it fast.. | 16:52 |
| arne_wiebalck | I think when we say "express", it should be express :) | 16:52 |
| TheJulia | yes, if you have a spinning device and no encryption key set/in use or just not supported, secure erase becomes a zero-out operation | 16:52 |
| TheJulia | fast ++ | 16:52 |
| arne_wiebalck | TheJulia: dtantsur right | 16:52 |
| dtantsur | I don't want to upset janders.. but I wonder if we're introducing this feature prematurely | 16:53 |
| TheJulia | s/shred against the filesystem/shred against the block device/ | 16:53 |
| dtantsur | if we understood the requirements behind it, we would not try to guess | 16:53 |
| arne_wiebalck | the problem is we cannot have it all as we do not know if when we try fast, we get fast | 16:53 |
| arne_wiebalck | the requirement was to have sth which is smart enough to do the maximum in a short time | 16:54 |
| arne_wiebalck | rather than only metadata or only shred | 16:54 |
| dtantsur | define "short time" | 16:54 |
| arne_wiebalck | less than 1 minute per disk | 16:54 |
| dtantsur | is risk to have it running 2 hours acceptable? | 16:55 |
| arne_wiebalck | I don't think so: what if users just want to redploy? | 16:55 |
| dtantsur | right | 16:55 |
| dtantsur | then we either need to find a way to determine if ATA erase is going to be fast.. or skip ATA erase from this new call | 16:55 |
| iurygregory | can the user check the type of cleaning we are doing? | 16:55 |
| dtantsur | an operator has access to configuration | 16:56 |
| TheJulia | So, the disks are *supposed to* provide an estimated time | 16:56 |
| dtantsur | an API user can only determine when it's already running | 16:56 |
| TheJulia | before you launch it | 16:56 |
| arne_wiebalck | dtantsur: I was suggesting to launch and abort if too long, but this seems to break some hardware. | 16:56 |
| dtantsur | yeah, I don't think aborting is a good idea | 16:56 |
| TheJulia | That is the give away on the pattern | 16:56 |
| TheJulia | Often, you can't abort secure erase ops | 16:56 |
| arne_wiebalck | I have no feeling for if a disk offers secure erase, how often does it take "long" ? | 16:57 |
| TheJulia | if you *try* you brick the disk into a security locked state and we've seen the couple people who've needed help with such issues over the years | 16:57 |
| arne_wiebalck | one suggestion I had was to try, let operators run into, and disable on a per node basis | 16:57 |
| TheJulia | arne_wiebalck: getting samples | 16:57 |
| arne_wiebalck | but then it seems we cannot configure this per node | 16:58 |
| dtantsur | I think there are clean priorities overrides per node? | 16:58 |
| dtantsur | or only in the configuration? | 16:58 |
| dtantsur | (we do need janders in this discussion...) | 16:58 |
| arne_wiebalck | we could try to schedule a dedicated session maybe? | 16:58 |
| iurygregory | ++ | 16:59 |
| arne_wiebalck | not sure this will be feasible with the interested party nicely distributed all over the globe | 16:59 |
| arne_wiebalck | *parties | 16:59 |
| rloo | is that a ptg topic, or something that needs to addressed asap? | 16:59 |
| arne_wiebalck | janders would like to get this into yoga | 16:59 |
| arne_wiebalck | so ptg is too late | 16:59 |
| rloo | oh... | 16:59 |
| dtantsur | Jacob wanted it in Yoga, but I don't think it's business-critical for us | 17:00 |
| arne_wiebalck | but it would be a good ptg topic | 17:00 |
| iurygregory | we discussed as a PTG topic last time | 17:00 |
| MahnoorAsghar | maybe same time of day, different date? | 17:00 |
| TheJulia | https://paste.openstack.org/show/bqeB4BHeKR2AtVWVJ6n7/ | 17:00 |
| dtantsur | can we mark it tech preview / proof of concept / do not use if you don't understand? | 17:00 |
| TheJulia | wow, one of my disks doesn't support Security at all *gasp* | 17:00 |
| TheJulia | arne_wiebalck: ^^^ | 17:00 |
| iurygregory | dtantsur, can we do that? O.o | 17:00 |
| arne_wiebalck | yes, this was what I had in mind | 17:00 |
| arne_wiebalck | basically opt-in | 17:00 |
| arne_wiebalck | and then refine if too many issues, e.g. with a config option | 17:01 |
| dtantsur | iurygregory: who will forbid us? :) | 17:01 |
| rloo | i'm concerned. unless it is a high priority, we shouldn't try to get it into yoga. Or at least, unless there is fairly strong consensus on a solution, we shouldn't. | 17:01 |
| arne_wiebalck | TheJulia: ++ | 17:01 |
| iurygregory | dtantsur, not me :D (I'm just checking) | 17:01 |
| dtantsur | TheJulia: so, if both times are within several minutes, we can continue? | 17:01 |
| arne_wiebalck | rloo: I agree | 17:01 |
| TheJulia | dtantsur: likely, but we can run these things in parallel as well | 17:02 |
| arne_wiebalck | rloo: so maybe it is a good ptg topic after all :) | 17:02 |
| TheJulia | The first one is an intel ssd, the second one is a samsung ssd | 17:02 |
| iurygregory | ++ | 17:02 |
| dtantsur | even in parallel, 36 minutes is not express | 17:02 |
| TheJulia | the third is a enterprise grade 7200 rpm spinner | 17:02 |
| rpittau | probably leaving the option jsut for nvme for now is better, and see possible solutions for ATA during PTG ? | 17:02 |
| arne_wiebalck | rpittau: it is the least invasive if we want to merge sth for yoga | 17:03 |
| rpittau | yeah, exactly | 17:03 |
| rpittau | and nvme express works | 17:03 |
| arne_wiebalck | rpittau: but will we ever touch this again once sth is merged ? | 17:04 |
| TheJulia | another question is "how do I re-run multiple distinct cleaning steps if I skip drives because of a reason and not re-run on them | 17:04 |
| TheJulia | I'm starting to think this might just be too early to call ready to ship | 17:04 |
| rpittau | arne_wiebalck: I think so, it's still a half-feature :) | 17:04 |
| arne_wiebalck | rpittau: yeah ... but we leave out the tricky bit, and everyone knows that | 17:05 |
| arne_wiebalck | TheJulia: I agree, maybe we should wait (and discuss as rloo suggested) | 17:05 |
| iurygregory | yeah, we can try to have discussion before the ptg and also during the PTG | 17:06 |
| arne_wiebalck | ok, let's see if we can settle before, otherwise it has to wait | 17:06 |
| iurygregory | cool | 17:06 |
| iurygregory | we are over the time of our meeting, but we have the Outreachy part | 17:07 |
| iurygregory | those who can't stay it's fine =) | 17:07 |
| iurygregory | I don't think we have updates for the SIG right arne_wiebalck ? | 17:07 |
| arne_wiebalck | iurygregory: NTR for the SIG | 17:07 |
| arne_wiebalck | sorry, nothing to report :) | 17:08 |
| iurygregory | no worries | 17:09 |
| iurygregory | MahnoorAsghar, TheJulia what would be the Outreachy discussion? =) | 17:09 |
| MahnoorAsghar | I have been working on the Sphinx extension to process docstrings | 17:10 |
| MahnoorAsghar | And would appreciate reviews, if somebody finds time please do review! | 17:11 |
| TheJulia | Part of the reason why is this is MahnoorAsghar's last week working on it as part of Outreachy | 17:11 |
| iurygregory | ack, I will provide some feedback today o/ | 17:11 |
| MahnoorAsghar | [https://review.opendev.org/c/openstack/ironic/+/827200/] | 17:11 |
| MahnoorAsghar | Small patch coming up, just to add a bit more docstring input into the extension | 17:12 |
| TheJulia | Thanks MahnoorAsghar | 17:12 |
| MahnoorAsghar | :) | 17:12 |
| MahnoorAsghar | I want to add it for all the API modules, but that would make the patch very hard to review | 17:12 |
| TheJulia | understandable | 17:13 |
| iurygregory | yeah, no worries! thank you for working on this! | 17:13 |
| MahnoorAsghar | ^-^ | 17:13 |
| MahnoorAsghar | It has been a pleasure working on it :) | 17:14 |
| rloo | thank you MahnoorAsghar! | 17:14 |
| MahnoorAsghar | :)) | 17:14 |
| iurygregory | we appreciate your efforts in our community! Tyvm! =) | 17:14 |
| MahnoorAsghar | I have had fun doing this, thanks to the community and Julia's help along the way :) | 17:15 |
| iurygregory | nice! | 17:16 |
| iurygregory | Thanks everyone! sadly it's time to end our meeting =) | 17:16 |
| iurygregory | #endmeeting | 17:16 |
| opendevmeet | Meeting ended Mon Mar 14 17:16:22 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:16 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/ironic/2022/ironic.2022-03-14-16.00.html | 17:16 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/ironic/2022/ironic.2022-03-14-16.00.txt | 17:16 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/ironic/2022/ironic.2022-03-14-16.00.log.html | 17:16 |
| iurygregory | but we are still around :D | 17:16 |
| MahnoorAsghar | Had so much in the agenda today | 17:16 |
| rpittau | heh almost time to make dinner here :) | 17:16 |
| MahnoorAsghar | I'm gonna run some tests and push the patch :) | 17:17 |
| MahnoorAsghar | patchset* | 17:18 |
| rpittau | good night! o/ | 17:25 |
| dtantsur | o/ | 17:57 |
| arne_wiebalck | bye everyone o/ | 17:57 |
| opendevreview | Ruby Loo proposed openstack/ironic stable/xena: Fix rebuilds using anaconda deploy interface https://review.opendev.org/c/openstack/ironic/+/833558 | 18:41 |
| opendevreview | Riccardo Pittau proposed openstack/ironic-python-agent-builder master: Update qemu version https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/776507 | 21:30 |
| opendevreview | Steve Baker proposed openstack/ironic-python-agent stable/train: Re-read the partition table with partx -a, part 2 https://review.opendev.org/c/openstack/ironic-python-agent/+/821792 | 22:31 |
| janders | Good morning Ironic o/ | 23:16 |
| janders | TheJulia regarding https://review.opendev.org/c/openstack/ironic-python-agent/+/818712, would you have a more favourable view of it if I just remove ata_erase in the initial version? | 23:18 |
| janders | We can then discuss what would it take to add it back and whether it's worth it at the PTG | 23:18 |
| TheJulia | janders: did you read the weekly meeting notes? | 23:32 |
| janders | I did look through scrollback but there isn't a clear direction coming out of it | 23:34 |
| janders | TheJulia personally I don't see anything too controversial about this if we run nvme_erase on NVMe devices and fallback to a metadata clean on non-NVMe devices - that essentially makes it a "hardware assisted" metadata_erase (which would be very useful to me right away). | 23:46 |
| janders | TheJulia having said that I don't see a clear yes or no to that approach in the meeting log, hence the question | 23:47 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!