Friday, 2017-04-21

*** thorst has quit IRC00:12
*** chas has joined #openstack-powervm00:26
*** chas has quit IRC00:31
*** chas has joined #openstack-powervm01:02
*** chas has quit IRC01:07
*** jpasqualetto has quit IRC01:08
*** thorst has joined #openstack-powervm01:25
*** thorst has quit IRC01:32
*** chas has joined #openstack-powervm01:39
*** jpasqualetto has joined #openstack-powervm01:43
*** chas has quit IRC01:43
*** dwayne has joined #openstack-powervm01:45
*** smatzek has joined #openstack-powervm01:49
*** smatzek has quit IRC02:02
*** thorst has joined #openstack-powervm02:05
*** thorst has quit IRC02:05
*** thorst has joined #openstack-powervm02:05
*** thorst has quit IRC02:10
*** thorst has joined #openstack-powervm02:36
*** thorst has quit IRC02:50
*** thorst has joined #openstack-powervm02:50
*** thorst has quit IRC02:50
*** chas has joined #openstack-powervm02:50
*** chas has quit IRC02:56
*** dwayne has quit IRC03:10
*** thorst has joined #openstack-powervm03:51
*** thorst has quit IRC03:56
*** shyama has joined #openstack-powervm04:45
*** thorst has joined #openstack-powervm04:52
*** thorst has quit IRC04:57
*** openstackgerrit has joined #openstack-powervm05:48
openstackgerritArun Mani proposed openstack/nova-powervm master: Deploy of VM occasionally fails with OSError  https://review.openstack.org/45770705:48
*** kylek3h has quit IRC05:52
*** kylek3h has joined #openstack-powervm05:52
*** thorst has joined #openstack-powervm05:52
*** kylek3h has quit IRC05:57
*** thorst has quit IRC05:57
openstackgerritArun Mani proposed openstack/nova-powervm master: Deploy of VM occasionally fails with OSError  https://review.openstack.org/45770705:59
*** kylek3h has joined #openstack-powervm06:53
*** thorst has joined #openstack-powervm06:53
*** kylek3h has quit IRC06:58
*** thorst has quit IRC06:58
*** chas has joined #openstack-powervm07:08
*** kylek3h has joined #openstack-powervm07:54
*** thorst has joined #openstack-powervm07:54
*** shyama has quit IRC07:57
*** kylek3h has quit IRC07:58
*** thorst has quit IRC08:14
*** shyama has joined #openstack-powervm08:42
*** k0da has joined #openstack-powervm08:49
*** kylek3h has joined #openstack-powervm08:55
*** kylek3h has quit IRC08:59
*** kylek3h has joined #openstack-powervm09:56
*** kylek3h has quit IRC10:00
*** thorst has joined #openstack-powervm10:11
*** thorst has quit IRC10:16
*** smatzek has joined #openstack-powervm10:44
*** kylek3h has joined #openstack-powervm10:56
*** kylek3h has quit IRC11:01
*** thorst has joined #openstack-powervm11:25
*** kylek3h has joined #openstack-powervm11:57
*** kylek3h has quit IRC12:02
*** jpasqualetto has quit IRC12:09
*** jpasqualetto has joined #openstack-powervm12:22
*** shyama_ has joined #openstack-powervm12:28
*** shyama has quit IRC12:29
*** shyama_ is now known as shyama12:30
*** kylek3h has joined #openstack-powervm12:46
*** jpasqualetto has quit IRC12:48
*** apearson has joined #openstack-powervm12:52
*** efried has quit IRC12:57
*** mdrabe has joined #openstack-powervm13:04
*** jpasqualetto has joined #openstack-powervm13:08
*** efried has joined #openstack-powervm13:09
*** edmondsw has joined #openstack-powervm13:15
*** esberglu has joined #openstack-powervm13:19
*** tjakobs has joined #openstack-powervm13:25
*** kjw3 has joined #openstack-powervm13:42
*** dwayne has joined #openstack-powervm13:43
*** jpasqualetto has quit IRC13:49
*** jpasqualetto has joined #openstack-powervm14:01
*** jpasqualetto has quit IRC14:18
*** jpasqualetto has joined #openstack-powervm14:32
walerQuick question, for a P8/NovaLink Compute node, the /etc/neutron/plugins/ml2/ml2_conf.ini file has the bridge_mappings attribute. If your VIOS has two SEA (one on one phyp vSwitch, one on another vSwitch), but only one of them is to be used by deployed VMs, do you still need to specify both in the file?14:53
*** mdrabe has quit IRC15:02
adreznecwaler: I don't think so... thorst efried? ^15:03
efriedwaler I wouldn't think so.  But yeah, that's a thorst question.15:04
walerjust trying to fathom out the meaning in the docs, to see if I've done "too much" config upfront. I configured the SEA with additional VLANs (when I build the VIOS). But the networking-powervm docs say "the operator does not need to add VLANs, those will be managed by the powervm agent".15:05
walerwould certainly be useful if there were some example "known good/working" configuration files - just as something to compare against15:08
*** mdrabe has joined #openstack-powervm15:10
efriedadreznec Our devref has examples at least, right?  Can you point waler to that?  (I never know where those are.)15:12
efriedwaler Obviously we can't have known good/working cause your hosts/devs will be named differently from ours.15:12
waleryeah I appreciate naming conventions will be different. but it just is proving quite an uphill task to make progress15:13
adreznecefried: thorst (waler) the devref has examples of format, but nothing about what would be required for a specific SEA config given X VIOSes with Y SEAs15:14
adreznecIt's here FWIW http://networking-powervm.readthedocs.io/en/latest/devref/usage.html#optional-configuration15:14
waleryep, already found that15:14
thorstwaler: what do you mean one on a PHYP vswitch and another on anoter vswitch?  Is that other vswitch still a PHYP vswitch/15:15
thorstbut basically, if you have two SEAs, you need to specify in the bridge mappings which should be used for each 'physical network'15:16
waleryes both are PHYP vswitches, first SEA is on one of them, 2nd sea is on the other15:16
thorstthe physical network is an attribute you set on the neutron network when you create it15:16
walerit's just a way to separate the "openstack management" traffic, from the "tennant/vm" traffic15:16
thorstif you don't set the physical network, the system assumes the name like 'default'.15:16
thorstbut the idea is in the ml2.conf, you specify "default:vios1:ent5'15:16
thorst(not positive on syntax)15:16
adreznecFormat: <phnet1>:<sea1>:<vio1>,<phnet2>:<sea2>:<vio2> Example: default:ent5:vios_1,speedy:ent6:vios_115:17
adreznecIs the example syntax we give15:17
thorstbut that says that if a neutron network is running on the 'default' physical network, for this host that means VIOS1 running on ent515:17
waleryes, I appreciate the syntax - that was fine/clear. It was just if you only needed to specify the one you wanted openstack to know/care about. as aside to any/all SEAs15:17
thorstyeah, just the one you know and care about15:18
thorstwith that said15:18
thorstI do think the code is limited to ETHERNET015:18
thorstfor phyp vswitch15:18
thorstthat's something I've had on the backlog for a while...15:18
walerright, so leave the default phyp vswitch with the default name. let me see if that helps15:19
thorstyeah...that could definitely be the issue15:19
walerand what about the VLANs? will it be an issue that I've configured the SEA up-front with the additional VLANs (ie. traditionally)?15:19
thorstshouldn't be.  The networking-powervm will configure it for you.  If you have additional trunks attached to the SEA, that is what it deploys to15:22
thorstyou are only guaranteed control over the primary VEA on the SEA...15:22
thorstnet - we'll periodically clean out unused VLANs on the box (that's the entire box...not just things OpenStack knows about)15:22
walerokay thanks. Let me try renaming the phyp vswitch back to the default and update the ml2_conf.ini accordingly and we'll try again15:24
*** kjw3 has quit IRC15:26
esbergluefried: You got time to talk IT CI patching15:26
efriedYah15:27
efriedSo scenarios:15:27
esberglu1) Running against a patch that isn't IT15:30
efried1) A pvm in-tree patch might be a) between master and console (including console), or b) after console.15:30
efrieddammit, that's #2!15:30
esbergluOh I though you were asking me for them lol15:31
efriedYeah, I paused too long - got sidelined on another channel.15:31
efriedOkay, so let's do pvm changes first.15:31
esbergluYep sounds good15:31
efried1a will break if we try to apply the whole chain individually until patches above the one being checked are rebased.15:32
efriedI think.15:32
esbergluYep15:32
esbergluAnd it will also break if any of the patches in the list get merged15:32
esbergluBecause we are only checking back to master15:33
efriedwell, hold on, I'm not talking about how we have the CI set up right now.15:33
esbergluokay sorry15:33
efriedI'm just trying to enumerate the scenarios.15:33
efriedSo we can rewrite the CI code accordingly.15:33
efriedSo to make 1a work... we could (brainstorming here) `git review -d` the change in question.  This will bring down the change and any deps below it.15:34
efriedThen we go through all the changes from console down, applying them one at a time; but for each, check if it's already in the chain, and skip it if so.15:35
efriedI think that'll actually work UNLESS the patch set on the change in question causes a merge conflict up the chain.15:35
efriedWhereupon we'll need to rebase the chain.15:35
efriedTo make 1b work, I think we do the same process.  It'll wind up skipping *all* the changes from console down, cause they're already applied.15:36
efriedThis is assuming the change in question is properly based on the latest console patch set.15:36
efriedNow non-pvm changes...15:36
efriedI think we do the same thing there.  git review -d will bring down that guy and any dependencies.  Then we cherry-pick from console down.15:36
efriedwhich should all work, unless the change in question is based on a branch containing an older patch set of in-flight pvm changes, which should never happen unless it's ours.15:37
efriedSo then the only quirk is that we need to do that look-back to a known merged commit that precedes our first in-tree change.15:38
efriedrather than master.15:38
efriedSo that we don't have to keep updating every time we merge one.15:38
esbergluThat's the only change from what we're already doing15:38
esbergluexcept we are cherry picking from #1 up instead of console down15:39
edmondswefried are you regretting adding me to these reviews yet? ;)15:39
esbergluDoes that make a difference?15:39
efriededmondsw I grudgingly appreciate your thoroughness.15:40
edmondsw:)15:40
efriedesberglu That was a misstatement on my part - we should be going up, not down.15:40
efriedesberglu So line 154 of prep_devstack.sh15:41
efriedChange origin/${ZUUL_BRANCH} to whatever hardcoded commit hash we decide on.15:41
efriedWe need to think through non-master scenarios.  In that case, do we even get here?15:42
efriedI guess we will once pike is cut - but burn that bridge when we cross it.15:42
esbergluNope nova in-tree only runs master15:42
efriedWith luck, we'll be merged up to console within the next week or two, and we can get rid of this whole shenanigans.15:42
efriedThe other option at this point is to bust the whitelist back to working only on what we've got merged.  Then we need no patches at all.15:42
efriedAnd lockstep the whitelist up with every new merge.15:43
efriedCourse then we don't get *real* CI for new patches.15:43
efriedSo I think I prefer keeping it this way, and adding new patches to the list as they're ready.  (At the same time, we can drop already-merged ones off, just for housekeeping.)15:43
esbergluYeah I'm okay with that15:44
esbergluI think flipping the whitelist to a blacklist is good call for IT too15:45
esbergluTo make the lockstep smoother15:45
efriedNot sure I agree there.15:45
efriedblacklist will be huge, and just as tough to maintain, if not tougher.15:45
efriedLet's try 9569bc3552f4ae2df5f7e063ab8b09b20103e61c as that bottom commit.  See if it works.15:49
esbergluK trying it out on a manual run quick15:49
efriedIma be afk for a while here.15:51
esbergluWhy not just use the one right before IT #1?15:51
efriedesberglu I think cherry-pick bombs (is that a cherry bomb?) if you try to base on a 'merge' commit.15:55
efriedBut feel free to try it out.15:55
*** k0da has quit IRC15:59
*** esberglu has quit IRC16:30
*** arunman has joined #openstack-powervm16:41
arunmanthorst, efried final changes on https://review.openstack.org/#/c/457707 is out for review.16:42
*** arunman has quit IRC17:08
*** esberglu has joined #openstack-powervm17:40
*** esberglu_ has joined #openstack-powervm17:41
*** esberglu has quit IRC17:41
*** apearson has quit IRC17:55
*** jpasqualetto has quit IRC18:10
*** apearson has joined #openstack-powervm18:10
*** jpasqualetto has joined #openstack-powervm18:23
*** chas has quit IRC18:26
*** dwayne has quit IRC19:01
*** apearson has quit IRC19:02
*** k0da has joined #openstack-powervm19:06
*** dwayne has joined #openstack-powervm19:14
*** apearson has joined #openstack-powervm19:14
*** k0da has quit IRC19:28
openstackgerritMerged openstack/nova-powervm master: Deploy of VM occasionally fails with OSError  https://review.openstack.org/45770719:28
*** dwayne has quit IRC19:32
*** k0da has joined #openstack-powervm19:34
*** dwayne has joined #openstack-powervm19:38
-openstackstatus- NOTICE: Gerrit will be offline briefly starting at 20:00 for scheduled maintenance http://lists.openstack.org/pipermail/openstack-dev/2017-April/115702.html19:42
*** dwayne has quit IRC19:49
efriedesberglu_ Howzat new commit chain logic working?19:52
esberglu_Works fine I put up a change for it19:53
esberglu_517719:53
efriedesberglu_ Yah, saw that, didn't know whether you were ready to pull the trigger on it.19:53
esberglu_Yep. Wasn't expecting the changes to start getting merged this fast!19:54
esberglu_Gonna be down to no patches by the time this gets in19:55
efriedesberglu_ Knock on wood19:55
esberglu_It will take another mgmt redeploy for this change to get in. Might hold off until this weekend to minimize disruption19:57
*** smatzek has quit IRC20:02
-openstackstatus- NOTICE: Gerrit is offline briefly for scheduled maintenance http://lists.openstack.org/pipermail/openstack-dev/2017-April/115702.html20:03
*** ChanServ changes topic to "Gerrit is offline briefly for scheduled maintenance http://lists.openstack.org/pipermail/openstack-dev/2017-April/115702.html"20:03
*** dwayne has joined #openstack-powervm20:11
*** jpasqualetto has quit IRC20:12
efriededmondsw Got a suggestion for an exception that'll percolate up to a 500?20:14
efriedhttps://review.openstack.org/#/c/391288/56/nova/virt/powervm/vm.py@46420:14
efriednm, I see how to figure it out.20:15
efriededmondsw Perhaps I should just raise a KeyError20:20
efriedThere's nothing likely in exceptions.py already, and I would hate to create a new one for this should-never-happen edge case.20:20
*** chas has joined #openstack-powervm20:26
*** chas has quit IRC20:31
*** ChanServ changes topic to "This channel is for PowerVM-related development and discussion. For general OpenStack support, please use #openstack."20:36
-openstackstatus- NOTICE: Gerrit is back in service and generally usable, though remote Git replicas (git.openstack.org and github.com) will be stale for the next few hours until online reindexing completes20:36
*** openstackgerrit has quit IRC20:48
*** thorst has quit IRC21:03
*** thorst has joined #openstack-powervm21:27
edmondswefried any uncaught exception should result in a 50021:31
*** smatzek has joined #openstack-powervm21:31
efriededmondsw KeyError seemed pretty appropriate.  See what you think.21:31
*** thorst has quit IRC21:32
*** smatzek has quit IRC21:32
*** smatzek has joined #openstack-powervm21:33
*** tjakobs has quit IRC21:41
edmondswefried, yeah, that's fine21:50
edmondsw2 nits, but I wouldn't respin for either21:50
edmondswpatch set 57 !!!21:50
*** smatzek has quit IRC21:55
*** dwayne has quit IRC21:56
*** k0da has quit IRC21:58
*** mdrabe has quit IRC22:00
*** thorst has joined #openstack-powervm22:22
*** chas has joined #openstack-powervm22:28
*** chas has quit IRC22:32
*** apearson has quit IRC22:36
*** thorst has quit IRC22:37
*** thorst has joined #openstack-powervm23:08
*** edmondsw has quit IRC23:09
*** edmondsw has joined #openstack-powervm23:09
*** thorst has quit IRC23:12
*** edmondsw has quit IRC23:14
*** esberglu_ has quit IRC23:17
*** thorst has joined #openstack-powervm23:38
*** thorst has quit IRC23:58

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!