| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-25 | |||
| 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 | >>> type(bdm_obj) | |
| 18:38:19 | mriedem | <class 'nova.objects.block_device.BlockDeviceMapping'> | |
| 18:38:19 | mriedem | >>> type(virt_bdm) | |
| 18:38:19 | mriedem | <class 'nova.virt.block_device.DriverSnapshotBlockDevice'> | |
| 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 | |
| 18:54:28 | smcginnis | I laughed. | |
| 18:54:39 | edleafe | *All* of IBM's e's?? [t 2CNr] | |
| 18:54:39 | purplerbot | <mriedem> let it be known i am getting it from all the IBM e's now [2018-04-25 18:45:19.088382] [n 2CNr] | |
| 18:54:53 | edleafe | mriedem: I've been behaving | |
| 18:54:54 | mriedem | edleafe: oh sorry | |
| 18:55:05 | mriedem | IBM (power) e's | |
| 18:55:25 | jaypipes | mriedem: :) | |
| 18:55:31 | edleafe | mriedem: yeah, I'm not that POWERful at IBM | |
| 18:56:13 | mriedem | edmondsw: anyway, i'll defer to melwitt on the CI situation | |
| 18:56:24 | mriedem | i'm not blocking, but not happy about it either | |
| 18:56:38 | edmondsw | mriedem honestly, I'm not happy about it myself | |
| 18:57:09 | mriedem | i'd be happy to be unhappy together | |
| 18:57:10 | edmondsw | and I will do what I can to see what we can do there | |
| 18:57:14 | edmondsw | wfm :) | |
| 18:59:19 | openstackgerrit | Zack Cornelius proposed openstack/nova-specs master: Libvirt file backed memory https://review.openstack.org/563704 | |
| 18:59:47 | edmondsw | dansmith doesn't look like the approved queens spec called out lack of CI for vSCSI. I know we discussed at the PTG before the spec was approved, but I think it was approved pretty quickly there before we updated it to call that out | |
| 19:00:27 | dansmith | ack | |
| 19:01:14 | mriedem | might it be possible to have an on-demand job for powervm+volume stuff? | |
| 19:01:23 | mriedem | then you can run it on patches when asked at least as a bridge to something more automated? | |