Thursday, 2013-12-26

« Wednesday, 2013-12-25 Index Friday, 2013-12-27 »
*** WackoRobie has joined #openstack-neutron00:04
*** bvandenh has quit IRC00:44
*** gongysh has quit IRC01:03
*** yamahata has joined #openstack-neutron01:14
*** yamahata has quit IRC01:30
*** harlowja_away is now known as harlowja02:00
*** ljjjustin has joined #openstack-neutron02:17
*** zzelle has quit IRC02:17
*** alexpilotti_ has joined #openstack-neutron02:26
*** yamahata_ has joined #openstack-neutron02:26
*** alexpilotti has quit IRC02:33
*** geekinutah has quit IRC02:34
*** yamahata__ has quit IRC02:34
*** alexpilotti_ is now known as alexpilotti02:34
*** geekinutah has joined #openstack-neutron02:42
*** liudong has joined #openstack-neutron02:53
*** liudong has quit IRC03:10
*** notel has joined #openstack-neutron03:17
*** Jianyong has joined #openstack-neutron03:34
*** harlowja is now known as harlowja_away03:55
*** jecarey has joined #openstack-neutron03:56
*** harlowja_away has quit IRC04:09
*** markwash has joined #openstack-neutron04:14
*** notel has quit IRC04:21
*** chandankumar has joined #openstack-neutron04:30
*** markwash has quit IRC04:42
*** amritanshu_RnD has joined #openstack-neutron04:47
openstackgerritJianing Yang proposed a change to openstack/neutron: Implement basic functionalities for port forwarding  https://review.openstack.org/6051204:51
*** markwash has joined #openstack-neutron05:15
*** WackoRobie has quit IRC05:25
*** Jianyong has quit IRC05:37
*** Jianyong has joined #openstack-neutron05:37
*** yfried has joined #openstack-neutron05:43
*** markwash has quit IRC05:52
*** dguitarbite has joined #openstack-neutron06:10
*** dguitarbite__ has joined #openstack-neutron06:11
*** ljjjustin has quit IRC06:22
*** ljjjustin has joined #openstack-neutron06:23
*** ljjjustin has quit IRC06:29
*** ljjjustin has joined #openstack-neutron06:30
*** gongysh has joined #openstack-neutron06:34
*** evgenyf has joined #openstack-neutron06:34
openstackgerritJenkins proposed a change to openstack/neutron: Imported Translations from Transifex  https://review.openstack.org/6387706:36
*** liudong has joined #openstack-neutron06:56
*** evgenyf has quit IRC06:56
*** garyk has joined #openstack-neutron06:58
*** fatguylittlecoat has joined #openstack-neutron07:11
*** gongysh has quit IRC07:19
*** notel has joined #openstack-neutron07:20
openstackgerritHaojie Jia proposed a change to openstack/neutron: ValueError should use '%' instead of ','  https://review.openstack.org/6410107:26
*** amuller has joined #openstack-neutron07:37
*** notel has quit IRC07:49
*** notel has joined #openstack-neutron07:49
*** irenab_ has joined #openstack-neutron07:53
*** evgenyf has joined #openstack-neutron07:57
*** amotoki has quit IRC08:07
openstackgerritEvgeny Fedoruk proposed a change to openstack/neutron: Passing configuration name to a driver  https://review.openstack.org/6406608:11
*** dguit238 has joined #openstack-neutron08:55
*** AndreyGrebenniko has joined #openstack-neutron08:58
*** safchain has joined #openstack-neutron09:11
*** fouxm has joined #openstack-neutron09:22
*** yamahata has joined #openstack-neutron09:26
*** ljjjustin has quit IRC09:31
*** yamahata has quit IRC09:35
*** dguit238 has quit IRC09:52
*** dguitarbite has quit IRC09:52
*** dguitarbite__ has quit IRC09:52
openstackgerritYuanchao Sun proposed a change to openstack/neutron: Fix NoSuchOptError in lbaas agent test  https://review.openstack.org/6411509:52
*** vkozhukalov has joined #openstack-neutron10:04
*** vkozhukalov_ has joined #openstack-neutron10:09
*** dguitarbite_ has joined #openstack-neutron10:14
*** vkozhukalov_ has quit IRC10:15
*** vkozhukalov has quit IRC10:15
*** vkozhukalov has joined #openstack-neutron10:16
*** dguitarbite_ has quit IRC10:22
*** vkozhukalov has quit IRC10:35
*** chandankumar is now known as ciypro10:35
*** vkozhukalov has joined #openstack-neutron10:38
*** yamahata has joined #openstack-neutron10:41
*** liudong has quit IRC10:42
*** Jianyong has quit IRC10:51
*** WackoRobie has joined #openstack-neutron11:22
*** WackoRobie has quit IRC11:27
*** irenab_ has quit IRC12:03
*** bvandenh has joined #openstack-neutron12:05
openstackgerritOleg Bondarev proposed a change to openstack/neutron: Reschedule router if new external gateway is on other network  https://review.openstack.org/5288412:20
openstackgerritEvgeny Fedoruk proposed a change to openstack/neutron: Passing configuration name to a driver  https://review.openstack.org/6413912:27
*** pcm_ has joined #openstack-neutron12:43
*** pcm_ has quit IRC12:44
*** pcm_ has joined #openstack-neutron12:45
*** fouxm has quit IRC13:13
*** Jianyong has joined #openstack-neutron13:17
*** vkozhukalov has quit IRC13:24
*** amritanshu_RnD has quit IRC13:27
*** fouxm has joined #openstack-neutron14:14
*** fouxm has quit IRC14:18
*** Jianyong has quit IRC14:23
*** dguitarbite_ has joined #openstack-neutron14:25
*** alexpilotti has quit IRC14:30
*** alexpilotti has joined #openstack-neutron14:37
*** yfried has quit IRC14:39
*** alexpilotti has quit IRC14:42
openstackgerritEvgeny Fedoruk proposed a change to openstack/neutron: Passing configuration name to a driver  https://review.openstack.org/6413914:54
*** [1]evgenyf has joined #openstack-neutron14:56
*** evgenyf has quit IRC14:58
*** [1]evgenyf is now known as evgenyf14:58
*** fatguylittlecoat has quit IRC15:05
*** dguitarbite_ has quit IRC15:11
*** fouxm has joined #openstack-neutron15:15
*** fouxm has quit IRC15:19
*** fouxm has joined #openstack-neutron15:24
*** amuller has quit IRC15:24
*** fouxm has quit IRC15:28
*** ciypro has quit IRC15:40
*** amuller has joined #openstack-neutron15:40
*** salv-orlando has joined #openstack-neutron15:42
*** yfried has joined #openstack-neutron15:43
*** amuller has quit IRC15:44
openstackgerritYuanchao Sun proposed a change to openstack/neutron: Fix NoSuchOptError in lbaas agent test  https://review.openstack.org/6411515:46
*** yfried has quit IRC15:48
*** yfried has joined #openstack-neutron15:49
*** aymenfrikha has joined #openstack-neutron15:54
*** harlowja has joined #openstack-neutron16:04
*** salv-orlando has quit IRC16:09
*** salv-orlando has joined #openstack-neutron16:09
*** jaypipes has joined #openstack-neutron16:17
*** salv-orlando_ has joined #openstack-neutron16:17
*** salv-orlando has quit IRC16:22
*** salv-orlando_ is now known as salv-orlando16:22
*** aymenfrikha has quit IRC16:40
*** aymenfrikha has joined #openstack-neutron16:41
*** salv-orlando has quit IRC16:50
*** salv-orlando has joined #openstack-neutron16:51
*** evgenyf has quit IRC16:56
*** otherwiseguy has joined #openstack-neutron16:57
*** garyk has quit IRC16:58
*** salv-orlando_ has joined #openstack-neutron17:00
*** salv-orlando has quit IRC17:03
*** salv-orlando_ is now known as salv-orlando17:03
*** alexpilotti has joined #openstack-neutron17:06
openstackgerritSalvatore Orlando proposed a change to openstack/neutron: Process port_update notifications in the main agent loop  https://review.openstack.org/5742017:10
*** fouxm has joined #openstack-neutron17:14
*** yamahata has quit IRC17:30
*** yfried has quit IRC17:44
*** yfried has joined #openstack-neutron17:46
*** nati_ueno has joined #openstack-neutron17:48
*** garyk has joined #openstack-neutron17:51
*** ashaikh has joined #openstack-neutron17:52
*** harlowja is now known as harlowja_away17:55
*** yfried has quit IRC18:04
*** zz_ajo is now known as ajo18:12
*** ajo is now known as zz_ajo18:19
openstackgerritNachi Ueno proposed a change to openstack/neutron: API Extension for SSL-VPN services  https://review.openstack.org/5889718:22
*** safchain has quit IRC18:24
openstackgerritNachi Ueno proposed a change to openstack/neutron: API Extension for SSL-VPN services  https://review.openstack.org/5889718:24
*** zz_ajo is now known as ajo18:30
*** fouxm has quit IRC18:41
*** fouxm has joined #openstack-neutron18:42
openstackgerritSalvatore Orlando proposed a change to openstack/neutron: Process port_update notifications in the main agent loop  https://review.openstack.org/6418518:44
*** mlavalle has joined #openstack-neutron18:45
*** fouxm has quit IRC18:46
*** fatguylittlecoat has joined #openstack-neutron18:54
*** ajo is now known as zz_ajo18:57
*** pcm_ has quit IRC19:00
*** salv-orlando has quit IRC19:02
*** mlavalle has quit IRC19:06
openstackgerritEdward Hope-Morley proposed a change to openstack/neutron: Adds optional timeout for neutronclient  https://review.openstack.org/6118319:10
*** yfried has joined #openstack-neutron19:11
*** fouxm has joined #openstack-neutron19:12
*** fouxm has quit IRC19:14
*** fouxm has joined #openstack-neutron19:14
*** fouxm has quit IRC19:19
nati_uenoSumitNaiksatam: hi are you around?20:03
SumitNaiksatamhi nati_ueno20:03
nati_uenoSumitNaiksatam: May I ask some questions on service vm bps?20:04
SumitNaiksatamnati_ueno: yeah sure20:04
nati_uenoSumitNaiksatam: mgmt-if for LSI is List. so What are values in the List?20:04
*** pcm_ has joined #openstack-neutron20:05
SumitNaiksatamnati_ueno: looking at it20:07
nati_uenoSumitNaiksatam: Thanks20:07
SumitNaiksatamnati_ueno: we had discussed two options20:08
SumitNaiksatamnati_ueno: ip and serial port20:08
SumitNaiksatamnati_ueno: but from the current spec i guess you can't tell which one is being used20:09
SumitNaiksatamnati_ueno: is that your concern too?20:09
*** WackoRobie has joined #openstack-neutron20:09
SumitNaiksatamnati_ueno: its a list because it could be more than one management interface20:09
nati_uenoSumitNaiksatam: so ip means ip address of the port?20:09
nati_uenoSumitNaiksatam: do you have some example values?20:10
SumitNaiksatamnati_ueno: most likely ip-address:port20:10
nati_uenoSumitNaiksatam: port is eth1 or something like that? not port_id ?20:10
SumitNaiksatamnati_ueno: i meant the actual ip address and tcp/udp port number20:11
SumitNaiksatamnati_ueno: at least that was the thinking then20:11
SumitNaiksatamnati_ueno: not sure if this has evolved since then20:11
SumitNaiksatamnati_ueno: but we also wanted to allow serial ports20:11
SumitNaiksatamnati_ueno: so that will not be of the form ip-address:port20:11
nati_uenoSumitNaiksatam: hmm it sounds like mgmt-url20:11
nati_uenoSumitNaiksatam: so what's example for serial port?20:12
SumitNaiksatamnati_ueno:yeah you are right, it seems that we would need to connect to the serial port over the network as well20:14
SumitNaiksatamnati_ueno: so yeah, depending how we proxy the connection, it can be a management url like you mention20:14
nati_uenoSumitNaiksatam: For serial port, it looks like nova side should be modified as you said.. so it looks like big change.20:15
nati_uenoSumitNaiksatam: Shouldn't we separate it as independent bp?20:15
SumitNaiksatamnati_ueno: hmmm...yeah, we never discussed serial port in detail, we just thought that there should be provision20:16
SumitNaiksatamnati_ueno: i agree with you20:16
nati_uenoSumitNaiksatam: We can add an independent serial_port attribute when nova side is ready for that.20:16
SumitNaiksatamnati_ueno: i agree20:16
SumitNaiksatamnati_ueno: good to check with isaku as well as to what's the most recent thinking on this20:16
nati_uenoSumitNaiksatam: may be I'm confused with mgnt_if in service vm and LSI one20:17
nati_uenoSumitNaiksatam: I got it20:17
nati_uenoyamahata_: are you around too?20:17
nati_uenoSumitNaiksatam: Service VM has mang_if. (eth0 , eth1 ,eth2 )20:17
nati_uenoSumitNaiksatam: How this related with LSI?20:17
SumitNaiksatamnati_ueno: i think one service VM can have multiple LSIs20:18
nati_uenoSumitNaiksatam: Ok, you mean usecase2?20:19
SumitNaiksatamnati_ueno: yes20:20
SumitNaiksatamnati_ueno: in use case 1, its the same20:20
nati_uenoSumitNaiksatam: gotcha20:20
SumitNaiksatamnati_ueno: 1 service vm, one LSI20:20
nati_uenoSumitNaiksatam: so mgmt_if in Service vm and mgmt_if in LSI is different meanings?20:21
SumitNaiksatamnati_ueno: i think mgmt-if in LSI is for access over the network20:22
SumitNaiksatamnati_ueno: so like you said, url or ip-address:port20:22
SumitNaiksatamnati_ueno: i am not sure if we are considering only of the two (in which case it should be the former)20:22
nati_uenoSumitNaiksatam: Ok so it is not nic20:22
SumitNaiksatamnati_ueno: i think vm_mgmt_if is the mic (for service vm)20:23
SumitNaiksatammic -> nic20:23
nati_uenoSumitNaiksatam: i got it20:23
SumitNaiksatamnati_ueno: and i think the thinking is that multiple management service endpoints can be reached via that nic on that network20:24
*** WackoRobie has quit IRC20:24
nati_uenoSumitNaiksatam: ok20:25
SumitNaiksatamnati_ueno: although i recollect that we also discussed the case where you might want multiple nics on VM for mgmt20:25
SumitNaiksatamnati_ueno: i am not sure if its capture here20:25
nati_uenoSumitNaiksatam: gotcah20:25
SumitNaiksatamnati_ueno: because out here i only see one vm_mgmt_intf20:25
nati_uenoSumitNaiksatam: so where can we specify networks for service_vm?20:26
SumitNaiksatamnati_ueno: the original proposal was to not distinguish between mgmt and data interfaces20:26
nati_uenoSumitNaiksatam: personally, I don't like specifying eth0 or eth1 because we can't validate it20:26
nati_uenoSumitNaiksatam: for RHEL it is em0 or em120:27
SumitNaiksatamnati_ueno: yeah20:27
nati_uenoSumitNaiksatam: I prefer specifying network_id20:27
SumitNaiksatamnati_ueno: but the mgmt network might not always be a neutron network, right?20:28
nati_uenoSumitNaiksatam: I think mgmt network should be neutron network also20:28
nati_uenoSumitNaiksatam: We should register it in the model20:29
SumitNaiksatamnati_ueno: the provider of the service would create/configure the network20:29
SumitNaiksatamnati_ueno: so it might be a completely different out-of-band network20:29
nati_uenoSumitNaiksatam: yes. so even if the data plane isn't provided by the plugin, we can create network with provider extension20:30
nati_uenoSumitNaiksatam: otherwise, how we can plug it for VM?20:30
SumitNaiksatamnati_ueno: i am wondering whether it should be mandated because not every service provider might want to implement provider extension20:30
SumitNaiksatamnati_ueno: might -> might not20:31
nati_uenoSumitNaiksatam: if it is necessary, service provider should implement it.20:32
nati_uenoSumitNaiksatam: IMO, every network related with neutron should be under the management of neutron.20:32
SumitNaiksatamnati_ueno: ok20:32
nati_uenoSumitNaiksatam: Also, we should let nova support non-neutron networks20:33
nati_uenoif we allow non-neutron-managed network20:33
nati_uenoSumitNaiksatam: I'm also not sure why we should let management network as special case.20:35
nati_uenoSumitNaiksatam: so the security policy for the management url could be different for each tenant20:35
nati_uenoSumitNaiksatam: One tenant may use just floating ip and security group. and access from internet20:36
nati_uenoSumitNaiksatam: One tenant will only allow it from VPN20:36
nati_uenoSumitNaiksatam: so, IMO, we should use normal neutron network for that20:36
SumitNaiksatamnati_ueno: the vm_mgmt_if in the service VM is so that provider can configure the VM side20:38
nati_uenoSumitNaiksatam: hmm may be i'm confusing the workflow of service vm framework20:40
SumitNaiksatamnati_ueno: but how that interface gets plugged into the network is left to the provider20:40
nati_uenoSumitNaiksatam: so who creates service vms?20:40
SumitNaiksatamnati_ueno: i think the workflow is to accommodate the existing implementations as well20:41
*** banix has joined #openstack-neutron20:41
SumitNaiksatamnati_ueno: the service provider creates the service VMs20:41
SumitNaiksatamnati_ueno: the user only creates the logical service20:41
*** ashaikh has quit IRC20:42
nati_uenoSumitNaiksatam: Ah OK, so service vm is only for providers20:42
SumitNaiksatamnati_ueno: at least that was my understanding when we last discussed :-)20:42
SumitNaiksatamnati_ueno: yeah, the user only sees the logical service, and ideally does not have to know whether its a VM or a physical device20:43
SumitNaiksatamnati_ueno: and or have to manage the VM if its a VM, the service provider should do that20:43
nati_uenoSumitNaiksatam: so service_vm_id is filled up by provider after user creates LSI20:44
SumitNaiksatamnati_ueno: if a user wants to use his own VM for a service, then the responsibility to manage the VM is of the user20:44
SumitNaiksatamnati_ueno: i am not sure that user even creates LSI20:44
nati_uenoSumitNaiksatam: It looks like tenant owns the VM, so it sound's like tenant should manage it20:45
nati_uenoSumitNaiksatam: if it is not, provider should own the VMs20:45
SumitNaiksatamnati_ueno: my understanding was that the user creates the service instance, the LSI is an object managed by the service VM framework20:45
nati_uenoSumitNaiksatam: oops.. Thanks. May be, I'm reading wrong bp.20:46
nati_uenoSumitNaiksatam: Where can I check service instance model?20:46
SumitNaiksatamnati_ueno: i think i am referring to the same bp you are looking at20:47
SumitNaiksatamnati_ueno: perhaps we are interpreting the LSI differently20:47
nati_uenoSumitNaiksatam: I'm reading this one https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms20:48
nati_uenoSumitNaiksatam: there is no notion of service instance20:48
SumitNaiksatamnati_ueno: yeah, i am looking at that one20:48
SumitNaiksatamnati_ueno: i agree, i think there should be20:48
nati_uenoSumitNaiksatam: Ah, you mean, FW or LB, VPN service resources?20:49
SumitNaiksatamnati_ueno: for example, if you take firewall, the user creates a logical firewall instance20:49
SumitNaiksatamnati_ueno: yeah20:49
nati_uenoSumitNaiksatam: I got it. The things get more clear for me now20:49
nati_uenoSumitNaiksatam: Thanks20:49
SumitNaiksatamnati_ueno: the service VM framework should create a LSI to map to that firewall20:49
SumitNaiksatamnati_ueno: at least thats how i was thinking about it20:50
nati_uenoSumitNaiksatam: so all of that is internal frameworks20:50
SumitNaiksatamnati_ueno: i think what you are saying is whether LSI and that firewall service instance is that same20:50
*** otherwiseguy has quit IRC20:50
nati_uenoSumitNaiksatam: IMO, both cases can be possible20:50
nati_uenoSumitNaiksatam: We may have a new services which don't have api in the neutron20:51
SumitNaiksatamnati_ueno: true, however based on discussions my understanding was that we don't necessarily want the user to know about the VM that is realizing the service instance20:51
SumitNaiksatamnati_ueno: hence LSI would be internal to the service vm framework20:52
SumitNaiksatamnati_ueno: however, as you point out, the current google doc is not capturing this20:52
SumitNaiksatamnati_ueno: so perhaps we should discuss and clarify20:52
nati_uenoSumitNaiksatam: so What's can I do if I want apply service by vm appliance in the service chain?20:53
SumitNaiksatamnati_ueno: as a user you choose the service, and the service chain from a particular provider20:53
nati_uenoSumitNaiksatam: so if the neutron didn't provides the service api? (for example IPS/IDS)20:54
nati_uenoSumitNaiksatam: user have a vm appliance in this case20:54
SumitNaiksatamnati_ueno: the provider for the chain and/or the service will use the service vm framework to create the VM20:54
SumitNaiksatamnati_ueno: i think the user bringing in the VM appliance is a different use case20:55
SumitNaiksatamnati_ueno: for that, the user is responsible for completely managing that VM20:55
SumitNaiksatamnati_ueno: and would need to create the neutron networks, etc.20:55
nati_uenoSumitNaiksatam: Ahh I'm looking for bp for bringing in the VM appliance... so this is the source of my confusion :P20:55
SumitNaiksatamnati_ueno: we try to abstract that out if using the service vm framework20:56
SumitNaiksatamnati_ueno: good to discuss20:56
nati_uenoSumitNaiksatam: Thanks! let's me think about it20:56
SumitNaiksatamnati_ueno: sure, we can brainstorm20:57
SumitNaiksatamnati_ueno: we should include yamahata_ also20:57
nati_uenoSumitNaiksatam: It is great to know this usecase in't discussed yet, because i misunderstand the service vm framework bp20:57
nati_uenoyeah, let's discuss including yamahata_20:58
SumitNaiksatamnati_ueno: disclaimer - this is my understanding (or rather our common understanding when we had f22 discussions), but yamahata_ was not around that time, so i am not sure if he is thinking differently20:58
SumitNaiksatamf22 -> f2f20:58
nati_uenoSumitNaiksatam: Thank you for your explanation! Things get more clear for me20:59
SumitNaiksatamnati_ueno: always good to discuss with you :-)21:00
nati_uenoSumitNaiksatam: Thanks! TL21:00
SumitNaiksatamnati_ueno: ok bye21:00
openstackgerritCarl Baldwin proposed a change to openstack/neutron: Use information from the dnsmasq hosts file to call dhcp_release  https://review.openstack.org/5626321:06
*** WackoRobie has joined #openstack-neutron21:09
openstackgerritJay Pipes proposed a change to openstack/neutron: Start of new developer documentation  https://review.openstack.org/6420521:10
SumitNaiksatamnati_ueno: i think per the bp we are looking for the mapping between the "servo" and the "LSI"21:11
openstackgerritJay Pipes proposed a change to openstack/neutron: Start of new developer documentation  https://review.openstack.org/6420521:11
*** dims has quit IRC21:20
openstackgerritCarl Baldwin proposed a change to openstack/neutron: Remove release_lease from the DHCP driver interface  https://review.openstack.org/5628521:20
openstackgerritJay Pipes proposed a change to openstack/neutron: Start of new developer documentation  https://review.openstack.org/6420521:22
*** dims has joined #openstack-neutron21:22
*** ashaikh has joined #openstack-neutron21:42
*** banix has quit IRC21:43
*** otherwiseguy has joined #openstack-neutron22:16
openstackgerritJay Pipes proposed a change to openstack/neutron: Start of new developer documentation  https://review.openstack.org/6420522:24
*** salv-orlando has joined #openstack-neutron22:30
*** mlavalle has joined #openstack-neutron22:30
*** dims has quit IRC22:31
*** zz_ajo is now known as ajo22:36
*** dims has joined #openstack-neutron22:47
*** clev has joined #openstack-neutron22:51
*** WackoRobie has quit IRC23:00
*** WackoRobie has joined #openstack-neutron23:00
*** jog0 has quit IRC23:05
*** jog0 has joined #openstack-neutron23:05
*** otherwiseguy has quit IRC23:15
*** alexpilotti has quit IRC23:19
« Wednesday, 2013-12-25 Index Friday, 2013-12-27 »

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