| *** edmonds__ has joined #openstack-powervm | 00:00 | |
| *** edmondsw_ has quit IRC | 00:01 | |
| *** edmondsw_ has joined #openstack-powervm | 00:01 | |
| *** edmondsw_ has quit IRC | 00:01 | |
| *** edmondsw_ has joined #openstack-powervm | 00:02 | |
| *** edmonds__ has quit IRC | 00:04 | |
| *** edmondsw_ has quit IRC | 00:26 | |
| *** edmondsw has joined #openstack-powervm | 00:29 | |
| *** edmondsw has quit IRC | 00:31 | |
| *** edmondsw has joined #openstack-powervm | 00:31 | |
| *** edmondsw has quit IRC | 00:36 | |
| *** thorst_afk has joined #openstack-powervm | 00:51 | |
| *** thorst_afk has quit IRC | 00:59 | |
| *** edmondsw has joined #openstack-powervm | 01:40 | |
| *** edmondsw has quit IRC | 01:44 | |
| *** apearson has joined #openstack-powervm | 01:59 | |
| *** thorst_afk has joined #openstack-powervm | 02:00 | |
| *** thorst_afk has quit IRC | 02:06 | |
| *** thorst_afk has joined #openstack-powervm | 03:01 | |
| *** thorst_afk has quit IRC | 03:06 | |
| *** apearson has quit IRC | 03:21 | |
| *** thorst_afk has joined #openstack-powervm | 04:02 | |
| *** thorst_afk has quit IRC | 04:07 | |
| *** thorst_afk has joined #openstack-powervm | 05:03 | |
| *** thorst_afk has quit IRC | 05:08 | |
| *** thorst_afk has joined #openstack-powervm | 06:03 | |
| *** thorst_afk has quit IRC | 06:09 | |
| *** k0da has quit IRC | 06:45 | |
| *** thorst_afk has joined #openstack-powervm | 07:05 | |
| *** thorst_afk has quit IRC | 07:10 | |
| *** edmondsw has joined #openstack-powervm | 07:40 | |
| *** edmondsw has quit IRC | 07:45 | |
| *** edmondsw has joined #openstack-powervm | 07:49 | |
| *** k0da has joined #openstack-powervm | 08:03 | |
| *** thorst_afk has joined #openstack-powervm | 08:05 | |
| *** thorst_afk has quit IRC | 08:10 | |
| *** edmondsw has quit IRC | 08:29 | |
| *** thorst_afk has joined #openstack-powervm | 09:06 | |
| *** thorst_afk has quit IRC | 09:11 | |
| *** edmondsw has joined #openstack-powervm | 09:35 | |
| *** edmondsw has quit IRC | 09:47 | |
| *** thorst_afk has joined #openstack-powervm | 11:07 | |
| *** thorst_afk has quit IRC | 11:12 | |
| *** edmondsw has joined #openstack-powervm | 11:48 | |
| *** chhavi has joined #openstack-powervm | 11:48 | |
| *** edmondsw has quit IRC | 11:52 | |
| *** thorst_afk has joined #openstack-powervm | 12:06 | |
| *** miltonm has joined #openstack-powervm | 12:23 | |
| *** apearson has joined #openstack-powervm | 12:52 | |
| *** esberglu has joined #openstack-powervm | 13:02 | |
| openstackgerrit | Matt Rabe proposed openstack/nova-powervm master: Change NVRAM manager and Swift APIs to accept UUID https://review.openstack.org/471926 | 13:02 |
|---|---|---|
| *** esberglu has quit IRC | 13:02 | |
| *** esberglu has joined #openstack-powervm | 13:03 | |
| efried | esberglu's IRC client is going haywire; he asked me to... | 13:03 |
| efried | never mind | 13:04 |
| esberglu | #startmeeting powervm_driver_meeting | 13:04 |
| openstack | Meeting started Tue Aug 29 13:04:01 2017 UTC and is due to finish in 60 minutes. The chair is esberglu. Information about MeetBot at http://wiki.debian.org/MeetBot. | 13:04 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 13:04 |
| openstack | The meeting name has been set to 'powervm_driver_meeting' | 13:04 |
| efried | \o | 13:04 |
| efried | edmondsw is at VMWorld. | 13:04 |
| efried | thorst_afk - you going to be here? | 13:04 |
| mdrabe | o/ | 13:04 |
| thorst_afk | not really | 13:04 |
| thorst_afk | will be catching up on the feed periodically | 13:05 |
| esberglu | #link https://etherpad.openstack.org/p/powervm_driver_meeting_agenda | 13:05 |
| esberglu | #topic In Tree Driver | 13:05 |
| esberglu | #link https://etherpad.openstack.org/p/powervm-in-tree-todos | 13:05 |
| efried | Okay. I guess it'll be mostly a status update. esberglu when done, send link to minutes out so others can catch up. | 13:05 |
| esberglu | I tested the config drive patch with FORCE_CONFIG_DRIVE=True | 13:06 |
| esberglu | Everything seemed to be working as expected | 13:06 |
| efried | Sweet. Have you seen my email? | 13:07 |
| esberglu | efried: Yep. Ran it last night, 0 failures | 13:07 |
| efried | Well, so here's the funky thing... | 13:07 |
| esberglu | Need to port that to the IT patch | 13:07 |
| efried | https://review.openstack.org/#/c/498614/ <== this passed our CI. | 13:07 |
| efried | It oughtn't to have. | 13:07 |
| esberglu | efried: Weird... | 13:08 |
| efried | We would have been sending down AssociatedLogicalPartition links like http://localhost:12080/rest/api/uom/ManagedSystem/None/LogicalPartition/<real_uuid> | 13:08 |
| efried | But... perhaps the REST side is just parsing the end off without looking too closely at the rest of it. | 13:09 |
| efried | The only side effect I can think of would have been that we would be ignoring fuse logic in mappings | 13:09 |
| efried | which just means every mapping ends up on its own bus. | 13:09 |
| efried | which wouldn't manifest any problems in the CI, really. | 13:09 |
| esberglu | efried: Want me to post the CI logs from the manual CI run to see if there's anything different going on? | 13:10 |
| efried | No, if it passes, we won't be able to see anything useful in there. | 13:10 |
| efried | Anyway, yeah, esberglu you want to pick up those two changes and run with 'em? | 13:11 |
| efried | finish up UT and whatnot? | 13:11 |
| esberglu | efried: Sure | 13:11 |
| esberglu | #action esberglu: Port host_uuid change to IT config drive patch | 13:11 |
| esberglu | #action esberglu: Finish UT for OOT host_uuid patch | 13:11 |
| esberglu | That | 13:12 |
| esberglu | that's it for IT? | 13:12 |
| efried | For completeness, the pypowervm side is 5818; the nova-powervm change to be finished up and ported to the in-tree cfg drive change is https://review.openstack.org/#/c/498614/ | 13:12 |
| efried | #action esberglu UT for 5818 too | 13:13 |
| efried | It's passing right now, but needs some extra testing for the stuff I changed. | 13:13 |
| esberglu | efried: ack | 13:13 |
| efried | Oh, and following up on vfc mappings. I don't have anything fibre-channely to test with. Do you? | 13:13 |
| esberglu | Don't think so | 13:14 |
| efried | Need to make sure the same logic (posting ROOT URIs to create mappings) also works for vfc, then make the same change in the vfc mapping bld methods. | 13:14 |
| efried | Can be a followon change, I suppose | 13:15 |
| efried | For the moment, we're just using it to trim down the cfg drive stuff, which is always vscsi. | 13:15 |
| esberglu | efried: Ok. We can loop back to that after this first wave is done and either add it in or start a new change | 13:16 |
| efried | yuh. Perhaps someone from pvc can lend us a fc-havin system for a day or two. | 13:16 |
| efried | mdrabe you got anything like that? | 13:16 |
| mdrabe | Yes | 13:16 |
| efried | nice | 13:17 |
| mdrabe | But as far as lending I'm not sure :/ | 13:17 |
| efried | I actually would literally need it for half an hour | 13:17 |
| mdrabe | All be consumed for pvc stories atm, in a few days they should be free I think | 13:17 |
| efried | and would need a free fc disk I could assign to an LPAR (even the nvl) | 13:17 |
| efried | Assuming that disk is free, the testing would be nondestructive. | 13:18 |
| efried | I just need to create a mapping in a certain way and make sure it works. | 13:18 |
| mdrabe | Testing with devstack though right? | 13:18 |
| efried | no | 13:18 |
| efried | just pypowervm | 13:18 |
| efried | don't even care what level | 13:18 |
| mdrabe | oh mkay | 13:18 |
| mdrabe | That's good then, dm me | 13:19 |
| efried | rgr | 13:19 |
| efried | #action efried to validate vfc mappings work the same way (with ROOT URIs for AssociatedLogicalPartition) using mdrabe's setup. | 13:19 |
| efried | aaaand... | 13:19 |
| efried | #action efried to continue thorough review of cfg drive change | 13:20 |
| efried | At some point I reckon we're gonna need thorst_afk to review it too. | 13:20 |
| efried | All three of us have had hands on it, so approval is going to be like supermajority consensus. | 13:20 |
| efried | Oh, wait, this is in tree. | 13:21 |
| efried | So we all just get to +1 it anyway. | 13:21 |
| efried | And community approval is going to entail... | 13:21 |
| efried | #action esberglu to drive pvm in-tree integration bp for q. | 13:21 |
| esberglu | efried: Yep | 13:22 |
| efried | Not sure if you caught my parting shot yesterday on that, but: may want to ask mriedem in -nova whether he wants a fresh bp or just re-approve existing. | 13:22 |
| esberglu | efried: Yep saw that was planning on putting that in motion today | 13:22 |
| efried | coo | 13:22 |
| esberglu | #topic Out Of Tree Driver | 13:23 |
| mdrabe | https://review.openstack.org/#/c/471926 passed functional testing | 13:23 |
| mdrabe | There's one issue uncovered from the testing left to be ironed out, but it's unrelated to the change | 13:23 |
| efried | What was the issue? | 13:24 |
| efried | Love it when test finds bugs. | 13:24 |
| efried | It kinda justifies the whole existence of testing as a thing. | 13:24 |
| mdrabe | One evacuation failed with the dreaded vscsi rebuild exception... | 13:25 |
| efried | got bug? | 13:25 |
| mdrabe | Can't link here, dming, sec | 13:26 |
| efried | If it's RTC, I don't care. | 13:26 |
| mdrabe | Heh k | 13:26 |
| efried | Is it not a bug in the community code? | 13:26 |
| efried | If so, we ought to have a lp bug for it. | 13:26 |
| mdrabe | It's been some time since I've looked at it | 13:26 |
| efried | oh, is it an old bug? | 13:27 |
| * efried confused | 13:27 | |
| mdrabe | No, I just mean within a weeks timeframe | 13:27 |
| mdrabe | I forget things quickly, sorry | 13:27 |
| efried | mdrabe Okay, well, I'm not in a huge hurry to get a lp bug opened, but if the changes are going into nova-powervm, that should happen eventually (before we merge it). | 13:28 |
| mdrabe | efried: The exception that was raised was this one: https://github.com/powervm/pypowervm/blob/develop/pypowervm/tasks/slot_map.py#L665 | 13:28 |
| mdrabe | For 1 out of 5 evacuations | 13:29 |
| efried | As in, we couldn't find one of the devices on the target system? | 13:29 |
| mdrabe | Right | 13:29 |
| efried | Uhm. | 13:29 |
| efried | So first of all, 1/5 ain't good. | 13:29 |
| mdrabe | And I _think_ I recall seeing LUA recovery failures in the logs | 13:29 |
| efried | Second, upon what are you basing your assertion that this is unrelated to your change? | 13:30 |
| mdrabe | Because it's not related to the slot map | 13:30 |
| efried | even though ten out of the 13 or so LOC leading up to that exception have 'slot' in 'em? | 13:31 |
| mdrabe | but | 13:31 |
| mdrabe | ok | 13:31 |
| mdrabe | I'll -1 WF until we resolve it | 13:32 |
| mdrabe | efried: fair? | 13:32 |
| efried | I had put a +2 on it, but yeah, I think we should follow up first. | 13:32 |
| esberglu | Reminder that pike official release is tomorrow | 13:34 |
| esberglu | That it for OOT? | 13:34 |
| efried | other than pci stuff, I think so. | 13:34 |
| esberglu | #topic PCI Passthrough | 13:35 |
| efried | okay | 13:35 |
| efried | Lots to catch up on here since last week. | 13:35 |
| efried | First of all, last week I got a prototype successfully claiming *and* assigning PCI passthrough devices during spawn. | 13:36 |
| efried | Were any of y'all in the demo on Friday? | 13:36 |
| esberglu | Yeah | 13:36 |
| mdrabe | nope | 13:36 |
| efried | The nova-powervm code is here: https://review.openstack.org/#/c/496434/ | 13:37 |
| efried | And I'm actually not sure ^ relies on any pypowervm or REST changes, as currently written. | 13:38 |
| efried | despite what the commit message says. | 13:38 |
| efried | now | 13:38 |
| efried | REST has merged the change that lets us assign slots on LPAR PUT. Which means I can remove the hack here: https://review.openstack.org/#/c/496434/3/nova_powervm/virt/powervm/vm.py@573 | 13:39 |
| efried | Also the much-debated PCI address spoofing I think I'm gonna keep in nova-powervm (abandoned 5755 accordingly) because... | 13:40 |
| efried | All of this is going to be temporary | 13:40 |
| efried | It may not even survive queens, gods willing. | 13:40 |
| mdrabe | efried: I forget, through what API do we assign PCI devices after spawn? | 13:41 |
| efried | mdrabe Before that REST fix? IOSlot.bld and append that guy to the LPAR's io_config.io_slots. Then POST the LPAR. | 13:41 |
| openstackgerrit | Eric Berglund proposed openstack/nova-powervm master: DNM: ci check https://review.openstack.org/328315 | 13:42 |
| mdrabe | efried: And that's triggered by an interface attach from an openstack perspective? | 13:42 |
| efried | mdrabe No, actually, I'm not sure what happens during interface attach - should probably look into that. | 13:43 |
| efried | No, in openstack the instance object we get passed during spawn contains a list of pci_devices that have been claimed for us. | 13:43 |
| openstackgerrit | Eric Berglund proposed openstack/nova-powervm master: DNM: CI Check2 https://review.openstack.org/328317 | 13:43 |
| efried | Via the above change sets, we're culling that info and sending it into LPARBuilder (curse him). | 13:44 |
| efried | mdrabe Is that what you were looking for? | 13:44 |
| mdrabe | I'm just trying to understand the flows affected | 13:45 |
| efried | Sure, definitely worth going over in more detail, let's do that. | 13:45 |
| mdrabe | Yea, I've been meaning to take some time to stare at this stuff, I'll probably ask better questions after I do that | 13:46 |
| efried | Nova gets PCI dev info from three places: | 13:46 |
| efried | => get_available_resource (in the compute driver - code we control) produces a list of pci_passthrough_devices as part of the json object it dumps. | 13:46 |
| efried | => The compute process looks in its conf for [pci]passthrough_whitelist, which it intersects with the above to filter down to only devices you're allowed to assign to VMs. | 13:47 |
| efried | => The nova API process looks in its conf (which may not be the same .conf as the compute process - took me a while to figure THAT one out) for [pci]alias entries, which it *also* uses to filter the above. | 13:48 |
| efried | The operator sets up a flavor. In the flavor extra_specs he sets a field called pci_passthrough:alias whose value is a comma-separated list of <alias>:<count> | 13:48 |
| *** edmondsw has joined #openstack-powervm | 13:49 | |
| efried | The <alias> names come from the [pci]alias config, and are how the op identifies what kinds of devices he wants on his VM. Those [pci]alias entries just map the alias name to a vendor/product ID pair. | 13:49 |
| efried | And the <count> is how many of that kind of dev you want. | 13:49 |
| efried | So | 13:50 |
| efried | When you do a spawn with that flavor, nova looks at the pci_passthrough:alias in the flavor, maps it to the vendor/product ID, and then goes and looks in the filtered-down pci_passthrough_devices list for devices that match. | 13:50 |
| efried | Meanwhile it's keeping track of how many of those kinds of devices it has claimed and whatnot. | 13:51 |
| mdrabe | Ok so adding/removing PCI devices is triggered through resize | 13:51 |
| efried | So assuming it finds suitable devices, it decrements their available count and assigns 'em to your instance. | 13:51 |
| efried | Yes, I believe that's the case, though I haven't explicitly tried it yet. | 13:51 |
| mdrabe | That makes me wonder how this works with SR-IOV | 13:52 |
| efried | To come full circle: nova puts the specific devices it claimed into your instance object that it passes to spawn, which is where our code again gets control. | 13:52 |
| efried | Yeah, SR-IOV is going to be a different story | 13:52 |
| efried | Especially since we're not doing the same thing nova does with SR-IOV. | 13:52 |
| efried | But much of the flow is the same. | 13:53 |
| *** edmondsw has quit IRC | 13:53 | |
| efried | pci_passthrough_devices is *supposed* to register each VF as a child of its respective PF. | 13:53 |
| efried | So you could claim a VF and the matching is done based on the parent. | 13:54 |
| efried | But when you're doing that as part of network interface setup, things go off the rails a bit. | 13:54 |
| efried | Now it starts looking for a physical_network tag on your device and trying to bind a neutron port with that network and all that jazz. | 13:55 |
| efried | In the rest of the world, you have to pre-create VFs, and they're passed through explicitly one by one and assigned directly to the VM. | 13:55 |
| efried | In our world... we don't have the VFs until we need 'em, and even then, they're not assigned directly to the VM. | 13:56 |
| efried | So we have to fool the pci manager by spoofing "fake" VFs in our pci_passthrough_devices list. We just create however many entries according to the MaxLPs on the PF. | 13:56 |
| mdrabe | Right okay, I'm stuck in the PowerVM perspective | 13:57 |
| efried | Yeah, so when we do a claim with SR-IOV, nova actually hands us one of those fake VFs, but we ignore it and just create our VNIC on the appropriate PF. | 13:58 |
| efried | This is probably enough historical treatise. The aforementioned PoC code gives me confidence that we can make this work in q without community involvement. Which is not bad. | 13:58 |
| efried | But it also ain't pretty. | 13:59 |
| efried | The main ugliness is that we have to spoof our PCI addresses. | 13:59 |
| efried | Because nova refuses to operate without a Linuxy PCI address in <domain>:<bus>:<slot>.<func> format. | 13:59 |
| efried | Our devices don't have those. We have DRC index and location code. | 13:59 |
| efried | Linuxy PCI addresses are 32-bit. DRC index is 64-bit. | 14:00 |
| mdrabe | What determines the DRC index for us? | 14:00 |
| efried | PHYP | 14:00 |
| mdrabe | phyp? | 14:00 |
| efried | So I started down a path of suggesting some changes to nova's pci manager that would allow us to use our DRC index (or location code, or whatever we wanted) to address and identify devices. | 14:01 |
| efried | https://review.openstack.org/497965 | 14:01 |
| efried | It was basically shot down as being an interim hackup that would be superseded by the move to placement and resource providers. | 14:02 |
| efried | Which is really what I was going for in the first place. I wanted to garner some attention and discussion that would get us moving in that direction. | 14:03 |
| efried | The upshot is that we (I believe Jay is the nova core most invested in this) want to make devices (not just PCI - any devices) managed through the placement and resource provider framework. | 14:04 |
| efried | In that nirvana, our compute driver provides a get_inventory method, which replaces get_available_resource. | 14:04 |
| efried | The information contained therein is able to represent any resource generically, and the nova code doesn't try to introspect values and do stuff with 'em like it is doing today for PCI addresses and whatnot. | 14:05 |
| mdrabe | That sounds like the way to go | 14:05 |
| efried | That work is off the ground at this point in nova, for resources like vcpu, mem, and disk. | 14:06 |
| efried | There's also some support for custom resource classes. | 14:06 |
| efried | So | 14:06 |
| efried | Jay and I are working up content for discussion at the PTG toward making devices managed by the same setup. | 14:06 |
| mdrabe | Cool | 14:07 |
| esberglu | Good discussion. We ready to move on? | 14:08 |
| efried | A resource provider would describe the devices it has available; those devices would have qualitative and quantitative properties. Nova would get a spawn request asking for a device with certain qualitative and quantitative properties. Placement and scheduler and claims and family would just match those values (again, blindly, not introspecting the values) and give us the resources. | 14:08 |
| efried | And we get the helm back in our driver and do whatever we want with those claimed resources. | 14:08 |
| mdrabe | I feel much more informed than I did an hour ago | 14:09 |
| esberglu | Same | 14:09 |
| efried | So my action this week is going to be collating some of these notes and stuff, creating an etherpad for the PTG, and perhaps putting some of it down in a blueprint https://blueprints.launchpad.net/nova/+spec/devices-as-resources whose spec is here: https://review.openstack.org/#/c/497978/ | 14:10 |
| mdrabe | efried: Is the resource provider change targetted for q? | 14:10 |
| efried | Well, that's what I don't know. | 14:11 |
| efried | I'm sure it will be targetted for q. | 14:11 |
| efried | Whether it will get done in q is another question. | 14:11 |
| efried | So | 14:11 |
| efried | We need to be prepared to move forward with our hacked version | 14:11 |
| efried | And we can transition over as able. | 14:11 |
| efried | It's a big piece of work. | 14:11 |
| efried | So I suspect that even if it gets done in q, it'll get done late in the cycle, possibly too late for us to exploit it fully ourselves. | 14:12 |
| efried | The really good news here is that Jay is very invested in this, and it fits with the overall direction nova is moving wrt placement and resource providers, so I don't doubt it's going to get done... eventually. | 14:12 |
| efried | It's not just us whining "we need this for PowerVM". | 14:12 |
| esberglu | Cool | 14:13 |
| efried | Okay, I think that's probably enough of that for now. Any further questions, or ready to move on? | 14:13 |
| efried | #action efried to write etherpad and/or spec content for nova device management as generic resources. | 14:14 |
| esberglu | I might have questions later, I need to look through the code still | 14:14 |
| esberglu | #topic PowerVM CI | 14:14 |
| esberglu | Not much to report here | 14:14 |
| esberglu | Still waiting for the REST change for the serialization issue | 14:15 |
| efried | esberglu It's been prototyped, though? | 14:15 |
| efried | And run through CI? | 14:15 |
| esberglu | efried: Prototyped and run through CI, but not with the latest version of the code | 14:15 |
| efried | 5775? | 14:16 |
| esberglu | efried: I think it requires the related changes as well. Not 100% sure though, hsien deployed it | 14:17 |
| esberglu | Other than that the compute driver was occaisionally failing to come up on CI runs. The stacks on the undercloud for a few systems were messed up | 14:18 |
| esberglu | I redeployed, haven't seen it since, gonna keep an eye out | 14:19 |
| esberglu | Those were the only failures hitting CI consistently, so failure rates should be pretty low now | 14:20 |
| esberglu | Well not now, once that rest fix is in | 14:20 |
| esberglu | That's all I had CI | 14:20 |
| esberglu | #topic Driver Testing | 14:20 |
| esberglu | Jay isn't on. But he was having problems stacking last week | 14:21 |
| esberglu | I got his system stacked, not sure if any further testing has been done on it yet | 14:21 |
| esberglu | Nothing else to report there | 14:22 |
| esberglu | #topic Open Discussion | 14:22 |
| esberglu | That's it for me | 14:22 |
| efried | nothing else here | 14:22 |
| esberglu | Alright. See you here next week | 14:23 |
| esberglu | #endmeeting | 14:23 |
| openstack | Meeting ended Tue Aug 29 14:23:50 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:23 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/powervm_driver_meeting/2017/powervm_driver_meeting.2017-08-29-13.04.html | 14:23 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/powervm_driver_meeting/2017/powervm_driver_meeting.2017-08-29-13.04.txt | 14:23 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/powervm_driver_meeting/2017/powervm_driver_meeting.2017-08-29-13.04.log.html | 14:23 |
| *** edmondsw has joined #openstack-powervm | 14:42 | |
| *** edmondsw has quit IRC | 14:54 | |
| *** edmondsw has joined #openstack-powervm | 14:58 | |
| *** edmondsw has quit IRC | 15:02 | |
| *** k0da has quit IRC | 15:11 | |
| *** edmondsw has joined #openstack-powervm | 15:54 | |
| openstackgerrit | Matt Rabe proposed openstack/nova-powervm master: Change NVRAM manager and Swift APIs to accept UUID https://review.openstack.org/471926 | 15:55 |
| *** edmondsw_ has joined #openstack-powervm | 15:58 | |
| *** edmondsw has quit IRC | 15:58 | |
| *** edmondsw_ has quit IRC | 16:00 | |
| *** thorst_afk has quit IRC | 16:01 | |
| *** thorst_afk has joined #openstack-powervm | 16:05 | |
| *** thorst_a_ has joined #openstack-powervm | 16:28 | |
| *** tjakobs has joined #openstack-powervm | 16:30 | |
| *** thorst_afk has quit IRC | 16:32 | |
| *** efried has quit IRC | 16:40 | |
| openstackgerrit | Taylor Jakobson proposed openstack/nova-powervm master: Add resize attached volume support https://review.openstack.org/498864 | 16:43 |
| *** thorst_a_ has quit IRC | 16:51 | |
| *** thorst_afk has joined #openstack-powervm | 16:52 | |
| *** efried has joined #openstack-powervm | 16:53 | |
| *** thorst_afk has quit IRC | 16:56 | |
| *** thorst_afk has joined #openstack-powervm | 17:04 | |
| *** k0da has joined #openstack-powervm | 17:17 | |
| *** k0da has quit IRC | 17:29 | |
| *** edmondsw has joined #openstack-powervm | 17:54 | |
| *** edmondsw_ has joined #openstack-powervm | 17:58 | |
| *** edmondsw has quit IRC | 17:59 | |
| *** edmondsw_ has quit IRC | 17:59 | |
| *** edmondsw has joined #openstack-powervm | 18:00 | |
| *** edmondsw has quit IRC | 18:07 | |
| *** chhavi has quit IRC | 18:23 | |
| *** edmondsw has joined #openstack-powervm | 18:23 | |
| *** edmondsw has quit IRC | 18:27 | |
| openstackgerrit | Satish Yadav proposed openstack/nova-powervm master: Add enable LPAR metric parameter https://review.openstack.org/498902 | 18:28 |
| *** edmondsw has joined #openstack-powervm | 18:41 | |
| *** edmondsw has quit IRC | 18:45 | |
| *** edmondsw has joined #openstack-powervm | 19:03 | |
| *** edmondsw has quit IRC | 19:04 | |
| *** edmondsw has joined #openstack-powervm | 19:07 | |
| *** edmondsw has quit IRC | 19:08 | |
| efried | esberglu thorst_afk Can I get a second look at 5806 please? | 19:39 |
| openstackgerrit | Eric Berglund proposed openstack/nova-powervm master: Remove host_uuid from config drive paths https://review.openstack.org/498614 | 19:40 |
| esberglu | efried: Sure | 19:40 |
| *** k0da has joined #openstack-powervm | 19:43 | |
| esberglu | efried: LGTM | 19:53 |
| efried | esberglu thx | 19:53 |
| *** edmondsw has joined #openstack-powervm | 19:55 | |
| *** edmondsw has quit IRC | 19:56 | |
| efried | esberglu You working on 5818? | 19:56 |
| esberglu | efried: Yeah | 19:58 |
| efried | coo | 19:58 |
| *** edmondsw has joined #openstack-powervm | 20:08 | |
| *** edmondsw has quit IRC | 20:13 | |
| *** thorst_afk has quit IRC | 21:22 | |
| *** thorst_afk has joined #openstack-powervm | 21:23 | |
| *** apearson has quit IRC | 21:24 | |
| esberglu | efried: I removed the WIP for removing VFC mappings from 5818. I was thinking a separate patch. Cool with you? | 21:24 |
| esberglu | * for removing host_uuid from the VFC mappings | 21:25 |
| *** thorst_afk has quit IRC | 21:27 | |
| *** k0da has quit IRC | 21:28 | |
| *** esberglu has quit IRC | 21:43 | |
| *** esberglu has joined #openstack-powervm | 21:44 | |
| *** k0da has joined #openstack-powervm | 21:44 | |
| *** esberglu has quit IRC | 21:48 | |
| *** thorst_afk has joined #openstack-powervm | 21:49 | |
| *** thorst_afk has quit IRC | 21:53 | |
| *** esberglu has joined #openstack-powervm | 21:57 | |
| efried | esberglu Yes, cool. | 22:00 |
| efried | Still need some more UT in that guy, I think. | 22:01 |
| efried | It may be overkill, but something proving host_uuid is unused in all those bld methods. | 22:01 |
| *** esberglu has quit IRC | 22:01 | |
| *** edmondsw has joined #openstack-powervm | 22:02 | |
| *** edmondsw has quit IRC | 22:04 | |
| *** edmondsw has joined #openstack-powervm | 22:04 | |
| *** miltonm has quit IRC | 22:07 | |
| *** esberglu has joined #openstack-powervm | 22:07 | |
| *** tjakobs has quit IRC | 22:08 | |
| *** edmondsw has quit IRC | 22:23 | |
| *** esberglu has quit IRC | 22:27 | |
| *** esberglu has joined #openstack-powervm | 22:27 | |
| *** esberglu_ has joined #openstack-powervm | 22:28 | |
| *** esberglu has quit IRC | 22:31 | |
| *** esberglu_ has quit IRC | 22:35 | |
| *** edmondsw has joined #openstack-powervm | 22:41 | |
| *** edmondsw has quit IRC | 22:45 | |
| *** edmondsw has joined #openstack-powervm | 22:58 | |
| *** edmondsw has quit IRC | 23:03 | |
| *** k0da has quit IRC | 23:13 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!