Tuesday, 2016-08-23

*** mdrabe has quit IRC00:29
*** apearson_ has quit IRC00:48
*** esberglu has joined #openstack-powervm01:06
*** tjakobs has joined #openstack-powervm01:07
*** thorst_ has quit IRC01:07
*** thorst has joined #openstack-powervm01:08
*** tjakobs has quit IRC01:12
*** kylek3h has joined #openstack-powervm01:16
*** thorst has quit IRC01:16
*** seroyer has joined #openstack-powervm01:17
*** kylek3h has quit IRC01:34
*** seroyer has quit IRC01:51
*** thorst has joined #openstack-powervm02:14
*** thorst has quit IRC02:22
*** apearson_ has joined #openstack-powervm02:38
*** esberglu has quit IRC02:43
*** thorst has joined #openstack-powervm03:20
*** thorst has quit IRC03:26
*** seroyer has joined #openstack-powervm04:08
*** thorst has joined #openstack-powervm04:24
*** thorst has quit IRC04:31
*** kotra03 has joined #openstack-powervm04:32
*** seroyer has quit IRC04:41
*** k0da has joined #openstack-powervm05:10
*** thorst has joined #openstack-powervm05:30
*** thorst has quit IRC05:37
*** k0da has quit IRC05:55
*** kairo has joined #openstack-powervm06:06
*** kairo has quit IRC06:08
*** kairo has joined #openstack-powervm06:08
*** thorst has joined #openstack-powervm06:34
*** thorst has quit IRC06:42
*** thorst has joined #openstack-powervm07:39
*** thorst has quit IRC07:46
*** k0da has joined #openstack-powervm08:02
*** openstackgerrit has quit IRC08:03
*** openstackgerrit has joined #openstack-powervm08:04
*** thorst has joined #openstack-powervm08:45
*** thorst has quit IRC08:52
*** thorst has joined #openstack-powervm10:47
*** thorst has quit IRC10:52
*** thorst has joined #openstack-powervm11:04
*** apearson_ has quit IRC12:09
*** seroyer has joined #openstack-powervm12:16
*** mdrabe has joined #openstack-powervm12:40
*** edmondsw has joined #openstack-powervm12:40
*** kylek3h has joined #openstack-powervm12:40
*** wangqwsh has joined #openstack-powervm13:07
*** wangqwsh has quit IRC13:08
efried1thorst, before I go looking, are you familiar with the protocol for an APIImpact tag on a commit message?13:24
thorstefried1: nope13:24
efried1k13:24
thorstdoes your neutron change have an API Impact?13:24
efried1Yes13:24
efried1It would help me a bunch if I understood the API13:25
thorstheh13:25
efried1Particularly how & where it gets used.13:25
efried1Cause there juuust might be a way I can use it that wouldn't require changing it.13:25
efried1Though my efforts yesterday yielded no fruit.13:25
efried1And, as you said, I'd rather not have to muck with the database.13:26
thorstright.  Lets propose it up and see what happens13:26
thorstwe can maybe ping mestery to see if he can suggest someone for us to follow up with.13:26
efried1It's proposed.  Got some good conversation with one of the neutron folks yesterday, and got the attention of a core.13:26
efried1She suggested I put an APIImpact tag in my commit message - hence the opening question.13:27
thorstahh, gotcha13:27
thorstcould probably google for some examples13:27
efried1swhat I'm doing now.13:27
adreznecefried1: Isn't it literally just putting "APIImpact" in your commit message?13:28
adreznecLike DocImpact?13:28
efried1adreznec, dunno ;-)13:28
efried1https://review.openstack.org/#/c/358125/13:29
adreznechttps://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z13:29
*** tjakobs has joined #openstack-powervm13:42
*** kairo has quit IRC13:47
*** kriskend has joined #openstack-powervm13:54
*** esberglu has joined #openstack-powervm14:04
*** tblakes has joined #openstack-powervm14:07
*** dwayne has quit IRC14:19
*** dwayne has joined #openstack-powervm14:24
*** seroyer has quit IRC14:41
*** tblakes has quit IRC14:46
*** seroyer has joined #openstack-powervm14:59
*** apearson_ has joined #openstack-powervm15:02
*** tblakes has joined #openstack-powervm15:07
*** kotra03 has quit IRC15:08
thorstdevstack has decided to stop doing the ovs remapping it seems...15:11
adreznecthorst: side-effect of neutron lib changes?15:13
adreznecSome new config we're missing?15:13
thorstunsure15:13
thorstjust know that my current devstack local.conf's isn't working15:13
*** kotra03 has joined #openstack-powervm15:49
*** ibmchas has joined #openstack-powervm17:08
*** ibmchas has quit IRC17:13
*** k0da has quit IRC17:25
*** kotra03 has quit IRC17:31
*** k0da has joined #openstack-powervm17:32
*** k0da has quit IRC17:41
*** ibmchas has joined #openstack-powervm17:50
*** ibmchas has quit IRC17:54
tblakesthorst: efried1: After talking with mdrabe: it looks like we might not want to remove the resize_ from before the VM name on a failed resize. destroy() is dependent on the VM name having resize_ prepended so it knows not to delete that VM. If we remove resize_ before the name and the destroy API is called immediately afterwards, the VM could be deleted.18:07
efried1yuh18:08
mdrabeYea I'm thinkin abandon this guy, leave resize_ prepended name on hypervisor18:09
*** ibmchas has joined #openstack-powervm18:11
*** ibmchas has quit IRC18:15
thorstcool18:18
*** tblakes has quit IRC18:19
*** tblakes has joined #openstack-powervm18:22
*** ibmchas has joined #openstack-powervm18:32
*** ibmchas has quit IRC18:36
openstackgerritEric Fried proposed openstack/networking-powervm: Mechanism driver & agent for powervm SR-IOV  https://review.openstack.org/34342318:46
openstackgerritEric Fried proposed openstack/networking-powervm: Mechanism driver & agent for powervm SR-IOV  https://review.openstack.org/34342318:59
thorstefried1: looked over that...I'm good with it19:03
thorstready for W+1?19:03
*** ibmchas has joined #openstack-powervm19:13
thorstadreznec: so heres the devstack failure to create my br-ex19:14
thorst2016-08-23 19:05:38.942 | +^[[38;5;242mlib/neutron_plugins/services/l3:is_provider_network:365 ^[(B^[[m '[' True == True ']'19:14
thorst2016-08-23 19:05:38.945 | +^[[38;5;242mlib/neutron_plugins/services/l3:is_provider_network:365 ^[(B^[[m '[' True == False ']'19:14
thorst2016-08-23 19:05:38.948 | +^[[38;5;242mlib/neutron_plugins/services/l3:is_provider_network:368 ^[(B^[[m return 119:14
thorstso uhh...yeah.19:14
thorstriddle me that.19:14
*** ibmchas has quit IRC19:18
thorstI see it...filing a devstack bug.19:19
*** svenkat has joined #openstack-powervm19:21
adreznecCool19:21
adreznecSorry, busy dealing with system issues19:21
svenkatefried , thorst: this is about port status staying in build after vnic plug19:26
thorstyeah...so the trick is a call to get_device_details will set status of port to build19:29
thorsttook me a while to realize that in the sea code19:29
thorstwhere are you doing a get_device_details?  Maybe a heal_and_optimize path?19:29
svenkatok… so we should avoid invoking get_device_details19:29
svenkatget_device_details is in the middle of processing incoming port and set its state up19:30
svenkati think it is to gt mac address. but we can get mac address from port itself19:30
svenkatlooking19:30
thorstsvenkat: you shouldn't avoid it.  You should call it if you have a reason to19:30
thorstbut19:30
thorstyou need to be aware of the repurcussions of calling it.19:30
thorstit is expected that you set the device up afterwards19:31
svenkatoh ok...19:31
svenkatso i think we can avoid getting mac using get_device_details and instead get it from the incoming port itself.19:31
svenkatand use it to call update_device_up19:31
efried1svenkat, thorst, I don't think that's the issue.  We must be calling get_device_details from somewhere else.  Looking...19:32
svenkatok...19:33
efried1daaah, nope.19:33
efried1The only place the sriov_agent is using it is here:19:34
efried1self.update_device_up(self.get_device_details(port['mac_address']))19:34
*** ibmchas has joined #openstack-powervm19:34
efried1I.e. we're doing update_device_up immediately after get_device_details.19:34
efried1So19:34
efried1Something else is punting the port back to build state?19:34
thorstefried1: I'm not aware of anything else that puts it into a build state19:35
efried1Does one of those things run asynchronously or something?19:35
efried1update_device_up calls across the wire, but that should be getting *started* after the get_device_details is already done, neh?19:36
*** ibmchas_ has joined #openstack-powervm19:36
svenkatlooking in update_device_up i agent base, what is ‘device’ in the data returend by get_device_details, is it mac address ?19:38
*** ibmchas has quit IRC19:38
efried1svenkat, looks like it could be.  Let's pdb it and find out?19:40
svenkatactually we are writing it in log…19:40
svenkatlooking19:40
thorstits an object19:41
thorstlook at sea_agent for usage19:41
thorstthe device up should be the 'rpc_device'19:41
svenkatself.plugin_rpc.update_device_up(self.context, device['device'],self.agent_id, cfg.CONF.host)19:41
svenkatis the actual code under the covers.. i am trying to gt eto what is device[‘device’]19:41
svenkatlet me look at sea code also19:42
efried1I can't find anything that's calling get_device_details - and that's the *only* thing that sets the device state to BUILD19:43
efried1So wtf?19:43
thorstefried1: you're checking agent_base?19:44
efried1thorst, I checked everywhere.  The invocations in agent_base aren't getting hit by the sriov_agent.19:45
efried1At least, I can't see how they would be.19:45
efried1Uh, we aren't registering the CNA event handler in the SRIOV agent, are we?  I was pretty sure I avoided that. Looking again...19:45
efried1no, just in the sea_agent.19:46
efried1And that's the only place, other than the sriov_agent's rpc_loop, that we're calling get_device_details.19:47
efried1svenkat, sanity check: did you remember to restart the agent after pulling down the patch set with the Queue logic?19:49
svenkatyes..19:49
svenkatstrange, i am not seeing any ‘Sending device up” in agent logs… looking...19:53
efried1svenkat, do you have the log handler for the agent set to debug?19:55
svenkatyes.. agent logs to /var/log/neutro19:55
svenkatn19:55
svenkatmy mistake, i missed a line whhile patching srov_agent… i missed putting port in queue19:59
svenkatlet me redo this19:59
thorstefried1: you want to chase a bug?  :-)19:59
efried1svenkat, why are you hand-patching the code?20:00
svenkatit is easier for only few lines…20:00
efried1Got roped into school runs today, out for 1h.  Can slack intermittently.20:01
svenkatsure...20:01
svenkatstarted a deploy20:03
svenkati got it this time20:04
svenkatso device[‘device’] is mac address20:04
svenkatso we can avoid making get_device_details call20:05
svenkatwe already have mac from incoming port20:05
thorstso I just want to be clear20:05
thorstif your intention is that you're going to 'build the port'20:05
thorstyou *should* call get_device_details20:05
svenkatok..20:05
thorstthat's a perfectly OK (and desired) thing to do20:05
svenkatwait, the port is shwoing active now on neutron..20:06
svenkatlet me wait for few minutes to see if deploy is ok20:06
*** k0da has joined #openstack-powervm20:09
svenkatcompute got vif plugged event. but not sure why deploy is still initializing20:12
*** edmondsw has quit IRC20:13
*** tjakobs has quit IRC20:58
*** miltonm has quit IRC21:23
*** miltonm has joined #openstack-powervm21:29
*** svenkat has quit IRC21:33
*** thorst has quit IRC21:44
*** thorst has joined #openstack-powervm21:47
*** seroyer has quit IRC21:49
*** thorst has quit IRC21:51
*** apearson_ has quit IRC21:57
*** apearson_ has joined #openstack-powervm21:58
*** k0da has quit IRC22:07
*** tblakes has quit IRC22:07
*** esberglu has quit IRC22:29
*** thorst_ has joined #openstack-powervm22:36
efried1thorst_, yt?22:37
efried1nod, please check launchpad bugs mail when able.22:38
*** thorst_ has quit IRC22:39
efried1neutron change got shot down by armax22:39
*** svenkat has joined #openstack-powervm22:44
*** ibmchas_ has quit IRC22:49
*** thorst_ has joined #openstack-powervm23:03
*** thorst_ has quit IRC23:05
*** thorst_ has joined #openstack-powervm23:06
*** thorst_ has quit IRC23:10
*** svenkat has quit IRC23:19

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