| *** thorst has joined #openstack-powervm | 00:13 | |
| *** thorst has quit IRC | 00:17 | |
| *** thorst has joined #openstack-powervm | 00:21 | |
| *** thorst_ has joined #openstack-powervm | 00:23 | |
| *** thorst has quit IRC | 00:26 | |
| *** thorst_ has quit IRC | 01:37 | |
| *** thorst has joined #openstack-powervm | 02:11 | |
| *** thorst has quit IRC | 02:11 | |
| *** thorst has joined #openstack-powervm | 02:12 | |
| *** thorst has quit IRC | 02:20 | |
| *** cody_ has joined #openstack-powervm | 02:27 | |
| *** cody_ is now known as wangqwsh | 02:27 | |
| *** wangqwsh has quit IRC | 03:09 | |
| *** thorst has joined #openstack-powervm | 03:18 | |
| *** thorst has quit IRC | 03:26 | |
| *** seroyer has joined #openstack-powervm | 03:56 | |
| *** thorst has joined #openstack-powervm | 04:25 | |
| *** thorst has quit IRC | 04:30 | |
| *** seroyer has quit IRC | 04:41 | |
| *** kotra03 has joined #openstack-powervm | 04:51 | |
| *** kotra03 has quit IRC | 04:51 | |
| *** kotra03 has joined #openstack-powervm | 04:56 | |
| *** thorst has joined #openstack-powervm | 05:27 | |
| *** thorst has quit IRC | 05:36 | |
| *** Cartoon_ has quit IRC | 06:00 | |
| *** thorst has joined #openstack-powervm | 06:35 | |
| *** thorst has quit IRC | 06:41 | |
| *** Cartoon_ has joined #openstack-powervm | 07:09 | |
| *** kotra03 has quit IRC | 07:10 | |
| *** kotra03 has joined #openstack-powervm | 07:12 | |
| *** thorst has joined #openstack-powervm | 07:39 | |
| *** thorst has quit IRC | 07:46 | |
| *** k0da has joined #openstack-powervm | 08:16 | |
| *** thorst has joined #openstack-powervm | 08:44 | |
| *** thorst has quit IRC | 08:51 | |
| *** thorst has joined #openstack-powervm | 09:48 | |
| *** thorst has quit IRC | 09:55 | |
| *** Cartoon_ has quit IRC | 10:40 | |
| *** thorst has joined #openstack-powervm | 10:54 | |
| *** mdrabe has joined #openstack-powervm | 10:59 | |
| *** thorst has quit IRC | 11:01 | |
| *** openstackgerrit has quit IRC | 11:03 | |
| *** openstackgerrit has joined #openstack-powervm | 11:04 | |
| *** apearson_ has quit IRC | 11:31 | |
| *** openstackstatus has quit IRC | 11:36 | |
| *** openstackstatus has joined #openstack-powervm | 11:38 | |
| *** ChanServ sets mode: +v openstackstatus | 11:38 | |
| *** thorst has joined #openstack-powervm | 11:49 | |
| *** kairo has joined #openstack-powervm | 12:16 | |
| *** edmondsw has joined #openstack-powervm | 12:30 | |
| *** tblakes has joined #openstack-powervm | 12:42 | |
| *** tblakes has quit IRC | 12:45 | |
| *** edmondsw has quit IRC | 13:09 | |
| *** tblakes has joined #openstack-powervm | 13:20 | |
| *** kylek3h has joined #openstack-powervm | 13:23 | |
| *** adreznec has joined #openstack-powervm | 13:23 | |
| *** adreznec has quit IRC | 13:25 | |
| *** adreznec has joined #openstack-powervm | 13:26 | |
| *** kotra03_ has joined #openstack-powervm | 13:30 | |
| *** kotra03 has quit IRC | 13:31 | |
| *** kotra03_ is now known as kotra03 | 13:31 | |
| *** esberglu has joined #openstack-powervm | 13:33 | |
| *** seroyer has joined #openstack-powervm | 13:37 | |
| *** tjakobs has joined #openstack-powervm | 13:55 | |
| *** kairo has quit IRC | 13:56 | |
| thorst | esberglu: how's the CI looking? I saw Hsien's stuff merged...do we need to get it deployed across the cloud? | 14:07 |
|---|---|---|
| *** edmondsw has joined #openstack-powervm | 14:07 | |
| *** esberglu has left #openstack-powervm | 14:08 | |
| *** esberglu has joined #openstack-powervm | 14:08 | |
| esberglu | thorst: Zuul died over the weekend so I restarted it this morning. Reverting the change that broke stacking merged over the weeked though, so we should be seeing some good runs today | 14:10 |
| *** burgerk has joined #openstack-powervm | 14:10 | |
| adreznec | thorst: efried Is this ready to merge in? https://review.openstack.org/#/c/322210/ | 14:22 |
| adreznec | Mostly looking for a networking-powervm change to drop in to trigger a docs run | 14:23 |
| adreznec | and it feels like that should already be merged | 14:23 |
| efried | Let me make sure svenkat is okay with merging it. | 14:24 |
| efried | adreznec, is this for the readthedocs thing? | 14:24 |
| adreznec | Yeah | 14:24 |
| adreznec | That merged in | 14:24 |
| adreznec | So the next patch we push should publish docs | 14:25 |
| efried | Does that pick up docs from networking-powervm/doc/* as well? | 14:25 |
| adreznec | Should | 14:25 |
| efried | okay. | 14:25 |
| efried | I'll have one ready there soon too. | 14:25 |
| adreznec | Assuming our docs config is set up properly | 14:25 |
| efried | Didn't you set it up? How could it not be? | 14:26 |
| adreznec | efried: It will pick up anything in /doc/source | 14:27 |
| efried | As well as anything in specs/ ? | 14:27 |
| adreznec | efried: No, that isn't getting built into our docs. Do we want it to? We're kind of in a weird middle area | 14:29 |
| adreznec | Where we have specs, but we don't have a dedicated specs repo | 14:29 |
| efried | Well, the change set you mentioned above is in specs, not in doc/source. | 14:29 |
| efried | Unless you're saying that any merge in the whole project will trigger a build of the docs. | 14:30 |
| adreznec | Yeah, shouldn't matter though. The docs publishing job will publish new docs on every commit | 14:30 |
| efried | Gotcha. | 14:30 |
| adreznec | You raise a good point though | 14:30 |
| efried | svenkat is okay with merging that blueprint. | 14:30 |
| adreznec | Today the only way to view our specs is in the github/git.openstack.org repos | 14:30 |
| adreznec | There's no place we generate/publish the spec RST | 14:30 |
| adreznec | like specs.openstack.org for example | 14:30 |
| efried | So should we move the specs, or is there a way to make them publish from where they are? | 14:31 |
| adreznec | Probably not a big deal, but it would be nice long term | 14:31 |
| adreznec | efried: We could probably update the build_sphinx part of the setup.cfg to include that somehow | 14:32 |
| adreznec | Would require investigation | 14:32 |
| efried | adreznec, thorst - on another topic, can y'all help me get attention for https://bugs.launchpad.net/neutron/+bug/1615128 / https://review.openstack.org/#/c/358125/ ? | 14:32 |
| openstack | Launchpad bug 1615128 in neutron "Custom binding:profile values not coming through" [Undecided,In progress] - Assigned to Eric Fried (efried) | 14:32 |
| *** seroyer has quit IRC | 14:33 | |
| adreznec | efried: Maybe, let me look it over. It can be hard to catch people's attention in Neutron sometimes | 14:34 |
| openstackgerrit | Taylor Jakobson proposed openstack/nova-powervm: Add iscsi support https://review.openstack.org/346920 | 14:36 |
| efried | adreznec: I found the people who had touched the surrounding code last, and called them out specifically in #openstack-neutron, but none of them responded. | 14:39 |
| efried | That was after I had put out a general call for help, both there and in #openstack-nova | 14:39 |
| efried | Wondering if I should hit a mailing list? | 14:40 |
| openstackgerrit | Eric Fried proposed openstack/networking-powervm: Mechanism driver & agent for powervm SR-IOV https://review.openstack.org/343423 | 14:42 |
| adreznec | efried: Hmm, that's really unpromising then... | 14:44 |
| efried | Maybe I'm on a list somewhere. | 14:44 |
| thorst | efried: was this working, but is not now? | 14:44 |
| *** efried1 has joined #openstack-powervm | 14:47 | |
| efried1 | Sorry, my PC crashed again. Did I miss anything since 9:44:49? | 14:47 |
| adreznec | [09:44:49] <thorst>efried: was this working, but is not now? | 14:48 |
| adreznec | Was the last thing | 14:48 |
| efried1 | thorst: I have no idea if it was ever working. I just know that when I went to test it out in my code, it didn't. | 14:48 |
| thorst | but svenkat said it was... That's the gap I'm trying to collapse... | 14:48 |
| efried1 | When you create the port, it shows up in the output. When you go to show the port (before you use it), it shows up in the output. | 14:48 |
| efried1 | But when you go to *use* the port, the binding:profile values don't come through - and then when you go to show the port again, they're gone. | 14:48 |
| *** efried has quit IRC | 14:49 | |
| thorst | hmm. | 14:49 |
| efried1 | And it's pretty obvious by following the code I called out in the above bug why that's happening. | 14:49 |
| efried1 | hmm indeed. | 14:49 |
| efried1 | And there may be a reason for it; and there may be some other way I'm supposed to get around it - but until I can get a SME to look at it... | 14:50 |
| *** Cartoon_ has joined #openstack-powervm | 14:53 | |
| *** seroyer has joined #openstack-powervm | 14:54 | |
| *** seroyer has quit IRC | 14:55 | |
| *** mdrabe_ has joined #openstack-powervm | 15:01 | |
| *** mdrabe has quit IRC | 15:03 | |
| thorst | efried1: yeah...I was wondering if it was that way because you can't have a binding profile until you're bound | 15:04 |
| thorst | but that's not really...true. I'm just guessing that may be the case? Who knows when a binding profile should exist... | 15:04 |
| *** seroyer has joined #openstack-powervm | 15:08 | |
| efried1 | thorst: Yeah, the binding:profile shows up when you do a neutron port-show when it's unbound. And then when it's bound, that disappears. That can't be right. | 15:08 |
| efried1 | ...unless it is. | 15:09 |
| thorst | exactly...unless it is | 15:10 |
| thorst | and the VLAN comes through...why? | 15:10 |
| efried1 | Because that's not part of the binding:profile | 15:11 |
| thorst | efried1: but could we put this stuff we want in the binding:profile into some meta field? | 15:12 |
| thorst | or, is the issue that if we do that, we don't actually store it in the db | 15:12 |
| thorst | (I think I caught myself up...) | 15:12 |
| efried1 | thorst, yeah, we had this discussion a couple of weeks ago, and figured out that binding:profile was the perfect place for it. | 15:13 |
| thorst | yep yep | 15:14 |
| thorst | takes me a while to catch up | 15:14 |
| efried1 | So we need someone from neutron to either confirm that the bug is a bug and agree to a fix (mine or whatever); or tell us we're using binding:profile wrong and (gods willing) suggest a better way for us to do what we need. | 15:14 |
| thorst | efried1: take a peak at 354179 | 15:17 |
| thorst | they've been trying for a while to get that through and while it works...I'm only a +1 on it. I don't want to block it though because I know they need it...so you can tell me if I'm being silly (probably am) | 15:18 |
| thorst | and efried1...according to this: http://docs.openstack.org/developer/networking-midonet/specs/kilo/port_binding.html | 15:19 |
| thorst | it seems like you're using it properly... | 15:19 |
| thorst | I think the issue is that you're perhaps changing the host_id? and therefore the binding:profile gets zapped? | 15:19 |
| openstackgerrit | Merged openstack/networking-powervm: Checkin blueprint for networking-powervm for SR-IOV VIFs support https://review.openstack.org/322210 | 15:22 |
| efried1 | thorst: it's not the host ID that makes the profile get zapped. Even if I was changing it, which I'm not afaik | 15:24 |
| thorst | yeah...you're just doing a show | 15:24 |
| thorst | so I think you've got a valid bug here... | 15:24 |
| thorst | I'd assume midonet is dead too...we should look at that plugin | 15:24 |
| *** Cartoon_ has quit IRC | 15:25 | |
| efried1 | wha? | 15:26 |
| thorst | efried1: I'm going to push 343423 through | 15:26 |
| thorst | efried1: plugins besides us are trying to use binding:profile this way | 15:26 |
| thorst | so ... are they broken? | 15:26 |
| efried1 | no idea. How to find out? | 15:26 |
| thorst | https://github.com/openstack/?utf8=%E2%9C%93&query=networking- | 15:27 |
| thorst | only a gruesome search ensues | 15:27 |
| efried1 | holy... | 15:28 |
| thorst | https://github.com/openstack/networking-midonet/blob/53d51142573027a07ba3e0af2fa28bbdd84bef69/midonet/neutron/db/port_binding_db.py | 15:28 |
| thorst | that's midonet, the plugin that introduced this. | 15:28 |
| thorst | looks like they have to do stuff we haven't imagined? | 15:29 |
| thorst | not excited if we have to do db things. | 15:30 |
| efried1 | we shouldn't have to. Did you look at the fix I proposed? | 15:31 |
| thorst | pssssh | 15:31 |
| thorst | no | 15:31 |
| thorst | seems reasonable...but does fail port binding tests | 15:32 |
| thorst | may in fact be worth a mailing list thread. | 15:32 |
| *** k0da has quit IRC | 15:37 | |
| *** kriskend has joined #openstack-powervm | 15:38 | |
| *** dwayne has joined #openstack-powervm | 15:45 | |
| efried1 | aw, thorst, I have no idea on https://review.openstack.org/#/c/354179/ | 15:54 |
| thorst | well, the rollback is fine | 15:55 |
| thorst | its just do we embed the rollback name in the task | 15:55 |
| thorst | or have the invoker pass it in | 15:55 |
| efried1 | I'm actually liking your suggestion - save off the previous name in the execute. | 15:56 |
| efried1 | That's the most readable and provably correct way to do it. | 15:56 |
| efried1 | And it's only less clean because we've hidden the LPAR GET under the vm.update deal. | 15:57 |
| efried1 | ...which we have an easy remedy for, via the entry param. | 15:58 |
| thorst | well | 16:01 |
| thorst | so you can't save it off | 16:01 |
| thorst | we got into a big hub-bub | 16:02 |
| thorst | the resize flow runs over many distinct manager calls down into the driver | 16:02 |
| efried1 | why can't you save it off? | 16:02 |
| thorst | so by the time it hits that, its actually already named the wrong thing | 16:02 |
| thorst | we went round and round on that | 16:02 |
| efried1 | Then the un-rename shouldn't be done here. | 16:02 |
| thorst | well, or a 'on failure, rename to'... | 16:02 |
| efried1 | The un-rename should be done in the revert of whatever Task did the rename. Or, as you say, have a totally separate "on failure" thing - but that defeats the purpose of reverts. | 16:03 |
| thorst | right... | 16:04 |
| efried1 | It's tough enough to read this stuff where we've insisted on four layers of indirection (driver method => Task => nova-powervm lib => pypowervm lib) to do what could be accomplished in one. It's one thing to have to understand how a specific Task works in order to understand it in the context of a whole flow - asking the reverse is just too much. | 16:07 |
| efried1 | thorst tblakes mdrabe_ | 16:07 |
| thorst | yeah. I like bundling things in tasks to build pipelines...but I don't like them embedding too much logic about previous steps in them... | 16:08 |
| thorst | I'll propose up a change here in a bit. | 16:08 |
| efried1 | I put up a review response. | 16:09 |
| efried1 | thorst, it looks like they're replacing the binding:profile on purpose, but it's because they think the following is true: | 16:29 |
| efried1 | # This will happen if a new host or profile was specified that # differs from the current one. | 16:29 |
| efried1 | So maybe we have to figure out how it is that we're "specifying" a "new" profile. I know we're not doing it on purpose. | 16:30 |
| efried1 | mm, maybe it's happening through the claim. Cause that's where we're getting the physical_network name and the other (wildcarded) values from the pci_passthrough_device we generate in the driver periodic task. | 16:31 |
| *** mdrabe_ is now known as mdrabe | 16:32 | |
| efried1 | If we were gonna fix that, we would need to intercept the Claim somehow. | 16:32 |
| mdrabe | efried1: We don't have to save the instance name off at tall | 16:33 |
| mdrabe | all* | 16:33 |
| mdrabe | We only change the instance name out on the hypervisor, the instance object's name stays the same the whole time | 16:33 |
| mdrabe | So I guess, we should add a comment to clarify | 16:33 |
| efried1 | At least. | 16:33 |
| efried1 | And we should add logic to vm.rename that only does the update if it's needed. (Compare old name to new name) | 16:34 |
| mdrabe | Saving off the old name is tricky | 16:34 |
| mdrabe | Because the name change happens in the Rename task, not the Resize task | 16:35 |
| efried1 | So we should be reverting it in the Rename task. | 16:35 |
| efried1 | And not passing it in at all in the update in the Resize task. | 16:35 |
| mdrabe | I *think* they're called in different taskflows | 16:35 |
| mdrabe | Lemme double check | 16:35 |
| efried1 | Or if there's some other code path where a rename is done in Resize, then the same rename-on-revert logic should be added to both. | 16:36 |
| efried1 | See, I'm seeing this as the kind of code change I should be able to review without having to understand all the flows involved. | 16:36 |
| mdrabe | heh wouldn't that be nice | 16:37 |
| efried1 | That's kinda the whole point of a Task - a self-contained, self-reverting unit of work that stands alone. | 16:37 |
| mdrabe | right but we gotta make sure what we *want* to do will actually get done | 16:37 |
| efried1 | reusable, too. | 16:37 |
| efried1 | So: Any Task that does a rename needs to revert the rename iff performed. | 16:37 |
| mdrabe | efried1: Here's Resize | 16:37 |
| mdrabe | https://github.com/openstack/nova-powervm/blob/master/nova_powervm/virt/powervm/driver.py#L1310-L1311 | 16:38 |
| mdrabe | Here's Rename | 16:38 |
| mdrabe | https://github.com/openstack/nova-powervm/blob/master/nova_powervm/virt/powervm/driver.py#L1222 | 16:38 |
| mdrabe | 2 different flows | 16:38 |
| mdrabe | If Resize fails, Rename doesn't get reverted | 16:38 |
| mdrabe | Regardless, we don't need to do any saving off | 16:38 |
| thorst | mdrabe: I'll propose up a second option | 16:39 |
| mdrabe | The instance object's name property reflects the hypervisor's name as it should be | 16:39 |
| mdrabe | thorst, efried1: tblakes and I stepped through this code, debugged it | 16:39 |
| efried1 | Should it or should it not be the case that both Resize and Rename revert the name change? | 16:40 |
| efried1 | ...if and only if one occurred | 16:40 |
| thorst | yeah, I dont' disagree with anything you've done so far. And I agree it'll work. What I don't like is that if someone else comes in and uses it...its kinda odd. It works for everything we have today, but kinda breaks the task contract. | 16:40 |
| efried1 | +1 | 16:40 |
| thorst | so its totally a "this isn't part of the task really" | 16:41 |
| thorst | since we've gone back and forth so much....give me 20 min...see if my proposal is ok enough. | 16:41 |
| mdrabe | floor's yours | 16:42 |
| openstackgerrit | Drew Thorstensen (thorst) proposed openstack/nova-powervm: Added revert for Resize https://review.openstack.org/354179 | 16:54 |
| thorst | mdrabe: ^^ something kinda like that | 16:54 |
| thorst | is what I had in mind...over complex, yeah a bit...but holds the contract a bit better... | 16:54 |
| thorst | efried1: you should look too. | 16:56 |
| mdrabe | tblakes: When you were debuggin this resize/rename stuff, did you notice ever that the VM's name would be resize_resize_<name> on the hypervisor? | 17:11 |
| mdrabe | thorst: Do we even know why we have to rename the LPAR's name? | 17:12 |
| tblakes | mdrabe: Yes, if the resize failed multiple times you could end up with multiple resize_ prepended. | 17:13 |
| thorst | mdrabe: kylek3h set that up. I think its because that is in line with the libvirt driver | 17:16 |
| efried1 | thorst, mdrabe: I thought it had something to do with not being allowed to have two VMs with the same name. And one of the flows involved two "copies" of the VM existing at the same time. | 17:19 |
| thorst | ahh, yeah | 17:20 |
| thorst | resize on same host | 17:20 |
| mdrabe | Is that a libvirt thing only? Or PowerVM makes this new partition when "resizing" as well? | 17:20 |
| thorst | mdrabe: I thought it was a compute manager thing | 17:21 |
| thorst | but again, we'd need to bounce off kylek3h | 17:21 |
| mdrabe | nevermind "We use the resize name so we don't destroy it on a revert when it's on the same host" | 17:21 |
| thorst | so does the revert you have proposed cause an issue? | 17:22 |
| mdrabe | Yes, but looking into the fact the vm.rename appears to be called twice for a resize right now... | 17:23 |
| mdrabe | thorst: Your review made me notice that Resize also renames the VM | 17:24 |
| thorst | mdrabe: right... | 17:25 |
| thorst | this isn't the rename task we're talking about here. | 17:25 |
| mdrabe | Oooh I see why it's not 'resize_resize_' | 17:26 |
| mdrabe | because it's always keying off the instance.name | 17:26 |
| mdrabe | So renaming the LPAR in the Resize task is redundant... | 17:27 |
| efried1 | thorst, still think we're making this way too complicated. | 17:27 |
| thorst | efried1: I wouldn't doubt that... | 17:28 |
| efried1 | You're not losing anything (processing-wise) by saving off the original name during execute. (If you even need to - if mdrabe's argument is correct, and instance.name is always the right thing to un-rename to, then you *really* don't lose anything.) And quite simply, if Rename renames, it should un-rename on revert; and if Resize renames, it should un-rename on revert. How can it need to be more complicated than that? | 17:29 |
| efried1 | Show me where there's even an extra GET. | 17:29 |
| efried1 | There isn't. | 17:30 |
| mdrabe | efried1: Yea I agree with that except I think we can just use instance.name in the revert | 17:31 |
| efried1 | mdrabe: The more I think about it, although that may be provably correct in the existing flows, it would still be more readable/clean/provably-correct to save off the old name during execute. | 17:32 |
| efried1 | and make a minor improvement to vm.rename that only updates if the name is different. | 17:32 |
| efried1 | see, then we even *improve* the performance ;-) | 17:33 |
| mdrabe | Maybe, Although I think the redundant name change just happens as part of the overall 'resize' PUT | 17:36 |
| mdrabe | or POST | 17:36 |
| mdrabe | but it's still redundant | 17:36 |
| thorst | so remember...that the resize is a multi step call from the manager to the driver | 17:37 |
| thorst | that's what tjakobs pointed out to me | 17:37 |
| efried1 | On resize we use vm.update, wherein we don't have an easy way to tell whether anything changed in the wrapper (because of LPARBuilder). We could add the condition into the bit where we set the name, but that doesn't save us anything really. | 17:37 |
| thorst | but the time the task is even initialized, some previous call from the manager has already renamed it | 17:37 |
| thorst | and your driver has no context of the 'original' name, because its outside of its process scope | 17:37 |
| thorst | that original name may have been on a different host. | 17:37 |
| efried1 | But in your revert, you were using vm.rename - the *only* thing that guy changes is the name and then POST. | 17:38 |
| mdrabe | Except we always know what the original name should be: instance.name | 17:39 |
| mdrabe | What really needs to be made clear is that we're only changing the name out on the hypervisor | 17:40 |
| efried1 | okay, that's an argument that could convince me that we should use instance.name instead of saving/restoring - as long as there's a very clear comment explaining why that's the case. | 17:40 |
| efried1 | Now, is it *always* the case that we should be un-renaming if Resize fails? | 17:41 |
| mdrabe | If we're saving off and restoring instance.name just for the sake of clarity, it also gives the impression that we're appeasing the taskflow, instead of the openstack dom | 17:41 |
| mdrabe | efried1: We can always use instance.name all the time (I say that with 90% confidence) | 17:41 |
| efried1 | mdrabe, I'm asking if there's ever a case where we *don't* want to remove the resize_ prefix when the flow fails. | 17:42 |
| mdrabe | oh right good question | 17:42 |
| efried1 | e.g. if doing so would (attempt to) result in two LPARs of the same name on the same system. | 17:42 |
| thorst | how about for now, we just embed a really solid comment | 17:43 |
| mdrabe | efried1: That comment I mentioned earlier now concerns me | 17:43 |
| thorst | and cross that bridge when we get to it? | 17:43 |
| efried1 | cross which bridge? You mean potentially inject a different bug and wait to solve it until it's noticed?? | 17:44 |
| thorst | efried1: well it is passing tempest ;-) | 17:44 |
| efried1 | Was this code change prompted by a tempest failure? | 17:45 |
| thorst | no, not sure what caused this actually | 17:45 |
| tblakes | Not directly. Manas changed an error message to use vm.name in a printout and noticed that it had resize_ prepended to it | 17:46 |
| mdrabe | thorst, efried1: Welp I think all this discussion may have been for nothing... | 17:46 |
| mdrabe | I think we want to keep resize_ prepended in the event of a resize failure | 17:46 |
| efried1 | Right, so if it's passing tempest, that means nothing, because clearly tempest doesn't have a test case that's hitting these edges. | 17:46 |
| efried1 | mdrabe, do tell | 17:46 |
| thorst | mdrabe: maybe a failed resize should clean up the VM? | 17:47 |
| mdrabe | Because, this is based off a comment, "resize_" being prepended is how openstack knows not to delete the VM | 17:47 |
| thorst | if its a copy of the original? | 17:47 |
| mdrabe | The rabbit hole's all over the place with this, not entirely sure what the purpose of "resize_" is just yet | 17:49 |
| mdrabe | thorst, efried1: Looks like driver.destroy gets called in the event of a resize failure: https://github.com/openstack/nova-powervm/blob/master/nova_powervm/virt/powervm/driver.py#L708-L716 | 17:51 |
| thorst | mdrabe: yeah...I had seen that... | 17:51 |
| thorst | there was also some finish-resize-revert flow too | 17:52 |
| mdrabe | Sounds like the "resize_" VM is the correct VM.... | 17:52 |
| mdrabe | Oh but this is the API | 17:52 |
| mdrabe | not something that triggers automatically if resize fails | 17:52 |
| *** kotra03 has quit IRC | 18:33 | |
| *** apearson_ has joined #openstack-powervm | 19:10 | |
| *** burgerk has quit IRC | 19:30 | |
| *** k0da has joined #openstack-powervm | 19:38 | |
| *** burgerk has joined #openstack-powervm | 19:58 | |
| *** burgerk has quit IRC | 20:01 | |
| efried1 | thorst: this new_vif thing - should new_vif=False mean SRIOV plug becomes a no-op? | 20:05 |
| thorst | yes | 20:05 |
| efried1 | thorst, or perhaps this is how we effect an "update"? | 20:06 |
| efried1 | (in the future) | 20:06 |
| thorst | it depends on where the update comes from | 20:07 |
| efried1 | thorst, fyi, finally got some traction: http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2016-08-22.log.html#t2016-08-22T18:03:51 | 20:08 |
| efried1 | Also may have found a better place to fix - about to test. | 20:08 |
| *** apearson_ has quit IRC | 20:32 | |
| openstackgerrit | Taylor Jakobson proposed openstack/nova-powervm: Add iscsi support https://review.openstack.org/346920 | 20:45 |
| *** apearson_ has joined #openstack-powervm | 21:00 | |
| *** tblakes has quit IRC | 21:02 | |
| *** kriskend has quit IRC | 21:19 | |
| *** thorst has quit IRC | 21:20 | |
| *** kriskend has joined #openstack-powervm | 21:21 | |
| *** apearson_ has quit IRC | 21:36 | |
| *** apearson_ has joined #openstack-powervm | 21:41 | |
| *** k0da has quit IRC | 21:48 | |
| *** tjakobs has quit IRC | 21:53 | |
| *** esberglu has quit IRC | 21:56 | |
| *** kylek3h has quit IRC | 22:07 | |
| *** edmondsw has quit IRC | 22:10 | |
| openstackgerrit | Eric Fried proposed openstack/nova-powervm: VIF driver implementation for SR-IOV https://review.openstack.org/343419 | 22:10 |
| *** kriskend has quit IRC | 22:12 | |
| *** apearson_ has quit IRC | 22:35 | |
| *** seroyer has quit IRC | 22:44 | |
| *** miltonm has quit IRC | 23:39 | |
| *** apearson_ has joined #openstack-powervm | 23:43 | |
| *** thorst has joined #openstack-powervm | 23:44 | |
| *** thorst_ has joined #openstack-powervm | 23:55 | |
| *** miltonm has joined #openstack-powervm | 23:56 | |
| *** thorst has quit IRC | 23:58 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!