Wednesday, 2016-09-07

*** diogogmt has joined #openstack-fwaas00:37
*** njohnsto_ has joined #openstack-fwaas02:16
*** njohnsto_ has quit IRC02:18
*** njohnsto_ has joined #openstack-fwaas02:19
*** vishwanathj has quit IRC02:54
*** mickeys has quit IRC03:17
*** njohnsto_ has quit IRC03:30
*** SarathMekala has joined #openstack-fwaas03:43
*** chandanc has joined #openstack-fwaas03:48
*** mickeys has joined #openstack-fwaas03:58
*** SridarK_ has joined #openstack-fwaas03:59
*** yushiro has joined #openstack-fwaas03:59
*** padkrish has joined #openstack-fwaas04:00
*** mickeys has quit IRC04:03
yushiropadkrish: Can we discuss about L2-agent?04:59
padkrishyushiro: sure04:59
padkrishfirst one, i am looking at now:05:00
padkrishhttps://review.openstack.org/#/c/323971/6/neutron_fwaas/services/firewall/agents/v2/l2/extensions/fwaas.py line 10005:00
*** SarathMekala is now known as SarathMekala_brb05:01
padkrishSo, we will be calling the plugin RPC for getting the fwg_id05:01
yushiropadkrish: At first, thanks for your e-mail :)05:01
padkrishyushiro# np, the least i could do at this time :)05:03
yushiropadkrish: OK. so, go back to your word..  Yes. we should get firewall-group-id at this timing.05:04
yushiropadkrish: In order to apply firewall-rules05:04
yushiroto the port.05:04
padkrishyes, am taking a shot at that05:05
yushiroHowever, 'port' of an argument doesn't include 'firewall-group' guys.05:06
padkrishand also based on IP address of the port, we should query the firewall address group ID, right? Or are we deferring that for now?05:06
padkrishyes, i dumped that...05:06
padkrish{u'profile': {}, u'network_qos_policy_id': None, u'qos_policy_id': None, u'allowed_address_pairs': [], u'admin_state_up': True, u'network_id': u'99ef5e31-e626-41e7-8095-39f9600c9442', u'segmentation_id': None, 'vif_port': <neutron.agent.common.ovs_lib.VifPort object at 0x7fdb9da206d0>, u'device_owner': u'network:dhcp', u'physical_network': None, u'mac_address': u'fa:16:3e:d6:c4:e8', u'device': u'ed9307d3-5191-44f6-aa1a-e5705:07
padkrish67ba54cee', u'port_security_enabled': False, u'port_id': u'ed9307d3-5191-44f6-aa1a-e5767ba54cee', u'fixed_ips': [{u'subnet_id': u'cc58fb01-f138-4bae-a34a-7c0e54870f1a', u'ip_address': u'10.0.0.2'}], u'network_type': u'local', u'security_groups': []}05:07
padkrishthis is the port data05:07
yushiropadkrish: thanks.  Regarding address_group_id, it is also necessary.  but this value is in the future.05:09
padkrishok05:10
padkrishshould we modify lines 53-59 and use regular RPC instead of versioned objects or can we continue with versioned objects?05:11
yushirohmm, if we use regular RPC, it is necessary to add some patch into neutron-side.05:13
yushiroWe use L2-agent extension, I think L53-59 is not necessary to modify.05:14
yushiroIf anything, we should extend 'firewall_group_id' in 'port' object and enable to insert 'firewall_group_id' into the return value from get_device_details.05:16
yushiroI'd like to sync with you at this point.05:17
yushiro(maybe 1 month ago, you've already mentioned about it :)05:17
yushiroHowever, we should clear the association b/w "port" and "firewall_group".05:18
padkrishi agree that's easiest and also modular... but that means modification in neutron RPC. And, it FWaaS is planning to be independent, isn't it?05:18
padkrishthat's we call another RPC to the FWaaS plugin05:18
yushiroah, OK. I see. sorry, I was confused .05:20
padkrishno worries at all....05:20
padkrishL2 agent extension is for port notification, for FW notification like policy, rule updates etc. we need either versioned objects or RPC from plugin to L2 agent extension05:21
yushiroyes.05:25
padkrishso, that's why asked about lines 53-5905:27
yushiroI see. thanks.05:28
yushiroHmm, padkrish, I'm still not clear.  please let me clarify05:31
padkrishok, sure..go ahead05:32
yushiroIn l2-agent, we should trigger 'port' create/update/delete.05:32
yushiroAnd also trigger firewall-group/rule/policy   create/update/delete.05:33
padkrishyes...05:33
yushiroand we should prevent neutron-side fix.05:34
padkrishyes05:35
yushiroOk, so, go back your opinion.05:38
yushiro1. another RPC to the FWaaS plugin ,  2. continue with versioned objects.05:39
yushiroRegarding 1., is it the way which njohnston has tought us on e-mail?05:39
padkrishyes....he has pointed us to L3 agent RPC example..05:41
yushiroOK. I understood.  How about 2. ?05:41
padkrishfor 2. either we continue with versioned objects or use RPC mechanisms like L3 agent05:44
padkrishsince versioned object hasn't merged, in order to make fast progress, i am thinking, we can follow L3 agent and then refactor this code, when versioned object is available.05:45
padkrishwhat do you think?05:45
yushiropadkrish: I agree with you because versioned object is necessary not only L2-agent but L3 one.05:46
padkrishok05:47
padkrishand regarding driver05:49
padkrishlines 44-45, we need to integrate with driver patch05:50
padkrishhave you tried integrating that for L3?05:55
yushirono I haven't.05:55
yushiroRegarding L44,45 I was given from chandanc about driver's interface information.05:57
yushiroYes, we need to integrate05:57
padkrishL3 agent would have already done that, right?05:58
padkrishDidn't get a chance to go through that patch in detail :(05:58
yushirojust a moment, please.05:58
yushiroI think so. I'll build today's latest devstack.06:00
padkrishok06:01
padkrishok, let me also look at the patch06:01
padkrishthat's it from my side...06:02
yushiropadkrish: I'll try to implement L3-agent  mech for L2 first, and check.  However, I have 1 wondering point.06:02
padkrishok06:03
yushiroIn case of 'port' create/update,  we should specify 'firewall_group_id' at that time.06:03
yushiroIn other words, 'firewall_group_id' should be displayed into port-show result.06:03
yushirolike qos_policy_id06:03
padkrishyes, it belongs to default one, i think, if not specified?06:06
yushiroYeah. if not specified, default firewall group should be applied.06:06
yushiroSo, in order to control from port, we should add more patch as extension, shouldn't we?06:07
padkrishhmmm...sorry, can you elaborate more? what patch should be added?06:08
yushiropadkrish: I think we should extend 'port' attributes_map like as follows:06:11
yushirohttps://github.com/openstack/neutron/blob/master/neutron/extensions/qos.py#L11606:12
yushiroI'm not sure that we can achieve this(enable to specify firweall-group-id from port)in fwaas repos.06:13
*** amotoki has joined #openstack-fwaas06:14
padkrishoh ok...06:16
yushiroping amotoki06:20
padkrishok, yushiro...bye, will chat later06:21
yushiropadkrish: OK. thanks.06:21
amotokiyushiro: pong06:21
yushiroamotoki: Hi, I have 1 quick question.06:21
amotokiyushiro: what?06:22
yushiroI'd like to specify 'firewall_group_id' like 'qos_policy_id' on port.06:23
yushiroRegarding QoS, following EXTENDED_ATTRIBUETS_2_0 has been used:06:24
yushirohttps://github.com/openstack/neutron/blob/master/neutron/extensions/qos.py#L11606:24
yushiroDo you know that is this definition also valid even if fwaas repos?06:26
yushiros/fwaas repos/other neutron repos06:26
*** padkrish has quit IRC06:29
amotokiyushiro: yes. it's possible.06:38
amotokiyushiro: note that the firewall plugin is responsible to populate additional attributes though.06:39
yushiroamotoki: Thanks a lot!07:06
yushiroamotoki: sorry. I was calling from my manager..07:06
*** yushiro is now known as yushiro_afk07:37
*** mickeys has joined #openstack-fwaas08:55
*** mickeys has quit IRC08:57
*** yushiro_afk has quit IRC09:22
*** chandanc has quit IRC10:58
*** amotoki has quit IRC11:06
*** SarathMekala_brb has quit IRC11:13
*** amotoki has joined #openstack-fwaas11:37
*** amotoki has quit IRC11:50
*** amotoki has joined #openstack-fwaas11:58
*** amotoki has quit IRC12:07
*** amotoki has joined #openstack-fwaas12:33
*** ntt has joined #openstack-fwaas12:36
nttHi, using the fwaas plugin it is possible to do a rule like: 192.168.177.10:2222 -> 10.0.0.5:22, where 192.168.177.10 = external gateway on the router (first ip of the the floating network range, assigned to an interface in the qrouter namespace) and 10.0.0.0/24 = tenant private network??12:36
*** vishwanathj has joined #openstack-fwaas13:11
*** diogogmt has quit IRC14:17
xgermanntt this looks like port rewriting we are more doing accept, reject, drop of packages but not rewriting them at the moment14:18
xgermanon the other hand the LBaaS project can do that if it’s tcp but not sure how well ssh proxying would work ;-)14:19
njohnstonFYI all: https://review.openstack.org/#/c/363967/14:50
*** SarathMekala has joined #openstack-fwaas14:51
*** amotoki has quit IRC14:56
*** diogogmt has joined #openstack-fwaas15:04
*** diogogmt has quit IRC15:15
*** diogogmt has joined #openstack-fwaas15:19
SridarK_ntt: hi15:31
SridarK_on ur question above  - u can have a rule in this manner, but the rules are applied on the qr- i/f15:32
*** chandanc has joined #openstack-fwaas15:33
SridarK_one thing to be careful abt is to ensure that addresses u refer to - there is no ambiguity due to NAT (post or pre)15:33
SridarK_this could pose an issue15:34
SridarK_njohnston: thx15:34
SridarK_i will add myself to 36396715:34
*** chandanc has quit IRC16:02
*** diogogmt has quit IRC16:46
*** _SarathMekala_ has joined #openstack-fwaas17:01
*** SarathMekala has quit IRC17:04
*** mickeys has joined #openstack-fwaas17:12
*** chandanc has joined #openstack-fwaas17:14
*** chandanc has quit IRC17:36
*** SarathMekala has joined #openstack-fwaas17:55
*** _SarathMekala_ has quit IRC17:58
*** diogogmt has joined #openstack-fwaas17:59
*** SarathMekala has quit IRC18:15
*** mickeys has quit IRC18:43
njohnstonSridarK_: SridarK_: Quick question for you.  Right now if you look at the fwaas reno notes, there is nothing at all that mentiones FWaaS v2 at all.  I was thinking about writing one to say 'introducing FWaaS v2.0' (with 2.1 being when we integrate the L2 component etc. and flesh out the spec).19:07
njohnstonThat being said, what would you list as the 'features' of what we have implemented as distinct from FWaaS v1?  Just that we have implemented the core FWaaS v2 engine for L3, and achieved rough feature parity with FWaaS v1?19:07
SridarK_njohnston: and also that we have moved to being able to apply on ports19:08
SridarK_so it is easier to move across L3 and L2(eventually)19:08
SridarK_in addition to what u say19:09
SridarK_also that we are aligned to using the L3Agent Ext framework19:09
njohnstonSo it would be correct to say we apply on router ports - and then when the L2 work lands that will change from 'router ports' to just 'any ports'?19:09
SridarK_i think we can say, eventually in addition to L3 Ports we can also apply on VM ports19:10
njohnstonI think a release note should only cover what a user can do wit the software at that time, not projected future uses; it's not that kind of document.  If I was an operator, I would definitely not want to see anything stated in the future tense in a release note.19:11
SridarK_ah ok agree19:12
mfranc213 fwiw i don't really have that sensibility19:12
mfranc213sorry, i'm lurking.19:12
SridarK_:-)19:12
SridarK_i think if we can word it so that we convey that ports but is is only L3 today and easy to support to L2 using the same API19:13
SridarK_but u are correct in that release notes cover what we are shipping19:14
njohnstonOK, I created https://review.openstack.org/366916 - hopefully that can be a jumping-off point for discussion19:19
SridarK_ok19:21
*** lnicolas has joined #openstack-fwaas19:29
*** lnicolas has quit IRC19:41
*** lnicolas has joined #openstack-fwaas19:42
*** mickeys has joined #openstack-fwaas20:13
*** mickeys has quit IRC20:18
*** lnicolas has quit IRC20:32
*** lnicolas has joined #openstack-fwaas20:34
*** mickeys has joined #openstack-fwaas20:38
*** vishwana_ has joined #openstack-fwaas20:51
*** vishwanathj has quit IRC20:52
*** diogogmt has quit IRC23:24

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