Tuesday, 2013-11-26

jog0so just saw a spike in gate-tempest-devstack-vm-neutron failures00:03
*** julim has quit IRC00:04
*** otherwiseguy has quit IRC00:14
*** qingluo has joined #openstack-neutron00:21
*** nati_uen_ has joined #openstack-neutron00:23
*** nati_uen_ has quit IRC00:25
*** nati_uen_ has joined #openstack-neutron00:26
*** nati_ueno has quit IRC00:27
openstackgerritSalvatore Orlando proposed a change to openstack/neutron: Send only one notification is sent on port_udate  https://review.openstack.org/5841500:27
*** jasonv has joined #openstack-neutron00:32
*** matsuhashi has joined #openstack-neutron00:32
openstackgerritSalvatore Orlando proposed a change to openstack/neutron: Send only one agent notification on port update  https://review.openstack.org/5841500:36
*** carl_baldwin has joined #openstack-neutron00:36
*** armax has joined #openstack-neutron00:37
idella4methinks the brittle internet connection @ the motel cracked. anteaya doesn't like the sound of that <crack>00:38
*** pete5 has quit IRC00:44
*** yamahata_ has joined #openstack-neutron00:48
*** otherwiseguy has joined #openstack-neutron01:02
*** carl_baldwin has quit IRC01:02
*** banix has joined #openstack-neutron01:04
qingluohow to set up network config for two nodes openstack(SINGLE NIC)? i have a controller node->192.168.0.63, a compute node->192.168.0.69. how to set bridge for host.01:08
*** jorisroovers has quit IRC01:14
*** nati_ueno has joined #openstack-neutron01:14
*** alagalah has joined #openstack-neutron01:16
*** jorisroovers has joined #openstack-neutron01:17
*** nati_uen_ has quit IRC01:17
openstackgerritZhenguo Niu proposed a change to openstack/neutron: Update Zhenguo Niu's mailmap  https://review.openstack.org/5380501:26
openstackgerritberlin proposed a change to openstack/neutron: Fix showing nonexistent NetworkGateway throws 500 instead of 404  https://review.openstack.org/5842301:29
*** Jianyong has joined #openstack-neutron01:30
*** jorisroovers has quit IRC01:31
*** SumitNaiksatam has quit IRC01:54
*** yamahata_ has quit IRC02:03
*** ljjjustin has joined #openstack-neutron02:03
*** netredem-jr has joined #openstack-neutron02:03
*** nati_uen_ has joined #openstack-neutron02:03
*** carl_baldwin has joined #openstack-neutron02:04
*** nati_ueno has quit IRC02:06
*** coolsvap has quit IRC02:06
*** netredem-jr has quit IRC02:08
*** carl_baldwin has quit IRC02:08
*** nati_uen_ has quit IRC02:09
*** nati_ueno has joined #openstack-neutron02:10
*** netredem-jr has joined #openstack-neutron02:15
*** nati_ueno has quit IRC02:21
*** armax has left #openstack-neutron02:31
*** dims has quit IRC02:38
*** networkstatic has joined #openstack-neutron02:41
*** networkstatic has quit IRC02:41
*** arosen has quit IRC02:45
*** arosen has joined #openstack-neutron02:47
*** matsuhashi has quit IRC03:11
*** carl_baldwin has joined #openstack-neutron03:16
*** carl_baldwin has quit IRC03:20
*** clev has joined #openstack-neutron03:26
*** nati_ueno has joined #openstack-neutron03:28
*** arosen has quit IRC03:28
*** clev has quit IRC03:32
*** nati_ueno has quit IRC03:35
*** nati_ueno has joined #openstack-neutron03:35
openstackgerritNachi Ueno proposed a change to openstack/neutron: Improve vif attributes related with firewalling  https://review.openstack.org/2194603:38
*** banix has quit IRC03:41
*** otherwiseguy has quit IRC03:45
openstackgerritZhang Hua proposed a change to openstack/neutron: Replace uuidutils.generate_uuid() with str(uuid.uuid4())  https://review.openstack.org/5823403:45
*** coolsvap has joined #openstack-neutron03:50
*** jasonv has quit IRC03:57
*** jorisroovers has joined #openstack-neutron03:59
*** jroovers has joined #openstack-neutron04:01
*** jorisroovers has quit IRC04:03
*** suresh12 has quit IRC04:05
*** chandankumar has joined #openstack-neutron04:05
*** yamahata_ has joined #openstack-neutron04:14
*** carl_baldwin has joined #openstack-neutron04:16
*** matsuhashi has joined #openstack-neutron04:19
*** carl_baldwin has quit IRC04:20
openstackgerritJianing YANG proposed a change to openstack/neutron: Exit by raising SystemExit instead of calling sys.exit().  https://review.openstack.org/5843304:23
*** nati_uen_ has joined #openstack-neutron04:29
*** coolsvap has quit IRC04:31
*** nati_ueno has quit IRC04:33
*** yamahata_ has quit IRC04:47
*** banix has joined #openstack-neutron04:55
*** coolsvap_ has joined #openstack-neutron05:05
*** zigo_ has quit IRC05:10
*** zigo has joined #openstack-neutron05:11
*** carl_baldwin has joined #openstack-neutron05:16
*** carl_baldwin has quit IRC05:21
*** coolsvap_ has quit IRC05:24
*** coolsvap has joined #openstack-neutron05:29
*** bashok has joined #openstack-neutron05:30
*** netredem-jr has quit IRC05:41
*** networkstatic has joined #openstack-neutron05:41
*** richardboswell has quit IRC05:47
*** matsuhashi has quit IRC05:50
*** richardboswell has joined #openstack-neutron05:50
*** matsuhashi has joined #openstack-neutron05:51
*** matsuhas_ has joined #openstack-neutron05:53
*** matsuhashi has quit IRC05:53
*** steven-weston_ has joined #openstack-neutron05:59
bashoksalv-orlando, hi06:02
*** banix has quit IRC06:04
*** yfried has joined #openstack-neutron06:14
*** carl_baldwin has joined #openstack-neutron06:16
*** matsuhas_ has quit IRC06:20
*** carl_baldwin has quit IRC06:20
*** coolsvap has quit IRC06:26
*** matsuhashi has joined #openstack-neutron06:29
*** coolsvap has joined #openstack-neutron06:33
*** yongli has quit IRC06:34
*** coolsvap has quit IRC06:36
*** yongli has joined #openstack-neutron06:36
openstackgerritJenkins proposed a change to openstack/neutron: Imported Translations from Transifex  https://review.openstack.org/5844606:39
*** amritanshu_RnD has joined #openstack-neutron06:43
*** mihgen has joined #openstack-neutron06:47
*** yongli has quit IRC06:48
*** yongli has joined #openstack-neutron06:48
*** yongli has quit IRC06:50
*** yongli has joined #openstack-neutron06:50
*** matsuhashi has quit IRC06:53
*** matsuhashi has joined #openstack-neutron06:54
*** nati_uen_ has quit IRC06:56
*** matsuhashi has quit IRC06:58
*** matsuhashi has joined #openstack-neutron06:59
*** gdubreui has quit IRC07:05
*** introom has joined #openstack-neutron07:06
introomhi07:06
*** mengxd has joined #openstack-neutron07:06
introomCan I install multiple openvswitch in openstack and arrange the topology as I like?07:06
*** yongli has quit IRC07:06
*** mengxd has quit IRC07:07
*** yongli has joined #openstack-neutron07:07
*** introom has quit IRC07:09
*** nati_ueno has joined #openstack-neutron07:12
*** afazekas has joined #openstack-neutron07:13
*** steven-weston_ has quit IRC07:16
*** steven-weston has joined #openstack-neutron07:23
*** matsuhashi has quit IRC07:26
*** matsuhashi has joined #openstack-neutron07:27
yfriedmarun: ping07:34
*** yongli has quit IRC07:35
*** yongli has joined #openstack-neutron07:35
*** alagalah has quit IRC07:37
*** matsuhas_ has joined #openstack-neutron07:39
*** matsuhashi has quit IRC07:42
*** SumitNaiksatam has joined #openstack-neutron07:43
*** x86brandon has joined #openstack-neutron07:49
*** jlibosva has joined #openstack-neutron07:59
openstackgerritA change was merged to openstack/neutron: Sync openstack.common.local from oslo  https://review.openstack.org/5790908:00
sgranobondarev: ping08:01
*** amuller has joined #openstack-neutron08:01
*** matsuhas_ has quit IRC08:05
*** matsuhashi has joined #openstack-neutron08:05
sgranand, morning all08:06
steven-westonmorning, sgran08:09
openstackgerritSalvatore Orlando proposed a change to openstack/neutron: Send only one agent notification on port update  https://review.openstack.org/5841508:11
*** mihgen has quit IRC08:11
*** fouxm has joined #openstack-neutron08:15
*** steven-weston is now known as sw208:16
openstackgerritMarios Andreou proposed a change to openstack/neutron: Make flow operation parameters explicit  https://review.openstack.org/5830808:16
*** steven-weston has joined #openstack-neutron08:17
openstackgerritberlin proposed a change to openstack/neutron: Fix showing nonexistent NetworkGateway throws 500 instead of 404  https://review.openstack.org/5842308:19
*** akamyshnikova has quit IRC08:20
QlawyHi, when I try to get metadata from inside instance I recive 500 Internal Server Error08:26
Qlawystacktrace http://wklej.org/hash/7e9cb2b5674/08:26
QlawyIts first time I have this issue08:26
*** steven-weston has quit IRC08:28
*** x86brandon has quit IRC08:29
*** nati_ueno has quit IRC08:29
EmilienMsalv-orlando: ping08:30
salv-orlandoEmilienM: in a meeting, will ping you back when I'm done08:31
sgranQlawy: you seem to be using the nova extension os-virtual-interfaces, which neutron doesn't support08:34
*** akamyshnikova has joined #openstack-neutron08:36
*** steven-weston has joined #openstack-neutron08:36
steven-westonsw2: ping08:36
Qlawysgran: yeah, just realized it ;)08:42
Qlawysgran: but thx08:42
*** steven-weston_ has joined #openstack-neutron08:45
*** yongli has quit IRC08:46
*** yongli has joined #openstack-neutron08:47
*** steven-weston_ has quit IRC08:50
*** steven-weston has quit IRC08:50
*** mihgen has joined #openstack-neutron08:55
*** mihgen has quit IRC09:00
*** mihgen has joined #openstack-neutron09:00
*** steven-weston has joined #openstack-neutron09:00
*** yonglihe_ has joined #openstack-neutron09:05
*** jistr has joined #openstack-neutron09:06
*** safchain has joined #openstack-neutron09:06
*** _coolsvap_ has joined #openstack-neutron09:06
*** yonglihe_ has quit IRC09:06
*** yonglihe_ has joined #openstack-neutron09:07
*** yongli has quit IRC09:07
*** yongli has joined #openstack-neutron09:07
*** nati_ueno has joined #openstack-neutron09:09
*** sw2 has quit IRC09:10
*** jpich has joined #openstack-neutron09:11
*** yongli has quit IRC09:13
*** yongli has joined #openstack-neutron09:13
openstackgerritYoucef Laribi proposed a change to openstack/neutron: Implements an LBaaS driver for NetScaler devices.  https://review.openstack.org/5752409:16
*** richardboswell has quit IRC09:17
openstackgerritSalvatore Orlando proposed a change to openstack/neutron: Send only one agent notification on port update  https://review.openstack.org/5841509:24
*** gdubreui has joined #openstack-neutron09:27
openstackgerritZhang Hua proposed a change to openstack/neutron: Replace uuidutils.generate_uuid() with str(uuid.uuid4())  https://review.openstack.org/5823409:29
steven-westonsalv-orlando: are you available for a quick momento? :-)09:30
*** yamahata_ has joined #openstack-neutron09:30
salv-orlandosteven-weston: I have just 5 minutes I am afraid09:32
salv-orlandoshoot09:32
steven-westonsalv-orlando: that's okay, I can wait .. I know you are busy ... just would like to know when we can work on the auto ip assignment bp, or of there is anything else I can help with instead09:33
*** ljjjustin has quit IRC09:33
salv-orlandosteven-weston: yeah that slipped off my mind, you're right. I have a 3-hour appointment now. Will you be online around 2 PM GMT?09:35
*** rpodolyaka has left #openstack-neutron09:35
steven-westonsalv-orlando: yes, let's talk more then?09:35
salv-orlandosounds good to me.09:37
*** yfried has quit IRC09:37
salv-orlandosteven-weston: ping me because I'll probably forget about it.09:37
*** _coolsvap_ has quit IRC09:37
steven-westonsalv-orlando: okay!  have a great appointment :-)09:37
*** nati_ueno has quit IRC09:40
openstackgerritJoe Mills proposed a change to openstack/neutron: Blackhole traffic not destined to existing port  https://review.openstack.org/5847409:45
*** networkstatic has quit IRC09:49
sgrancan I have a pair of eyes on https://review.openstack.org/#/c/56815/ and https://review.openstack.org/#/c/40381/ ?09:57
sgranor are people holding off approving/merging at the moment?  I saw something about gate issues09:57
*** matsuhas_ has joined #openstack-neutron09:58
*** matsuhas_ has quit IRC09:58
*** matsuhashi has quit IRC10:02
steven-westonsgran: how are you choosing the 192.168 address as the load balancer ip?  should it be chosen from the range on the network you are testing the lb against?10:06
sgranwhere?  In the test?10:06
steven-westonyes10:07
sgranself.member() defaults to 192.168.1.10010:07
sgranso I'm just making it explicit to make it obvious10:07
steven-westonok, gotcha ... i don't currently have a way to test it, I am rebuilding my dev gate, but it looks okay to me.10:08
sgrangreat10:08
*** Jianyong has quit IRC10:12
enikanorovsteven-weston: what kind of gate are you reffering in the review?10:19
steven-westonenikanorov: the jenkins gate ... i thought it was down10:20
enikanorovjenkins +1ed the patch10:20
steven-westonoh, i didn't see that .. just a second10:20
*** qingluo has quit IRC10:22
EmilienMsalv-orlando: it was just to let you know i started a work on grenade for Neutron10:24
steven-westonenikanorov: okay, better?10:26
enikanorovsteven-weston: sure, if you have confidence in it :-)10:27
steven-westonenikanorov: yes, unless I shouldn't be ... if it works in devstack gate then it is good enough for jenkins?10:29
*** yamahata_ has quit IRC10:36
*** jroovers has quit IRC10:54
openstackgerritAnn Kamyshnikova proposed a change to openstack/neutron: Implement testing of migrations  https://review.openstack.org/4859411:02
*** rossella_s has joined #openstack-neutron11:03
*** yfried has joined #openstack-neutron11:06
*** gdubreui has quit IRC11:10
*** roeyc has joined #openstack-neutron11:23
*** jorisroovers has joined #openstack-neutron11:26
*** jorisroovers has quit IRC11:27
*** jorisroovers has joined #openstack-neutron11:27
*** nissim_ has joined #openstack-neutron11:38
nissim_hi11:38
nissim_can anyone assist with a small neutron/metadata proxy issue?11:38
*** pcm_ has joined #openstack-neutron11:41
decedenissim_: whats the issue?11:44
*** jroovers has joined #openstack-neutron11:44
*** francois_eleouet has joined #openstack-neutron11:44
nissim_I am testing openstack grizzly and have 2 private networks connected to two virtual routers via vlans, thing is I can't connect to http://169.254.169.254 to get instance metadata11:45
*** jorisroovers has quit IRC11:46
*** feleouet has quit IRC11:46
nissim_my setup include: controller-node, network-node, mysql-node (includes keystone) & nova-node11:46
nissim_I am trying to access the metadata on ubuntu 12.0.4-3 instance not cirros which I know is not working11:47
nissim_decede?11:48
decedenissim_: for support join #openstack you'll get a better response11:54
nissim_tried that, looks like there is no traffic there , but thanks.11:55
*** nissim_ has left #openstack-neutron11:55
*** pcm_ has quit IRC11:55
*** pcm_ has joined #openstack-neutron11:56
roeycHi there, can anyone help to clarify some points regarding external third party testing of vendor specific plugin ?12:07
openstackgerritAnn Kamyshnikova proposed a change to openstack/neutron: Sync models with migrations  https://review.openstack.org/5541112:09
*** yongli has quit IRC12:17
*** mihgen has quit IRC12:26
EmilienMsalv-orlando: ping12:28
*** mihgen has joined #openstack-neutron12:33
*** amrit_ has joined #openstack-neutron12:41
*** amritanshu_RnD has quit IRC12:43
*** amrit_ has quit IRC12:43
*** amritanshu_RnD has joined #openstack-neutron12:43
*** yamahata_ has joined #openstack-neutron12:47
*** jasonv has joined #openstack-neutron12:51
*** jasonv has quit IRC12:52
*** dims has joined #openstack-neutron12:55
*** markmcclain has joined #openstack-neutron12:56
*** arosen has joined #openstack-neutron13:00
*** ygbo has joined #openstack-neutron13:12
*** insanidade has joined #openstack-neutron13:13
insanidadeHi all. How do I find out my neutron client's version? I'm trying to figure out the reason why 'neutron agent-list' is trying to point to a wrong endpoint (it appends '/v2' to the endpoint registered in keystone)13:14
insanidadeany help ?13:14
*** dhellmann-afk is now known as dhellmann13:15
salv-orlandoneutron --version13:22
salv-orlandoEmilienM: I'm all yours...13:22
salv-orlando…until wife calls for lunch13:22
EmilienMsalv-orlando: lol13:22
EmilienMsalv-orlando: i started something yesterday night on grenade13:22
salv-orlandoEmilienM: very good13:23
salv-orlandodo you have a rough idea of the things we need to do.13:23
EmilienMsalv-orlando: a WIP, i'll finish it tonight i think. Do you think i have to delete draft stuff and publish it ?13:23
EmilienMsalv-orlando: is it a question ?13:23
salv-orlandoeven if WIP, yes it would be good if you can publishit13:23
salv-orlandoyes, but you already answered it I guess13:23
EmilienMsalv-orlando: yeah i understand grenade, i'll make it happen for this week13:24
salv-orlando"publishit" is an interesting whitespace failure13:24
salv-orlandoEmilienM: awesome13:24
EmilienMpublished13:24
EmilienMsalv-orlando: thanks13:24
salv-orlandocool, I'll check it out later13:24
enikanorov_insanidade:13:27
insanidadesalv-orlando: yes, neutron --version reports the client's version or server version?13:27
insanidadehi, enikanorov_13:27
enikanorov_insanidade: afaik, current client only supports 2.013:27
sgranroeyc: what do you want to know?13:28
salv-orlandoclient version13:28
sgranI don't know that I have the answers, but I'm learning about it too, so maybe we can try together :)13:28
insanidadeenikanorov_: right. but I don't understand why that 'neutron agent-list' appends a '/v2' to the endpoint registered in keystone13:28
salv-orlandodoes it append the same /v2 to net-list and all the other cmmands, or just agent-list?13:29
insanidadeenikanorov_: actually, it adds '/v2/v2.0' to the endpoint url I see in keystone endpoint-list13:29
enikanorov_what is in  the endpoint list?13:29
insanidadesalv-orlando: it appends to net-list as well.13:30
enikanorov_i guess neutron should not be registered in the keystone with api version in url13:30
enikanorov_unlike some other OS projects13:31
insanidadeenikanorov_: I have http://192.168.100.45:9696/ for all three endpoint values13:31
*** arosen has quit IRC13:31
salv-orlandocan you post the whole output from keystone endpoint-list13:31
enikanorov_and as a result client sends http://192.168.100.45:9696/v2/v2.0/networks.json?13:31
salv-orlandoand then the output from neutron -v net-list?13:31
sgranor from neutron --debug net-list13:31
*** dhellmann is now known as dhellmann-afk13:31
salv-orlandouse paste.openstack.org if you want13:31
sgraner, yes, -v13:32
*** gongysh has joined #openstack-neutron13:32
insanidadesalv-orlando, enikanorov_ : sure. just a sec.13:33
*** bashok has quit IRC13:34
insanidadesalv-orlando, enikanorov_ : please, take a look: http://paste.openstack.org/show/53984/13:35
roeycsgran: Would like to know if all tests under tempest should be run and against which patchsets ( Neutrons only )?13:36
*** amotoki has joined #openstack-neutron13:37
salv-orlandoinsanidade: have you always been hitting a 300 error?13:38
salv-orlandoout for lunch, back in 20 minutes13:38
insanidadesalv-orlando: yes. every neutron command I issue returns that 300 error.13:39
enikanorov_can you post neutron.conf?13:40
insanidadeenikanorov_: one sec. copying it.13:42
*** alagalah has joined #openstack-neutron13:44
insanidadeenikanorov_: neutron.conf: http://paste.openstack.org/show/53985/13:45
*** arosen has joined #openstack-neutron13:47
*** markvoelker1 has joined #openstack-neutron13:50
*** markmcclain has quit IRC13:50
*** gongysh has quit IRC13:57
insanidadeenikanorov_: did you have the time to check it ?13:59
enikanorov_looking14:00
*** yfried has quit IRC14:01
sgranroeyc: that's my understanding, yeah14:09
steven-westonsalv-orlando: may I steal you back from your wife now? :-)  https://etherpad.openstack.org/p/NeutronFloatingIPAutoAssociation14:11
*** dhellmann-afk is now known as dhellmann14:11
*** julim has joined #openstack-neutron14:12
*** salv-orlando has quit IRC14:15
roeycsgran: Allright. Thanks14:17
*** arosen has quit IRC14:17
*** salv-orlando has joined #openstack-neutron14:21
salv-orlandosteven-weston: ping14:21
steven-westonsalv-orlando: I'm here ;-)14:22
*** clev has joined #openstack-neutron14:22
steven-westonsalv-orlando: ping14:23
steven-westonI think ...14:24
salv-orlandosteven-weston: hi. Can you refresh me on the workflow when one uses nova-network?14:24
salv-orlandoI mean auto-assign-floatingIP with nova-network14:24
steven-westonI think when external network connectivity is needed when the vm boots14:26
ygboHi all, is it normal that a non-admin user can not see the internet IP of his router (neutron router-port-list <router_id>)? Because it is a bit of an issue for VPNaaS where one needs to know his external IP to configure it.14:26
insanidadeenikanorov_: I keep receiving a 300 error message stating that there are 'multiple options' (to be returned, probably). Do I have to explicitly tell the command the version I want to use ?14:28
salv-orlandoygbo: that's how it works at the moment; it can be changed, but is not trivial. If you have ideas perhaps share them on the mailing list14:29
openstackgerritAleksandr Chirko proposed a change to openstack/neutron: Bugfix and refactoring for ovs_lib.OVSBridge flow managment methods  https://review.openstack.org/5853314:29
sgranhurrah, the gate is unwedged, they say14:29
salv-orlandosteven-weston: when nova boots a vm to be associated with a floating IP, does it make separate calls to nova network, or a single call to allocate both the vifs and the floating ip14:30
sgrancan I ask for an approval on https://review.openstack.org/#/c/56815/ and https://review.openstack.org/#/c/40381/ ?14:30
sgranpretty please? :)14:30
salv-orlandosgran: were they already approved by core devs and then the patch did not pass the gate?14:31
ygbosalv-orlando: Thanks, is this a keystone limitation? or from the neutron side?14:31
salv-orlandoygbo: neutron authZ model14:31
sgransalv-orlando: they're waiting for approval14:31
steven-westonsalv-orlando: i don't know, let me check ...14:31
sgranI was assuming approvals were being withheld because the gate was wedged14:31
salv-orlandosgran: so they were already +2'ed from 2 cores, I guess14:31
ygbosalv-orlando: ok, thanks.14:31
sgran40381 has a +2, 56815 still needs one14:32
salv-orlandosgran: ok. I will review then14:32
sgran\o/14:32
sgranthanks :)14:32
salv-orlandomight take a while 40381 is huge14:32
sgranyes, yes it is.  It's not my change, but I'm kind of trying to champion it because I think it's a good change, and I have some work that will need refactoring once it gets merged14:33
sgran56815 should be fairly trivial, though14:33
openstackgerritA change was merged to openstack/neutron: Imported Translations from Transifex  https://review.openstack.org/5844614:38
*** clev has quit IRC14:38
*** aveiga has joined #openstack-neutron14:39
*** dyerm has joined #openstack-neutron14:39
*** insanida1e has joined #openstack-neutron14:43
*** banix has joined #openstack-neutron14:43
steven-westonsalv-orlando: looks like it is currently done as separate calls14:45
*** insanidade has quit IRC14:46
salv-orlandosteven-weston: I was asking because when interfacing with neutron we should keep the same interface14:46
insanida1esalv-orlando, enikanorov_ : I think I found the problem.14:46
salv-orlandonova-api would call into nova.network api which instead of calling nova-network service will call neutron. does that make sense?14:47
insanida1esalv-orlando, enikanorov_ : pointing to nova-network instead of neutron (copy & paste error)14:47
salv-orlandoinsanida1e: I finally got your nick right. What was it?14:47
salv-orlandook, I see14:47
steven-westonsalv-orlando: ok.  perhaps I am being a bit too optimistic in the blueprint, it should simply be considered from a nova parity perspective?14:47
insanida1esalv-orlando, enikanorov_ : thanks :) learning a lot trying to isntall havana from the ground up.14:47
*** insanida1e is now known as insanidade14:48
steven-westonsalv-orlando: yes, that makes sense14:48
salv-orlandosteven-weston: not really, but is a requirement that nova should be able to auto-assign the floating IP with neutron as well14:48
salv-orlandoAnd I was try to understand if we can have a solution that minimises the amount of change on the nova side.14:49
*** thedodd has joined #openstack-neutron14:50
steven-westonsalv-orlando: it all depends on how you want it done.  I think it would be possible that there would be no change required from the nova side at all, besides changing the ip manager from the conf file, that is ...14:51
*** clev has joined #openstack-neutron14:53
salv-orlandosteven-weston: on the neutron side how would the API change to allow for auto associating floating IPs?14:56
*** jroovers has quit IRC14:56
*** clev has quit IRC14:57
*** peristeri has joined #openstack-neutron14:58
*** clev has joined #openstack-neutron15:00
steven-westonsalv-orlando: it may not have to change at all.  i'm looking at allocate_for_instance in nova/network/floating_ips.py and since the calls are currently separate I can look into getting it working by simply changing the floating ip manager in the nova.conf file15:01
steven-westonsalv-orlando: it may work already, i haven't tried it yet ;-)15:01
*** armax has joined #openstack-neutron15:01
salv-orlandosteven-weston: let's start from this and then we'll look at how to optimise with api changes15:02
*** jecarey has joined #openstack-neutron15:04
steven-westonsalv-orlando: sounds like a plan!  Any changes that should be made to the bp or the etherpad right now, or should we wait until I can answer the questions you asked today?15:04
*** fouxm_ has joined #openstack-neutron15:08
*** fouxm_ has quit IRC15:09
*** fouxm has quit IRC15:09
*** fouxm has joined #openstack-neutron15:09
*** fouxm_ has joined #openstack-neutron15:11
*** fouxm_ has quit IRC15:12
*** fouxm_ has joined #openstack-neutron15:13
*** roeyc has quit IRC15:14
*** fouxm has quit IRC15:15
salv-orlandoI think we can wait15:15
sgransalv-orlando: both good nits15:16
sgranI'll reupload15:16
*** amuller has quit IRC15:17
steven-westonsalv-orlando: ok, great!  do you need anything else right now?  I can get back to you before the end of your day tomorrrow with my answers, at the very latest.15:18
salv-orlandosteven-weston: thanks for everything your plan sounds good.15:20
steven-westonsalv-orlando: absolutely!  what time should I meet you back here tomorrow?15:21
salv-orlandoI am online usually from 8AM-1PM GMT and 5PM-11PM GMT; This way I can work with Europe, Asia, and US15:22
steven-westonsalv-orlando: very good.  thanks for your direction today!!15:24
*** carl_baldwin has joined #openstack-neutron15:24
*** amritanshu_RnD has quit IRC15:32
*** alexpilotti has joined #openstack-neutron15:38
*** dhellmann is now known as dhellmann-afk15:41
*** peristeri has quit IRC15:43
*** briancline has joined #openstack-neutron15:50
*** carl_baldwin has quit IRC15:57
*** yfried has joined #openstack-neutron15:57
*** dhellmann-afk is now known as dhellmann15:58
*** carl_baldwin has joined #openstack-neutron16:01
*** afazekas has quit IRC16:02
*** armax has left #openstack-neutron16:02
*** armax has joined #openstack-neutron16:02
*** SumitNaiksatam has quit IRC16:03
openstackgerritDane LeBlanc proposed a change to openstack/neutron: Improve unit test coverage for Cisco plugin model code  https://review.openstack.org/5812516:08
ygbosalv-orlando: I actually logged https://bugs.launchpad.net/neutron/+bug/125514216:09
*** yamahata_ has quit IRC16:10
*** dhellmann is now known as dhellmann-afk16:17
*** idella4 has quit IRC16:17
*** mihgen has quit IRC16:22
openstackgerritSalvatore Orlando proposed a change to openstack/neutron: Rebind allowed address pairs only if they changed  https://review.openstack.org/5856616:26
openstackgerritStephen Gran proposed a change to openstack/neutron: Enforce unique constraint on neutron pool members  https://review.openstack.org/5681516:26
*** networkstatic has joined #openstack-neutron16:28
marunsalv-orlando: project_name vs tenant_name?16:29
salv-orlandodo you want me to make a random choice?16:30
marunsalv-orlando: I'm wondering wtf, actually, hoping you can fill me in16:31
marunsalv-orlando: I mean, Keystone v3 has switched from tenant to project16:32
marunsalv-orlando: I think nova must have always been project16:32
salv-orlandoYes, we were warned about this. Somewhere before the Folsom release.16:32
marunsalv-orlando: but where does that leave neutron?  do we have a preference?16:32
salv-orlandoAt the time we chose to go with whatever keystone decided.16:32
marunsalv-orlando: so if that's the case, is there any reason to continue using 'tenant' instead of 'project'?16:33
marunsalv-orlando: i.e. can a search-replace patch solve this issue once and for all?16:33
salv-orlandoI think that might be good16:33
marunsalv-orlando: ok.  I'll file a bug and see if I can get buy-in on the mailing list.16:34
salv-orlandomarun: enikanorov has a patch that puts both tenant_name and project_name in context16:34
marunsalv-orlando: I was working on a similar patch:https://review.openstack.org/#/c/58348/16:34
salv-orlandoah I see16:34
*** SumitNaiksatam has joined #openstack-neutron16:35
marunsalv-orlando: oleg's question of whether tenant_name was needed prompted me to pursue this line of questioning16:35
marunsalv-orlando: do you have a link to his patch?16:35
*** ywu has joined #openstack-neutron16:42
*** beagles has quit IRC16:45
openstackgerritRalf Haferkamp proposed a change to openstack/neutron: Reassign IP to vlan interface when deleting a VLAN bridge  https://review.openstack.org/5857516:46
*** beagles has joined #openstack-neutron16:47
openstackgerritstephen-ma proposed a change to openstack/neutron: L3 Agent restart causes network outage  https://review.openstack.org/3098816:52
*** rkukura has left #openstack-neutron16:53
openstackgerritMaru Newby proposed a change to openstack/neutron: Add missing key to context dict to fix rpc logging  https://review.openstack.org/5834816:56
morganfainbergmarun, salv-orlando, (let me put on my Keystone hat), moving to "project" from "tenant" seems to make the most sense based upon the thread on the ML.  As a keystone person, I'd like to see it all unified under project.16:57
marunmorganfainberg: https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project16:58
morganfainbergmarun, yay!16:58
marunmorganfainberg: I need to send an email to the ml to get everyone on board.16:58
morganfainbergmarun, totally understand.  i'll keep my eyes open and jump in if needed to champion "project" ;)16:59
marunmorganfainberg: I don't think there will be resistance, I'm just not sure of the priority it will be given early in the cycle where testing is our biggest issue.16:59
morganfainbergmore important than personal bias thouhg, it'll be nice once all projects reference the "project"/"tenant" grouping as the same thing (UX wise)17:00
*** pete5 has joined #openstack-neutron17:04
*** rkukura has joined #openstack-neutron17:06
marunmorganfainberg: agreed, consistency is a very nice property17:07
*** markmcclain has joined #openstack-neutron17:09
enikanorovsalv-orlando: i think that it's marun who have a patch, not me :)17:12
*** carl_baldwin has quit IRC17:18
salv-orlandook, I'm confused then17:19
*** clev has quit IRC17:19
marunsalv-orlando: feel free to review ;) https://review.openstack.org/#/c/58348/17:20
openstackgerritArmando Migliaccio proposed a change to openstack/neutron: Handle IPAddressGenerationFailure on create_dhcp_port  https://review.openstack.org/5781217:21
salv-orlandomarun: I +2 but there is a comment inline, which is a draft I had from yesterday. I think what we said today clears that comment17:23
insanidadeis there any guide on giving a machine a floating ip after it is provisioned through heat ?17:23
insanidademachine=  vm17:23
maruninsanidade: not sure many here are too familiar with heat17:25
maruninsanidade: may want to ask on #openstack17:25
sgraninsanidade: heat simply provisions an instance17:26
sgranafterwards, you can do the same thing you would normally do without heat17:26
insanidadesgran, marun: yes. I believe I might be missing something for setting that floating ip to that vm - I understand the "heat" factor should not be important for that matter.17:26
*** ygbo has quit IRC17:27
*** reaper has joined #openstack-neutron17:27
*** clev has joined #openstack-neutron17:28
*** safchain has quit IRC17:31
*** clev has quit IRC17:32
*** networkstatic has quit IRC17:34
*** clev has joined #openstack-neutron17:35
*** markmcclain has quit IRC17:39
*** jistr has quit IRC17:39
*** rossella_s has quit IRC17:49
*** clev has quit IRC17:56
*** jlibosva has quit IRC17:58
*** jlibosva has joined #openstack-neutron17:58
*** nati_ueno has joined #openstack-neutron17:58
*** nati_ueno has quit IRC17:59
*** nati_ueno has joined #openstack-neutron18:00
*** otherwiseguy has joined #openstack-neutron18:00
*** suresh12 has joined #openstack-neutron18:01
*** alagalah has quit IRC18:03
*** alagalah has joined #openstack-neutron18:03
*** alagalah_ has joined #openstack-neutron18:04
openstackgerritSalvatore Orlando proposed a change to openstack/neutron: Rebind security groups only when they're updated  https://review.openstack.org/5859718:11
marunhttps://bugs.launchpad.net/neutron/+bug/125144818:16
openstackgerritNachi Ueno proposed a change to openstack/neutron: Improve vif attributes related with firewalling  https://review.openstack.org/2194618:23
*** alagalah_ has quit IRC18:23
*** alagalah_ has joined #openstack-neutron18:24
*** clev has joined #openstack-neutron18:26
*** networkstatic has joined #openstack-neutron18:35
*** jprovazn has joined #openstack-neutron18:38
*** jlibosva has quit IRC18:41
*** fouxm_ has quit IRC18:45
*** clev has quit IRC18:52
*** jistr has joined #openstack-neutron18:57
*** jlibosva has joined #openstack-neutron18:58
*** suresh12 has quit IRC19:00
*** mlavalle has joined #openstack-neutron19:15
*** aymenfrikha has joined #openstack-neutron19:16
*** nati_uen_ has joined #openstack-neutron19:26
*** nati_ueno has quit IRC19:28
*** nati_uen_ has quit IRC19:30
*** nati_ueno has joined #openstack-neutron19:30
*** suresh12 has joined #openstack-neutron19:30
openstackgerritNachi Ueno proposed a change to openstack/neutron: VPNaaS integration with service type framework  https://review.openstack.org/4182719:31
*** opilotte has joined #openstack-neutron19:31
opilottecan someone help me with this patch-set? can't figure out what is wrong: https://review.openstack.org/#/c/54170/19:31
opilotteused to pass every jenkins check19:32
opilottenow it's a mess19:32
*** suresh12 has quit IRC19:36
*** suresh12 has joined #openstack-neutron19:37
openstackgerritArmando Migliaccio proposed a change to openstack/neutron: Handle IPAddressGenerationFailure on create_dhcp_port  https://review.openstack.org/5781219:37
*** yfried has quit IRC19:42
*** jecarey has quit IRC19:44
openstackgerritArmando Migliaccio proposed a change to openstack/neutron: Handle IPAddressGenerationFailure on create_dhcp_port  https://review.openstack.org/5781219:48
sgranI think I've now addressed all the comments on https://review.openstack.org/#/c/56815/ , if someone has a moment to review it19:51
*** alagalah has quit IRC19:55
*** alagalah_ has quit IRC19:55
*** alagalah_ has joined #openstack-neutron19:55
*** alagalah has joined #openstack-neutron19:56
*** gdubreui has joined #openstack-neutron20:01
*** jlibosva has quit IRC20:11
nati_uenomestery: Hi!20:14
mesterynati_ueno: on phone give me 1520:15
nati_uenomestery: sure! Thanks20:15
*** julim has quit IRC20:17
*** suresh12 has quit IRC20:18
*** nati_uen_ has joined #openstack-neutron20:18
*** nati_ueno has quit IRC20:21
openstackgerritNachi Ueno proposed a change to openstack/neutron: Improve vif attributes related with firewalling  https://review.openstack.org/2194620:26
openstackgerritMaru Newby proposed a change to openstack/neutron: Fix format errors seen in rpc logging  https://review.openstack.org/5834820:30
*** jecarey has joined #openstack-neutron20:33
*** dhellmann-afk is now known as dhellmann20:44
*** jistr has quit IRC20:49
mesterynati_uen_: I am back, whats up?20:54
mesterymarun: Apologies for approving your WIP patch earlier. :(20:58
marunmestery: no worries.  i didn't realize that was possible or i would have -1d20:58
mesterymarun: Me either! I guess I'm still learning something new everyday. ;)20:59
*** alagalah has quit IRC20:59
*** alagalah_ has quit IRC20:59
openstackgerritMaru Newby proposed a change to openstack/neutron: Fix format errors seen in rpc logging  https://review.openstack.org/5834821:01
*** alagalah has joined #openstack-neutron21:01
*** x86brandon has joined #openstack-neutron21:02
*** prometheanfire has quit IRC21:05
*** prometheanfire has joined #openstack-neutron21:05
*** banix has quit IRC21:09
*** clev has joined #openstack-neutron21:13
openstackgerritAkihiro Motoki proposed a change to openstack/neutron: Return request-id in API response  https://review.openstack.org/5827021:13
*** suresh12 has joined #openstack-neutron21:14
*** mlavalle has quit IRC21:24
*** safchain has joined #openstack-neutron21:25
*** x86brandon has quit IRC21:25
openstackgerritSylvain Afchain proposed a change to openstack/neutron: Add LeastRouters Scheduler to Neutron L3 Agent  https://review.openstack.org/4749021:26
*** x86brandon has joined #openstack-neutron21:26
*** steven-weston has quit IRC21:26
*** julim has joined #openstack-neutron21:26
*** banix has joined #openstack-neutron21:31
*** devlaps has joined #openstack-neutron21:35
*** yamahata_ has joined #openstack-neutron21:36
*** banix has quit IRC21:37
*** dims has quit IRC21:40
*** mlavalle has joined #openstack-neutron21:40
*** networkstatic has quit IRC21:41
*** jprovazn has quit IRC21:42
*** suresh12 has quit IRC21:43
*** suresh12 has joined #openstack-neutron21:44
*** suresh12 has quit IRC21:46
*** alexpilotti has quit IRC21:52
*** dims has joined #openstack-neutron21:54
*** yamahata_ has quit IRC22:00
marunamotoki: ping22:00
amotokimarun: pong22:00
*** markvoelker1 has quit IRC22:01
marunamotoki: ah, nmind.  i just saw your review22:01
*** gdubreui has quit IRC22:05
nati_uen_mestery: Hi22:05
mesterynati_eun_: Yo, whats up?22:06
nati_uen_mestery: why ML2 stores port_filter information on DB?22:06
mesterynati_uen_: Checking ...22:06
nati_uen_cap_port_filter isn't used anywhere, but it is stored in the DB model22:07
mesteryWell, I think the idea was to store all the port information needed for port binding.22:07
mesteryWhich included cap_port_filter. But it's not used anymore? Checking that now too.22:08
nati_uen_yes. That's attribute isn't used anywhere for functionalities22:08
*** aymenfrikha has quit IRC22:08
mesteryOK, so perhaps it should be removed then. :)22:09
mesteryMaybe it was previously used when rkukura did the port binding work?22:09
nati_uen_mestery: yeah, that was intented to be used, but the spec itself changed22:09
nati_uen_so my question is is it really needed store all information in DB even if it is static?22:10
mesterynati_uen_: OK22:10
rkukuramestery, nati_uen_: what's the question?22:10
mesterynati_uen_: I think the idea was to store information necessary for port binding.22:10
nati_uen_rkukura I'm working on this one https://review.openstack.org/#/c/21946/22:11
mesteryrkukura: nati_uen_ is asking specifically about why we store cap_port_filter in the DB22:11
nati_uen_I'm going to remove cap_port_filter and add vif_security22:11
nati_uen_it looks ML2 stores cap_port_filter22:11
rkukuraThe DB is actually storing the result of port binding - that's one of the things that the MechanismDriver supplies when it calls PortContext.set_binding()22:11
nati_uen_so my question is why we are storing immutable information in db such as cap_port_filter?22:12
rkukuralooking at the patch to driver_api.py, I think we'd need to be able to set whatever is replacing cap_port_filter, and store that instead22:12
nati_uen_so I should store vif_security in the DB?22:13
rkukuranati_uen_: What makes it immutable?22:13
nati_uen_vif_security value is defined per plugin22:13
nati_uen_so it will not be different per port22:13
rkukuraCouldn't it at least very depending on what MechanismDriver does the binding, and maybe based on information it has about the node?22:13
*** yamahata_ has joined #openstack-neutron22:14
rkukuranati_uen_: I don't think that makes sense with ML222:14
nati_uen_we can let MechanismDriver define vif_security value22:14
nati_uen_but even if so, it is static per MechanismDriver22:14
rkukuraMaybe not different per port, but could be different for different drivers in the same deployment (think of a mix of KVM and HyperV nodes)22:14
nati_uen_rkukura: That's makes sence22:15
rkukuraSo we could have ML2 call into the bound MechanismDriver, but are you sure it will always be static?22:15
nati_uen_so IMO, driver -> vif security value mappings is static22:15
nati_uen_at least for current specs22:15
nati_uen_so if we know vif_type22:16
nati_uen_vif_security_value will be defined22:16
rkukuraHas anyone worked out how things like PCI-passthru fit into this?22:16
nati_uen_rkukura: I think no one is thinking about it22:17
rkukuraThat's another case where a MechanismDriver would need to include information related to the binding that might vary from port to port22:17
nati_uen_ah so in that mode, we wanna let configure different value for vif_security?22:18
nati_uen_How we know the port is in the PC-passthru mode?22:19
rkukuraNot sure about vif_security, but I think it hints that a more general mechanism may be needed for feed information from the ML2 MechanismDriver that binds to the GenricVIFDriver in nova22:19
*** banix has joined #openstack-neutron22:20
mesteryrkukura: I think that makes sense to me. I agree that even with PCI passthrough vif_security may be static though.22:20
rkukuraIt "may" be static, but do we know it will always be static?22:21
nati_uen_rkukura: Everything should be static until we get usecase in which it is dynamic22:21
nati_uen_In current spec, it is static22:22
*** gdubreui has joined #openstack-neutron22:22
nati_uen_I agree in future, we can have a bp for let admin or user configure the vif_security value per port22:22
mesteryI think per-MechanismDriver it will be static for now, unless someone wants to change it.22:22
rkukuraIs there a spec I should look at?22:22
nati_uen_https://bugs.launchpad.net/nova/+bug/111291222:23
nati_uen_is a spec22:23
rkukuraI'm OK with per-MechanismDriver, or calling into the bound MechanismDriver each tme its needed rather than caching it in the DB22:23
mesteryrkukura: The second option would make it dynamic from ML2 perspective, but each MD could choose to make it static at that level.22:23
rkukuraright22:24
mesterynati_uen_: Thoughts on that approach?22:24
nati_uen_It makes sence22:24
nati_uen_so in this patch, I'll let each MD to decide vif_security value22:24
nati_uen_but I'm not going to store it in the db22:24
* mestery nods in agreement.22:24
nati_uen_rkukura: is this makes sence?22:25
rkukuraSo should this call from the plugin into the MechanismDriver be specific to vif_security, or should it allow the MechanismDriver to add arbitrary attributes to the port dictionary being built?22:25
nati_uen_I wanna work on specific to vif_security in this patch.22:26
rkukuranati_uen_, mestery: I'm OK with not storing it in the DB, but we do need to make sure there are sensible values (None?) to use when there is no bound MechanismDriver to call22:27
*** SumitNaiksatam has quit IRC22:28
rkukuranati_uen_: I understand keeping this patch focused on vif_security, but also want to balance this against churn in the ML2 driver API22:28
*** SumitNaiksatam_ has joined #openstack-neutron22:28
nati_uen_rkukura: ok sure. it is also makes sence22:28
nati_uen_I'm not professional for ML2 now, so if you have a preferred design for this, I would like to follow it22:29
nati_uen_or may be we can leave simple impl in this patch, then we can have another patch for refactoring the design on ML222:29
mesterynati_uen_: I think simple in your patch is good and we can refactor it later.22:30
nati_uen_rkukura: is this OK for you too?22:31
rkukuranati_uen_: Seems _update_port_dict_binding() is going to need to call some new function on MechansmDriver, right?22:31
rkukuraOn the bound one, if there is a bound one.22:31
nati_uen_rkukura: yes my current plan is let _update_port_dict_binding call driver22:32
nati_uen_so i'm going to add update_port_dict_binding on each driver22:32
nati_uen_and inside update_port_dict_binding code, I'll add vif_security dict22:32
rkukuraI guess I think its worth thinking about whether that function should be something like MechnanismDriver.get_vif_security(), or something like MechanismDriver.extend_port_dict()22:33
nati_uen_I'm +1 for MechanismDriver.extend_port_dict()22:33
*** thedodd has quit IRC22:33
rkukuramestery: What do you think of that option?22:33
mesteryrkukura: I like that option.22:35
nati_uen_ok deal :)  I'll add new MD method "extend_port_dict(port)"22:35
nati_uen_then call it from _update_port_dict_binding22:35
nati_uen_Thank you for your suggestions!22:35
rkukuraSounds good - and the doc string in driver_api.py should specify that its called inside at transaction, I think.22:36
nati_uen_rkukura: sure. I'll add doc strings also22:36
rkukuranati_uen_: Sounds like a plan!22:37
nati_uen_russellb: Thanks!22:37
rkukuranati_uen_: Please don't hesitrate to ask for advice if you run into any major gotchas.22:37
nati_uen_typo22:37
nati_uen_rkukura: sure22:38
*** yamahata_ has quit IRC22:38
nati_uen_rkukura: mestery: may I ask few more questions?22:41
rkukurasure22:42
mesterysure22:42
nati_uen_How I can get Mechdrvier from inside of _update_port_dict_binding ?22:42
nati_uen_It looks it get PortContext22:42
nati_uen_May be I should update MechanismManager also22:43
*** suresh12 has joined #openstack-neutron22:44
rkukuraIt looks like everywhere that calls _update_port_dict_binding() has a PortContext, so maybe you can just pass this to _update_port_dict_binding() as well.22:45
mesteryrkukura: Another ML2 question: Should we do the ML2 meeting tomorrow morning?22:47
mesteryWill you be around?22:47
rkukuraWell _ml2_extend_port_dict_binding() does not have a PortContext, and I'm not positive whether its inside a tranaction22:47
nati_uen_so let's _update_port_dict_binding have a mech context?22:48
nati_uen_ah I got your point now22:49
nati_uen__ml2_extend_port_dict_binding can get only port and binding22:49
mesteryThat makes sense to me.22:50
mesterynati_uen_ rkukura: I need to take off now for a bit.22:52
nati_uen_mestery: Thanks for your help :)22:52
nati_uen_tl22:52
mesteryrkukura: Let me know your thoughts on ML2 meeting, have 2 action items to cover, both could be done in email if needed.22:52
rkukuraI should be around, but not sure about others22:52
*** yamahata_ has joined #openstack-neutron22:57
*** suresh12 has quit IRC22:58
nati_uen_rkukura: I'm not still not clear to how to implement this. it looks like Mec Manager call all drivers. Is this true?22:59
nati_uen_How can we call actual mechdriver in update_port_dict_binding?23:00
rkukuraYes, you'd probably need to add a MechanismManager.extend_port_dict() function that takes care of calling the bound MechanismDriver.23:00
nati_uen_rkukura: but _call_on_drivers looks calling all driver's method. How we can choose proper one?23:02
rkukuranati_uen_: Look at the validate_port_binding() and unbind_port() methods on MechansimManager23:03
*** jpich has quit IRC23:04
nati_uen_rkukura: thanks!23:04
nati_uen_can I do this? MechanismManager.extend_port_dict(binding, port_dict)23:05
rkukuraI'd probably use MechanismManager.extend_port_dict(context, port_dict) to be more consistent with the other methods. Also, the context needs to be passed to the driver I think23:07
nati_uen_rkukura: I agree, but how I can get context in _ml2_extend_port_dict_binding ?23:07
rkukuraOne consideration with all of this is whether port dictionaries and this notion of extending them will still exist with the refactoring markmcclain has been talking about23:08
nati_uen_yeah, but this patch will be faster than his refactoring23:08
nati_uen_Currently, neutron + nova security group isn't working.. so I wanna fix this issue as fast as I can23:09
rkukuranati_uen_: Agreed this will be merged first.23:09
*** amotoki has quit IRC23:09
rkukuraCan you check to make sure _ml2_extend_port_dict_binding() is called within the transaction?23:10
nati_uen_sure23:10
*** pcm_ has quit IRC23:10
rkukuraAnd I guess _ml2_extend_port_dict_binding() will need to construct a PortContext23:11
nati_uen_rkukura: this is outside of transaction https://github.com/openstack/neutron/blob/master/neutron/db/db_base_plugin_v2.py#L91623:11
rkukuranati_uen_: I need to head out to dinner with my family.23:12
nati_uen_rkukura: sure Thank you for your help. TL23:12
rkukuraIt does kind of look like the code avoids a transaction for the get_port()23:13
rkukuraMaybe we can just specify that MechanismDriver.extend_port_dict() may be called inside or outside a transaction if that is the case23:13
rkukuranati_uen_: Send me an email or look for me online tomorrow if we need to continue this discussion.23:14
nati_uen_rkukura: Thanks. I'll do my proposal in my review, I'll ping you when I finish 1st draft23:15
*** julim has quit IRC23:16
*** banix has quit IRC23:17
openstackgerritSalvatore Orlando proposed a change to openstack/neutron: Rebind security groups only when they're updated  https://review.openstack.org/5859723:17
*** otherwiseguy has quit IRC23:18
*** yamahata_ has quit IRC23:20
openstackgerritArmando Migliaccio proposed a change to openstack/neutron: Handle exceptions on create_dhcp_port  https://review.openstack.org/5781223:24
*** reaper has quit IRC23:26
*** armax has left #openstack-neutron23:28
*** otherwiseguy has joined #openstack-neutron23:31
*** aymenfrikha has joined #openstack-neutron23:32
*** gdubreui has quit IRC23:59

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