| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2026-06-17 | |||
| 13:32:23 | chandankumar | or I can do opposite, take some of the work from nvmevirt and add it into pci-sim | |
| 13:32:29 | chandankumar | But I need to think on that | |
| 13:33:02 | chandankumar | on another note, I was writting some tests to validate cyborg placemnt workflow with pci scenario test https://review.opendev.org/c/openstack/cyborg-tempest-plugin/+/992210 it might be useful | |
| 13:33:23 | chandankumar | I will update my above review with pci-sim work for the tempest tests | |
| 13:33:26 | chandankumar | brb | |
| 13:46:51 | sean-k-mooney | oh cool | |
| 13:47:35 | sean-k-mooney | ya i was plannign to focus on scenairo test to validate the vm lifecycle | |
| 13:47:50 | sean-k-mooney | so the placmeent reporting tests will complement that | |
| 14:02:44 | opendevreview | Merged openstack/cyborg master: devstack: add pci-sim fake SR-IOV PCI passthrough test fixture https://review.opendev.org/c/openstack/cyborg/+/989470 | |
| 14:02:46 | opendevreview | Merged openstack/cyborg master: Add pci-sim developer guide https://review.opendev.org/c/openstack/cyborg/+/991177 | |
| 14:55:44 | opendevreview | chandan kumar proposed openstack/cyborg master: Rename devstack CYBORG_CONF_FILE to CYBORG_CONF for consistency https://review.opendev.org/c/openstack/cyborg/+/979805 | |
| 14:55:45 | opendevreview | chandan kumar proposed openstack/cyborg master: Add NVMeVirt emulated NVMe device support for devstack https://review.opendev.org/c/openstack/cyborg/+/977083 | |
| 14:57:40 | opendevreview | chandan kumar proposed openstack/cyborg master: Add NVMeVirt emulated NVMe device support for devstack https://review.opendev.org/c/openstack/cyborg/+/977083 | |
| 15:30:27 | opendevreview | chandan kumar proposed openstack/cyborg master: Rename devstack CYBORG_CONF_FILE to CYBORG_CONF for consistency https://review.opendev.org/c/openstack/cyborg/+/979805 | |
| 15:30:28 | opendevreview | chandan kumar proposed openstack/cyborg master: Add NVMeVirt emulated NVMe device support for devstack https://review.opendev.org/c/openstack/cyborg/+/977083 | |
| #openstack-cyborg - 2026-06-18 | |||
| 05:26:39 | opendevreview | chandan kumar proposed openstack/cyborg master: Add NVMeVirt emulated NVMe device support for devstack https://review.opendev.org/c/openstack/cyborg/+/977083 | |
| 06:29:36 | opendevreview | chandan kumar proposed openstack/cyborg master: Add NVMeVirt emulated NVMe device support for devstack https://review.opendev.org/c/openstack/cyborg/+/977083 | |
| 07:13:56 | chandankumar | sean-k-mooney: https://123b844dd0bc940cd071-d2975a8f065f970ca29e743c021b8a36.ssl.cf1.rackcdn.com/openstack/5f698c9d53e44e52bbd22509f59b8b25/testr_results.html tempest test is working now with nvmevirt and pci-sim | |
| 07:30:58 | opendevreview | chandan kumar proposed openstack/cyborg-tempest-plugin master: [WIP] Add cyborg pci nvme test https://review.opendev.org/c/openstack/cyborg-tempest-plugin/+/979847 | |
| 07:32:38 | opendevreview | chandan kumar proposed openstack/cyborg-tempest-plugin master: [WIP] Add cyborg pci nvme test https://review.opendev.org/c/openstack/cyborg-tempest-plugin/+/979847 | |
| 07:40:13 | opendevreview | chandan kumar proposed openstack/cyborg-tempest-plugin master: [WIP] Add cyborg pci nvme test https://review.opendev.org/c/openstack/cyborg-tempest-plugin/+/979847 | |
| 07:40:47 | chandankumar | revived the old nvmevirt scenario tests, might not be ready for review, but seems to be working | |
| 07:41:08 | chandankumar | for pci-sim | |
| 07:44:13 | opendevreview | chandan kumar proposed openstack/cyborg-tempest-plugin master: [WIP] Add cyborg pci nvme test https://review.opendev.org/c/openstack/cyborg-tempest-plugin/+/979847 | |
| 10:02:03 | opendevreview | chandan kumar proposed openstack/cyborg-tempest-plugin master: [WIP] Add cyborg pci nvme test https://review.opendev.org/c/openstack/cyborg-tempest-plugin/+/979847 | |
| #openstack-cyborg - 2026-06-19 | |||
| 04:56:28 | opendevreview | chandan kumar proposed openstack/cyborg-specs master: Add generic NVMe driver spec with secure cleanup https://review.opendev.org/c/openstack/cyborg-specs/+/985349 | |
| 05:22:33 | opendevreview | chandan kumar proposed openstack/cyborg-specs master: Add generic NVMe driver spec with secure cleanup https://review.opendev.org/c/openstack/cyborg-specs/+/985349 | |
| #openstack-cyborg - 2026-06-22 | |||
| 06:09:32 | opendevreview | chandan kumar proposed openstack/cyborg-specs master: Add generic NVMe driver spec with secure cleanup https://review.opendev.org/c/openstack/cyborg-specs/+/985349 | |
| 09:44:19 | chandankumar | sean-k-mooney: Hello | |
| 09:44:29 | sean-k-mooney | o/ | |
| 09:44:32 | chandankumar | I wanted to discuss about nvme cleanup fallback strategy. | |
| 09:44:41 | chandankumar | In previous draft spec, we were checking whether the driver supports which of the cleaning strategy: nvme sanitize (CES, BES, OWS) or nvme format(SES2, SES1). If not then we can move it shred or dd. But shred or dd is not gurantee secure erase. | |
| 09:44:51 | chandankumar | Since In libvirt emuluted nvme, it supports SES2 and SES1. SES2 performs cypto erase | |
| 09:44:59 | chandankumar | It is the last cleaning strategy available for testing right now in our emulated env. | |
| 09:45:05 | sean-k-mooney | secure erase is not the goal | |
| 09:45:05 | chandankumar | Here is what I was thinking about new cleanup strategy: | |
| 09:45:16 | sean-k-mooney | cleaning is | |
| 09:45:22 | chandankumar | nvme sanitize (CES, BES, OWS) then nvme format(SES2) if not supported then move the device to error state and let' operator decide what to do that. | |
| 09:45:30 | sean-k-mooney | no | |
| 09:45:46 | sean-k-mooney | either we only suprpot device with sanitize | |
| 09:46:06 | sean-k-mooney | or we have a fallback that works for all devices | |
| 09:46:17 | sean-k-mooney | but its not ok for use to provision a device to a vm that we cant clean | |
| 09:46:28 | sean-k-mooney | we coudl use nvme format | |
| 09:46:49 | sean-k-mooney | but if the device will alwasy end up in error then we shoudl not allow ti to be managed by cybrog | |
| 09:47:42 | sean-k-mooney | also while we can have teird cleaning levels we should not fallback at runtime | |
| 09:48:35 | sean-k-mooney | we shoudl discover the clenaing supprot level and or allow specify the cleaning mode via the config but we shoudl only attpemt one method of cleaning in the runtime path | |
| 09:49:01 | sean-k-mooney | shread/dd woudl jusut overrite the entirly block device if we use that path | |
| 09:49:49 | sean-k-mooney | that is what we do for lvm volumes in cidner and nova | |
| 09:50:03 | chandankumar | Not all devices support nvme format also | |
| 09:50:17 | sean-k-mooney | right which is why im not really that intersted in supproting that | |
| 09:50:48 | sean-k-mooney | dd/sheread is a universal method that will work its just slow and consumes a full driver write cycle | |
| 09:51:29 | chandankumar | in that case, we have two options 1. use fallback as shread or dd (just like nova or cinder) or 2. provide cleanup method via config | |
| 09:51:59 | chandankumar | But if we pass the cleanup method via config, how os-triats will report to placement here | |
| 09:52:20 | sean-k-mooney | we woudl filter the triat based on the selected cleanup method | |
| 09:52:22 | chandankumar | if it might be something else other than snaitize or dd/shread | |
| 09:52:35 | sean-k-mooney | it wont be arbaitary | |
| 09:53:07 | sean-k-mooney | it would be and enuma of "sanitize", "format" or "zero" | |
| 09:53:14 | sean-k-mooney | zero beign shread or dd | |
| 09:53:34 | chandankumar | ok, in that case it will work | |
| 09:54:52 | sean-k-mooney | i have no interest in allowing oeprator to pass a cleaning command | |
| 09:55:03 | sean-k-mooney | that is a security nightmare so while i am ok with them chooing a policy | |
| 09:55:33 | sean-k-mooney | im not ok with giving them free rain to plug in anything they want fro the cleaning command | |
| 09:55:48 | sean-k-mooney | we can also supprot an auto value as the default | |
| 09:56:03 | sean-k-mooney | where we will use the best/fasted method the device supprots | |
| 09:56:45 | chandankumar | yes, that source better | |
| 09:56:49 | sean-k-mooney | so the config option (in the device-spec) would not be required its just an overried if the operaotr need to set it for soem reason i.e. there device is buggy | |
| 09:57:24 | chandankumar | so the cleanup option would be auto, santitize, format, zero | |
| 09:57:49 | sean-k-mooney | yep i think that woudl work again we can decied if we want to suprpot format or not | |
| 09:58:09 | sean-k-mooney | but that somethign we can refine at implemation time | |
| 09:58:13 | chandankumar | perfect | |
| 09:58:23 | sean-k-mooney | how common is it that sanatize is not supproted these days | |
| 09:59:39 | sean-k-mooney | most read intensive ssd are rated at 1 total drive write per day DWPD wer as mixed use drives are rated at 10 adn write intensive deves at 25+ | |
| 10:00:13 | sean-k-mooney | so on a moder driver just zeroing it with dd/shred is not terible for the lifetime of the drive | |
| 10:00:24 | sean-k-mooney | and if your passing a drive to a vm they can do that anyway | |
| 10:01:08 | sean-k-mooney | so i think having "zero" as the work for anything fallback is fine for legacy drives but i suspect almost everyting will work with on eof the sanitize levels | |
| 10:03:39 | sean-k-mooney | we could also looks at blockdiscard/trim but we can dicuss that later when it comes to reiving the zero implemation | |
| 10:04:20 | chandankumar | nvme sanitize was added nvme 1.3 specification, these days most of the nvme device comes with nvme 2.0 | |
| 10:04:25 | chandankumar | it should have sanitize | |
| 10:04:39 | sean-k-mooney | right that my thinkign as well | |
| 10:05:10 | chandankumar | The I have in my laptop have , it does not support cyrpot erase | |
| 10:05:40 | chandankumar | Block Erase Sanitize Operation Supported | |
| 10:06:59 | sean-k-mooney | ya so again cyrpto erase is nice to have but not required | |
| 10:07:18 | sean-k-mooney | if you want encypted storage you should just add luks on top of the nvme device in the gust | |
| 10:07:32 | sean-k-mooney | an not rely on the device cleaning to do that for you | |
| 10:08:00 | chandankumar | yes adding luks wuld do the job | |
| 10:08:09 | chandankumar | let me update the spec based on above discussion | |
| 10:08:13 | chandankumar | thank you! | |
| 10:08:15 | sean-k-mooney | my intuition is to just supprot sanatize and zero by the way | |
| 10:08:20 | sean-k-mooney | and skip format entirly | |
| 10:09:29 | sean-k-mooney | i do not like that format only works on the first namespace | |
| 10:09:42 | sean-k-mooney | or if a namespace still exists | |
| 10:10:19 | chandankumar | sure, I will drop format | |
| 10:11:22 | sean-k-mooney | cool any other question on any of the feedback i left on the spec? | |
| 10:11:43 | sean-k-mooney | ill try and do anohter full pass over it in the next day or two | |
| 10:11:48 | chandankumar | nope rest of them I have address | |
| 10:11:59 | chandankumar | I will try to get it updated by eod or tomorrow morning | |
| 10:12:15 | sean-k-mooney | cool ill plan to take a look tomorow or wednesday so | |
| 10:12:36 | sean-k-mooney | assuming there are no other issues and we are mostly aligned we will probly merge it end ro week or early next week | |
| 10:18:22 | chandankumar | sounds good | |
| 10:26:45 | sean-k-mooney | so thinking about this i wonder if cypto erase need to be configurable. the block erase version of sanitize and format is actully more secure then cypto erase alone | |