| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-25 | |||
| 17:06:11 | openstackgerrit | Matt Riedemann proposed openstack/nova master: libvirt: fix hard reboot issue with mdevs https://review.openstack.org/564257 | |
| 17:28:50 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Transform missing delete notifications https://review.openstack.org/410297 | |
| 17:28:51 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Send soft_delete from context manager https://review.openstack.org/476459 | |
| 17:43:39 | openstackgerrit | Merged openstack/nova master: Address issues raised in adding member_of to GET /a-c https://review.openstack.org/554357 | |
| 17:49:09 | esberglu | mriedem: Was working with efried an we aren't sure how this is working for the ironic driver | |
| 17:49:11 | esberglu | https://review.openstack.org/#/c/526094/46/nova/virt/powervm/driver.py@545 | |
| 17:49:57 | esberglu | When we get the bdm from the list of bdms it is regular dict | |
| 17:50:16 | esberglu | We are doing the same thing as ironic | |
| 17:50:51 | esberglu | Take the block_device_info (passed into spawn) and run block_device_info_get_mapping to get bdms | |
| 17:50:54 | esberglu | Then loop through them | |
| 17:52:05 | esberglu | Not sure what I'm missing, but I thought the bdm was supposed to be a DriverVolumeBlockDevice there | |
| 17:53:36 | esberglu | Here's what I'm actually seeing for the bdm at that point | |
| 17:53:37 | esberglu | http://paste.openstack.org/show/719946/ | |
| 17:55:48 | mriedem | esberglu: you have to rebase on top of efried's patch for the is_volume thing | |
| 17:55:58 | mriedem | https://review.openstack.org/#/c/564017/ | |
| 17:56:19 | mriedem | oh nvm i see what you're doing | |
| 17:56:46 | esberglu | mriedem: I've tried both with efrieds patch (bdm.is_volume) and without it (bdm._bdm_obj.is_volume) | |
| 17:56:57 | esberglu | Neither work in my test env. | |
| 17:57:13 | mriedem | are the unit tests using a list of DriverVolumeBlockDevice objects? | |
| 17:57:21 | esberglu | mriedem: yes | |
| 17:57:41 | esberglu | mriedem: https://review.openstack.org/#/c/526094/46/nova/tests/unit/virt/powervm/test_driver.py@487 | |
| 17:58:06 | esberglu | But it seems that we aren't getting a list of DriverVolumeBlockDevice objects live, just a list of dicts | |
| 17:58:52 | mriedem | well DriverVolumeBlockDevice is a dict | |
| 17:59:26 | mriedem | and it proxies through the special attributes for the wrapped bdm object | |
| 17:59:50 | mriedem | i see the unit tests are passing on your change.. | |
| 18:01:10 | esberglu | mriedem: Yeah, which is why it seems that we are getting something other than DriverVolumeBlockDevice live | |
| 18:01:27 | mriedem | you powervm guys need to stop saying "live" | |
| 18:02:11 | esberglu | *in my test environment :) | |
| 18:05:52 | mriedem | if only the 3rd party ci could test volume operations.... | |
| 18:09:57 | openstackgerrit | Jay Pipes proposed openstack/nova master: support multiple member_of qparams https://review.openstack.org/561315 | |
| 18:10:54 | mriedem | esberglu: i pulled down efried's change, and then your change on top of it, and changed bdm._bdm_obj.is_volume to bdm.is_volume and the unit tests passed | |
| 18:11:01 | mriedem | so i'm not sure what is different about your test environment | |
| 18:11:16 | mriedem | but either your test env is wrong, or the unit tests aren't actually validating this correctly | |
| 18:13:19 | esberglu | mriedem: It seems to be something with a test env. Otherwise this would be broken for ironic too. | |
| 18:13:21 | esberglu | But like I said, we are running the exact same code to extract the bdm the they are | |
| 18:13:39 | mriedem | yeah i see that | |
| 18:13:40 | esberglu | Is there anything that could cause the block_device_info passed into spawn() to be different | |
| 18:23:51 | esberglu | mriedem: ^? | |
| 18:24:04 | mriedem | don't think so | |
| 18:24:08 | esberglu | efried: Yeah waiting for a reply | |
| 18:25:15 | mriedem | esberglu: spawn() gets the result of this https://github.com/openstack/nova/blob/936695221e7c22546cc09f0505a063744c1d38a2/nova/compute/manager.py#L2191 | |
| 18:25:29 | mriedem | https://github.com/openstack/nova/blob/936695221e7c22546cc09f0505a063744c1d38a2/nova/compute/manager.py#L1563 | |
| 18:25:48 | mriedem | https://github.com/openstack/nova/blob/936695221e7c22546cc09f0505a063744c1d38a2/nova/virt/driver.py#L37 | |
| 18:26:05 | mriedem | ^ takes a BlockDeviceMappingList and transforms the list into DriverVolumeBlockDevice objects | |
| 18:27:16 | esberglu | efried: You have any ideas here? We're UTing with DriverVolumeBlockDevice objects, which are able to access the necessary fields | |
| 18:27:24 | efried | mriedem: What does "live" mean to you? To me it means "not in a test suite". It doesn't necessarily imply "production". | |
| 18:27:42 | mriedem | beyond that band from the 90s | |
| 18:27:43 | mriedem | ? | |
| 18:27:50 | mriedem | or frampton | |
| 18:28:00 | esberglu | And we should be getting DriverVolumeBlockDevice objects based on the last two links | |
| 18:28:06 | esberglu | In the live environment | |
| 18:28:08 | efried | esberglu: Yes, I agree. | |
| 18:28:16 | esberglu | In the test env :) | |
| 18:28:19 | efried | (including with your use of "live") | |
| 18:37:50 | mriedem | esberglu: efried: i have no problems with these objects using efried's change http://paste.openstack.org/show/719952/ | |
| 18:38:19 | mriedem | <class 'nova.virt.block_device.DriverSnapshotBlockDevice'> | |
| 18:38:19 | mriedem | >>> type(virt_bdm) | |
| 18:38:19 | mriedem | <class 'nova.objects.block_device.BlockDeviceMapping'> | |
| 18:38:19 | mriedem | >>> type(bdm_obj) | |
| 18:38:48 | efried | mriedem: What, you're running on a real POWER system with NovaLink? | |
| 18:38:55 | efried | mriedem: This is what we mean by "live" :P | |
| 18:39:12 | efried | I think esberglu's problem was found when running in such an environment. | |
| 18:39:19 | esberglu | efried: mriedem: Correct | |
| 18:39:37 | efried | Though I'm getting skeptical | |
| 18:39:52 | efried | ...that pdb was actually telling you the right thing when you asked it `whatis` | |
| 18:40:12 | cdent | why have a power system when you can have a POWER system? | |
| 18:40:38 | efried | not helping | |
| 18:40:42 | mriedem | efried: yeah i still have a tunnel into ibm | |
| 18:41:08 | edleafe | cdent: STOP SHOUTING | |
| 18:41:23 | mriedem | maybe you've got some stale pyc or pyo files or something, idk how your setup your test environments | |
| 18:41:30 | mriedem | *you setup | |
| 18:41:58 | mriedem | anywho, i don't even know if we should move forward with this if it can't get CI testing | |
| 18:42:42 | mriedem | btw, what is an SSP cinder driver? | |
| 18:42:44 | mriedem | what is SSP again? | |
| 18:42:49 | efried | Shared Storage Pools | |
| 18:42:51 | mriedem | super serious power | |
| 18:42:53 | mriedem | oh | |
| 18:42:57 | efried | (as opposed to shared storage pools, cdent) | |
| 18:43:18 | efried | A VIOS cluster-based distributed storage thing. | |
| 18:43:25 | mriedem | i do remember the shit stain that is trying to do CI with a v7k | |
| 18:43:44 | mriedem | it would brick at least once a week, with synchronous CI job runs no less | |
| 18:43:56 | mriedem | enterprise! | |
| 18:44:22 | mriedem | so is a SSP cinder driver in the future? | |
| 18:44:25 | efried | Of all the problems we have with our CI, I don't think our SAN bricking is one of them. esberglu True? | |
| 18:44:44 | esberglu | yeah | |
| 18:44:55 | efried | mriedem: SSP cinder is something we've played with and partially proposed in the past, but haven't (yet) followed through with. | |
| 18:45:03 | edmondsw | mriedem ignore the SSP comment... that doesn't really relate here | |
| 18:45:18 | edmondsw | that is a totally different volume driver that would also use vSCSI technology | |
| 18:45:19 | mriedem | let it be known i am getting it from all the IBM e's now | |
| 18:45:30 | edmondsw | but that would be vSCSI SSP, not vSCSI FC, which is this commit | |
| 18:45:41 | edmondsw | lol | |
| 18:47:19 | mriedem | in both situation and build, i think it's fair to say i'm the guy in the middle here http://img.wennermedia.com/social/the-new-day-wwe-smackdown-tag-team-champs-43c77d8f-41a5-43fb-b6c9-9f629a507f3c.jpg | |
| 18:47:44 | edmondsw | mriedem the resemblance is uncanny | |
| 18:48:19 | smcginnis | Not the ref? | |
| 18:49:27 | edmondsw | mriedem we agreed to proceed with vSCSI in nova without CI back in Denver. What changed? | |
| 18:50:24 | mriedem | idk, i'm not ptl anymore so i can push back on stuff now? | |
| 18:50:30 | edmondsw | ha | |
| 18:50:47 | dansmith | I don't remember agreeing to that, | |
| 18:50:48 | dansmith | potentially because I was disinterested in general | |
| 18:50:53 | dansmith | but I think it's kinda crazy to be lacking that | |