| *** thorst_ has joined #openstack-powervm | 00:00 | |
| *** thorst_ has quit IRC | 00:09 | |
| *** thorst_ has joined #openstack-powervm | 00:10 | |
| *** thorst_ has quit IRC | 00:19 | |
| *** jwcroppe has joined #openstack-powervm | 00:23 | |
| *** jwcroppe has quit IRC | 00:28 | |
| *** thorst_ has joined #openstack-powervm | 00:34 | |
| *** thorst_ has quit IRC | 00:39 | |
| *** thorst_ has joined #openstack-powervm | 00:53 | |
| *** thorst_ has quit IRC | 00:53 | |
| *** smatzek has joined #openstack-powervm | 01:09 | |
| *** smatzek has quit IRC | 01:41 | |
| *** thorst_ has joined #openstack-powervm | 01:52 | |
| *** thorst_ has quit IRC | 02:07 | |
| *** thorst_ has joined #openstack-powervm | 02:08 | |
| *** thorst_ has quit IRC | 02:16 | |
| *** seroyer has joined #openstack-powervm | 02:20 | |
| *** jwcroppe has joined #openstack-powervm | 02:26 | |
| *** jwcroppe has quit IRC | 02:31 | |
| *** thorst_ has joined #openstack-powervm | 03:15 | |
| *** thorst_ has quit IRC | 03:21 | |
| *** seroyer has quit IRC | 03:33 | |
| *** thorst_ has joined #openstack-powervm | 04:18 | |
| *** esberglu has joined #openstack-powervm | 04:22 | |
| *** thorst_ has quit IRC | 04:26 | |
| *** jwcroppe has joined #openstack-powervm | 04:29 | |
| *** jwcroppe has quit IRC | 04:33 | |
| *** esberglu has quit IRC | 05:11 | |
| *** thorst_ has joined #openstack-powervm | 05:25 | |
| *** thorst_ has quit IRC | 05:31 | |
| *** kotra03 has joined #openstack-powervm | 05:55 | |
| *** svenkat has quit IRC | 06:16 | |
| *** jwcroppe has joined #openstack-powervm | 06:23 | |
| *** jwcroppe has quit IRC | 06:28 | |
| *** thorst_ has joined #openstack-powervm | 06:29 | |
| *** thorst_ has quit IRC | 06:36 | |
| *** thorst_ has joined #openstack-powervm | 07:34 | |
| *** thorst_ has quit IRC | 07:41 | |
| *** k0da has joined #openstack-powervm | 08:25 | |
| *** thorst_ has joined #openstack-powervm | 08:39 | |
| *** thorst_ has quit IRC | 08:47 | |
| *** thorst_ has joined #openstack-powervm | 09:45 | |
| *** thorst_ has quit IRC | 09:52 | |
| *** jwcroppe has joined #openstack-powervm | 10:20 | |
| *** jwcroppe has quit IRC | 10:27 | |
| *** thorst_ has joined #openstack-powervm | 11:04 | |
| *** edmondsw has joined #openstack-powervm | 12:04 | |
| *** smatzek has joined #openstack-powervm | 12:06 | |
| *** svenkat has joined #openstack-powervm | 12:10 | |
| *** jwcroppe has joined #openstack-powervm | 12:15 | |
| *** jwcroppe has quit IRC | 12:26 | |
| thorst_ | efried: there? | 12:33 |
|---|---|---|
| *** esberglu has joined #openstack-powervm | 12:47 | |
| *** seroyer has joined #openstack-powervm | 12:47 | |
| *** seroyer has quit IRC | 12:54 | |
| *** k0da has quit IRC | 12:56 | |
| *** seroyer has joined #openstack-powervm | 13:01 | |
| *** kylek3h has joined #openstack-powervm | 13:03 | |
| *** k0da has joined #openstack-powervm | 13:04 | |
| *** esberglu has quit IRC | 13:05 | |
| *** esberglu has joined #openstack-powervm | 13:05 | |
| *** mdrabe has joined #openstack-powervm | 13:08 | |
| *** esberglu has quit IRC | 13:09 | |
| *** jwcroppe has joined #openstack-powervm | 13:19 | |
| *** seroyer has quit IRC | 13:25 | |
| *** esberglu has joined #openstack-powervm | 13:25 | |
| efried | thorst_, sup? | 13:34 |
| thorst_ | can't make sprint planning today | 13:34 |
| thorst_ | you just hammering away at the SR-IOV? | 13:34 |
| *** jwcroppe has quit IRC | 13:37 | |
| efried | thorst_, yeah. Optimistically, I may finish the community drivers this week. If that's the case, do we have something specific lined up next for me? | 13:41 |
| thorst_ | efried: a refocus on CI... | 13:44 |
| efried | ight | 13:44 |
| thorst_ | SR-IOV is top priority, but CI is next | 13:44 |
| thorst_ | we need to stabilize... | 13:45 |
| *** tblakes has joined #openstack-powervm | 13:45 | |
| efried | thorst_, ack. Will help as able. | 13:47 |
| efried | thorst_, what should I report for your activity this sprint? | 14:01 |
| thorst_ | efried: I'm trying to get that zero downtime for live migration | 14:02 |
| thorst_ | and possibly multiple vSwitch support for SEA | 14:02 |
| thorst_ | but that depends on you getting that mechanism driver stuff in | 14:02 |
| thorst_ | plus some OSA stuff | 14:02 |
| efried | rgr | 14:02 |
| *** seroyer has joined #openstack-powervm | 14:04 | |
| *** kotra03 has quit IRC | 14:10 | |
| efried | thorst_ (adreznec): recall https://review.openstack.org/#/c/350268/ -- we were considering reworking this to use add_lpar_storage_scrub_tasks with the new flag, but would need pypowervm 3692 into the 1.0.0.3.1 hotfix. What do you think? Is it worth it, or is the community code sufficiently non-ugly that we can leave it as is? | 14:11 |
| *** apearson has joined #openstack-powervm | 14:22 | |
| *** burgerk has joined #openstack-powervm | 14:23 | |
| thorst_ | efried: I'd rather not bump a pypowervm requirement | 14:32 |
| thorst_ | I'd leave as is | 14:32 |
| thorst_ | in fact, I kinda want a mitaka change that moves the pypowervm req to 1.0.0.3 | 14:33 |
| *** kotra03 has joined #openstack-powervm | 14:34 | |
| *** mdrabe has quit IRC | 14:37 | |
| *** tjakobs has joined #openstack-powervm | 14:41 | |
| *** mdrabe has joined #openstack-powervm | 14:45 | |
| *** apearson has quit IRC | 14:58 | |
| *** apearson has joined #openstack-powervm | 14:59 | |
| *** kylek3h_ has joined #openstack-powervm | 15:00 | |
| *** kylek3h has quit IRC | 15:02 | |
| thorst_ | efried: wanna chat console? | 15:12 |
| efried | thorst_, aaight. | 15:18 |
| thorst_ | so basically, the problem is that when a console is created...if not explicitly destroyed...it sticks around forever and the 'config' of that console can't change | 15:19 |
| efried | adreznec: https://review.openstack.org/#/c/350525/ | 15:19 |
| thorst_ | when managing via OpenStack, it assumes that OpenStack owns the environment... | 15:19 |
| thorst_ | so I think that it should override and destroy the previous console | 15:19 |
| thorst_ | but | 15:19 |
| thorst_ | I'm thinking I can add a 'force' of sorts on the API to allow nova-powervm to state "destroy what's there" | 15:20 |
| thorst_ | but I don't know of any use cases today that would set that to False. | 15:20 |
| efried | If the "manual" vterm is still open and in use. | 15:20 |
| efried | then I don't think we want to yank the rug without a force specified. | 15:21 |
| thorst_ | well, I'm OK putting a force in | 15:21 |
| efried | It'd be kinda like if you did mkvterm today and it automatically rmvterm'd for you by default. | 15:21 |
| thorst_ | efried: heck yeah, I wish it did | 15:21 |
| thorst_ | mkvterm ; rmvterm; mkvterm | 15:21 |
| thorst_ | super annoying. | 15:21 |
| efried | More annoying: being kicked off an active vterm. | 15:22 |
| efried | Here's a question, though: is there any way to specify this force flag from within the horizon dashboard? | 15:22 |
| efried | thorst_ ^^ | 15:23 |
| thorst_ | efried: nope | 15:23 |
| thorst_ | btw - it reuses the console IF it is opened in VNC | 15:23 |
| efried | Yeah | 15:24 |
| thorst_ | so its only dropping the console if you change type | 15:24 |
| efried | So that's what the openstack user has come to expect. | 15:24 |
| thorst_ | and the openstack user will get the console always | 15:24 |
| efried | If we error on the horizon dashboard, do we have the ability for the user to see a helpful message? | 15:24 |
| thorst_ | (but two users can share it) | 15:24 |
| thorst_ | nope | 15:24 |
| efried | eff. | 15:24 |
| thorst_ | yep | 15:24 |
| thorst_ | its limited | 15:24 |
| thorst_ | its called 'get_console' | 15:24 |
| thorst_ | you better just return a darn console | 15:24 |
| thorst_ | :-) | 15:24 |
| efried | Community change to make a useful error come through? | 15:25 |
| thorst_ | uhhh...I think you'd need a noVNC change to come through | 15:25 |
| thorst_ | I mean, I could post an error there | 15:25 |
| adreznec | Thanks efried | 15:25 |
| thorst_ | but I still think nova-powervm should just force it through | 15:25 |
| thorst_ | 95% of the time a console is still open | 15:26 |
| thorst_ | is because the user is actually done and forgot to close it | 15:26 |
| thorst_ | I don't think I've ever booted someone | 15:26 |
| thorst_ | and also...now that I think about it...when you create the console in horizon, it does keep the context | 15:26 |
| thorst_ | so the horizon user would get the context. | 15:26 |
| thorst_ | it doesn't reload you to sign in (unless a specific AIX I think) | 15:26 |
| efried | not if we blew away a mkvterm | 15:27 |
| thorst_ | yes, even if we blow away a mkvterm | 15:27 |
| thorst_ | it just doesn't work that way on VIOS | 15:27 |
| thorst_ | and *certain* AIX's | 15:27 |
| thorst_ | so the visual would be blank...sure. But the 'context' (command history, am I signed in, etc...) would still be there. | 15:27 |
| efried | okay. | 15:28 |
| efried | So I'm convinced (though barely) that we should force by default on the horizon dashboard. | 15:29 |
| efried | What about retrying any time stdout is empty? | 15:29 |
| thorst_ | I'd be OK if the stderr starts with PVME, retry | 15:30 |
| thorst_ | and log what that PVME is | 15:30 |
| efried | I can dig that. As long as it's made clear in the commit message that what we're doing is way more general than just detecting whether a mkvterm is open. | 15:30 |
| thorst_ | fine fine | 15:32 |
| thorst_ | you worry so much :-) | 15:32 |
| *** seroyer has quit IRC | 15:32 | |
| *** kotra03 has quit IRC | 15:33 | |
| openstackgerrit | Merged openstack/nova-powervm: Move LPAR scrub tasks from build_map to Create task https://review.openstack.org/354217 | 15:33 |
| *** mdrabe has quit IRC | 15:35 | |
| *** mdrabe has joined #openstack-powervm | 15:35 | |
| *** seroyer has joined #openstack-powervm | 15:46 | |
| efried | thorst_, 3746: discuss? | 15:52 |
| thorst_ | can't atm | 15:52 |
| efried | thorst_, np, just look at comments when able. | 15:54 |
| *** kylek3h_ has quit IRC | 16:06 | |
| *** kylek3h_ has joined #openstack-powervm | 16:08 | |
| *** efried has quit IRC | 16:12 | |
| *** apearson has quit IRC | 16:12 | |
| *** dwayne has joined #openstack-powervm | 16:21 | |
| *** k0da has quit IRC | 16:28 | |
| *** apearson has joined #openstack-powervm | 16:32 | |
| *** chmod666org has quit IRC | 17:01 | |
| *** chmod666org has joined #openstack-powervm | 17:07 | |
| *** tblakes has quit IRC | 18:19 | |
| *** tblakes has joined #openstack-powervm | 18:23 | |
| *** efried has joined #openstack-powervm | 18:52 | |
| adreznec | esberglu: Congrats on https://review.openstack.org/#/c/352455/ | 18:54 |
| esberglu | adreznec: Thanks | 18:58 |
| adreznec | Now we can have working quotas again :) | 18:58 |
| adreznec | Or lack thereof | 18:59 |
| adreznec | efried: thorst_ esberglu What do you guys think about signing up for requirements enforcement on our projects? https://github.com/openstack/requirements/#enforcement-in-projects | 19:00 |
| adreznec | Basically it would make sure that we're not adding any deps outside of global-reqs, and the system would automatically push a review request to update our requirements when global-reqs changes | 19:01 |
| efried | adreznec, I'm concerned about that first thing. We have reqs that aren't in global-requirements. Like pypowervm. | 19:01 |
| adreznec | Sorry, outside == versions outside the range of global reqs | 19:02 |
| adreznec | I think we can still have other dependencies | 19:02 |
| efried | "ensures that those projects can not add a requirement that is not already in global-requirements.txt" | 19:02 |
| thorst_ | adreznec: yeah, I'm on board. pypowervm still is an issue | 19:02 |
| adreznec | Oh, hmm | 19:02 |
| adreznec | Well technically we don't list pypowervm in requirements today... | 19:02 |
| adreznec | Soooooooo | 19:02 |
| efried | I also don't see where it says it'll automatically create a change set when global requirements change. | 19:03 |
| thorst_ | adreznec: right... | 19:03 |
| thorst_ | so it could be done | 19:03 |
| efried | Which would really be the only thing I'm seriously interested in doing | 19:03 |
| adreznec | "For instance: if a review is accepted to global-requirements.txt that increases the minimum version of python-keystoneclient, the system will submit patches to all the OpenStack projects that list python-keystoneclient as a requirement or test requirement to match this new version definition." | 19:03 |
| efried | so we can be proactive instead of reactive. | 19:03 |
| adreznec | efried: Yeah, that was the part I care about | 19:04 |
| adreznec | Updating reqs continuously is a pain | 19:04 |
| thorst_ | adreznec: +1 | 19:04 |
| efried | Though it seems like we might be able to do better with a hand-written job | 19:04 |
| thorst_ | its usually a 'o, I hadn't done this before' | 19:04 |
| thorst_ | efried: possibly...but why be different? | 19:04 |
| efried | If we don't need requirements that aren't global, no reason. | 19:04 |
| adreznec | efried: True, but then we have to maintain it | 19:05 |
| efried | Can we try it without committing to it? ;-) | 19:05 |
| adreznec | Maintenance is no fun at all | 19:05 |
| adreznec | :P | 19:05 |
| efried | Meh. Give it to Dom. | 19:05 |
| adreznec | We can run the tool manually I guess | 19:05 |
| adreznec | and see if we pass | 19:05 |
| efried | yeah. Let's do that first. | 19:05 |
| adreznec | I'll take a swing at it while doing my next OSA run in the background | 19:06 |
| adreznec | See how things shake out | 19:06 |
| efried | noyce | 19:06 |
| *** tblakes has quit IRC | 19:15 | |
| *** tblakes has joined #openstack-powervm | 19:24 | |
| *** k0da has joined #openstack-powervm | 19:41 | |
| efried | thorst_, mdrabe: 3746. Does this stand a chance with you guys in any form? I just gotta get rid of __get_prop. Hate that guy. | 19:43 |
| mdrabe | efried: How is it represented in the REST schema? Is it VNIC/VNICDetails ? | 19:46 |
| mdrabe | lookin myself jw if you know off top | 19:46 |
| efried | VirtualNICDedicated.VirtualNICDetails.<stuff> I believe. | 19:47 |
| mdrabe | Oh yea it's VirtualNICDedicated.Details | 19:48 |
| efried | So yeah, no matter what, I'm gonna make all the Details props show up under VNIC. | 19:49 |
| efried | I just really don't want to do it with one of these gross __get_props() methods. That's ugly and stupid. | 19:49 |
| mdrabe | Yea so this proxy thing is gonna make it so that you could still do both? | 19:49 |
| mdrabe | i.e. VNIC.VNICDetails.mac or VNIC.mac ? | 19:49 |
| efried | Well, yes, but I'm going to make _details a private @property. | 19:49 |
| efried | I don't *want* you to go through the indirect path. | 19:50 |
| mdrabe | Oh so it'd be VNIC._details.mac? | 19:50 |
| efried | No, dammit, it'll be VNIC.mac | 19:50 |
| efried | Don't use _details publicly. | 19:50 |
| efried | It's stupid. | 19:50 |
| efried | It should have never been in the schema. | 19:50 |
| efried | I'm going to hide it in the wrappers. | 19:50 |
| mdrabe | Yea... | 19:50 |
| efried | Heck, maybe I should make it __details | 19:50 |
| mdrabe | My opinion is that wrappers and REST schema should be aligned, even if REST schema is stupid | 19:51 |
| efried | Oh, that one I'm gonna veto. | 19:51 |
| mdrabe | But my opinion is also certainly subject to being stupid | 19:51 |
| efried | Yeah, that's not on the table | 19:51 |
| efried | We already have precedent for hiding stupid levels of indirection. We're gonna keep doing that. | 19:51 |
| efried | The only question is how. | 19:51 |
| efried | So in this case, I wrote a generic way for doing it that works for all of the cases where we need it. | 19:52 |
| efried | The execution may be a little unreadable as currently written. | 19:53 |
| efried | So what I'm asking is: would it be more acceptable if I split the assignments so they're one per line? | 19:53 |
| mdrabe | Would it be under the VNIC class then? | 19:54 |
| mdrabe | Or still VNICDetails class which is private of VNIC? | 19:54 |
| mdrabe | option 1 or 2 there | 19:54 |
| efried | In the VNIC class, instead of | 19:55 |
| efried | pvid, allowed_vlans, mac, allowed_macs, capacity = u.proxyprops( | 19:55 |
| efried | _details, VNICDetails.pvid, VNICDetails.allowed_vlans, VNICDetails.mac, | 19:55 |
| efried | VNICDetails.allowed_macs, VNICDetails.capacity) | 19:55 |
| efried | it would be more like | 19:55 |
| efried | pvid = u.proxyprop(_details, VNICDetails.pvid) | 19:55 |
| efried | allowed_vlans = u.proxyprop(_details, VNICDetails.allowed_vlans) | 19:55 |
| efried | etc. | 19:55 |
| mdrabe | Yea I like that better, nice and explicit | 19:57 |
| mdrabe | sort of | 19:57 |
| efried | Better name for proxyprop? Maybe nestedprop? | 19:58 |
| *** seroyer has quit IRC | 19:58 | |
| mdrabe | Yea nestedprop, subprop maybe | 19:58 |
| *** seroyer has joined #openstack-powervm | 19:58 | |
| efried | I'll propose it up that way and see if thorst_ can stand it. | 19:58 |
| efried | Debugging-wise, you'll still wind up in the same place as before if you're stepping through. | 19:59 |
| mdrabe | Will you? | 19:59 |
| mdrabe | Not in any of this proxyprop business? | 19:59 |
| efried | I can try it out. But thinking it through, you would just end up inside of the @property getter within the nested wrapper class. | 20:00 |
| efried | The proxyprop method gets called when the class is evaluated (at "compile" time). Just like the @property decorator does. | 20:01 |
| efried | So it's n/a at runtime. Just like the @property decorator. | 20:01 |
| mdrabe | efried: Can you make proxyprop to be used as a decorator like @property is? | 20:05 |
| efried | Tried to make that work. But what would the contents of the method be? | 20:06 |
| mdrabe | A pass I guess... | 20:06 |
| efried | Resulting in zero LOC reduction from existing code, and arguably harder to read. (This method doesn't do anything, to all appearances.) | 20:09 |
| efried | It's not a horrible idea, but I think I like it a little bit less than the way it's being done. | 20:10 |
| * thorst_ doesn't like proxy props yet | 20:11 | |
| efried | thorst_, cool - we're getting rid of them. We'll now have a separate nestedprop for each one. | 20:12 |
| thorst_ | efried: if it helps, I admire the code | 20:13 |
| thorst_ | I just don't like the experience to someone new | 20:13 |
| efried | thorst_, hoping making it more readable will help. | 20:14 |
| mdrabe | If you're gonna do the proxyprop thing, at that point might as well just make VNICDetails private and for something like the MAC address just to self._details.mac | 20:14 |
| mdrabe | just do* | 20:14 |
| efried | I don't follow. | 20:15 |
| efried | Where would I just do self._details.mac? | 20:15 |
| efried | In a normal @property getter? | 20:15 |
| mdrabe | In VNIC.mac | 20:15 |
| mdrabe | Yea | 20:15 |
| efried | That's not better than __get_prop | 20:16 |
| mdrabe | efried: b/c of LOC? | 20:18 |
| efried | Heck, if I wanted to have all those methods, I could just do _get_val_str(u.xpath(_VNIC_DETAILS, _VNICD_MAC)) | 20:18 |
| efried | Yeah. Repetition of code, and bloated useless vertical space consumption. | 20:19 |
| efried | Not to mention sonar... | 20:19 |
| mdrabe | Why not just get rid of VNICDetails all together | 20:20 |
| mdrabe | er maybe that's what you were getting at? | 20:20 |
| efried | And do the above. Could do that. | 20:20 |
| esberglu | thorst: adreznec: Second AIO local.conf attempt failed trying to load the neutron trunk plugin | 20:21 |
| esberglu | http://paste.openstack.org/show/557619/ | 20:21 |
| thorst_ | esberglu: turn off tests in prod, remove plugin. Wait it out in staging? | 20:22 |
| thorst_ | see if bug opened against it | 20:22 |
| efried | thorst_, mdrabe - take a look at PS4. If you still hate it, I'll... do something else. | 20:23 |
| mdrabe | efried: I kinda like blasting VNICDetails all together. If it's so stupid why even give it it's own class | 20:24 |
| mdrabe | efried: question, with nestedprop that allows for the setting of the props as well? Are some of those fields not supposed to be set? | 20:26 |
| efried | nestedprop clones both get & set, and behaves correctly if the setter doesn't exist. | 20:27 |
| esberglu | thorst_: Don’t see any bugs reported. I’m trying another build without q-trunk. | 20:28 |
| thorst_ | also check in openstack-neutron | 20:28 |
| thorst_ | wonder if we just have a weird config thing | 20:28 |
| mdrabe | @efried: idk man. The nestedprop thing is neat, but moving VNICDetails into VNIC is less LOC (since nestedprop util isn't needed) and more readable.... | 20:34 |
| mdrabe | plus I doubt ps4 convinces the other guy | 20:35 |
| *** smatzek has quit IRC | 21:05 | |
| efried | mdrabe, can't do it. | 21:06 |
| efried | Need the intermediate wrapper to keep track of element order, and to facilitate setting props that ain't there yet. | 21:06 |
| efried | I got close. Then got the door slammed in my face. | 21:06 |
| mdrabe | Sure you can't close the door? | 21:07 |
| efried | Only if you don't look at me. | 21:07 |
| efried | mdrabe, I think the best I could do is leave just the setters in the nested wrapper, use u.xpath to two-step the getters. Not sure I like the idea of splitting up the getter & setter for a given property. | 21:09 |
| *** k0da has quit IRC | 21:09 | |
| *** svenkat has quit IRC | 21:14 | |
| efried | ...'cept I can't split up a setter @property from its getter. Would have to dup anyway in such cases. | 21:15 |
| mdrabe | If getting rid of the VNICDetails, I don't understand why the setter becomes a problem | 21:16 |
| efried | Because the setter has to put the values under <Details> in the actual XML. | 21:17 |
| mdrabe | For the child order does pvm_type not enforce the order of "sub" wrapper | 21:17 |
| efried | And you can't say "set the value of Details/Foo to 'bar'" | 21:17 |
| efried | pvm_type has no notion of subwrappers. | 21:17 |
| mdrabe | You can't? You sure about that | 21:17 |
| efried | Yes, cause I tried it, and it punted. | 21:18 |
| mdrabe | Ok sorry, that's weird | 21:18 |
| efried | Have to seed the nested property first, then parse down into it, then find or seed the new property, then set that guy. | 21:18 |
| efried | Which either requires doing that manually any time I need it, or rewriting bits of the wrapper infrastructure that are super central to everything we do everywhere (read: risky as hell). | 21:19 |
| mdrabe | The former there yea... | 21:19 |
| efried | I guess I could write a new core method to do it. | 21:19 |
| efried | But still have the problem of nested element order. | 21:20 |
| efried | Would need a new paradigm for specifying that. | 21:20 |
| efried | All together, gets to be more trouble than it's worth. | 21:20 |
| efried | The nestedprop thing is the best thing so far. | 21:20 |
| mdrabe | Is it so bad just saying vnic.details.mac? | 21:24 |
| efried | There are other side effects. | 21:24 |
| mdrabe | like? | 21:25 |
| efried | See https://review.openstack.org/#/c/343419/16/nova_powervm/virt/powervm/vif.py@477 | 21:25 |
| efried | That search doesn't work unless mac is directly under VNIC. | 21:25 |
| efried | Are there other ways around it? Sure. | 21:25 |
| efried | But having Details nested is *still* stupid, regardless of that. | 21:26 |
| mdrabe | efried: I'll wait on what thorst_ thinks | 21:33 |
| *** dwayne has quit IRC | 21:34 | |
| *** miltonm has quit IRC | 21:44 | |
| *** burgerk has quit IRC | 21:48 | |
| *** esberglu has quit IRC | 22:06 | |
| *** thorst_ has quit IRC | 22:08 | |
| *** mdrabe has quit IRC | 22:09 | |
| *** thorst_ has joined #openstack-powervm | 22:13 | |
| *** thorst_ has quit IRC | 22:18 | |
| *** apearson has quit IRC | 22:19 | |
| *** tblakes has quit IRC | 22:32 | |
| *** tjakobs has quit IRC | 22:32 | |
| *** dwayne has joined #openstack-powervm | 22:37 | |
| openstackgerrit | Eric Fried proposed openstack/nova-powervm: VIF driver implementation for SR-IOV https://review.openstack.org/343419 | 22:43 |
| *** seroyer has quit IRC | 22:44 | |
| *** efried has quit IRC | 22:49 | |
| *** edmondsw has quit IRC | 22:51 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!