| *** esberglu has quit IRC | 03:49 | |
| *** chhagarw has joined #openstack-powervm | 04:32 | |
| *** AlexeyAbashkin has joined #openstack-powervm | 06:32 | |
| *** AlexeyAbashkin has quit IRC | 06:49 | |
| *** AlexeyAbashkin has joined #openstack-powervm | 06:50 | |
| *** AlexeyAbashkin has quit IRC | 06:54 | |
| *** AlexeyAbashkin has joined #openstack-powervm | 07:02 | |
| *** AlexeyAbashkin has quit IRC | 07:53 | |
| *** AlexeyAbashkin has joined #openstack-powervm | 07:56 | |
| *** openstackgerrit has quit IRC | 12:04 | |
| *** edmondsw has joined #openstack-powervm | 12:17 | |
| *** edmondsw has quit IRC | 12:28 | |
| *** edmondsw has joined #openstack-powervm | 12:51 | |
| *** apearson has joined #openstack-powervm | 12:55 | |
| *** esberglu has joined #openstack-powervm | 13:26 | |
| esberglu | efried: edmondsw: Can we talk about https://review.openstack.org/#/c/554688/ quick? | 13:46 |
|---|---|---|
| esberglu | efried: I think that the powervm:proc_units is the extra spec used. I don't think we are missing the proc_units_factor extra spec | 13:47 |
| efried | I looked at this last night. powervm:proc_units is proc_units. The proc_units_factor goes into the init of the standardizer, and is not configurable via extra specs. | 13:48 |
| efried | IOW we clearly didn't want people to be able to adjust proc_units_factor on a per-instance basis. We wanted that to be one-and-done in the config. And the way people get more processing power is by specifying more proc_units in their flavor. | 13:49 |
| efried | thorst may remember why. Or Kyle. | 13:50 |
| edmondsw | ah, that makes sense | 13:50 |
| edmondsw | allowing proc_units_factor to change on a per-instance basis wouldn't make sense because then it would be meaningless to say how many proc units a VM has... | 13:51 |
| efried | That's one way to look at it, yeah. | 13:51 |
| edmondsw | (without also knowing the proc_units_factor for the VM) | 13:51 |
| edmondsw | if it's consistent across all VMs, then you can compare apples to apples looking at num proc_units per VM | 13:52 |
| esberglu | So mriedem is mistaken in his comments on PS9? | 13:53 |
| edmondsw | esberglu I'll help you reword the commit message and help/comments after our meeting | 13:53 |
| edmondsw | trying to finish a call atm | 13:54 |
| * efried looks at the comments... | 13:54 | |
| * efried responds... | 13:57 | |
| efried | esberglu: Done. edmondsw: I stole your apples. | 14:01 |
| edmondsw | efried thanks | 14:01 |
| edmondsw | #startmeeting PowerVM Driver Meeting | 14:01 |
| openstack | Meeting started Tue Apr 10 14:01:30 2018 UTC and is due to finish in 60 minutes. The chair is edmondsw. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:01 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:01 |
| *** openstack changes topic to " (Meeting topic: PowerVM Driver Meeting)" | 14:01 | |
| openstack | The meeting name has been set to 'powervm_driver_meeting' | 14:01 |
| edmondsw | #link agenda: https://etherpad.openstack.org/p/powervm_driver_meeting_agenda | 14:01 |
| edmondsw | #topic In-Tree Driver | 14:01 |
| *** openstack changes topic to "In-Tree Driver (Meeting topic: PowerVM Driver Meeting)" | 14:01 | |
| edmondsw | #link https://etherpad.openstack.org/p/powervm-in-tree-todos | 14:02 |
| edmondsw | esberglu update on IT status? | 14:02 |
| esberglu | edmondsw: Everything before localdisk is ready for core review | 14:03 |
| esberglu | efried: I've responded to all your comments on localdisk except | 14:03 |
| esberglu | https://review.openstack.org/#/c/549300/18/nova/virt/powervm/disk/localdisk.py@122 | 14:03 |
| esberglu | Wasn't sure exactly what you meant there | 14:03 |
| edmondsw | hotplug merged, so I've removed that from the todo etherpad | 14:04 |
| esberglu | jichenjc left a few more comments that I haven't hit yet | 14:04 |
| efried | shall we talk about that comment now? | 14:05 |
| edmondsw | go ahead | 14:05 |
| efried | We're building a ftsk, which is supposed to have a list of VIOSes in it as getters rather than wrappers, which is supposed to allow us to defer the retrieval of the VIOS(es) until we want to do the actual work, which is supposed to minimize the window for conflicts. | 14:06 |
| efried | But we're doing things here that are eliminating those benefits. | 14:06 |
| efried | First off, there's only one VIOS we care about, and we already know which one it is (self._vios_uuid or whatever). So using build_active_vio_feed_task - which goes out and tries to figure out which of all the VIOSes are "active" (RMC up) and stuffs all of those into the ftsk - will only *hopefully* include that VIOS, and may very well include the other(s) that we don't care about. | 14:08 |
| edmondsw | agree that we only care about one VIOS | 14:08 |
| efried | Second, L137 accesses the .wrapper @property, which prefetches the wrappers in the ftsk, so we're not getting the benefit of deferring that fetch. | 14:08 |
| edmondsw | __init__ only sets self._vios_uuid, it does not cache the vios_w, so we do need a way to get vios_w | 14:09 |
| edmondsw | and we do need to get it to make sure we have the latest info there, right? | 14:09 |
| efried | The main benefit I forgot to mention is running the subtasks in parallel across the VIOSes. Which is n/a here since there is (should be) only one VIOS we care about. | 14:09 |
| esberglu | efried: So what you're proposing is that instead of adding the rm_func to the stg_ftsk we would just call tsk_map.remove_maps | 14:10 |
| esberglu | Directly after find_maps? | 14:10 |
| edmondsw | so do we need a different stg_ftsk that only retrieves one vios, or do we need to get the vios without a feedtask? | 14:10 |
| efried | I'm saying using a ftsk at all in this method is overkill. | 14:10 |
| efried | unnecessary. | 14:10 |
| efried | esberglu: Let me look; it's possible remove_maps already returns the maps that get removed. | 14:11 |
| edmondsw | are feedtasks only relevant when you're dealing with lists, and not singletons? | 14:11 |
| edmondsw | feed = list? | 14:11 |
| efried | ...which means we could have probably extracted those results out of the ftsk after execute. | 14:12 |
| *** chhavi__ has joined #openstack-powervm | 14:12 | |
| efried | edmondsw: No, that's not the only advantage. Doing multiple operations, reverting stuff, etc. (FeedTask is a derivative of TaskFlow) | 14:13 |
| efried | ...yup, remove_maps already returns the list of maps removed. | 14:13 |
| efried | I haven't looked, but I suspect the current code is an artifact of slot manager garbage from OOT, and we're going to have to re-complexify it later when we put that shit back in. | 14:13 |
| efried | but for now, we can make this way simpler. | 14:14 |
| esberglu | efried: So rip out the stg_ftsk & rm_func stuff, rip out find_maps | 14:14 |
| esberglu | And just have | 14:14 |
| esberglu | vios_w = stg_ftsk.wrapper_tasks[self._vios_uuid].wrapper | 14:14 |
| edmondsw | you just said rip out stg_ftsk, so that won't work | 14:14 |
| esberglu | Oh right | 14:15 |
| efried | No stg_ftsk. Retrieve the VIOS wrapper afresh based on self.vios_uuid | 14:15 |
| *** chhagarw has quit IRC | 14:15 | |
| edmondsw | yep | 14:15 |
| efried | ...using the SCSI xag | 14:15 |
| efried | VIO_SMAP | 14:15 |
| edmondsw | and then tsk_map.remove_maps on it | 14:15 |
| edmondsw | and done | 14:15 |
| esberglu | Okay got it | 14:16 |
| edmondsw | esberglu for vscsi, we already did this right? "Add a follow on to use pypowervm 1.1.12 for wwpns" | 14:16 |
| edmondsw | so I'm removing that from TODO etherpad | 14:16 |
| esberglu | edmondsw: Yeah | 14:17 |
| edmondsw | has anything merged other than netw hotplug | 14:17 |
| *** AndyWojo has quit IRC | 14:17 | |
| edmondsw | or have comments we need to address, other than localdisk? | 14:17 |
| *** AndyWojo has joined #openstack-powervm | 14:17 | |
| esberglu | edmondsw: Nope, nothing has been reviewed, still a few things ahead of us in runways | 14:17 |
| edmondsw | yep | 14:17 |
| edmondsw | any updates on migrate/resize? | 14:18 |
| esberglu | Gonna finish up localdisk today and get it ready for review, then jump back into that | 14:18 |
| edmondsw | cool | 14:18 |
| esberglu | Ready for core review | 14:18 |
| edmondsw | ok, anything else IT? | 14:18 |
| esberglu | Is there any system requirements for SDE installs? My install failed | 14:19 |
| esberglu | And I need that to test localdisk snapshot | 14:19 |
| efried | (esberglu: Just noticed gaffe in the commit message) | 14:19 |
| edmondsw | esberglu thinking... but check with seroyer | 14:20 |
| edmondsw | I think there are some local disk size requirements? | 14:21 |
| esberglu | edmondsw: I'll ask and try again, might also see if anyone can loan me a system for a couple days | 14:22 |
| edmondsw | #topic Out-of-Tree Driver | 14:22 |
| *** openstack changes topic to "Out-of-Tree Driver (Meeting topic: PowerVM Driver Meeting)" | 14:22 | |
| edmondsw | #link https://etherpad.openstack.org/p/powervm-oot-todos | 14:22 |
| edmondsw | I've got a meeting setup with the PowerVC folks to talk about the volume refactoring | 14:23 |
| edmondsw | and get everyone on the same page there | 14:23 |
| edmondsw | I'd talked to gfm about this, and he was onboard, but some others on his team are freaking out | 14:23 |
| edmondsw | so need to calm them down | 14:23 |
| edmondsw | I've been working with chhavi__ quite a bit on iscsi | 14:24 |
| edmondsw | I think we're making progress there | 14:24 |
| edmondsw | I need to ping burgerk about https://review.openstack.org/#/c/428433/ again | 14:24 |
| edmondsw | #action edmondsw to ping burgerk about config drive UUID | 14:25 |
| edmondsw | I also need to start writing code for MSP support | 14:25 |
| edmondsw | efried I think the pypowervm support is already there for that, though obviously untested | 14:26 |
| edmondsw | efried I will probably be proposing a change to at least the docstring, though, since it says name where it actually needs IPs | 14:27 |
| edmondsw | and the arg is badly named as well... I'd love to rename it, but that would break backward compat | 14:27 |
| efried | "MSP support"? | 14:27 |
| efried | What arg? | 14:27 |
| efried | What docstring? | 14:27 |
| edmondsw | do you think that's ok since it didn't work before? | 14:27 |
| efried | What's going on here?? | 14:27 |
| edmondsw | one sec | 14:27 |
| edmondsw | https://github.com/powervm/pypowervm/blob/master/pypowervm/tasks/migration.py#L52 | 14:28 |
| edmondsw | dest_msp_name and src_msp_name should actually be lists of IP addresses | 14:28 |
| edmondsw | not names | 14:28 |
| edmondsw | MSP = mover service partition | 14:28 |
| edmondsw | specifying IPs allows you to dictate which interfaces are used for LPM | 14:29 |
| edmondsw | new for NovaLink, but HMC has had this... presumably the pypowervm code was copied from HMC support | 14:29 |
| edmondsw | efried make more sense now? | 14:30 |
| efried | I thought the "lists of" thing was something new coming down the pipe. | 14:30 |
| efried | And... you're saying those args don't work at all today? | 14:30 |
| edmondsw | efried NovaLink didn't support those in REST until the changes Nicolas has just now been working on | 14:31 |
| edmondsw | so they couldn't have worked (for NovaLink) before | 14:31 |
| efried | OIC, we just copied that method from k2operator or whatever? | 14:32 |
| edmondsw | I assume, yes | 14:32 |
| efried | was REST just ignoring any values passed down there? | 14:32 |
| efried | cause if so, we can't remove/rename them. If it was erroring, then maybe we can get away with it. | 14:33 |
| edmondsw | efried right, I have to check with Nicolas on that | 14:33 |
| edmondsw | until I know otherwise, I'm assuming we have to leave them and just cleanup the docstring | 14:33 |
| efried | Well... | 14:33 |
| efried | If they can now be lists, we should probably accept (python) lists, and convert 'em to comma-delimited (or whatever) within the method. | 14:34 |
| edmondsw | yes | 14:34 |
| edmondsw | I don't mean there would only be a docstring change... just that I wouldn't rename the args unless they were erroring before | 14:34 |
| efried | Dig. | 14:35 |
| edmondsw | anything else to discuss OOT? | 14:35 |
| esberglu | nope | 14:36 |
| edmondsw | #topic Device Passthrough | 14:36 |
| *** openstack changes topic to "Device Passthrough (Meeting topic: PowerVM Driver Meeting)" | 14:36 | |
| edmondsw | #efried you're up | 14:36 |
| efried | I started working on granular. Some pretty intricate algorithms happening there. | 14:36 |
| efried | Got grudging agreement from jaypipes that the spec as written is the way we should go (rather than switching to separate-by-default) | 14:36 |
| edmondsw | cool | 14:37 |
| efried | he still has to convince Dan, but I think since the path of least resistance is what we've got, it'll just fall off. | 14:37 |
| efried | In case you're interested in looking at the code: https://review.openstack.org/#/c/517757/ | 14:37 |
| efried | I need to fix test, but the general idea is there. | 14:38 |
| edmondsw | I'm interested, but won't have time | 14:38 |
| efried | At this point I've given up waiting for Jay to finish nrp-in-alloc-cands before I do that. | 14:38 |
| edmondsw | :) | 14:38 |
| efried | So whichever one of us wins, the other has to figure out how to integrate granular+NRP. | 14:38 |
| efried | There's a new #openstack-placement channel you may wish to join. | 14:39 |
| edmondsw | efried ah, tx for the heads up | 14:39 |
| efried | upt stuff is mostly merged. I think my runway expires tomorrow. But the stuff that's left is pretty nonessential - if it doesn't get in, it's not the end of the world. | 14:40 |
| edmondsw | so the last important one did merge? | 14:40 |
| efried | I think so. Lemme double check. | 14:40 |
| efried | yeah. The pending ones are nice-to-have, but we can get by without 'em if we need. | 14:41 |
| efried | https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/update-provider-tree | 14:42 |
| edmondsw | efried so are we ready to start making changes in our driver? | 14:42 |
| efried | Yes, if someone else wants to do it. I'm going to be heads down on granular and reviewing other placement stuff for a while yet. | 14:42 |
| efried | also note that we can't get any mileage out of actual trees until Jay's thing is done. | 14:42 |
| efried | We can do single-provider stuff with traits, but we won't be able to do anything with child providers for GPUs etc. | 14:43 |
| edmondsw | so that'll probably wait a bit longer then, because I have too many other things on my plate right now as well | 14:43 |
| *** tjakobs has joined #openstack-powervm | 14:43 | |
| efried | We could hack that together with custom resource classes, one per GPU, inventory of 1. But that would be an interim solution. | 14:44 |
| efried | If we get to the end of Rocky and the NRP work still isn't finished, we may have to do that. | 14:44 |
| edmondsw | k | 14:44 |
| edmondsw | anything else? | 14:44 |
| efried | Well, on your side, have we gotten any further figuring out how we want to map/represent/filter supported devices? | 14:45 |
| edmondsw | I think it's pretty much what we'd talked about before | 14:45 |
| edmondsw | provider per adapter | 14:45 |
| edmondsw | so we can allow selection by unique id if need be | 14:46 |
| edmondsw | for PCI, representation will use PCI vendor/device IDs | 14:47 |
| efried | hm, then I wonder if we actually want to model it with custom resource classes. | 14:47 |
| efried | Nah, the cores will freak about that. | 14:47 |
| edmondsw | the custom bit will the unique id | 14:47 |
| efried | Right, but we need to use traits for that. | 14:48 |
| edmondsw | so we could use a common provider and have custom traits? | 14:48 |
| edmondsw | if so, great | 14:48 |
| efried | no, if it's a common provider, it would need to be distinct RCs. | 14:48 |
| efried | Separate providers, traits. | 14:48 |
| efried | otherwise there's no way to know which trait belongs to which device. | 14:49 |
| edmondsw | I did not follow that | 14:49 |
| efried | btw, RP names are freeform - no char restrictions - so we can do whatever tf we want with them. | 14:49 |
| efried | meaning that we can use the DRC name (or whatever) for the RP name, and not have to do any weird mapping. | 14:50 |
| efried | Sorry, okay, lemme back up. | 14:50 |
| efried | Traits are on providers, not resources. | 14:51 |
| esberglu | efried: edmondsw: Sorry to butt in, but I've got to present on CI in a few minutes | 14:51 |
| esberglu | Multinode CI status: Have working multinode stack within staging, updated prep_devstack to handle control and compute | 14:51 |
| esberglu | Still seeing a few errors there | 14:51 |
| edmondsw | efried yeah, let's give esberglu a few min on CI and we can continue later | 14:52 |
| edmondsw | #topic PowerVM CI | 14:52 |
| *** openstack changes topic to "PowerVM CI (Meeting topic: PowerVM Driver Meeting)" | 14:52 | |
| edmondsw | #link https://etherpad.openstack.org/p/powervm_ci_todos | 14:52 |
| esberglu | Next up is getting zuul/nodepool to work with multinode | 14:52 |
| esberglu | And figuring out the tempest failures | 14:52 |
| esberglu | That's pretty much all I have | 14:52 |
| edmondsw | esberglu tempest failures? | 14:53 |
| edmondsw | is that specific to multinode, or in general? | 14:53 |
| esberglu | Seeing cold mig tempest failures (not all, just a few tests) | 14:53 |
| esberglu | On OOT | 14:53 |
| edmondsw | ok | 14:54 |
| esberglu | Gotta run | 14:54 |
| edmondsw | I need to run as well | 14:54 |
| edmondsw | #topic Open Discussion | 14:54 |
| *** openstack changes topic to "Open Discussion (Meeting topic: PowerVM Driver Meeting)" | 14:54 | |
| edmondsw | anything quick here? | 14:55 |
| efried | edmondsw: If we want to have all of our devices in the same provider, and have them all with the same generic resource class (e.g. "GPU"), it doesn't help us to have all the traits that represent all the devices on that provider, because when you pick one off, you don't know which trait goes with which inventory item. And we don't want to be editing traits on the fly to indicate that kind of thing. So if we want all ou | 14:55 |
| efried | custom resource classes (e.g. "GPU_<drc_index>") and we kinda lose the ability to request different types (e.g. based on vendor/product IDs). | 14:55 |
| efried | So what we want is one RP per device, with the provider name equating to a unique identifier we can correlate back to the real device, and traits on the RP marking the type (vendor/product IDs, capabilities, whatever). | 14:56 |
| efried | each RP has inventory 1 of the generic resource class (e.g. "GPU") | 14:56 |
| efried | If that's still murky, hmu later and we can talk it through s'more. | 14:56 |
| edmondsw | so we can use the common/generic RC | 14:56 |
| edmondsw | but need custom RP | 14:57 |
| efried | We were going to want to do that to some extent anyway. | 14:57 |
| edmondsw | that's what I was hoping | 14:57 |
| efried | Theoretically we could group like devices | 14:57 |
| efried | but then we lose the ability to target a *specific* device. | 14:57 |
| efried | which I gather is something we still want. | 14:57 |
| edmondsw | I think so | 14:57 |
| efried | even though it's not very cloudy. | 14:57 |
| edmondsw | well... there are different definitions of cloud | 14:58 |
| edmondsw | I think you're falling into the nova definition trap :) | 14:58 |
| edmondsw | s/nova/certain nova cores/ | 14:58 |
| edmondsw | #endmeeting | 14:58 |
| *** openstack changes topic to "This channel is for PowerVM-related development and discussion. For general OpenStack support, please use #openstack." | 14:58 | |
| openstack | Meeting ended Tue Apr 10 14:58:55 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:58 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/powervm_driver_meeting/2018/powervm_driver_meeting.2018-04-10-14.01.html | 14:58 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/powervm_driver_meeting/2018/powervm_driver_meeting.2018-04-10-14.01.txt | 14:58 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/powervm_driver_meeting/2018/powervm_driver_meeting.2018-04-10-14.01.log.html | 14:59 |
| efried | that is a very fair point. | 14:59 |
| *** apearson has quit IRC | 15:29 | |
| *** apearson has joined #openstack-powervm | 15:33 | |
| *** AlexeyAbashkin has quit IRC | 15:33 | |
| *** apearson has quit IRC | 15:45 | |
| *** AlexeyAbashkin has joined #openstack-powervm | 15:47 | |
| *** edmondsw has quit IRC | 16:00 | |
| *** edmondsw has joined #openstack-powervm | 16:01 | |
| esberglu | edmondsw: efried: SDE install worked this time, should be able to finish localdisk testing today | 16:01 |
| edmondsw | awesome | 16:02 |
| *** apearson has joined #openstack-powervm | 16:03 | |
| *** apearson has quit IRC | 16:49 | |
| *** AlexeyAbashkin has quit IRC | 16:59 | |
| *** openstackgerrit has joined #openstack-powervm | 17:01 | |
| openstackgerrit | Chhavi Agarwal proposed openstack/nova-powervm master: WIP: Having iSCSI Initiator locks per VIOS https://review.openstack.org/557800 | 17:01 |
| chhavi__ | edmondsw: updated change set with test. | 17:02 |
| edmondsw | chhavi__ ack, thanks... will look after meetings | 17:02 |
| chhavi__ | we need additional pypowervm changes to get hdisk from udid | 17:02 |
| *** AlexeyAbashkin has joined #openstack-powervm | 17:07 | |
| *** AlexeyAbashkin has quit IRC | 17:12 | |
| *** apearson has joined #openstack-powervm | 17:14 | |
| *** openstackgerrit has quit IRC | 17:34 | |
| *** AlexeyAbashkin has joined #openstack-powervm | 18:36 | |
| esberglu | edmondsw: efried: Just came across something testing localdisk. Saw a SCSI mapping left around after deleting an instance | 18:46 |
| esberglu | Because we are missing https://github.com/openstack/nova-powervm/blob/master/nova_powervm/virt/powervm/driver.py#L625-L641 | 18:47 |
| esberglu | Is that needed prior to localdisk? I didn't see any related issues testing prior to this | 18:48 |
| esberglu | Also I don't think the evacuate comment there is accurate, this was just a normal spawn/delete | 18:49 |
| edmondsw | esberglu well it does only mention evacuate as an example | 18:50 |
| edmondsw | doesn't say that's the only case | 18:50 |
| esberglu | edmondsw: Yeah, but I'm inclined to rip that part out if it's seen in a more general case | 18:51 |
| edmondsw | just the (e.g....) ? | 18:52 |
| esberglu | Yeah | 18:52 |
| edmondsw | so you're going to need to update the vscsi commit with this, right? | 18:53 |
| esberglu | edmondsw: Yeah that's what I was thinking, just wanted some more context since I wasn't seeing any issues without it | 18:53 |
| edmondsw | I'm a little surprised you would have seen this because what were you doing that would have removed a volume from the VIOS? | 18:54 |
| efried | snapshot? | 18:55 |
| esberglu | No just testing a spawn/delete with localdisk, no volume stuff at all | 18:55 |
| esberglu | After spawning would see an entry in scsi list like | 18:56 |
| esberglu | | neo39-inst | 4 | vios1 | 4 | i_6e8ab136_65fc | | 18:56 |
| esberglu | | LPAR | LPAR Slot | VIOS | VIOS Slot | Storage | | 18:56 |
| esberglu | After delete that entry was | 18:56 |
| esberglu | | <None> | 4 | | | | | 18:57 |
| esberglu | Added that code block above, and the scsi map gets removed during destroy | 18:58 |
| esberglu | Sorry that second entry after delete was actually | 18:59 |
| esberglu | | <None> | 4 | vios1 | 4 | | | 18:59 |
| esberglu | I don't think this is talking about cinder volumes. Its talking about the lvs created during localdisk spawn? | 19:00 |
| esberglu | After spawning, there is in lv on the localdisk volume group named i_6e8ab136_65fc | 19:07 |
| esberglu | The deletion of that works fine, but the SCSI mapping doesn't get cleaned up | 19:07 |
| esberglu | efried: edmondsw: That make sense? | 19:08 |
| esberglu | As in this has nothing to do with vSCSI | 19:09 |
| esberglu | cinder vSCSI | 19:09 |
| esberglu | How does localdisk snapshot work in SDE mode? You can't create vgs when in SDE right? | 19:38 |
| esberglu | *how does localdisk work at all in SDE mode | 19:38 |
| edmondsw | ok, so no changes to the vscsi commit... that's good, since respinning that would bump a bunch of commits based on it | 19:42 |
| edmondsw | tjakobs can you create volume groups in SDE mode? | 19:42 |
| tjakobs | you can create volume groups manually, not sure if there is api support for it | 19:43 |
| tjakobs | from personal experience, I've manually created a "lparHosting" volume group, then set these in local.conf `DISK_DRIVER=localdisk` and `VOL_GRP_NAME=lparHosting` | 19:44 |
| tjakobs | edmondsw esberglu ^ | 19:45 |
| edmondsw | tx | 19:45 |
| edmondsw | esberglu I'm still confused as to why you saw the mapping not get cleaned up... I wonder if the code you pointed to was hiding a bug here | 19:46 |
| edmondsw | i.e., it should have been cleaned up somewhere else, and wasn't, but we didn't notice because https://github.com/openstack/nova-powervm/blob/master/nova_powervm/virt/powervm/driver.py#L625-L641 cleaned it up | 19:47 |
| esberglu | edmondsw: I can rip that bit back out and recreate | 19:50 |
| *** openstackgerrit has joined #openstack-powervm | 19:51 | |
| openstackgerrit | Chhavi Agarwal proposed openstack/nova-powervm master: WIP: Having iSCSI Initiator locks per VIOS https://review.openstack.org/557800 | 19:51 |
| openstackgerrit | Chhavi Agarwal proposed openstack/nova-powervm master: WIP: Having iSCSI Initiator locks per VIOS https://review.openstack.org/557800 | 19:52 |
| edmondsw | esberglu looking at the code, it does delete the disk right before that, and not the mapping, so I guess it's pretty obvious that block is needed to delete the mapping | 20:02 |
| esberglu | edmondsw: This is probably an issue with how I changed the code based the stg_ftsk discussion this morning | 20:03 |
| esberglu | Now that I'm looking at it again | 20:03 |
| edmondsw | oh? | 20:10 |
| esberglu | edmondsw: Yeah, after reverting back to the latest version of localdisk on gerrit, not seeing it | 20:10 |
| edmondsw | interesting | 20:10 |
| esberglu | edmondsw: Posted my changes there in slack for nicer formatting | 20:11 |
| edmondsw | oh the detach disk is supposed to remove mappings... good | 20:11 |
| edmondsw | so we just need to fix that | 20:12 |
| *** AlexeyAbashkin has quit IRC | 20:16 | |
| *** AlexeyAbashkin has joined #openstack-powervm | 20:17 | |
| chhavi__ | please review https://review.openstack.org/#/c/557800/ | 20:24 |
| *** AlexeyAbashkin has quit IRC | 20:25 | |
| *** chhavi__ has quit IRC | 20:29 | |
| *** apearson has quit IRC | 21:15 | |
| *** tjakobs has quit IRC | 21:38 | |
| *** edmondsw has quit IRC | 21:42 | |
| *** edmondsw has joined #openstack-powervm | 21:42 | |
| *** edmondsw has quit IRC | 21:43 | |
| *** tjakobs has joined #openstack-powervm | 21:46 | |
| *** esberglu has quit IRC | 21:52 | |
| *** edmondsw has joined #openstack-powervm | 22:09 | |
| *** edmondsw has quit IRC | 22:10 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!