| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-25 | |||
| 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 | |
| 18:51:01 | dansmith | in case anyone cares what I think :) | |
| 18:51:08 | mriedem | it would be one thing if this was a weird api that is seldom used or weird config to set it up, like nfv stuff, | |
| 18:51:11 | edmondsw | I'll try to dig into what's keeping us from doing vSCSI in CI and pick away at it, but we're at the 11th hour here... seems pretty harsh to hold it up now on that grounds | |
| 18:51:13 | mriedem | but volume attach/detach is pretty basic | |
| 18:51:39 | mriedem | i haven't -2d this | |
| 18:51:42 | mriedem | just raising it | |
| 18:51:45 | edmondsw | fair | |
| 18:52:02 | edmondsw | dansmith you were there, but didn't say anything :) | |
| 18:52:08 | mriedem | also, i'd say we're at the 4pm early bird special hour | |
| 18:52:16 | mriedem | aka jaypipes' dinner time | |
| 18:52:21 | dansmith | edmondsw: any words written down to validate that | |
| 18:52:25 | dansmith | as a formal decision? | |
| 18:52:48 | edmondsw | mriedem this was slated for Queens, only moved to Rocky because it wasn't reviewed in time | |
| 18:52:58 | mriedem | L315 https://etherpad.openstack.org/p/nova-ptg-queens | |
| 18:52:59 | smcginnis | The cinder video recordings have come in handy on more than one occasion for things like this. | |
| 18:53:19 | mriedem | "CI would not be running with this because CI with FC is hard." | |
| 18:53:25 | edmondsw | dansmith I think this was called out in the approved spec, I'll go double check | |
| 18:54:04 | mriedem | i'm kind of hurt that i didn't get any kudos for the jay + FL burn | |