Monday, 2016-08-15

*** thorst_ has joined #openstack-powervm00:00
*** thorst_ has quit IRC00:09
*** thorst_ has joined #openstack-powervm00:10
*** thorst_ has quit IRC00:19
*** jwcroppe has joined #openstack-powervm00:23
*** jwcroppe has quit IRC00:28
*** thorst_ has joined #openstack-powervm00:34
*** thorst_ has quit IRC00:39
*** thorst_ has joined #openstack-powervm00:53
*** thorst_ has quit IRC00:53
*** smatzek has joined #openstack-powervm01:09
*** smatzek has quit IRC01:41
*** thorst_ has joined #openstack-powervm01:52
*** thorst_ has quit IRC02:07
*** thorst_ has joined #openstack-powervm02:08
*** thorst_ has quit IRC02:16
*** seroyer has joined #openstack-powervm02:20
*** jwcroppe has joined #openstack-powervm02:26
*** jwcroppe has quit IRC02:31
*** thorst_ has joined #openstack-powervm03:15
*** thorst_ has quit IRC03:21
*** seroyer has quit IRC03:33
*** thorst_ has joined #openstack-powervm04:18
*** esberglu has joined #openstack-powervm04:22
*** thorst_ has quit IRC04:26
*** jwcroppe has joined #openstack-powervm04:29
*** jwcroppe has quit IRC04:33
*** esberglu has quit IRC05:11
*** thorst_ has joined #openstack-powervm05:25
*** thorst_ has quit IRC05:31
*** kotra03 has joined #openstack-powervm05:55
*** svenkat has quit IRC06:16
*** jwcroppe has joined #openstack-powervm06:23
*** jwcroppe has quit IRC06:28
*** thorst_ has joined #openstack-powervm06:29
*** thorst_ has quit IRC06:36
*** thorst_ has joined #openstack-powervm07:34
*** thorst_ has quit IRC07:41
*** k0da has joined #openstack-powervm08:25
*** thorst_ has joined #openstack-powervm08:39
*** thorst_ has quit IRC08:47
*** thorst_ has joined #openstack-powervm09:45
*** thorst_ has quit IRC09:52
*** jwcroppe has joined #openstack-powervm10:20
*** jwcroppe has quit IRC10:27
*** thorst_ has joined #openstack-powervm11:04
*** edmondsw has joined #openstack-powervm12:04
*** smatzek has joined #openstack-powervm12:06
*** svenkat has joined #openstack-powervm12:10
*** jwcroppe has joined #openstack-powervm12:15
*** jwcroppe has quit IRC12:26
thorst_efried: there?12:33
*** esberglu has joined #openstack-powervm12:47
*** seroyer has joined #openstack-powervm12:47
*** seroyer has quit IRC12:54
*** k0da has quit IRC12:56
*** seroyer has joined #openstack-powervm13:01
*** kylek3h has joined #openstack-powervm13:03
*** k0da has joined #openstack-powervm13:04
*** esberglu has quit IRC13:05
*** esberglu has joined #openstack-powervm13:05
*** mdrabe has joined #openstack-powervm13:08
*** esberglu has quit IRC13:09
*** jwcroppe has joined #openstack-powervm13:19
*** seroyer has quit IRC13:25
*** esberglu has joined #openstack-powervm13:25
efriedthorst_, sup?13:34
thorst_can't make sprint planning today13:34
thorst_you just hammering away at the SR-IOV?13:34
*** jwcroppe has quit IRC13:37
efriedthorst_, 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
thorst_SR-IOV is top priority, but CI is next13:44
thorst_we need to stabilize...13:45
*** tblakes has joined #openstack-powervm13:45
efriedthorst_, ack.  Will help as able.13:47
efriedthorst_, what should I report for your activity this sprint?14:01
thorst_efried: I'm trying to get that zero downtime for live migration14:02
thorst_and possibly multiple vSwitch support for SEA14:02
thorst_but that depends on you getting that mechanism driver stuff in14:02
thorst_plus some OSA stuff14:02
*** seroyer has joined #openstack-powervm14:04
*** kotra03 has quit IRC14:10
efriedthorst_ (adreznec): recall -- we were considering reworking this to use add_lpar_storage_scrub_tasks with the new flag, but would need pypowervm 3692 into the 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-powervm14:22
*** burgerk has joined #openstack-powervm14:23
thorst_efried: I'd rather not bump a pypowervm requirement14:32
thorst_I'd leave as is14:32
thorst_in fact, I kinda want a mitaka change that moves the pypowervm req to
*** kotra03 has joined #openstack-powervm14:34
*** mdrabe has quit IRC14:37
*** tjakobs has joined #openstack-powervm14:41
*** mdrabe has joined #openstack-powervm14:45
*** apearson has quit IRC14:58
*** apearson has joined #openstack-powervm14:59
*** kylek3h_ has joined #openstack-powervm15:00
*** kylek3h has quit IRC15:02
thorst_efried: wanna chat console?15:12
efriedthorst_, aaight.15:18
thorst_so basically, the problem is that when a console is created...if not explicitly sticks around forever and the 'config' of that console can't change15: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 console15: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
efriedIf the "manual" vterm is still open and in use.15:20
efriedthen I don't think we want to yank the rug without a force specified.15:21
thorst_well, I'm OK putting a force in15:21
efriedIt'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 did15:21
thorst_mkvterm ; rmvterm; mkvterm15:21
thorst_super annoying.15:21
efriedMore annoying: being kicked off an active vterm.15:22
efriedHere's a question, though:  is there any way to specify this force flag from within the horizon dashboard?15:22
efriedthorst_ ^^15:23
thorst_efried: nope15:23
thorst_btw - it reuses the console IF it is opened in VNC15:23
thorst_so its only dropping the console if you change type15:24
efriedSo that's what the openstack user has come to expect.15:24
thorst_and the openstack user will get the console always15:24
efriedIf 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_its limited15:24
thorst_its called 'get_console'15:24
thorst_you better just return a darn console15:24
efriedCommunity change to make a useful error come through?15:25
thorst_uhhh...I think you'd need a noVNC change to come through15:25
thorst_I mean, I could post an error there15:25
adreznecThanks efried15:25
thorst_but I still think nova-powervm should just force it through15:25
thorst_95% of the time a console is still open15:26
thorst_is because the user is actually done and forgot to close it15:26
thorst_I don't think I've ever booted someone15:26
thorst_and that I think about it...when you create the console in horizon, it does keep the context15: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
efriednot if we blew away a mkvterm15:27
thorst_yes, even if we blow away a mkvterm15:27
thorst_it just doesn't work that way on VIOS15:27
thorst_and *certain* AIX's15: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
efriedSo I'm convinced (though barely) that we should force by default on the horizon dashboard.15:29
efriedWhat about retrying any time stdout is empty?15:29
thorst_I'd be OK if the stderr starts with PVME, retry15:30
thorst_and log what that PVME is15:30
efriedI 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 fine15:32
thorst_you worry so much  :-)15:32
*** seroyer has quit IRC15:32
*** kotra03 has quit IRC15:33
openstackgerritMerged openstack/nova-powervm: Move LPAR scrub tasks from build_map to Create task
*** mdrabe has quit IRC15:35
*** mdrabe has joined #openstack-powervm15:35
*** seroyer has joined #openstack-powervm15:46
efriedthorst_, 3746: discuss?15:52
thorst_can't atm15:52
efriedthorst_, np, just look at comments when able.15:54
*** kylek3h_ has quit IRC16:06
*** kylek3h_ has joined #openstack-powervm16:08
*** efried has quit IRC16:12
*** apearson has quit IRC16:12
*** dwayne has joined #openstack-powervm16:21
*** k0da has quit IRC16:28
*** apearson has joined #openstack-powervm16:32
*** chmod666org has quit IRC17:01
*** chmod666org has joined #openstack-powervm17:07
*** tblakes has quit IRC18:19
*** tblakes has joined #openstack-powervm18:23
*** efried has joined #openstack-powervm18:52
adreznecesberglu: Congrats on
esbergluadreznec: Thanks18:58
adreznecNow we can have working quotas again :)18:58
adreznecOr lack thereof18:59
adreznecefried: thorst_ esberglu What do you guys think about signing up for requirements enforcement on our projects?
adreznecBasically 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 changes19:01
efriedadreznec, I'm concerned about that first thing.  We have reqs that aren't in global-requirements.  Like pypowervm.19:01
adreznecSorry, outside == versions outside the range of global reqs19:02
adreznecI think we can still have other dependencies19: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 issue19:02
adreznecOh, hmm19:02
adreznecWell technically we don't list pypowervm in requirements today...19:02
efriedI 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 done19:03
efriedWhich would really be the only thing I'm seriously interested in doing19: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
efriedso we can be proactive instead of reactive.19:03
adreznecefried: Yeah, that was the part I care about19:04
adreznecUpdating reqs continuously is a pain19:04
thorst_adreznec: +119:04
efriedThough it seems like we might be able to do better with a hand-written job19:04
thorst_its usually a 'o, I hadn't done this before'19:04
thorst_efried: possibly...but why be different?19:04
efriedIf we don't need requirements that aren't global, no reason.19:04
adreznecefried: True, but then we have to maintain it19:05
efriedCan we try it without committing to it?  ;-)19:05
adreznecMaintenance is no fun at all19:05
efriedMeh.  Give it to Dom.19:05
adreznecWe can run the tool manually I guess19:05
adreznecand see if we pass19:05
efriedyeah.  Let's do that first.19:05
adreznecI'll take a swing at it while doing my next OSA run in the background19:06
adreznecSee how things shake out19:06
*** tblakes has quit IRC19:15
*** tblakes has joined #openstack-powervm19:24
*** k0da has joined #openstack-powervm19:41
efriedthorst_, 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
mdrabeefried: How is it represented in the REST schema? Is it VNIC/VNICDetails ?19:46
mdrabelookin myself jw if you know off top19:46
efriedVirtualNICDedicated.VirtualNICDetails.<stuff> I believe.19:47
mdrabeOh yea it's VirtualNICDedicated.Details19:48
efriedSo yeah, no matter what, I'm gonna make all the Details props show up under VNIC.19:49
efriedI just really don't want to do it with one of these gross __get_props() methods.  That's ugly and stupid.19:49
mdrabeYea so this proxy thing is gonna make it so that you could still do both?19:49
mdrabei.e. VNIC.VNICDetails.mac or VNIC.mac ?19:49
efriedWell, yes, but I'm going to make _details a private @property.19:49
efriedI don't *want* you to go through the indirect path.19:50
mdrabeOh so it'd be VNIC._details.mac?19:50
efriedNo, dammit, it'll be VNIC.mac19:50
efriedDon't use _details publicly.19:50
efriedIt's stupid.19:50
efriedIt should have never been in the schema.19:50
efriedI'm going to hide it in the wrappers.19:50
efriedHeck, maybe I should make it __details19:50
mdrabeMy opinion is that wrappers and REST schema should be aligned, even if REST schema is stupid19:51
efriedOh, that one I'm gonna veto.19:51
mdrabeBut my opinion is also certainly subject to being stupid19:51
efriedYeah, that's not on the table19:51
efriedWe already have precedent for hiding stupid levels of indirection.  We're gonna keep doing that.19:51
efriedThe only question is how.19:51
efriedSo in this case, I wrote a generic way for doing it that works for all of the cases where we need it.19:52
efriedThe execution may be a little unreadable as currently written.19:53
efriedSo what I'm asking is: would it be more acceptable if I split the assignments so they're one per line?19:53
mdrabeWould it be under the VNIC class then?19:54
mdrabeOr still VNICDetails class which is private of VNIC?19:54
mdrabeoption 1 or 2 there19:54
efriedIn the VNIC class, instead of19:55
efriedpvid, 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
efriedit would be more like19:55
efriedpvid = u.proxyprop(_details, VNICDetails.pvid)19:55
efriedallowed_vlans = u.proxyprop(_details, VNICDetails.allowed_vlans)19:55
mdrabeYea I like that better, nice and explicit19:57
mdrabesort of19:57
efriedBetter name for proxyprop?  Maybe nestedprop?19:58
*** seroyer has quit IRC19:58
mdrabeYea nestedprop, subprop maybe19:58
*** seroyer has joined #openstack-powervm19:58
efriedI'll propose it up that way and see if thorst_ can stand it.19:58
efriedDebugging-wise, you'll still wind up in the same place as before if you're stepping through.19:59
mdrabeWill you?19:59
mdrabeNot in any of this proxyprop business?19:59
efriedI 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
efriedThe proxyprop method gets called when the class is evaluated (at "compile" time).  Just like the @property decorator does.20:01
efriedSo it's n/a at runtime.  Just like the @property decorator.20:01
mdrabeefried: Can you make proxyprop to be used as a decorator like @property is?20:05
efriedTried to make that work.  But what would the contents of the method be?20:06
mdrabeA pass I guess...20:06
efriedResulting in zero LOC reduction from existing code, and arguably harder to read.  (This method doesn't do anything, to all appearances.)20:09
efriedIt'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 yet20:11
efriedthorst_, 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 code20:13
thorst_I just don't like the experience to someone new20:13
efriedthorst_, hoping making it more readable will help.20:14
mdrabeIf 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.mac20:14
mdrabejust do*20:14
efriedI don't follow.20:15
efriedWhere would I just do self._details.mac?20:15
efriedIn a normal @property getter?20:15
mdrabeIn VNIC.mac20:15
efriedThat's not better than __get_prop20:16
mdrabeefried: b/c of LOC?20:18
efriedHeck, if I wanted to have all those methods, I could just do _get_val_str(u.xpath(_VNIC_DETAILS, _VNICD_MAC))20:18
efriedYeah.  Repetition of code, and bloated useless vertical space consumption.20:19
efriedNot to mention sonar...20:19
mdrabeWhy not just get rid of VNICDetails all together20:20
mdrabeer maybe that's what you were getting at?20:20
efriedAnd do the above.  Could do that.20:20
esbergluthorst: adreznec: Second AIO local.conf attempt failed trying to load the neutron trunk plugin20:21
thorst_esberglu: turn off tests in prod, remove plugin.  Wait it out in staging?20:22
thorst_see if bug opened against it20:22
efriedthorst_, mdrabe - take a look at PS4.  If you still hate it, I'll... do something else.20:23
mdrabeefried: I kinda like blasting VNICDetails all together. If it's so stupid why even give it it's own class20:24
mdrabeefried: 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
efriednestedprop clones both get & set, and behaves correctly if the setter doesn't exist.20:27
esbergluthorst_: Don’t see any bugs reported. I’m trying another build without q-trunk.20:28
thorst_also check in openstack-neutron20:28
thorst_wonder if we just have a weird config thing20: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
mdrabeplus I doubt ps4 convinces the other guy20:35
*** smatzek has quit IRC21:05
efriedmdrabe, can't do it.21:06
efriedNeed the intermediate wrapper to keep track of element order, and to facilitate setting props that ain't there yet.21:06
efriedI got close.  Then got the door slammed in my face.21:06
mdrabeSure you can't close the door?21:07
efriedOnly if you don't look at me.21:07
efriedmdrabe, 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 IRC21:09
*** svenkat has quit IRC21:14
efried...'cept I can't split up a setter @property from its getter.  Would have to dup anyway in such cases.21:15
mdrabeIf getting rid of the VNICDetails, I don't understand why the setter becomes a problem21:16
efriedBecause the setter has to put the values under <Details> in the actual XML.21:17
mdrabeFor the child order does pvm_type not enforce the order of "sub" wrapper21:17
efriedAnd you can't say "set the value of Details/Foo to 'bar'"21:17
efriedpvm_type has no notion of subwrappers.21:17
mdrabeYou can't? You sure about that21:17
efriedYes, cause I tried it, and it punted.21:18
mdrabeOk sorry, that's weird21:18
efriedHave to seed the nested property first, then parse down into it, then find or seed the new property, then set that guy.21:18
efriedWhich 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
mdrabeThe former there yea...21:19
efriedI guess I could write a new core method to do it.21:19
efriedBut still have the problem of nested element order.21:20
efriedWould need a new paradigm for specifying that.21:20
efriedAll together, gets to be more trouble than it's worth.21:20
efriedThe nestedprop thing is the best thing so far.21:20
mdrabeIs it so bad just saying vnic.details.mac?21:24
efriedThere are other side effects.21:24
efriedThat search doesn't work unless mac is directly under VNIC.21:25
efriedAre there other ways around it?  Sure.21:25
efriedBut having Details nested is *still* stupid, regardless of that.21:26
mdrabeefried: I'll wait on what thorst_ thinks21:33
*** dwayne has quit IRC21:34
*** miltonm has quit IRC21:44
*** burgerk has quit IRC21:48
*** esberglu has quit IRC22:06
*** thorst_ has quit IRC22:08
*** mdrabe has quit IRC22:09
*** thorst_ has joined #openstack-powervm22:13
*** thorst_ has quit IRC22:18
*** apearson has quit IRC22:19
*** tblakes has quit IRC22:32
*** tjakobs has quit IRC22:32
*** dwayne has joined #openstack-powervm22:37
openstackgerritEric Fried proposed openstack/nova-powervm: VIF driver implementation for SR-IOV
*** seroyer has quit IRC22:44
*** efried has quit IRC22:49
*** edmondsw has quit IRC22:51

Generated by 2.14.0 by Marius Gedminas - find it at!