Monday, 2014-07-07

*** baoli has quit IRC00:03
*** otherwiseguy has joined #openstack-neutron00:05
*** otherwiseguy has quit IRC00:09
*** nlahouti has quit IRC00:09
*** nlahouti has joined #openstack-neutron00:10
*** zhipeng has quit IRC00:11
*** yamamoto has joined #openstack-neutron00:13
*** zhipeng has joined #openstack-neutron00:14
*** WackoRobie has joined #openstack-neutron00:23
*** nplanel has joined #openstack-neutron00:24
*** xuhanp has quit IRC00:26
*** WackoRobie has quit IRC00:28
*** networkstatic has joined #openstack-neutron00:31
*** ijw has joined #openstack-neutron00:33
*** ijw has quit IRC00:39
*** Dev_Taro has joined #openstack-neutron00:39
*** tomoe_ has joined #openstack-neutron00:47
*** leseb has joined #openstack-neutron00:50
*** leseb has quit IRC00:54
*** baoli has joined #openstack-neutron00:59
openstackgerritshihanzhang proposed a change to openstack/neutron-specs: Using ipset for security group  https://review.openstack.org/10076101:00
*** baoli has quit IRC01:04
*** leseb has joined #openstack-neutron01:16
*** leseb has quit IRC01:21
*** WackoRobie has joined #openstack-neutron01:24
*** WackoRobie has quit IRC01:29
*** gongysh has joined #openstack-neutron01:33
*** ijw has joined #openstack-neutron01:33
*** ijw has quit IRC01:33
*** ijw has joined #openstack-neutron01:34
*** amotoki has quit IRC01:38
*** diegows has quit IRC01:39
*** stanzgy has joined #openstack-neutron01:39
*** yamahata has joined #openstack-neutron01:42
*** amotoki has joined #openstack-neutron01:46
*** yuyang-vm has joined #openstack-neutron01:47
*** yuyang-vm has left #openstack-neutron01:50
*** otherwiseguy has joined #openstack-neutron01:53
*** yuyang-vm has joined #openstack-neutron01:54
*** otherwiseguy has quit IRC01:58
*** shashankhegde has joined #openstack-neutron02:00
*** baoli has joined #openstack-neutron02:00
*** networkstatic has quit IRC02:00
*** mestery_ has joined #openstack-neutron02:00
*** baoli has quit IRC02:04
*** mestery_ has quit IRC02:05
*** jckasper has quit IRC02:09
*** jckasper has joined #openstack-neutron02:09
*** flwang_ has joined #openstack-neutron02:15
gongyshping amotoki02:16
amotokipong gongysh02:16
gongyshamotoki: http://developer.openstack.org/api-ref-networking-v2.html02:17
gongyshI see the API has 'tenant_id' in url, is that true?02:17
*** leseb has joined #openstack-neutron02:17
amotokiI think it is not true. If i remmber correctly, there is a similar topic recently.02:18
*** dims has quit IRC02:18
gongyshI tried to access the API via the tenant bore URL, it fails.02:18
gongyshok, thanks02:18
amotokii am not sure how this document is created.02:18
*** flwang_ has quit IRC02:20
*** ranger81_ has quit IRC02:20
*** ranger81 has joined #openstack-neutron02:21
*** leseb has quit IRC02:22
*** WackoRobie has joined #openstack-neutron02:25
*** ranger81 has quit IRC02:26
*** WackoRobie has quit IRC02:30
*** dbite has joined #openstack-neutron02:30
*** yuyang-vm has left #openstack-neutron02:31
*** WackoRob_ has joined #openstack-neutron02:32
*** WackoRob_ has quit IRC02:36
*** mwagner_lap has joined #openstack-neutron02:39
*** dims has joined #openstack-neutron02:44
*** dims has quit IRC02:50
*** yuyang-vm has joined #openstack-neutron02:51
*** ramishra has joined #openstack-neutron02:57
*** popw1 has quit IRC02:57
*** mestery_ has joined #openstack-neutron03:01
*** shashankhegde has quit IRC03:04
*** coolsvap|afk is now known as coolsvap03:05
*** mestery_ has quit IRC03:05
*** mrsnivvel has joined #openstack-neutron03:07
*** gildub has joined #openstack-neutron03:09
*** seizadi has joined #openstack-neutron03:12
*** dvorkinista has quit IRC03:16
*** leseb has joined #openstack-neutron03:18
*** a_le has joined #openstack-neutron03:18
*** leseb has quit IRC03:23
*** jeraldv has joined #openstack-neutron03:24
*** seizadi has quit IRC03:30
*** WackoRobie has joined #openstack-neutron03:32
*** liusheng has quit IRC03:33
*** liusheng has joined #openstack-neutron03:34
*** zz_blogan is now known as blogan03:37
*** WackoRobie has quit IRC03:37
*** yuyang-vm has left #openstack-neutron03:40
*** zhiyan_ is now known as zhiyan03:40
*** seizadi has joined #openstack-neutron03:43
*** otherwiseguy has joined #openstack-neutron03:45
*** dims_ has joined #openstack-neutron03:46
*** dims_ has quit IRC03:51
*** coolsvap is now known as coolsvap|afk04:00
*** iwamoto has joined #openstack-neutron04:01
*** dvorkinista has joined #openstack-neutron04:04
*** noose_caboose has quit IRC04:13
*** yfried has quit IRC04:13
*** leseb has joined #openstack-neutron04:18
*** zhiyan is now known as zhiyan_04:20
*** leseb has quit IRC04:23
*** lori|away is now known as lori04:24
*** shashankhegde has joined #openstack-neutron04:27
openstackgerritSudhakar Babu Gariganti proposed a change to openstack/neutron: Cleanup empty namespace after unplugging a device  https://review.openstack.org/10501804:31
*** ranger81 has joined #openstack-neutron04:33
*** SridharG has joined #openstack-neutron04:36
*** seizadi has quit IRC04:41
*** nplanel has quit IRC04:44
*** dims_ has joined #openstack-neutron04:47
*** padkrish has joined #openstack-neutron04:50
*** dims_ has quit IRC04:52
*** ajc_ has joined #openstack-neutron04:52
*** ranger81 has quit IRC04:58
*** irenab has joined #openstack-neutron05:01
*** nlahouti has quit IRC05:02
irenabamotoki: hi05:02
*** mestery_ has joined #openstack-neutron05:02
amotokiirenab: hi05:02
*** nlahouti has joined #openstack-neutron05:02
irenabamotoki: do you have few mins to discuss binding:profile related issue I have with ML2 plugin, I saw you deal with it in NEC plugin05:04
amotokiirenab: sure05:04
irenabamotoki: what I see with ML2 plugin is when call port-update for any attribute, it clears the binding:profile05:05
irenabamotoki: I filled the bug: https://bugs.launchpad.net/neutron/+bug/1338202 and wanted to fix is the same way as you handle it in NEC plugin.05:06
irenabamotoki: what I cannot understand is how to send the request to clear binding:profile05:06
*** nlahouti has quit IRC05:07
*** mestery_ has quit IRC05:07
*** amitpp has joined #openstack-neutron05:07
amotokiirenab: I think what you are proposing is to send None to clear binding:profile.05:07
*** blogan is now known as zz_blogan05:08
amotokito do so, "neutron port-update PORT-ID --binding:profile action=clear" should work.05:08
irenabamotoki: the problem is when binding:profile is not requested to change (let's say the request is to change admin_state_up), it still looks like plugin receives it as None05:09
irenabamotoki: I was not aware of this option, thanks. I'll try. Is it the way it works for NEC plugin?05:10
amotokiirenab: I see. In nec pluign, None is used to clear binding:profile and it works for our plugin.05:12
*** ranger81 has joined #openstack-neutron05:12
amotokiin nec plugin, we check binding:profile is included in the new port dict.05:12
irenabamotoki: how can you pass None to the port-update call?05:13
amotokiirenab: do you mean the way to pass None from CLI?05:13
irenabamotoki: I see that plugin gets None even when not passing binding:profile from cli. So how do you distinguish?05:14
amotokiirenab: A plugin receives None only for updated attributes. If it is not speicified, None is not passed at update_port() method of the plugin.05:15
*** ghyoc has joined #openstack-neutron05:16
amotokiirenab: I think ML2 plugin use  new_port.get("binding:profile"), so you cannot distinguish it.05:16
irenabamotoki: in ML2 the profile calculated in this way: profile = attrs and attrs.get(portbindings.PROFILE)05:17
amotokiirenab: hmm... IMO we need to improve this logic.05:17
irenabamotoki: so actually, I think the right way to handle it is following NEC plugin way. What do you think?05:18
*** Vishal_ has joined #openstack-neutron05:19
irenabFor now I am more concerned regarding the unwanted clear operation, that occurs on any update call05:19
*** leseb has joined #openstack-neutron05:19
amotokiI think it is good. the similar way is used for other attributes.05:19
amotokiAgree. the current behavior should be fixed.05:20
irenabamotoki: but there should be a way to clear it laso, I didn't find any documentation, except on comment in the code for NEC plugin05:20
irenabamotoki: Do you suggest to handle it by: "neutron port-update PORT-ID --binding:profile action=clear"?05:21
*** padkrish has quit IRC05:21
amotokiirenab: it is really a gray zone. we don't have any good documentation how to clear an attribute: None vs an empty dict/list.05:21
irenabamotoki: just tried to pass None or empty string, and there is an error...05:22
irenabReason: 'None' is not a dictionary05:22
Vishal_gongysh: Hi05:22
irenabamotoki: any suggestion how to pass None?05:23
*** leseb has quit IRC05:24
amotokiirenab: i think the error occurs in ML2 plugin _process_port_binding(). The situation is a bit complicated.05:26
amotokiirenab: Neutron CLI cannot send {} or [] now. It only can send None without defining a new argument.05:26
amotokion the other hand, there is no good consensus for None and an empty dict/list on the server side.05:27
irenabamotoki: How None can be set?05:27
amotokiirenab: on the CLI side?05:28
*** otherwiseguy has quit IRC05:28
irenabamotoki: yes, I tried neutron port-update  PORT_ID  --binding:profile None05:28
irenabit fails on input validation05:28
amotokiplease try "neutron port-update PORT-ID --binding:profile action=clear".05:29
irenabamotoki: this pass, but didn't clear.05:29
*** yfried has joined #openstack-neutron05:29
irenabamotoki: I think, I'll try to rework the ML2 code to handle action=clear and fix the current behavior05:30
*** coolsvap|afk is now known as coolsvap05:30
irenabamotoki: Many thanks for your help on trying to understand how to handle this issue05:31
amotokiirenab: It sounds good to me. We can handle CLI side issue. The curfrent neutron CLI options is not easy to understand :-)05:31
gongyshVishal_: hi05:31
amotokiirenab: thanks for working on it.05:31
Vishal_gongysh: This is regarding defect https://bugs.launchpad.net/neutron/+bug/133780105:31
Vishal_I can see your comment on it05:31
irenabamotoki: agree, I will start with Server side05:31
gongyshVishal_: yes05:32
Vishal_gongysh: I feel the defect is a valid one...but bit confused how to proceed for it now05:32
Vishal_gongysh: since as I was also thinking that device_owner update is required for nova05:33
Vishal_gongysh: Please let me know your opinion on the same05:34
*** chandan_kumar has joined #openstack-neutron05:34
*** rolledback has joined #openstack-neutron05:42
*** afazekas is now known as __afazekas05:43
*** yamahata has quit IRC05:44
*** Longgeek has joined #openstack-neutron05:45
*** rolledback has quit IRC05:47
*** dims_ has joined #openstack-neutron05:47
*** devvesa has joined #openstack-neutron05:48
*** dims_ has quit IRC05:53
*** jlibosva has joined #openstack-neutron05:57
*** jprovazn has joined #openstack-neutron06:01
*** dvorkinista has quit IRC06:02
*** fandi has joined #openstack-neutron06:05
fandi hi all, i have problem l3-agent failed synchronizing routers;06:05
fandinow port state is down :(06:05
fandiwe know to solved this problem have to restart .. but i'll take almost 30 minutes to recreate all router .. how to fix without restart l3-agent06:06
*** dvorkinista has joined #openstack-neutron06:07
openstackgerritOpenStack Proposal Bot proposed a change to openstack/neutron: Imported Translations from Transifex  https://review.openstack.org/10445906:09
*** fandikurnia has joined #openstack-neutron06:09
*** yuyangbj has joined #openstack-neutron06:09
*** fandi has quit IRC06:12
gongyshfandi: disable router, and then enable it one by one.06:15
*** dvorkinista has quit IRC06:17
*** leseb has joined #openstack-neutron06:20
*** ranger81 has quit IRC06:21
*** ramishra has quit IRC06:23
*** pradipta_away is now known as pradipta06:23
*** leseb has quit IRC06:24
*** seizadi has joined #openstack-neutron06:25
*** shashankhegde has quit IRC06:27
*** ramishra_ has joined #openstack-neutron06:28
*** dvorkinista has joined #openstack-neutron06:29
*** kickinz1 has quit IRC06:31
*** seizadi1 has joined #openstack-neutron06:35
*** kickinz1 has joined #openstack-neutron06:36
*** trinaths has joined #openstack-neutron06:38
*** seizadi has quit IRC06:38
*** ghyoc has quit IRC06:40
*** ghyoc has joined #openstack-neutron06:41
*** seizadi1 has quit IRC06:44
*** seizadi has joined #openstack-neutron06:44
*** dims_ has joined #openstack-neutron06:48
*** liusheng has quit IRC06:48
*** seizadi has quit IRC06:49
*** sweston has joined #openstack-neutron06:50
*** liusheng has joined #openstack-neutron06:50
*** dims_ has quit IRC06:53
*** dvorkinista has quit IRC06:54
*** bashok has joined #openstack-neutron06:56
*** xianghui has joined #openstack-neutron06:56
openstackgerritXu Han Peng proposed a change to openstack/neutron: Use EUI64 for IPv6 SLAAC when subnet is specified  https://review.openstack.org/10143306:59
*** a_le has quit IRC07:00
openstackgerritXu Han Peng proposed a change to openstack/python-neutronclient: Create new IPv6 attributes for Subnets by client  https://review.openstack.org/7587107:02
*** luqas has joined #openstack-neutron07:06
*** leseb has joined #openstack-neutron07:09
*** fandikurnia has quit IRC07:10
*** amuller has joined #openstack-neutron07:14
*** afazekas_ has joined #openstack-neutron07:15
*** xianghui has quit IRC07:16
*** popw has joined #openstack-neutron07:20
*** suresh12 has joined #openstack-neutron07:20
*** chandan_kumar is now known as chandankumar07:23
*** salv-orlando has joined #openstack-neutron07:25
*** dvorkinista has joined #openstack-neutron07:25
*** dvorkinista has quit IRC07:30
*** rotbeard has joined #openstack-neutron07:30
*** amuller has quit IRC07:33
*** WackoRobie has joined #openstack-neutron07:35
*** jgallard has joined #openstack-neutron07:36
*** gildub has quit IRC07:39
*** WackoRobie has quit IRC07:40
*** mitz_ has quit IRC07:41
*** pasquier-s has joined #openstack-neutron07:43
*** yamahata has joined #openstack-neutron07:45
*** ianw is now known as ianw_pto07:47
*** jgallard has quit IRC07:49
*** jgallard has joined #openstack-neutron07:49
*** oreillyd has joined #openstack-neutron07:51
openstackgerritIsaku Yamahata proposed a change to openstack/neutron-specs: l3 plugin for router vm with service vm project  https://review.openstack.org/10507807:54
*** dianab has quit IRC07:58
*** safchain has joined #openstack-neutron08:00
*** amaretskiy has joined #openstack-neutron08:00
*** jpich has joined #openstack-neutron08:01
openstackgerritCedric Brandily proposed a change to openstack/neutron: Add partial specs support in ML2 for gre/vxlan provider networks  https://review.openstack.org/7405508:03
openstackgerritCedric Brandily proposed a change to openstack/neutron: Add partial specs support in ML2 for multiprovider extension  https://review.openstack.org/10146708:03
openstackgerritCedric Brandily proposed a change to openstack/neutron: Add partial specs support in ML2 for vlan provider networks  https://review.openstack.org/7190408:03
*** ygbo has joined #openstack-neutron08:05
*** ajo has joined #openstack-neutron08:05
*** zzelle has joined #openstack-neutron08:06
*** sweston has quit IRC08:10
*** xianghui has joined #openstack-neutron08:11
*** ihrachyshka has joined #openstack-neutron08:18
*** flwang_ has joined #openstack-neutron08:18
*** yamahata has quit IRC08:20
*** doude has quit IRC08:20
*** doude has joined #openstack-neutron08:21
*** flwang_ has quit IRC08:22
*** mitz_ has joined #openstack-neutron08:23
*** dvorkinista has joined #openstack-neutron08:25
*** leseb has quit IRC08:26
*** leseb has joined #openstack-neutron08:28
*** zhiyan_ is now known as zhiyan08:30
*** dvorkinista has quit IRC08:30
*** ramishra_ has quit IRC08:33
*** WackoRobie has joined #openstack-neutron08:36
*** WackoRobie has quit IRC08:41
openstackgerritliusheng proposed a change to openstack/neutron: Use None instead of mutables in method params defaults  https://review.openstack.org/10371308:43
*** leseb has quit IRC08:46
*** leseb has joined #openstack-neutron08:46
*** leseb has quit IRC08:47
*** yfried_ has joined #openstack-neutron08:52
*** coolsvap is now known as coolsvap|afk08:52
*** yfried has quit IRC08:52
*** ramishra has joined #openstack-neutron08:52
*** ijw has quit IRC08:54
*** fandi has joined #openstack-neutron08:55
fandihi, gongsyh08:56
fandihi, gongysh we only running 1 router08:56
*** yfauser has joined #openstack-neutron08:58
*** gkotton_ has quit IRC08:58
*** yfauser has left #openstack-neutron08:58
*** gkotton_ has joined #openstack-neutron08:58
*** iwamoto has quit IRC08:58
openstackgerritgongysh proposed a change to openstack/neutron: Deletes floatinip related connection states  https://review.openstack.org/10347508:59
*** amitpp has quit IRC09:00
*** Xurong has quit IRC09:00
*** Xurong has joined #openstack-neutron09:00
*** amuller has joined #openstack-neutron09:03
*** coolsvap|afk is now known as coolsvap09:04
openstackgerritCedric Brandily proposed a change to openstack/neutron: Add partial specs support in ML2 for multiprovider extension  https://review.openstack.org/10146709:07
*** flwang_ has joined #openstack-neutron09:11
*** amitpp has joined #openstack-neutron09:23
*** ijw has joined #openstack-neutron09:25
*** ihrachyshka has quit IRC09:26
*** dvorkinista has joined #openstack-neutron09:26
*** ihrachyshka has joined #openstack-neutron09:26
*** geekinut1h has quit IRC09:30
*** geekinutah has joined #openstack-neutron09:30
*** dvorkinista has quit IRC09:31
*** ijw has quit IRC09:31
*** tomoe_ has quit IRC09:32
*** yamamoto has quit IRC09:33
*** ijw has joined #openstack-neutron09:33
*** WackoRobie has joined #openstack-neutron09:37
*** ijw has quit IRC09:39
*** WackoRobie has quit IRC09:42
*** obondarev has joined #openstack-neutron09:43
*** obondarev_ has quit IRC09:44
*** yfauser has joined #openstack-neutron09:44
*** yfried__ has joined #openstack-neutron09:44
*** jp_at_hp has joined #openstack-neutron09:45
*** fandi has quit IRC09:48
openstackgerritmouad benchchaoui proposed a change to openstack/neutron: lb-agent: refactor and fix deletion bridge  https://review.openstack.org/10281109:48
*** yfried_ has quit IRC09:49
*** devvesa has quit IRC09:55
*** yfauser has left #openstack-neutron09:59
*** bvandenh has joined #openstack-neutron10:02
*** luqas has quit IRC10:04
*** luqas has joined #openstack-neutron10:07
*** pcm_ has joined #openstack-neutron10:08
*** xianghui has quit IRC10:11
*** pcm_ has quit IRC10:12
*** gongysh has quit IRC10:13
*** pcm_ has joined #openstack-neutron10:13
*** xianghui has joined #openstack-neutron10:13
*** xianghui has quit IRC10:22
*** bashok has quit IRC10:22
*** bashok has joined #openstack-neutron10:22
*** tomoe_ has joined #openstack-neutron10:24
*** dvorkinista has joined #openstack-neutron10:25
*** devvesa has joined #openstack-neutron10:29
*** dvorkinista has quit IRC10:30
*** ijw has joined #openstack-neutron10:33
*** suresh12 has quit IRC10:34
*** suresh12 has joined #openstack-neutron10:35
*** WackoRobie has joined #openstack-neutron10:38
*** popw has quit IRC10:38
*** yfauser has joined #openstack-neutron10:38
*** overlayer has joined #openstack-neutron10:38
*** ijw has quit IRC10:39
*** suresh12 has quit IRC10:39
*** WackoRobie has quit IRC10:42
*** yfauser has left #openstack-neutron10:43
*** overlayer has quit IRC10:48
*** tomoe_ has quit IRC10:48
*** jgallard has quit IRC10:49
*** luqas has quit IRC10:50
*** luqas has joined #openstack-neutron10:52
*** dims_ has joined #openstack-neutron10:53
*** yfauser has joined #openstack-neutron10:53
*** yfauser has left #openstack-neutron10:53
*** pasquier-s has quit IRC10:55
*** xianghui has joined #openstack-neutron10:57
*** dims_ has quit IRC10:58
*** coolsvap is now known as coolsvap|afk11:08
*** pasquier-s has joined #openstack-neutron11:14
*** dims_ has joined #openstack-neutron11:14
*** pradipta is now known as pradipta_away11:15
*** coolsvap|afk is now known as coolsvap11:16
*** xianghui has quit IRC11:19
*** dvorkinista has joined #openstack-neutron11:26
*** dvorkinista has quit IRC11:31
*** ijw has joined #openstack-neutron11:33
*** jgallard has joined #openstack-neutron11:34
*** tomoe_ has joined #openstack-neutron11:35
*** WackoRobie has joined #openstack-neutron11:39
*** ijw has quit IRC11:40
*** WackoRobie has quit IRC11:43
*** flwang_ has quit IRC11:43
*** ramishra has quit IRC11:43
*** coolsvap is now known as coolsvap|afk11:46
*** krtaylor_away is now known as krtaylor11:51
*** tomoe_ has quit IRC11:54
*** tomoe_ has joined #openstack-neutron11:55
*** afazekas_ has quit IRC12:02
*** markmcclain has joined #openstack-neutron12:09
*** trinaths has quit IRC12:09
*** yamamoto has joined #openstack-neutron12:12
*** devvesa has quit IRC12:16
*** afazekas_ has joined #openstack-neutron12:17
*** dave_tucker_zzz is now known as dave_tucker12:17
openstackgerritAnn Kamyshnikova proposed a change to openstack/neutron: Database healing migration  https://review.openstack.org/9643812:20
*** xianghui has joined #openstack-neutron12:21
*** afazekas_ has quit IRC12:23
openstackgerritAnn Kamyshnikova proposed a change to openstack/neutron: Database healing migration  https://review.openstack.org/9643812:24
openstackgerritAnn Kamyshnikova proposed a change to openstack/neutron: WIP Implement test  https://review.openstack.org/7652012:26
*** dvorkinista has joined #openstack-neutron12:27
*** mancdaz has quit IRC12:28
*** roaet_ has quit IRC12:28
*** mgagne has quit IRC12:28
*** wendar has quit IRC12:29
*** dougwig has quit IRC12:29
*** wendar has joined #openstack-neutron12:29
*** baffle_ has joined #openstack-neutron12:30
*** strictlyb is now known as sb12:30
*** shadyabh1 has joined #openstack-neutron12:30
*** coolsvapl has joined #openstack-neutron12:30
*** zacksh has quit IRC12:30
*** tomoe_ has quit IRC12:30
*** mongo2_ has joined #openstack-neutron12:30
*** zacksh has joined #openstack-neutron12:30
*** Lookcrab1 has joined #openstack-neutron12:30
*** TrevorV has quit IRC12:30
*** coolsvap|afk has quit IRC12:30
*** edhall has quit IRC12:31
*** shadyabhi has quit IRC12:31
*** baffle has quit IRC12:31
*** Lookcrabs has quit IRC12:31
*** mongo2 has quit IRC12:31
*** dougwig has joined #openstack-neutron12:31
*** shadyabh1 is now known as shadyabhi12:31
*** mgagne has joined #openstack-neutron12:31
*** coolsvapl has quit IRC12:31
*** coolsvapl has joined #openstack-neutron12:31
*** mancdaz has joined #openstack-neutron12:31
*** dougwig has quit IRC12:31
*** dougwig has joined #openstack-neutron12:31
*** roaet_ has joined #openstack-neutron12:31
*** dvorkinista has quit IRC12:32
*** TrevorV has joined #openstack-neutron12:32
*** ajc_ has quit IRC12:33
*** ijw has joined #openstack-neutron12:33
*** radez_g0n3 is now known as radez12:34
*** ramishra has joined #openstack-neutron12:36
*** devvesa has joined #openstack-neutron12:36
*** dims_ has quit IRC12:37
*** dims_ has joined #openstack-neutron12:37
*** ijw has quit IRC12:39
*** luqas has quit IRC12:43
*** luqas has joined #openstack-neutron12:44
*** noose_caboose has joined #openstack-neutron12:45
*** noose_caboose has quit IRC12:46
pcm_mestery: ping12:46
*** devvesa has quit IRC12:48
*** afazekas_ has joined #openstack-neutron12:49
*** sb has quit IRC12:49
*** strictlyb has joined #openstack-neutron12:50
*** stanzgy has quit IRC12:51
*** zhhuabj has joined #openstack-neutron12:57
*** otherwiseguy has joined #openstack-neutron12:57
*** mestery__ has joined #openstack-neutron12:57
*** WackoRobie has joined #openstack-neutron12:59
*** mestery__ has quit IRC12:59
*** julim has joined #openstack-neutron13:00
mesterypcm_: Whats up?13:01
*** otherwiseguy has quit IRC13:02
*** WackoRobie has quit IRC13:03
*** WackoRobie has joined #openstack-neutron13:03
*** diegows has joined #openstack-neutron13:05
*** ygbo has quit IRC13:05
*** amitpp has quit IRC13:05
*** zhhuabj has quit IRC13:06
*** ajo has quit IRC13:08
*** devvesa has joined #openstack-neutron13:09
*** yfried has joined #openstack-neutron13:09
*** yfried_ has joined #openstack-neutron13:10
*** chandan_kumar has joined #openstack-neutron13:10
*** yfried__ has quit IRC13:12
*** yfried has quit IRC13:14
*** chandankumar has quit IRC13:15
*** chandan_kumar is now known as chandankumar13:15
*** jecarey has quit IRC13:15
*** mestery has quit IRC13:17
*** ygbo has joined #openstack-neutron13:17
*** mestery has joined #openstack-neutron13:17
*** xuhanp has joined #openstack-neutron13:19
*** yamahata has joined #openstack-neutron13:20
*** devvesa has quit IRC13:22
*** mwagner_lap has quit IRC13:22
mtreinishmestery: I was just looking at: https://wiki.openstack.org/wiki/NeutronThirdPartyTesting#What_Tests_To_Run you could also suggest just using 'network' as a filter13:23
mtreinishthat will pick up all the neutron-specific tests and any other tests that are tagged as requiring networking13:23
*** ajo has joined #openstack-neutron13:23
mtreinishwhich will include things like the nova tests that use things like secgroups or floating ips13:24
mesterymtreinish: That's a good suggestion, thanks!13:24
mesterymtreinish: If you want, feel free to update the wiki, or I'll do that today :)13:25
mtreinishmestery: I'll throw something up there you can clean it up if it needs it13:25
mesterymtreinish: thanks, awesome!13:27
*** dvorkinista has joined #openstack-neutron13:28
openstackgerritOpenStack Proposal Bot proposed a change to openstack/neutron: Updated from global requirements  https://review.openstack.org/10516913:29
mesterymtreinish: looks great, thanks for the update!13:31
*** dvorkinista has quit IRC13:32
*** scheuran has joined #openstack-neutron13:33
*** ijw has joined #openstack-neutron13:33
*** ajo has quit IRC13:34
*** jecarey has joined #openstack-neutron13:34
*** irenab has quit IRC13:35
*** xianghui has quit IRC13:36
*** zhiyan is now known as zhiyan_13:37
*** tomoe_ has joined #openstack-neutron13:37
*** ijw has quit IRC13:39
*** seizadi has joined #openstack-neutron13:39
*** bashok has quit IRC13:42
*** jgallard has quit IRC13:48
*** armax has joined #openstack-neutron13:50
*** nplanel has joined #openstack-neutron13:52
*** trad511 has joined #openstack-neutron13:57
*** markmcclain has quit IRC13:58
*** nplanel has quit IRC14:01
*** swat30 has quit IRC14:01
*** thurloat has quit IRC14:01
*** nplanel has joined #openstack-neutron14:02
*** yfried__ has joined #openstack-neutron14:03
*** obondarev has quit IRC14:06
openstackgerritArmando Migliaccio proposed a change to openstack/neutron: Add L3 Extension for Distributed Routers  https://review.openstack.org/8422314:06
*** yfried_ has quit IRC14:07
*** swat30 has joined #openstack-neutron14:07
*** yamamoto has quit IRC14:09
*** TrevorV_ has joined #openstack-neutron14:11
*** markmcclain has joined #openstack-neutron14:11
*** thurloat has joined #openstack-neutron14:13
*** rolledback has joined #openstack-neutron14:13
*** SridharG has quit IRC14:13
*** tomoe_ has quit IRC14:17
*** rolledback has quit IRC14:19
*** rolledback has joined #openstack-neutron14:19
*** annegent_ has joined #openstack-neutron14:20
*** jgrimm has joined #openstack-neutron14:20
*** amotoki_ has joined #openstack-neutron14:21
*** amotoki has quit IRC14:22
*** pradk has joined #openstack-neutron14:23
*** bklei has joined #openstack-neutron14:23
*** ajo has joined #openstack-neutron14:25
bkleiAnyone willing to review https://review.openstack.org/#/c/92390?  This is for keystone V3 support in the neutron client...14:25
*** Lookcrab1 is now known as Lookcrabs14:26
*** regXboi has joined #openstack-neutron14:27
*** karimb has joined #openstack-neutron14:29
*** ghyoc has quit IRC14:31
*** xianghui has joined #openstack-neutron14:33
*** alagalah has joined #openstack-neutron14:33
*** ijw has joined #openstack-neutron14:33
*** Longgeek has quit IRC14:34
*** Longgeek has joined #openstack-neutron14:36
markmcclainbklei: it was on my list of items to review this morning14:38
*** ijw has quit IRC14:39
bkleiawesome, thx markmcclain14:39
*** jaypipes has joined #openstack-neutron14:40
*** yamamoto has joined #openstack-neutron14:40
*** yamamoto_ has joined #openstack-neutron14:42
*** nplanel has quit IRC14:42
*** xuhanp has quit IRC14:44
*** otherwiseguy has joined #openstack-neutron14:44
*** yamamoto has quit IRC14:45
*** yamamoto_ has quit IRC14:47
*** xgerman has joined #openstack-neutron14:47
openstackgerritRossella Sblendido proposed a change to openstack/neutron: Add retry_on_deadlock decorator to retry DB operations  https://review.openstack.org/10493614:47
openstackgerritHareesh Puthalath proposed a change to openstack/neutron: Configuration agent for Cisco devices  https://review.openstack.org/10359314:48
*** xarses_ has quit IRC14:48
openstackgerritRossella Sblendido proposed a change to openstack/neutron: Add retry_on_deadlock decorator to retry DB operations  https://review.openstack.org/10493614:50
*** chandankumar has quit IRC14:51
*** yamamoto has joined #openstack-neutron14:53
*** dkehnx1 has joined #openstack-neutron14:54
*** dvorkinista has joined #openstack-neutron14:56
*** carl_baldwin has joined #openstack-neutron14:57
*** scheuran has quit IRC14:58
*** a_le has joined #openstack-neutron14:58
*** jlibosva has quit IRC15:02
*** annegent_ has quit IRC15:02
*** ramishra has quit IRC15:02
*** bklei has quit IRC15:02
*** alagalah_ has joined #openstack-neutron15:02
*** devvesa has joined #openstack-neutron15:02
*** annegent_ has joined #openstack-neutron15:02
*** rotbeard has quit IRC15:04
*** afazekas_ has quit IRC15:05
*** alagalah has quit IRC15:06
*** chandan_kumar has joined #openstack-neutron15:06
openstackgerritArmando Migliaccio proposed a change to openstack/neutron: L2 Model additions to support DVR  https://review.openstack.org/10210115:07
*** scheuran has joined #openstack-neutron15:09
*** alexpilotti has quit IRC15:11
*** yfried__ has quit IRC15:11
*** seizadi has quit IRC15:12
*** amuller has quit IRC15:12
*** alexpilotti has joined #openstack-neutron15:13
*** karimb has quit IRC15:18
*** ramishra has joined #openstack-neutron15:18
*** overlayer has joined #openstack-neutron15:19
*** rotbeard has joined #openstack-neutron15:19
*** thedodd has joined #openstack-neutron15:21
*** mlavalle has joined #openstack-neutron15:21
*** doddstack has joined #openstack-neutron15:24
openstackgerritIhar Hrachyshka proposed a change to openstack/neutron-specs: Switch from MySQLdb to MySQL Connector  https://review.openstack.org/10490515:25
*** networkstatic has joined #openstack-neutron15:25
*** thedodd has quit IRC15:26
*** leenheer has joined #openstack-neutron15:26
*** TrevorV_ has quit IRC15:27
*** dave_tucker is now known as dave_tucker_zzz15:28
*** sbfox has joined #openstack-neutron15:29
openstackgerritSergey Kolekonov proposed a change to openstack/neutron: Fix missing migration default value  https://review.openstack.org/10521215:30
*** xianghui has quit IRC15:31
*** sbfox1 has joined #openstack-neutron15:31
*** xianghui has joined #openstack-neutron15:32
*** s3wong has joined #openstack-neutron15:32
*** jckasper has quit IRC15:33
*** sbfox has quit IRC15:33
*** ijw has joined #openstack-neutron15:33
*** markmcclain has quit IRC15:33
*** coolsvapl is now known as coolsvap15:37
*** trinaths has joined #openstack-neutron15:37
*** alagalah_ has quit IRC15:37
*** sbfox1 has quit IRC15:38
*** alagalah has joined #openstack-neutron15:39
*** ijw has quit IRC15:39
*** Longgeek has quit IRC15:39
*** [1]trinaths has joined #openstack-neutron15:39
*** overlayer has quit IRC15:41
*** trinaths has quit IRC15:43
*** [1]trinaths is now known as trinaths15:43
*** ijw has joined #openstack-neutron15:43
*** alagalah has quit IRC15:44
*** flwang_ has joined #openstack-neutron15:45
ihrachyshkamestery: hey. seems like switching to another mysql client library will not only fix db deadlocks, but may also give a huge performance boost.15:45
ihrachyshkamestery: see some basic test results at: https://review.openstack.org/#/c/104905/3/specs/juno/switch-to-mysql-connector.rst15:46
mesteryihrachyshka: nice nice nice!15:46
ihrachyshkaline 88 and below15:46
ihrachyshkabut the testing is still very limited, I need to do more scenarios15:46
*** rwsu has joined #openstack-neutron15:47
openstackgerritArmando Migliaccio proposed a change to openstack/neutron: L2 Model additions to support DVR  https://review.openstack.org/10210115:47
openstackgerritJaume Devesa proposed a change to openstack/python-neutronclient: Found a useless comment.  https://review.openstack.org/10521715:48
*** flwang_ has quit IRC15:50
*** s3wong has quit IRC15:53
*** ijw has quit IRC15:53
*** leenheer has quit IRC15:54
*** suresh12 has joined #openstack-neutron15:54
openstackgerritArmando Migliaccio proposed a change to openstack/neutron: L2 Model additions to support DVR  https://review.openstack.org/10210115:55
*** dave_tucker_zzz is now known as dave_tucker15:55
*** yamamoto has quit IRC15:55
*** ihrachyshka has quit IRC15:56
*** _cjones_ has joined #openstack-neutron15:57
*** rotbeard has quit IRC15:58
*** nlahouti has joined #openstack-neutron15:59
*** alagalah has joined #openstack-neutron16:00
*** sbfox has joined #openstack-neutron16:00
*** scheuran has quit IRC16:01
*** a_le has quit IRC16:01
*** yfauser has joined #openstack-neutron16:03
*** yfauser has left #openstack-neutron16:03
*** a_le has joined #openstack-neutron16:03
*** yfauser1 has joined #openstack-neutron16:05
*** yfauser1 has left #openstack-neutron16:05
*** annegent_ has quit IRC16:07
*** jckasper has joined #openstack-neutron16:08
*** afazekas_ has joined #openstack-neutron16:11
*** doddstack has quit IRC16:16
openstackgerritRossella Sblendido proposed a change to openstack/neutron: Add retry_on_deadlock decorator to retry DB operations  https://review.openstack.org/10493616:16
*** coolsvap is now known as coolsvap|afk16:16
*** pasquier-s_ has joined #openstack-neutron16:17
*** yfried__ has joined #openstack-neutron16:17
*** yfried__ has quit IRC16:17
*** yfried__ has joined #openstack-neutron16:17
*** pasquier-s_ has quit IRC16:18
*** aveiga has joined #openstack-neutron16:20
*** sbfox1 has joined #openstack-neutron16:23
*** manishg has joined #openstack-neutron16:24
*** sbfox has quit IRC16:26
*** yamamoto has joined #openstack-neutron16:26
*** paraa has joined #openstack-neutron16:28
*** sbfox1 has quit IRC16:29
*** sbfox has joined #openstack-neutron16:29
*** jpich has quit IRC16:30
*** yamamoto has quit IRC16:31
*** seizadi has joined #openstack-neutron16:34
*** thedodd has joined #openstack-neutron16:34
*** sweston has joined #openstack-neutron16:36
*** trinaths has quit IRC16:39
*** yamamoto has joined #openstack-neutron16:40
*** packet has joined #openstack-neutron16:41
*** suresh12 has quit IRC16:42
openstackgerritArmando Migliaccio proposed a change to openstack/neutron: Modify L3 Agent for Distributed Routers  https://review.openstack.org/8941316:42
*** SridharG has joined #openstack-neutron16:43
_cjones_Hey guys. One more question for developers. As I understand the ML2 Mechanism drivers are chained and called one after another. However, this is *not* the case for the type drivers, correct? You may only have one type specificed?16:43
*** yamamoto has quit IRC16:45
*** ygbo has quit IRC16:45
*** pasquier-s has quit IRC16:47
openstackgerritJaume Devesa proposed a change to openstack/python-neutronclient: Found a useless comment  https://review.openstack.org/10521716:50
*** shashankhegde has joined #openstack-neutron16:51
*** alagalah has quit IRC16:51
openstackgerritstephen-ma proposed a change to openstack/neutron: L2 Agent-side additions to support DVR  https://review.openstack.org/8773016:51
*** dave_tucker is now known as dave_tucker_zzz16:51
openstackgerritA change was merged to openstack/neutron: Fix example for running individual tests  https://review.openstack.org/10189616:52
*** annegent_ has joined #openstack-neutron16:53
*** ijw has joined #openstack-neutron16:54
*** ijw has quit IRC17:00
*** alagalah has joined #openstack-neutron17:01
*** yfauser has joined #openstack-neutron17:01
*** harlowja_away is now known as harlowja17:01
*** dsneddon has joined #openstack-neutron17:02
*** oreillyd has quit IRC17:02
*** dsneddon has quit IRC17:02
*** dsneddon has joined #openstack-neutron17:02
*** shakamunyi has joined #openstack-neutron17:03
*** shashankhegde has quit IRC17:04
*** xianghui has quit IRC17:05
*** dsneddon has quit IRC17:05
*** yfauser has left #openstack-neutron17:05
*** jorgem has joined #openstack-neutron17:07
*** amaretskiy has quit IRC17:09
chuckC_cjones_: Type is associated with network segment, so drivers for types associated with the appropriate network are called.  See providernet extension.17:10
*** rolledback has quit IRC17:12
openstackgerritSalvatore Orlando proposed a change to openstack/neutron: Do not mark device as processed if it wasn't  https://review.openstack.org/10523917:12
*** bandarji has joined #openstack-neutron17:13
*** jobewan has joined #openstack-neutron17:14
*** luqas has quit IRC17:14
manishg_cjones_ - like mentioned by chuckC, network_type of the segment dictates the type driver.  It doesn't make sense to call flat network driver for a vlan network.  However mechanism drivers are to realize the network and there maybe multiple of them involved hence chaining.17:15
*** dsneddon has joined #openstack-neutron17:16
*** ranger81 has joined #openstack-neutron17:17
*** safchain_ has joined #openstack-neutron17:19
_cjones_manishg / chuckC: Thanks guys. I just wanted to confirm that the way I was reading things was correct. Also the purpose of the type driver is to just ensure that the resources are available and to reserve them, correct?17:21
*** alagalah has quit IRC17:22
*** alagalah has joined #openstack-neutron17:22
*** safchain has quit IRC17:23
*** ijw has joined #openstack-neutron17:24
*** mestery has quit IRC17:28
*** thedodd has quit IRC17:28
*** mestery has joined #openstack-neutron17:29
*** leenheer has joined #openstack-neutron17:30
*** sweston has quit IRC17:30
*** dave_tucker_zzz is now known as dave_tucker17:31
*** yfauser has joined #openstack-neutron17:33
*** yfauser has left #openstack-neutron17:33
*** ramishra has quit IRC17:33
*** crc32 has joined #openstack-neutron17:33
*** sweston has joined #openstack-neutron17:35
*** zzelle_ has joined #openstack-neutron17:36
*** yamamoto has joined #openstack-neutron17:40
*** dkehnx1 has quit IRC17:40
*** networkstatic is now known as networkstatic_zZ17:43
*** afazekas_ has quit IRC17:43
*** dfarrell07 has joined #openstack-neutron17:44
*** yamamoto has quit IRC17:45
*** shashankhegde has joined #openstack-neutron17:45
*** flwang_ has joined #openstack-neutron17:46
*** flwang_ has quit IRC17:51
*** suresh12 has joined #openstack-neutron17:52
*** rolledback has joined #openstack-neutron17:53
*** zzelle has quit IRC17:56
*** ajo has quit IRC17:57
*** suresh12 has quit IRC17:57
*** amotoki_ has quit IRC18:02
*** luqas has joined #openstack-neutron18:03
*** marun has joined #openstack-neutron18:05
*** jgrimm has quit IRC18:08
openstackgerritA change was merged to openstack/neutron-specs: Add spec for ML2 mechanism driver for SDN-VE  https://review.openstack.org/8810118:09
*** alagalah_ has joined #openstack-neutron18:09
*** ajo has joined #openstack-neutron18:09
*** TrevorV_ has joined #openstack-neutron18:11
*** alagalah has quit IRC18:12
openstackgerritPaddu Krishnan proposed a change to openstack/neutron-specs: VDP support in OVS Neutron Agent  https://review.openstack.org/8972818:13
*** thedodd has joined #openstack-neutron18:14
*** afazekas_ has joined #openstack-neutron18:14
*** mestery has quit IRC18:14
*** dims_ has quit IRC18:14
*** mestery has joined #openstack-neutron18:15
*** chuckC has quit IRC18:15
*** mestery has quit IRC18:16
*** mestery has joined #openstack-neutron18:16
*** dims has joined #openstack-neutron18:19
*** mestery has quit IRC18:19
*** mestery has joined #openstack-neutron18:20
*** mestery has quit IRC18:22
*** mestery has joined #openstack-neutron18:22
*** devvesa has quit IRC18:27
openstackgerritShiv Haris proposed a change to openstack/neutron-specs: L3 Router service plugin to provide hardware based routing  https://review.openstack.org/10525018:30
*** s3wong has joined #openstack-neutron18:32
*** dave_tucker is now known as dave_tucker_zzz18:33
*** jprovazn has quit IRC18:33
*** amcrn has joined #openstack-neutron18:34
*** afazekas_ has quit IRC18:35
*** padkrish has joined #openstack-neutron18:35
*** radez is now known as radez_g0n318:39
*** seizadi has quit IRC18:39
*** yamamoto has joined #openstack-neutron18:40
*** alagalah_ has quit IRC18:44
*** yamamoto has quit IRC18:45
*** thurloat has quit IRC18:45
*** alagalah has joined #openstack-neutron18:45
*** swat30 has quit IRC18:46
*** networkstatic_zZ is now known as networkstatic18:46
*** toMeloos has joined #openstack-neutron18:47
*** packet has quit IRC18:52
*** marun has quit IRC18:56
*** luqas has quit IRC19:00
*** radez_g0n3 is now known as radez19:00
*** sweston has quit IRC19:02
*** garyduan has joined #openstack-neutron19:03
*** VijayB has joined #openstack-neutron19:03
*** seizadi has joined #openstack-neutron19:04
*** gduan has quit IRC19:04
*** beagles has quit IRC19:04
openstackgerritShiv Haris proposed a change to openstack/neutron-specs: L3 Router service plugin to provide hardware based routing  https://review.openstack.org/10525019:05
manishg_cjones_ , yes.  it will validate the segment with what is configured in the ml2 conf + reserve.19:05
*** chandan_kumar has quit IRC19:06
*** SridharG has quit IRC19:07
*** annegent_ has quit IRC19:07
*** annegent_ has joined #openstack-neutron19:08
*** jgrimm has joined #openstack-neutron19:09
*** mestery has quit IRC19:13
*** annegent_ has quit IRC19:13
*** mestery has joined #openstack-neutron19:13
*** afazekas_ has joined #openstack-neutron19:14
*** seizadi has quit IRC19:17
*** rolledback has quit IRC19:20
*** otherwiseguy has quit IRC19:21
*** ijw has quit IRC19:22
*** shashankhegde has quit IRC19:22
*** lori is now known as lori|away19:25
pcm_enikanorov: ping19:31
openstackgerritCedric Brandily proposed a change to openstack/neutron-specs: DHCP agent customization  https://review.openstack.org/9935619:31
*** beagles has joined #openstack-neutron19:31
_cjones_manishg: TYVM!19:34
*** VijayB has quit IRC19:34
*** VijayB has joined #openstack-neutron19:35
*** VijayB has quit IRC19:36
*** annegent_ has joined #openstack-neutron19:36
*** rolledback has joined #openstack-neutron19:36
*** afazekas_ has quit IRC19:37
*** rolledba_ has joined #openstack-neutron19:39
*** chuckC has joined #openstack-neutron19:39
*** amcrn is now known as ghost_of_amcrn19:39
*** yamamoto has joined #openstack-neutron19:40
*** rolledback has quit IRC19:40
*** annegent_ has quit IRC19:41
*** ijw has joined #openstack-neutron19:41
*** bvandenh has quit IRC19:41
*** shashankhegde has joined #openstack-neutron19:44
*** yamamoto has quit IRC19:45
zzelle_mestery, hi19:46
mesteryzzelle_: yo!19:46
zzelle_mestery, one question about vxlan ... is ti possible to define multiple endpoints for the same ip (with different ports) ?19:47
openstackgerritSalvatore Orlando proposed a change to openstack/neutron: Do not mark device as processed if it wasn't  https://review.openstack.org/10523919:47
*** gduan has joined #openstack-neutron19:47
*** flwang_ has joined #openstack-neutron19:47
*** yfauser has joined #openstack-neutron19:47
*** garyduan has quit IRC19:48
*** yfauser has left #openstack-neutron19:48
zzelle_s/ti/it/19:48
mesteryzzelle_: So you want to use different ports for tenant networks?19:49
*** erecio has joined #openstack-neutron19:49
*** erecio has quit IRC19:49
zzelle_mestery, nope but the code is not coherent19:49
zzelle_mestery, more precisely, it's possible to insert multiple endpoints with the same ip and different ports19:50
mesteryzzelle_: OVS allows the use of different ports19:50
mesteryzzelle_: Yes19:50
zzelle_https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/type_vxlan.py#L202-L21419:50
zzelle_mestery, but ^ expect at most one endpoint per ip19:51
zzelle_mestery, because the select filter on the ip not ip and port19:51
*** flwang_ has quit IRC19:52
mesteryzzelle_: Ah, ok, now I get you.19:52
mesteryzzelle_: It's possible the OVS code allows this, but we don't allow this when using VXLAN tunnels in Neutron.19:52
zzelle_mestery, ouf19:52
mesteryzzelle_: I think that's what you've discovered.19:52
zzelle_mestery, so there is a trouble the primary key must be only composed of endpoint ip ? not endpoint ip and port ?19:54
mesteryzzelle_: Let me look at the configuration to see if we allow what you're looking for or not.19:54
*** sweston has joined #openstack-neutron19:55
chuckCsalv-orlando: carl_baldwin: We got in a bit early, so I'm available to discuss Link Aggregation if now is a good time.19:57
*** mriedem has joined #openstack-neutron19:57
salv-orlandochuckC: I’ll grab a coffe and be with you19:58
openstackgerritbadveli_vishnuus proposed a change to openstack/neutron: Implements: blueprint FWaaS extension for customized service and service group  https://review.openstack.org/10473919:58
openstackgerritbadveli_vishnuus proposed a change to openstack/neutron: mend  https://review.openstack.org/10526119:58
*** padkrish has quit IRC19:58
carl_baldwinchuckC: I was just finalizing some comments on the bp.19:58
chuckCcarl_baldwin: sorry I didn't give you advance warning, but I at least want to talk to salv-orlando since he marked the bp wip19:58
zzelle_mestery, according to code, it's current quite impossible to have multiple endpoints with the same ip ... except with a race condition but the model constraints do not reflect it19:58
chuckCcarl_baldwin: thanks, I'll take a look when you're done19:59
mesteryzzelle_: Then I think we have our answer.19:59
mriedemsdague: salv-orlando: i have a meeting, but going to drop this in here http://lists.openstack.org/pipermail/openstack-dev/2014-July/039530.html19:59
mesteryzzelle_: The underlying OVS supports this, but we currently don't.19:59
zzelle_ok, i will correct the db model in order to remove the SELECT FOR UPDATE19:59
zzelle_mestery, thanks20:00
mesteryzzelle_: Thanks!20:00
mriedemenikanorov: http://lists.openstack.org/pipermail/openstack-dev/2014-July/039530.html since i think you opened a few of those bugs or wrote the e-r queries20:00
salv-orlandomriedem: I stumbled upon that section of the wiki earlier on today and wondered who wrote it ;)20:01
salv-orlandoneedless to say, I’m too lazy to check wiki page history20:01
mriedemsalv-orlando: zzzeek, who isn't in here20:02
mriedemhe's in -dev and -oslo though20:02
*** shivharis has joined #openstack-neutron20:02
mriedembut as russellb just pointed out in -nova, that requires a patch to eventlet which comstud had proposed but i don't think eventlet has merged,20:02
salv-orlandochuckC: the only reason for me marking it WIP is the amount of TBD. We’re entering crush mode for spec review, and I swept through a good chunk of them.20:02
mriedemso basically not usable for us20:02
salv-orlandomriedem: yes, I know the story from that side. I spoke to comstud a while ago20:03
chuckCsalv-orlando: ok, this is my first bp/spec so I'm just wondering how to get a conversation going on this topic.  carl_baldwin is reviewing now, so maybe I'll just wait to get his perspecitve first.20:05
salv-orlandochuckC: yes. make sense. From my perspective, I understand the reasoning behind wanting Ironic to be able to leverage link aggregation. I would like to see a solution where we can achieve that while preserving a rather simple abstraction at the logical level (ie: the neutron resource)20:06
chuckCsalv-orlando: we are trying to get this into Juno since it may not be a whole lot of work and TripleO/Ironic have interest20:06
salv-orlandochuckC: on a wider note, what you say above is important. Put it in the spec maybe because the core team will need to choose which specs can be accepted for juno or not20:06
salv-orlandothere are already way more specs under review than those we can land.20:07
salv-orlandoso letting the core team know why a spec is important would be useful.20:07
salv-orlandofor the technical details we can wait for carl_baldwin20:07
salv-orlandoI will be around for about 3 more hours.20:07
*** ghost_of_amcrn is now known as amcrn20:07
carl_baldwinchuckC: salv-orlando:  I’m trying to wrap up comments.20:08
chuckCsalv-orlando: have you looked at the Neutron Switch Port Extension doc (https://docs.google.com/document/d/12LU-C2A8cNMNJFB6KYy5zuWoW0OzbMgwZGWxjrHYP6Q/edit#)20:08
sdaguemriedem: right, so my thinking is if we're talking about changing the mysql driver, we should be talking about it openstack wide, and not just in neutron20:08
carl_baldwinchuckC: My initial reaction is that supporting link aggregation in a compute instance is an OS thing.  I’m not sure yet how Neutron should be involved.20:08
sdagueespecially as that seems like it's zzzeek's suggestion20:08
chuckCsalv-orlando: Ironic PTL recommended I look at it, but I haven't really absorbed it yet20:08
salv-orlandoneither have I, chuckC. Perhaps you should ask the people involved in advanced services discussion, seems it faills in the area20:09
salv-orlandowhat I know is only it did not land in trunk yet20:09
salv-orlandoand afaik there’s nothing under review (but I might have missed it)20:10
carl_baldwinchuckC: Is there no way for Ironic to determine what the mac address will be on the aggregate and boot from the interface with that mac address before aggregation?20:10
chuckCcarl_baldwin: the argument is that Ironic already uses Neutron ports on baremetal compute nodes20:10
chuckCcarl_baldwin: the main problem is to be able to boot from one of several interfaces, and regardless which one is chosen, end up with the same IP address20:11
carl_baldwinWhy is “regardless of which one is chosen” part of the requirement?20:12
*** ijw_ has joined #openstack-neutron20:12
chuckCThat's the link aggregation part.  After the OS comes up, those interfaces will be bonded, hence have a single IP address.20:13
chuckCIt's an HA requirement.20:13
carl_baldwinchuckC: I understand the desire to aggregate links.20:13
*** VijayB_ has joined #openstack-neutron20:14
chuckCcarl_baldwin: maybe I'm not understanding your question20:15
*** ijw has quit IRC20:15
*** VijayB_ has quit IRC20:15
*** VijayB_ has joined #openstack-neutron20:16
*** shakamunyi has quit IRC20:16
chuckCIronic needs to be able to tolerate the failure of any arbitrary interface20:16
*** yamahata__ has joined #openstack-neutron20:17
chuckCcarl_baldwin: ^20:17
*** shakamunyi has joined #openstack-neutron20:17
*** sbfox has quit IRC20:17
chuckCcarl_baldwin: 'tolerate' in the sense of detect failure and retry boot on another interface20:17
carl_baldwinchuckC: understood.  I’m not questioning the value of aggregating the links.20:17
*** yamahata_ has quit IRC20:17
carl_baldwinCan DHCP be run on a bond interface?20:18
*** padkrish has joined #openstack-neutron20:18
chuckCcarl_baldwin: AFAIK, the client currently presents a mac address and gets back the associated IP address20:19
carl_baldwinchuckC: Is the DHCP client run on the bond interface or the underlying physical interface?20:20
*** pcm_ has quit IRC20:21
chuckCAt boot time, it's the underlying interface.  When the OS is started, I think it's the bond.20:22
*** pcm_ has joined #openstack-neutron20:22
*** nlahouti has quit IRC20:22
chuckCThink about network boot.20:22
openstackgerritA change was merged to openstack/neutron: VPNaaS REST Client UT Broken  https://review.openstack.org/10367520:23
salv-orlandoI confess being ignorant about Link Aggr. I only recall explicitly configuring it on switch ports. Have no recollection about how that works.20:23
salv-orlandowith DHCP I mean...20:23
chuckCOS image must be loaded from network first, then OS is started and DHCP again configures the bond.20:24
chuckCDHCP used for both20:24
*** otherwiseguy has joined #openstack-neutron20:25
*** jecarey has quit IRC20:25
salv-orlandoso you initially have eth0 and eth1 and they both send a DHCPREQUEST.20:25
carl_baldwinchuckC: So, initial ironic boot to load the guest OS is done without bond interfaces.  The first boot is PXE or something like it?20:26
salv-orlandothe first that receive a DHCPOFFER will determine the machine’s IP for the link aggregated iface, and the the bond is created20:26
chuckCcarl_baldwin: OK, this is where my understanding starts hitting the limit.  I think the PXE part just gets the basic boot stuff loaded, then TFTP is used to load the OS, then the OS starts and does the usual stuff.20:27
mriedemsdague: yeah, definitely do it in the sqla mysql driver20:27
salv-orlandochuck: right PXE. That was the bit I was missing.20:27
salv-orlandothe PXE part is unaware of the bond.20:28
*** sballe__ has quit IRC20:28
*** ijw_ is now known as ijw20:29
chuckCsalv-orlando: DHCPDISCOVER with mac address, then server replies DHCPOFFER with IP address, then server sends DHCPREQUEST to confirm wanting that address, then I forget the last one.20:29
chuckCSo it seems I should add this detail to the spec problem statement….20:30
*** julim has quit IRC20:30
salv-orlandoit’s DHCPACK but that’s not important, I think. Do you need fault tolerance on DHCP as well?20:32
*** sbfox has joined #openstack-neutron20:32
salv-orlandoI guess so.20:32
chuckCYes, but that's a different problem.20:33
chuckCIf you mean the DHCP server.20:33
chuckCWill that be covered by L3 HA?20:33
carl_baldwinchuckC: salv-orlando: I was also thinking the problem is fault tolerance on DHCP.  Is the problem that PXE boot does not aggregate but tries to DHCP from each interface individually?20:34
salv-orlandoyeah but I don’t know if you can present that to PXE20:35
chuckCcarl_baldwin: essentially, yes, PXE and the boot programs do not know about the aggregate.  So, Ironic needs to take that into account.20:35
salv-orlandothat would mean presenting to the instance a single interface which is actually a link aggregate20:35
salv-orlandoand implement the aggregate in openvswitch or linux bridge20:35
salv-orlandonot sure if that’s even possible, just thinking aloud20:36
chuckCsalv-orlando: right, boot/PXE don't do that, I think20:36
salv-orlandochuckC: under this assumption the instance has definetely two distinct neutron interfaces. Otherwise the ironic driver would never plug two distinct VIFs… unless we define a LA network whose ports are plugged as two VIFs or has many VIFs as (n_slaves +1)20:39
salv-orlandoLA is link aggregation, not Los Angeles, obviouvsly!20:40
*** yamamoto has joined #openstack-neutron20:40
*** rolledba_ has quit IRC20:41
*** banix has joined #openstack-neutron20:41
ijwsalv-orlando, chuckC: I've tried (accidentally) the LA / PXE boot thing and I don't recommend it.20:41
*** yamamoto_ has joined #openstack-neutron20:42
ijwBut if you're looking for fault tolerance of an interface failure on boot (and, you know, it's not obvious that Ironic *does* need to be fault tolerant in that regard) you can unbond the interfaces, do the install and bond them on reboot20:42
*** yamamoto has quit IRC20:42
ijwAnd if you accept DHCP from either MAC then you are basically fine to do the install over whichever interface happens to be working.20:42
_cjones_I recently wrote an L3 service, and a co-worker was all up in arms about the use of "id" as one of my parameters because it is a python keyword. I notice that this is used extensively in many Neutron db mixins, etc... What's the community stance on this?20:42
salv-orlandoijw: cool, if you’ve experienced it maybe you can comment on this spec proposal -> https://review.openstack.org/#/c/103765/20:43
openstackgerritRobert Kukura proposed a change to openstack/neutron: Group Policy: Resource Mapping Driver  https://review.openstack.org/10527220:43
ijwThe trick we used was to change the bond status on reboot (which worked just fine)20:43
carl_baldwinijw: in what sense did you change the bond status?20:44
salv-orlandoijw: and that would be something which the instance will sort out in its operating system. To neutron, that’s just an instance with two poers.20:44
salv-orlandopoers/ports20:44
chuckCI think this is not just for install, but also for network boot20:45
*** yamamoto_ has quit IRC20:46
chuckCijw: why do you think Ironic doesn't need to tolerate interface failure?20:46
openstackgerritArmando Migliaccio proposed a change to openstack/neutron: Add L3 Scheduler Changes for Distributed Routers  https://review.openstack.org/8969420:46
chuckCijw: and what do you mean by 'accept DHCP from either MAC'?  Does 'accept' mean serve the same IP address for?20:48
ijwWell, this is for PXE - you can serve whatever address you please so long as you put the right OS image on there20:48
ijw(assuming Ironic works the same as I think it does - PXE boot, install image, reboot from HD)20:49
*** jorgem has quit IRC20:49
ijwchuckC: in the same way that a VM can die in a cloud, an Ironic instance can find itself suffering hardware failure and becoming unusuable.  Fault tolerance is something you would like the option to do but it absolutely isn't mandatory.20:50
chuckCijw: It's a feature, right?  One we want to be able to offer.20:50
openstackgerritArmando Migliaccio proposed a change to openstack/neutron: Add L3 Scheduler Changes for Distributed Routers  https://review.openstack.org/8969420:51
ijwIf you have a cloud of Ironic servers, then you can usually afford to be without one for as long as it takes for someone to go and repair the interface.  It's not the same as it would be with a normal single-purpose server, where that may be the only server you have that does that job and anything to keep it going a bit longer is valudable20:51
ijwchuckC: Yes, a feature, but one that isn't a core feature - that's all I'm saying.20:51
ijwAs in we're not in the territory of 'neither Ironic nor Neutron will be fit to use until this is fixed'20:51
*** Sukhdev has joined #openstack-neutron20:52
*** sballe has joined #openstack-neutron20:52
chuckCijw: sure.  I believe it's a feature TripleO wants to offer.20:52
*** VijayB_ has quit IRC20:52
*** nlahouti has joined #openstack-neutron20:53
ijwchuckC, salv-orlando: OK, looking at just the first section of that spec I have two problems so far:20:56
*** paraa has quit IRC20:56
*** VijayB has joined #openstack-neutron20:56
chuckCijw: it's a deployment issue for them.  They will be using the baremetal node to deploy other stuff, so if that particular one fails due to an interface problem, it messes up a lot of the deployment.20:56
*** yamamoto has joined #openstack-neutron20:57
ijw1. boot is entirely and completely separate from link aggregation - you may want to connect multiple interfaces to your boot network but you don't need to aggregate them at all (and in fact agg would be counterproductive since it doesn't work)20:57
*** marun has joined #openstack-neutron20:57
ijw2. aggregation in its entirety is not specific to Ironic, it works just fine with VMs as well (with various degrees of utility) and I suggest that part of the spec is rewritten to remove the word 'ironic'.20:58
*** toMeloos has left #openstack-neutron20:58
ijwchuckC: If you bring up a machine with a faulty interface how do you avoid using the interface when it's up?20:58
ijwActually, let me rephrase that.  If you have a faulty NIC, is it better to work around the faulty NIC, or to use a different server because that one's broken and get someone to fix it?20:59
ijwBearing in mind that as long as your cloud is not *full*, the latter is essentially free.20:59
chuckCijw: yes, it's separate, but there is a common requirement.  And yes, aggregation is not specific to Ironic, but both Ironic and TripleO will work better if boot can work in the face of a NIC failure.20:59
ijwActually I don't think the requirement is common at all.21:00
ijwYou can boot in the face of a NIC failure by linking two NICs to a single network21:00
*** markmcclain has joined #openstack-neutron21:00
ijw(and boot from whichever one you get a DHCP request through for)21:00
*** pcm_ has left #openstack-neutron21:00
*** nlahouti has quit IRC21:01
ijwno agg required.  Which is just as well because installers don't support it and it's not in the PXE spec.21:01
chuckCI need to confirm with those teams, but I believe the selection of node is done via template, so there may not be flexibility to choose another.21:01
*** scott-millward has joined #openstack-neutron21:01
ijwchuckC: Umm, you're saying in a cloud based system that you're deploying an image to a specific machine and it won't work on any other?21:01
*** WackoRobie has quit IRC21:02
chuckCijw: There's a heat template that specifies which HW to use for which purpose.21:02
*** harlowja is now known as harlowja_away21:02
*** nlahouti has joined #openstack-neutron21:03
ijwI presume it specifies the requirements of the hardware, not a specific machine21:03
*** WackoRobie has joined #openstack-neutron21:03
ijwAnyway, I would absolutely split the thing down the middle - how to boot, which has a different network arrangement from what you might use when the machine is up.  You can make either thing fault tolerant independent of the other and there's really no need to tie the two things together at all21:03
ijw(although clearly you'd normally want to use both)21:03
chuckCijw: since it' a deployment scenario, it doesn't make sense to specify backup servers when it's a one-time operation.21:03
ijwThe reason I'd keep it separate is that your implementation will be a lot more focussed that way21:03
ijwThere's no overlap to speak of between the two things21:04
ijwchuckC: I think I'm missing something here - if the deployment fails wouldn't you take the server out of service and then reschedule?21:04
chuckCijw: you wouldn't want to fail the deployment of 500 servers because a single interface card failed.21:05
openstackgerritA change was merged to openstack/neutron: NSX: properly handle floating ip status  https://review.openstack.org/10321421:05
*** SumitNaiksatam has joined #openstack-neutron21:06
*** WackoRobie has quit IRC21:07
chuckCijw: I clearly need to document the flow here so we can have a better discussion of all this.21:07
chuckCijw: please comment in the document so your issues can be captured!21:08
chuckCijw: Thanks for all the discussion here!21:09
anteayaSukhdev: can you hang out in irc after the meeting? I need to talk to you21:10
Sukhdevanteaya: yes, sure21:10
anteayathanks21:11
*** jp_at_hp has quit IRC21:11
*** TrevorV_ has quit IRC21:11
ijwchuckC: I might be a bit blunt in the comments.  Nothing personal, I'm just reading this and I don't think there's a good train of thought here.21:13
*** jecarey has joined #openstack-neutron21:14
ijwYou need to be clear about the problem you *are going to solve* not the problems that *you might at some point solve in the future* because a spec needs to be a definitive statement of work, a set of work to do that entirely answers the problem description it specifies.21:14
*** zhhuabj has joined #openstack-neutron21:18
ijwPrimarily I would suggest two things:21:19
ijw1. write a separate spec for boot21:19
*** alagalah_ has joined #openstack-neutron21:20
ijw2. assume Neutron will change the switch config, stop trying to write a spec where you adapt to the switch config21:20
*** AbsinthMind has joined #openstack-neutron21:20
ijw(clearly it will change switch config because otherwise you can't have Ironic and programmable network ports)21:20
*** AbsinthMind has left #openstack-neutron21:23
*** kakuma has joined #openstack-neutron21:24
*** alagalah has quit IRC21:24
ijwchuckC: Actually I'm just discussing a cloud-init format for network information, which is where you'd want to carry that link agg stuff over to the guest OS21:24
*** jobewan has quit IRC21:25
*** radez is now known as radez_g0n321:26
*** networkstatic is now known as fatguylittleglov21:28
chuckCijw: ok, I will remove all contextual info from the spec and focus only on the immediate issue, which is resilient boot.21:30
*** dvorkinista has quit IRC21:30
*** karimb has joined #openstack-neutron21:30
ijwYup - then what I suggest you do is assume that multiple-if is fixed (spec's approved and the patch is nearly there) and then you have to do two things:21:30
ijw1. attach multiple interfaces (perhaps all of them) to one Neutron network21:31
*** WackoRobie has joined #openstack-neutron21:31
ijw2. put a boot record in for every one of those interfaces into the DHCP server21:31
ijw3. whichever one comes through, do the same thing and install the image you want.21:31
ijwtwo-ish things ;)21:31
chuckCIronic/tripleo has no way to determine which interfaces connect to the same network21:32
ijwEr.21:32
ijwI think the issue we have is a communication one.  Let me ask you a question: when is it going to become possible to configure any port on an Ironic machine to attach to any network, which is clearly the point at which it becomes a full fledged Neutron client?21:33
ijwBecause any solution you're proposing at the moment is going to suck until that is fixed.21:33
chuckCDefinitely communication issue.  How can you configure interfaces on a baremetal machine to connect to switches they don't have wires to?21:35
ijwYou don't.  You configure switches to connect them to virtual networks they're supposed to be attached to.21:35
*** WackoRobie has quit IRC21:35
chuckCDon't you still need wires going to the right switches?21:35
ijwYou need wires going to switches that are under Neutron control, yes.  (Unless you're using Cisco gear, which is strangely magical in this regard, but in general...)21:36
ijwYou've seen Kevin Benton's external attachment patch, right?21:36
chuckCSo, if an Ironic server has has interfaces to 2 completely distinct physical networks, how do you tell which interfaces are connected to which?21:37
*** dave_tucker_zzz is now known as dave_tucker21:38
ijwI assume you're thinking that an Ironic machine is permanently attached to a Neutron network with no option to change that21:38
ijwBut that's really not in keeping with Neutron's philosophy21:38
ijwchuckC: mu21:38
*** terryw has joined #openstack-neutron21:38
kevinbentonchuckC: someone had mentioned Ironic listening for LLDP at some point to provide the physical attachment information21:38
chuckCI'm just talking about how physical wires are connected.21:39
ijwkevinbenton: I think that might be wishful thinking right now (also exposing a bit too much information to the guests running on those machines)21:39
chuckCijw: ^21:39
ijwchuckC: I know you are, but when is the last time you saw a physical wire with three ends?21:40
ijwevery port from an Ironic machine is connected to a separate physical network, from it to the switch port it's plugged into21:40
ijwNow, that can be written down - it doesn't change magically - so failing anything else it can be config for Ironic21:40
ijwBut the other bit - which virtual Neutron network that switch port is connected to - is entirely programmable if you can change the switch's setup, and Neutron can do that (witness the Cisco Nexus plugin, and it's not the only example)21:41
ijwkevinbenton: Actually, now you're here, I wanted a word with you about the external attachment jobbie21:42
*** otherwiseguy has quit IRC21:42
kevinbentonijw: sure. i have to leave in about 10 minutes though21:42
kevinbentonijw: traveling atm21:42
ijwOK - so firstly I got over the point that you'll have more types of external attachment than you can possibly enumerate in the plugin so you need that bit to be extensible, right?21:43
*** terryw has quit IRC21:43
ijwkevinbenton: That aside, I was trying to understand why the port - external attachment isn't a 1:1 mapping.  Are you thinking that you would create a port for every device / a number of devices on the other side of the attachment, or are you thinking of a switch (rather than a switch port) as an attachment, or what?21:44
*** otherwiseguy has joined #openstack-neutron21:44
kevinbentonijw: yes, if there are many devices on the other side, they will each need a neutron port to get a dhcp reservation21:46
kevinbentonijw: and they are all associated with the attachment point to prevent it from being deleted or re-assigned while they exist21:46
ijwWhat if you just want to bridge to something unknown on the other side?  And what about firewalling for the attachment port?21:48
ijwI mean, I'm wondering here if it might be a master and sub-port thing that we need21:49
kevinbentonijw: that’s fine. you just won’t have any neutron ports associated with it21:49
ijwSo the attachment port itself is master (and pretty faceless - no address or MAC, but on the other hand the minimum thing you need) and then you can have subports onit.  Seems to closely relate to Erik's idea of VLAN subports, too21:50
kevinbentonijw: the external attachment assignment is what configures the port to be on the correct neutron network21:50
kevinbentonijw: the neutron port association is just to express the dependency21:50
ijwkevinbenton: OK, now I'm confused - you attach the external attachment point to a network without using a port, in that case?21:50
kevinbentonijw: yes21:50
ijwI missed that bit.21:50
kevinbentonijw: that’s why the external attachment port has a network_id field21:51
*** jordandh has quit IRC21:51
ijwI was thinking we'd use a port to make the attachment: network -> port -> external attachment21:51
*** nati_ueno has joined #openstack-neutron21:51
ijw(with, as I say, the port being fairly faceless)21:51
kevinbentonijw: no, we avoided that because it doesn’t make sense to have the port in the general L2 gateway use case since it needs  a MAC21:52
ijwWell, it needs a MAC at the moment, we can change that21:52
kevinbentonijw: a port implies an end-node21:52
kevinbentonijw: not a part of the network that provides connectivity21:53
ijwOK - which brings us back to connecting two networks together, which is always the problem with this stuff21:53
ijwOK - I see your logic and it works fine, I just need to go and think a bit more about it21:53
*** rmcall has joined #openstack-neutron21:54
*** mriedem has quit IRC21:54
kevinbentonijw: ok. i have to go now. i’m replying to a few of your comments on the patch as well21:54
kevinbentonijw: i’ll be back on later21:54
*** zz_blogan is now known as blogan21:56
ijwI'm trying mentally to draw a parallel between this and provider networks, because I think if you have this right you should be able to subsume them21:56
ijwAnd I'm fairly sure that a part of the answer is finding a solution to the VLAN breakout plans that seem to be multiplying without end21:57
ijwWhich reminds me, need to find yamahata21:57
yamahataijw: hi21:57
ijwwell hello21:58
ijwSo, VLAN trunking21:58
* ijw tries to find your spec21:58
yamahataAh I see.21:58
ijwhttps://review.openstack.org/#/c/97714/ btw, you've not reviewed the latest21:58
yamahataLet me see the diff...21:59
yamahataI understand that your modification to api doesn't conflict with other proposal.22:00
*** a_le has quit IRC22:00
ijwYeah, I wanted to look at yours again but I can't find the review now - got a link?22:01
*** a_le has joined #openstack-neutron22:01
*** banix has quit IRC22:01
yamahataI haven't given review yet. Will do today22:01
mesterysalv-orlando: Regarding https://review.openstack.org/#/c/105239/, I was confused as to you commenting on your own code, but now it makes sense.22:02
openstackgerritSubrahmanyam Ongole proposed a change to openstack/python-neutronclient: Group Policy CLI-1: EP, EPG, L2 Policy, L3 Policy  https://review.openstack.org/10401322:02
*** sgordon has joined #openstack-neutron22:02
*** alexpilotti has quit IRC22:03
*** alexpilotti has joined #openstack-neutron22:04
yamahataijw: So its okay with the api modification22:04
*** harlowja_away is now known as harlowja22:04
yamahatachuckC: ping?22:04
yamahataijw: Regarding to unaddressed-port, your proposal doens't touch any db manipulation in my understanding. Right?22:06
ijwNot intended to other than storing the flag22:07
chuckCyamahata: hi22:07
yamahataijw: So when port is created without address, actually subnet is associated to the port.22:07
chuckCyamahata: I only have a minute or two…22:07
ijwI think that it's basically portsecurity per port, really - portsecurity seems to operate on a network basis.  I couldn't remember the details of it (other than I'd looked at it a while back and decided it wasn't the right answer)22:07
*** jordandh has joined #openstack-neutron22:08
yamahatachuckC: I see. Regarding to physical-topology blueprint22:08
ijwyamahata: Yes, I wonder if I should rename that flag to something else22:08
yamahatachuckC: I think the scope of what you want to discuss is the next step. Not 1st step.22:08
yamahatachuckC: So can we move the discussion to the blueprint for the next step which I'm now preparing?22:09
chuckCyamahata: your spec, right?22:09
*** alexpilotti has quit IRC22:09
yamahatachuckC: Yes.22:09
chuckCyamahata: yes22:09
ijwyamahata: also, regarding services22:09
yamahataijw: Okay. I understand the situation. the flag name was very mis-leading.22:10
ijwyamahata: I don't understand why we're trying to incorporate service manager, service agent and so on into Neutron22:10
*** alagalah_ has quit IRC22:10
ijwWhy can't we write something trivial that sends the minimum number of messages out to an (external) service orchestrator and give it enough leeway to make sensible decisions?22:11
yamahatachuckC: thanks. when I uploaded, I'll add you as reviewer22:11
*** alagalah has joined #openstack-neutron22:11
chuckCyamahata: thanks22:11
yamahataijw: I don't follow you. Which blueprint are you talking about?22:11
*** markmcclain has quit IRC22:12
ijwhttps://docs.google.com/presentation/d/1gmuBprzedbvTQBt98JYiDFgLlTipDjr1ZgaEGL0xkcs/edit#slide=id.p22:13
ijwseems to be your founding document22:13
nlahoutirkukura: ping22:13
yamahataijw: Ah the document is stale. I should have included the date.22:14
yamahataijw: At the Atlanta summit, the consensus is to create standalone project out of neutron22:15
yamahataijw: servicevm project.22:15
yamahatahttps://wiki.openstack.org/wiki/ServiceVM22:15
yamahataijw: does it make sense?22:16
*** mestery has quit IRC22:16
ijwYes, but again, I thought you were still interested in your various components to manage VMs being an internal part of Neutron22:18
ijwAlso, that 'stale' presentation is at the very top of the Tacker page as well...22:19
*** sweston has quit IRC22:20
ijwyamahata: I think you're going the same way - you're assuming that Neutron manages the VMs, but in fact it's more likely that Neutron would be communicating with an external orchestrator that is service specific and manages the VMs and config for you22:20
yamahataijw: which component? At this point, l3-plugin for routervm and extensions for neutron ports22:20
openstackgerritArvind Somya proposed a change to openstack/neutron-specs: ML2 Type driver for Overlay Networking  https://review.openstack.org/10434122:20
ijwyamahata: I'm talking about the approach rather than any particular service22:20
yamahataijw:  I see.22:21
openstackgerritA change was merged to openstack/neutron-specs: Security group extension for PLUMgrid plugin  https://review.openstack.org/10440122:22
*** jckasper has quit IRC22:23
ijwI mean - why are you tracking and controlling VMs in Neutron?  The method of control is almost certainly specific to the VM in question and you can't use services like Heat for as long as you're running in Neutron22:23
anteayaSukhdev: you still around?22:24
*** karimb has quit IRC22:24
anteayaSukhdev: I need to ask you about the gerrit-trigger plugin22:24
yamahataijw: I assume you mean servicevm server, not neutron.22:24
anteayaSlickNik says it complied and he still can't get it to work22:25
ijw Let me put it a different way.  If I was writing a mail server for Linux, I would want Linux to offer me the APIs I need to run the server and connect to the server, but the service itself would not be a part of the kernel.  So when we're writing services in Neutron why are we making them an integrated part of Neutron (or Tacker, same thing applies)?22:25
ijwYou only need to manage the requests for services in Tacker and make that data available to the thing controlling the service.  You don't necessarily have to integrate the service in the same codebase.22:26
anteayaSukhdev: 2014-07-07T16:44:48  <SlickNik> anteaya: made the changes in config file according to the google doc as well.22:26
anteaya2014-07-07T16:45:39  <SlickNik> anteaya: But am still not able to get the gerrit trigger plugin to respond to comments based on comment content.22:26
anteayahttp://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2014-07-07.log22:26
anteayaSukhdev: can you follow up with him?22:26
ijwYou might want to make an example controller, but that's different, and doesn't have to go through the same degree of consideration and review if it isn't integrated into Openstack and isn't running on the host.22:27
ijwAnd an external controller could quite easily run as a tenant VM, with limited privileges.22:27
openstackgerritArmando Migliaccio proposed a change to openstack/neutron: Add L3 Scheduler Changes for Distributed Routers  https://review.openstack.org/8969422:28
yamahataijw: Hmm, at least such service controller is out of scope. It's up to services.22:29
*** armax has quit IRC22:29
ijwYes - and if that is the case then why do you need to implement anything relating to VMs, devices and service implementation within Tacker?22:29
ijwWhich appears to be there in the current working document, there's really quite extensive material on that subject22:30
yamahataijw: For now, the agent and its communication is low priority.22:30
ijwLook22:30
yamahataijw: for l3-plugin routervm as first PoC, it won't be addressed22:31
ijwThe spec here contains a load of commands relating to services and service VMs22:31
ijwMy point is not the priority22:31
ijwMy point is that it shouldn't be in the spec at all22:31
yamahataijw: you mean create/update/delete service instances API?22:32
ijwWell, I'm confused an fascinated that there's an API for that at all, but I mean that Openstack should know *absolutely nothing* about service instances22:32
Sukhdevanteaya: Sorry - I was pulled into a meeting22:32
Sukhdevanteaya: i thought we had solved SlickNik's issue last week22:33
*** zzelle_ has quit IRC22:33
yamahataijw: by absolutely nothing you mean openstack should not know even which service instance is running in which vm?22:34
ijwYup22:34
yamahataijw: So it's the role of a kind of orchestrator?22:35
yamahataijw: not openstack.22:35
ijwYup22:35
*** otherwiseguy has quit IRC22:35
*** pradk has quit IRC22:36
yamahataijw:  I see. Is it based on ETSI NFV standard? which may not be published yet.22:36
*** sbfox has quit IRC22:36
ijwETSI documents things in big blocks, so the standards are not always very applicable, but I think this would be a VNFM in their terminology22:36
*** oda-g has joined #openstack-neutron22:37
yamahataijw: is VNFM out of the scope of openstack?22:38
*** thedodd has quit IRC22:38
ijwYes.22:38
yamahataijw: Is it a bad idea for openstack to cover (a part of) VNFM?22:38
*** sbfox has joined #openstack-neutron22:38
ijwBecause mostly NFV solutions are run by tenants, not resold to tenants22:38
ijwIt's a terrible idea, to be honest22:38
*** bandarji has quit IRC22:39
ijwyamahata: you would expect VNFs to be brought to run on Openstack as applications.  You don't change the Openstack codebase because someone's running a new application today, and VNFs are like that22:39
ijwyamahata: what you should be writing in Openstack is a neat way to make an XaaS interface communicate its wishes to a service running in a tenant22:40
ijw(and be able to attach to other tenants, where it's been instructed to attach)22:40
ijwAnd quite honestly I think the more of that that is orchestrated *outside* of Openstack and in a tenant, the better, to be honest22:41
ijwBear in mind the prui22:42
yamahataijw: I see. maybe I need to give it a consideration22:42
ijwprimary use case for VNFs is not for reselling to tenants.  Mainly they're there just to provide services according to whatever orchestrates them, which in the NFV world will not be Openstack but higher level business logic.  We should be planning to make use of that.22:43
yamahataijw: Yeah, openstack is just internal realization. It's not what end user will face22:44
ijwErm, no, that's not really the point22:44
*** padkrish has quit IRC22:44
ijwThe point is that, in this instance, Openstack is not the lowest level of API22:44
ijwBeneath it is a service API that Openstack calls will be translated to22:44
ijwThat service API is not particularly standardised, so I would suggest a generic interface that's asynchronous and tolerant to message loss to communicate what you want the service to do from tacker22:45
yamahataHmm the API is specific to service. which can vary22:45
*** padkrish has joined #openstack-neutron22:46
ijw(and the best candidate for that is probably a data model with change notifications, which is resilient to message loss and won't hang Tacker up when it talks to the service controller)22:46
ijwSo there'd be a bit of glue code - also outside Openstack - that monitors what Tacker wants, and tells the service to do it22:46
yamahataIt sounds like a service specific driver. Since it's very service specific, you claim that it should be out of openstack. Right?22:48
*** Sukhdev has quit IRC22:52
*** pcm_ has joined #openstack-neutron22:52
openstackgerritSalvatore Orlando proposed a change to openstack/neutron: Do not mark device as processed if it wasn't  https://review.openstack.org/10523922:56
*** alagalah has quit IRC22:57
*** bandarji has joined #openstack-neutron22:57
*** shivharis has quit IRC22:58
ijwyamahata: we have a terminology issue (or at least I do) - it's specific to the service implementation.22:58
ijwyamahata: I would expect there to be a piece of code inside Openstack specific to the service type (like L3, for instance)22:59
ijwyamahata: and then, independently, something outside of Openstack that implements that service using whatever VMs it chooses (or potentially even hardware, since if we do it this way that outside controller can do whatever it likes) - and that would be service implementation specific23:00
ijwyamahata: that works providing you lay down a set of rules for what the interface between the two looks like in general, plus some quite details specifics per service type23:00
ijwyamahata: but the Openstack side shouldn't have any implementation-specific code in it at all - anyone could come along and implement a new service implementation without requiring changes to core Openstack code23:01
*** armax has joined #openstack-neutron23:02
ijwyamahata: Then your primary API for services is probably 'neutron service-register <service-type> <orchestrator-ip>'23:02
*** Sukhdev has joined #openstack-neutron23:02
ijwyamahata: I'm told you were moving over here - have you arrived yet or are you still in Japan?23:02
*** mlavalle has quit IRC23:08
*** a_le_ has joined #openstack-neutron23:08
*** a_le has quit IRC23:08
*** crc32 has quit IRC23:11
openstackgerritArmando Migliaccio proposed a change to openstack/neutron: Add L3 Scheduler Changes for Distributed Routers  https://review.openstack.org/8969423:11
*** crc32 has joined #openstack-neutron23:14
*** yfried__ has quit IRC23:14
*** mestery has joined #openstack-neutron23:19
*** jp_at_hp has joined #openstack-neutron23:19
*** jp_at_hp has quit IRC23:19
*** jp_at_hp has joined #openstack-neutron23:19
*** yamamoto has quit IRC23:21
*** mestery has quit IRC23:24
*** trad511 has quit IRC23:25
*** bandarji has quit IRC23:27
*** banix has joined #openstack-neutron23:27
openstackgerritArmando Migliaccio proposed a change to openstack/neutron: Add L3 Scheduler Changes for Distributed Routers  https://review.openstack.org/8969423:27
*** padkrish has quit IRC23:29
*** padkrish has joined #openstack-neutron23:33
*** yfried__ has joined #openstack-neutron23:33
*** dims has quit IRC23:37
*** ijw has quit IRC23:39
openstackgerritMandeep Dhami proposed a change to openstack/neutron-specs: Initial version of Neutron Service Chaining Specification  https://review.openstack.org/9352423:43
*** scott-millward has quit IRC23:48
*** scott-millward has joined #openstack-neutron23:48
openstackgerritArmando Migliaccio proposed a change to openstack/neutron: Add L3 Scheduler Changes for Distributed Routers  https://review.openstack.org/8969423:50
*** yamamoto has joined #openstack-neutron23:53
*** a_le has joined #openstack-neutron23:53
*** a_le_ has quit IRC23:53
anteayaSukhdev: yes, well it appears SlickNik has implemented your changes, but doesn't yet see the results he is looking for23:54
*** jp_at_hp has quit IRC23:54
*** gabriel-bezerra has quit IRC23:54
anteayaSukhdev: can you talk to him about it?23:54
*** jp_at_hp has joined #openstack-neutron23:55
*** seizadi has joined #openstack-neutron23:56
*** xgerman has quit IRC23:56
*** dims has joined #openstack-neutron23:57
*** Sukhdev has quit IRC23:58
*** gabriel-bezerra has joined #openstack-neutron23:58

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