| *** amotoki_away is now known as amotoki | 00:23 | |
| *** cuongnv has joined #openstack-fwaas | 00:59 | |
| *** SridarK has joined #openstack-fwaas | 02:06 | |
| SridarK | reedip: hi | 02:06 |
|---|---|---|
| SridarK | sorry just got home | 02:07 |
| reedip | Hi | 02:07 |
| reedip | I just JUST reached office | 02:07 |
| SridarK | did u guys start the discussion | 02:07 |
| SridarK | ah ok | 02:07 |
| reedip | no , but I think yushiro was also going to join | 02:07 |
| xgerman_ | hi | 02:08 |
| reedip | we are also missing yamamoto | 02:08 |
| SridarK | so can u summarize the issue for me | 02:08 |
| SridarK | xgerman_: hi | 02:08 |
| reedip | hi xgerman_ | 02:08 |
| reedip | so this is the issue | 02:08 |
| SridarK | so basically once we moved the fwaas api into neutron-lib | 02:08 |
| SridarK | although we seem to be fine | 02:08 |
| SridarK | midonet seems to have some failures | 02:09 |
| reedip | When we moved to neutron-lib's definition to https://review.openstack.org/#/c/456511/ | 02:09 |
| SridarK | is that an accurate understanding ? | 02:09 |
| reedip | midonet started failing | 02:09 |
| reedip | https://review.openstack.org/#/c/471699/ | 02:09 |
| reedip | As per yamamoto san's comments, The change seems to have a confusion between | 02:09 |
| reedip | service type constant ("FIREWALL") and the extension. ("fwaas") | 02:09 |
| reedip | so before we moved to neutron-lib, we were using FIREWALL as a constant to define the service | 02:10 |
| SridarK | yes | 02:10 |
| reedip | now if we see the base file in https://review.openstack.org/#/c/456511/22/neutron_fwaas/extensions/firewall_v2.py , you will find in line#32, we are using FIREWALL | 02:11 |
| reedip | this is also defined as a constant in https://review.openstack.org/#/c/456511/22/neutron_fwaas/common/fwaas_constants.py | 02:12 |
| reedip | but during migration to neutron-lib, the FIREWALL value was converted to fwaas | 02:12 |
| SridarK | i think the ext alias | 02:13 |
| SridarK | will return fwaas | 02:13 |
| reedip | As per yamamoto, the unit test took care of the current predicament by changing fwaas to FIREWALL https://review.openstack.org/#/c/456511/22/neutron_fwaas/tests/unit/services/firewall/test_fwaas_plugin.py@102 | 02:13 |
| reedip | such changes probably allowed FWaaS Unit tests to pass, and were in line with the changes made in the extension | 02:14 |
| SridarK | yes this is the service type to load the correct plugin | 02:15 |
| reedip | Even after the service name constant was reverted in https://review.openstack.org/#/c/471720/ , the unit tests didnt fail , although now the unit tests accepted FIREWALL instead of fwaas | 02:15 |
| SridarK | do u happen to have a pointer to the midonet logs | 02:16 |
| SridarK | with the failures | 02:16 |
| reedip | SridarK, and infact if we follow https://review.openstack.org/#/c/471720/ , midonet tests right now pass | 02:16 |
| reedip | if we execute the tests serially | 02:16 |
| SridarK | reedip: yes as u mentioned in the mtg | 02:16 |
| SridarK | now that is puzzling | 02:16 |
| reedip | Sorry, wrong link above | 02:17 |
| SridarK | in fact if this is a problem - i am pulling my hair (not that there is much there now) | 02:17 |
| SridarK | how does serial exec pass | 02:17 |
| reedip | SridarK , xgerman_ : The logs here state that Midonet passes the gate | 02:18 |
| reedip | http://logs.openstack.org/16/443416/2/check/gate-networking-midonet-python27-ubuntu-xenial/5540ce8/console.html.gz | 02:18 |
| SridarK | do u happen to have a pointer where it failed | 02:18 |
| xgerman_ | so non issue? | 02:18 |
| reedip | SrdiarK , xgerman_ Parallel Execution fails ! | 02:19 |
| reedip | serial doesnt | 02:19 |
| xgerman_ | mmh, so it’s order dependant? | 02:20 |
| SridarK | that could be | 02:21 |
| SridarK | when it fails, which test fails ? | 02:21 |
| reedip | xgerman_ could be | 02:21 |
| SridarK | reedip: v1 or v2 - any consistent pattern | 02:21 |
| reedip | SridarK : not defined. But you can easily replicate it. | 02:21 |
| SridarK | ok | 02:22 |
| reedip | You can run py27 Midonet tests for fwaas and you will see the errors coming as of now | 02:22 |
| reedip | its mainly in v1 | 02:22 |
| SridarK | So i clone midonet | 02:22 |
| reedip | SridarK , xgerman : What me and yushiro noticed was something like this : http://logs.openstack.org/16/443416/2/check/gate-networking-midonet-python27-ubuntu-xenial/5540ce8/console.html.gz#_2017-06-08_06_36_52_192427 | 02:22 |
| SridarK | and do run py27 | 02:23 |
| reedip | Duplicate extension is already loaded and therefore the extension is not reloaded | 02:23 |
| reedip | SridarK : yes, that would work | 02:23 |
| reedip | SridarK : you can also run fwaas specific tests like | 02:23 |
| reedip | " tox -v -e py27 midonet.neutron.tests.unit.test_extension_fwaas" | 02:24 |
| reedip | That would reduce the number of test cases and generally fails in my checkout | 02:24 |
| SridarK | yes duplicate ext would be a prob | 02:24 |
| SridarK | reedip: and the repo is ? | 02:26 |
| SridarK | sorry i have never tried anything in midonet | 02:26 |
| reedip | SridarK : IIUC the situation, it states that the extension is already loaded and therefore doenst load it again, but the loaded extension is actually not present. The false positive fails to load the extension and thus fails the extension related test cases | 02:26 |
| reedip | Sridark : just clone networking-midonet | 02:26 |
| SridarK | ah ok | 02:26 |
| *** yushiro has joined #openstack-fwaas | 02:26 | |
| SridarK | ok let me try some tonight | 02:27 |
| SridarK | my time | 02:27 |
| yushiro | morning. So sorry for late. | 02:27 |
| SridarK | yushiro: hi | 02:27 |
| yushiro | SridarK, Hi, good day | 02:27 |
| SridarK | i am not opposed to the revert | 02:27 |
| SridarK | but will be good to have some data | 02:27 |
| SridarK | reedip: do u think another day will cause a lot of pain and issue ? | 02:28 |
| xgerman_ | we had it sitting for a while so a day more shouldn’t be an issue | 02:28 |
| SridarK | ok | 02:28 |
| reedip | ok | 02:29 |
| reedip | xgerman_ SridarK , I agree, we can keep it for one more day | 02:29 |
| reedip | hi yushiro , we were just discussing the problem at hand | 02:29 |
| SridarK | reedip: thx for the context | 02:29 |
| SridarK | let me look some | 02:30 |
| SridarK | and will let u know | 02:30 |
| reedip | SridarK : yeah sure | 02:30 |
| SridarK | i will put a comment on gerrit so yamamoto is aware | 02:30 |
| reedip | ok | 02:30 |
| yushiro | reedip, OK. a cause was loading twice fwaas extension, wasn't it? | 02:30 |
| reedip | yushiro : IIUC the situation, it states that the extension is already loaded and therefore doenst load it again, but the loaded extension is actually not present. The false positive fails to load the extension and thus fails the extension related test cases . The same has been conveyed in the meeting | 02:30 |
| SridarK | we can discuss tomorrow and then if there is no obvious issue | 02:30 |
| SridarK | sorry no obvious solution - we can revert | 02:31 |
| reedip | yushiro : yes, seems to be that. On serial execution the extension is not loaded twice. | 02:31 |
| xgerman_ | fwaas loaded twice is fishy… sometimes those tests’ inheritance is pretty circular | 02:31 |
| reedip | but seems to be loaded twice on parallel execution | 02:31 |
| reedip | xgerman_ : any tool to find cross inheritance in the code without going too deep ? | 02:31 |
| xgerman_ | sorry, I just use pycharms “Find Definition” repeatedly | 02:32 |
| reedip | what you say may be possible because of the test cases loading up the same file twice in parallel execution | 02:32 |
| reedip | how do we use that xgerman_ ? | 02:32 |
| xgerman_ | I remember when I added something I had to be pretty surgical in overriding | 02:33 |
| xgerman_ | well, it just goes to the superclass’s definition and you can trace it by hand | 02:33 |
| SridarK | and also why we dont see it in the fwaas repo is another thing | 02:34 |
| reedip | SridarK : I saw it earlier in the fwaas repo but the Unit test change may have hidden it | 02:35 |
| SridarK | hmm oh u did | 02:35 |
| reedip | I did see it | 02:35 |
| SridarK | what u pointed earlier L#102 ? | 02:35 |
| SridarK | reedip: ^^ | 02:35 |
| reedip | but after making the Unit test plugin similar to the firewall extension, the issue didnt occur | 02:35 |
| reedip | SridarK : yes | 02:35 |
| SridarK | ok | 02:36 |
| SridarK | thx reedip tht is good info | 02:36 |
| xgerman_ | +1 | 02:37 |
| reedip | I think this issue may b visible in https://review.openstack.org/#/c/421472/29 right now as well, if I am correct | 02:38 |
| reedip | this was the older patch from Nate | 02:38 |
| xgerman_ | k | 02:39 |
| SridarK | ok | 02:39 |
| SridarK | let me do some digging too a bit later tonight | 02:40 |
| reedip | yushiro , if you have time, lets discuss more on this. SridarK, xgerman_ I guess its already late for you so if you would like to continue the discussion today evening ( our side) /tomorrow morning( your side ) , then let us know | 02:40 |
| reedip | xgerman_ : I will try the pycharms | 02:40 |
| yushiro | reedip, sure. | 02:40 |
| SridarK | reedip: yes that is good idea | 02:40 |
| SridarK | i will step away for sometime but will look at the logs | 02:41 |
| yushiro | Now I'm digging into midonet/neutron/tests/unit/test_extension_fwaas.py | 02:41 |
| SridarK | and also shoot me an email if u find something | 02:41 |
| reedip | ok ... | 02:41 |
| SridarK | thx | 02:41 |
| xgerman_ | same — I will check back tomorrow morning… | 02:41 |
| reedip | lets put our points in the email and on this channel | 02:41 |
| yushiro | thanks reedip | 02:43 |
| *** yushiro is now known as yushiro_lunch | 03:02 | |
| *** SarathMekala has joined #openstack-fwaas | 03:05 | |
| *** SridarK has quit IRC | 03:44 | |
| *** yushiro_lunch is now known as yushiro | 03:48 | |
| *** yamamoto has joined #openstack-fwaas | 03:57 | |
| reedip | yushiro , hi. It seems midonet is not able to get the proper plugin for Firewall in midonet/neutron/services/logging_resource/plugin.py | 04:32 |
| reedip | Line#173 | 04:32 |
| yushiro | fw_plugin = directory.get_plugin(const.FIREWALL) f_log_info['firewall'] = fw_plugin.get_firewall(context, f_log_info['firewall_id'], fields=['id', 'tenant_id']) | 04:35 |
| yushiro | directory.get_plugin(const.FIREWALL) | 04:35 |
| yushiro | is fishy | 04:35 |
| yushiro | +1 | 04:36 |
| reedip | yamamoto is online, maybe he can also help ? | 04:36 |
| *** SarathMekala has quit IRC | 04:37 | |
| yushiro | yamamoto, ping | 04:37 |
| reedip | yushiro : can we check if extension is loaded , before the plugin loads the extension ? | 05:04 |
| amotoki | yushiro: do you see +2 right in neutron-fwaas-dashbaord like https://review.openstack.org/#/c/475965/ ? | 05:05 |
| yushiro | reedip, I'll try it. Just a moment. | 05:05 |
| amotoki | yushiro: I expect I see +2 button as horizon-core but I don't see +2 button though.... so i would like some others to check it. | 05:05 |
| yushiro | amotoki, just a moment... | 05:06 |
| yushiro | amotoki, Yes, I have +2 right. | 05:06 |
| amotoki | yushiro: hmm... what is happening to me.... self-patch??? | 05:06 |
| yushiro | amotoki, If this patch is self-patch, you can put +2... I could it in networking-fujitsu repos. | 05:07 |
| yushiro | that's strange situation.. | 05:07 |
| amotoki | yushiro: I think so too. we can usually put +2 to self-patch | 05:08 |
| amotoki | yushiro: could you approve that one? it is simple enough and part of initial setup works. there is no problem. | 05:08 |
| amotoki | yushiro: i will ask it in the infra channel. | 05:08 |
| yushiro | amotoki, OK. | 05:09 |
| yushiro | amotoki, +A is OK? | 05:09 |
| amotoki | yushiro: yes, please | 05:09 |
| yamamoto | yushiro: pong | 05:09 |
| yushiro | amotoki, done | 05:10 |
| amotoki | yushiro: thanks. | 05:11 |
| amotoki | yushiro: in addition, I suddenly see +2 button now. somehow strange, but it is okay now. | 05:11 |
| yushiro | amotoki, that's fine :) | 05:11 |
| yamamoto | yushiro: reedip: i read the back log but i'm not sure what i can help. can you explain? | 05:13 |
| *** cuongnv has quit IRC | 05:14 | |
| yamamoto | it's more than two weeks. can you consider to revert? https://review.openstack.org/#/c/471699/ | 05:16 |
| yushiro | yamamoto, still discussing. Currently, I'm reading networking-midonet and test result. Maybe it loads twice for fwaas extension. | 05:18 |
| yamamoto | btw, we're going to disable tests to unblock the gate. https://review.openstack.org/#/c/475245/ | 05:18 |
| yamamoto | discussing what? | 05:18 |
| *** cuongnv has joined #openstack-fwaas | 05:19 | |
| yamamoto | i don't see any point to keep it broken. | 05:20 |
| yushiro | ah, reverting patch will approve it but need to know why fails networking-midonet. | 05:23 |
| reedip | yamamoto : we agree that keeping it broken doenst make sense but we are trying to find the cause of the issue. We would likely revert the whoile change but we also need to push for migration to neutron-lib. | 05:23 |
| reedip | In order to avoid the same issue to occur again, we would like to knoe why networking-midonet fails | 05:24 |
| yushiro | we're discussing what is the next approach after merging reverting patch. | 05:24 |
| yushiro | yamamoto, yes. reedip says what I'd like to say. | 05:24 |
| yamamoto | what's wrong with reverting it, and then investigate? | 05:24 |
| reedip | yamamoto : nothing wrong. The revert will probably get the votes today evening. we have discussed the same in yesterday's meeting | 05:25 |
| reedip | we are inclined to fix the midonet issue soon, do not get us wrong :) | 05:26 |
| yamamoto | ok | 05:26 |
| yamamoto | wrt why it fails, | 05:26 |
| yamamoto | 1. service type mismatch | 05:27 |
| yamamoto | 2. race in midonet reedip mentioned (i'm not sure what it is) | 05:27 |
| yamamoto | anything else known? | 05:27 |
| reedip | yamamoto : the directory.get_plugin( 'FIREWALL') returns None in midonet/neutron/services/logging_resource/plugin.py | 05:30 |
| reedip | We are looking at that as well | 05:30 |
| yushiro | https://github.com/openstack/networking-midonet/blob/master/midonet/neutron/services/logging_resource/plugin.py#L172 | 05:30 |
| yamamoto | it should be a consequence of the service type mismatch | 05:31 |
| yushiro | yamamoto, https://github.com/openstack/neutron-lib/commit/1331fb208330d1ca385996a716f0bc0c7ad1a07f | 05:35 |
| yushiro | boden has committed into neutron-lib as plugin common constants | 05:36 |
| yushiro | this is 'FIREWALL'. Previous name was 'fwaas'. That's a service type mismatch I think. So, in order to recover networking-midonet, should we modify service type from 'FIREWALL' to 'fwaas' ? | 05:37 |
| yushiro | I'd like to know a next approach for case "1" | 05:39 |
| yamamoto | yushiro: no. FIREWALL is correct. service type != extension alias | 05:48 |
| amotoki | 'FIREWALL' is used to look up service plugin or something. extension alias is used in the API. | 05:49 |
| yushiro | yamamoto, amotoki OK, thank you. I confused. | 06:04 |
| *** trungnv has quit IRC | 06:18 | |
| *** trungnv has joined #openstack-fwaas | 06:21 | |
| reedip | amotoki, yamamoto : do you have any idea how the Service type matches the extension ? I mean how are they related ? | 07:09 |
| yamamoto | reedip: see EXT_TO_SERVICE_MAPPING | 07:11 |
| reedip | yamamoto : this is https://github.com/openstack/neutron/blob/b40ce0759f2c2e8d957813b54146f56fb1a19cbe/neutron/plugins/common/constants.py#L31 | 07:12 |
| reedip | it maps the extension fwaas to the service FIREWALL | 07:12 |
| yamamoto | yes | 07:13 |
| reedip | yamamoto : but this doesnt map fwaas_v2 and firewallrouterinsertion | 07:16 |
| yamamoto | it isn't available for every extensions. right. | 07:17 |
| reedip | yeah, because its valid only for core extension | 07:17 |
| reedip | yamamoto : the plugin is loaded by https://github.com/openstack/neutron/blob/aeee7a5c908122074dc9c5117d5a5747fc4784d2/neutron/manager.py#L173 | 07:18 |
| yamamoto | the term "core extension" is usualy used for something different. | 07:18 |
| reedip | yamamoto : can you explain what is meant by core extension ? | 07:18 |
| reedip | it would help me understand better | 07:19 |
| yamamoto | extension for core resources | 07:19 |
| yamamoto | core resources are network, subnet, port | 07:19 |
| reedip | so network, router, ports etc | 07:19 |
| yamamoto | iirc router is not | 07:19 |
| amotoki | generally speaking, there are neutron plugins (one core plugin + one+ service plugins) and each plugin needs to declare which extension it implements. | 07:23 |
| amotoki | one extension must be implemented by only one plugin. | 07:23 |
| amotoki | MAP_TO_SERVICE_MAPPING is originaly prepared to check it. | 07:24 |
| amotoki | I think this logic can be improved to more simple one, but it is what we have now. | 07:25 |
| reedip | ok amotoki, yamamoto, thanks | 07:31 |
| reedip | let me look at the issue further. | 07:31 |
| reedip | yushiro : as per https://github.com/openstack/neutron-lib/blob/fc38a3fe8e6fa7c75572180554a02b43a72f9af9/neutron_lib/plugins/directory.py#L40 , it seems that midonet doesnt know if the Alias "FIREWALL" exists | 08:08 |
| reedip | thats why its returning NONE | 08:08 |
| yushiro | reedip, aha. So, it's better to refer ALIES in neutron-lib directly, isn't it? | 08:09 |
| yushiro | a, | 08:09 |
| reedip | yushiro : the thing is, midonet is referring the neutron-lib constants for the alias | 08:10 |
| reedip | Let me check one thing , wait | 08:10 |
| yushiro | yes. sorry I confused again ;( | 08:10 |
| reedip | yushiro : not more than me :) | 08:12 |
| reedip | the extension-service name combination is not easy | 08:13 |
| yushiro | ALIAS = 'fwaas' | 08:16 |
| reedip | yushiro : that actually works | 08:19 |
| reedip | yushiro : not sure why | 08:20 |
| yushiro | In order to refer plugin, it should be executed in advance. directory.add_plugin(fw_const.FIREWALL, fw_plugin) | 08:23 |
| yushiro | I think. | 08:23 |
| yushiro | for testing... | 08:24 |
| yushiro | reedip, you said 'race' is such as loading plugin ? | 08:24 |
| yushiro | s/is/was | 08:25 |
| reedip | yushiro : yes | 08:25 |
| reedip | WARNING [neutron.api.extensions] Extension file firewall.py wasn't loaded due to Found duplicate extension: fwaas. | 08:25 |
| reedip | WARNING [neutron.api.extensions] Extension file firewallrouterinsertion.py wasn't loaded due to Found duplicate extension: fwaasrouterinsertion. | 08:25 |
| *** lnicolas has quit IRC | 08:25 | |
| yushiro | According to this warning msg, I thought directory.add_plugin() called twice | 08:26 |
| reedip | yushiro : me too | 08:27 |
| yushiro | reedip, ah... just a moment. https://github.com/openstack/neutron-lib/blob/fc38a3fe8e6fa7c75572180554a02b43a72f9af9/neutron_lib/plugins/directory.py#L33 | 08:28 |
| reedip | yushiro , yamamoto : let me push a patch. I think the change in the ALIAS of Firewall extension is a reason for the failure | 08:28 |
| yushiro | self._plugins is just a dict. If same 'key' is registered twice, it result in | 08:28 |
| reedip | ?? | 08:29 |
| yushiro | 1 key. | 08:29 |
| reedip | yushiro : but the thing is we are expecting an ALIAS | 08:29 |
| yushiro | yes... sorry, my brain is now heating ;p | 08:31 |
| reedip | yushiro : relax | 08:32 |
| reedip | yushiro :as you stated earlier, boden changed the ALIAS from fwaas to FIREWALL in neutron-lib | 08:32 |
| reedip | now midonet refers the neutron-lib constants to fetch the alias, to map it with a dictionary | 08:33 |
| reedip | to load the plugin | 08:33 |
| yushiro | OK. | 08:33 |
| reedip | firewall extension still illustrates the ALIAS as fwaas | 08:33 |
| reedip | and not firewall | 08:33 |
| reedip | when boden changed fwaas to FIREWALL | 08:34 |
| reedip | there was no change in midonet | 08:37 |
| reedip | but when firewall picked up the neutron-lib definition , a lot of changes were incorporated | 08:37 |
| yushiro | OK, I understood 'fwaas' -> 'FIREWALL' has no effect. | 08:39 |
| yushiro | Hmm, migrating a lot of definitions has some effect to networking-midonet. | 08:39 |
| reedip | yushiro: now midonet also uses the fwaas_constants | 08:39 |
| reedip | so changes done there also impacted midonet | 08:39 |
| reedip | the revert of the service name did not hide the effect of the alias name change as done by boden. | 08:40 |
| reedip | https://review.openstack.org/#/c/456511/22/neutron_fwaas/extensions/firewall.py@81 loaded firewall as fwaas | 08:41 |
| reedip | if you see https://github.com/openstack/neutron/blob/7e9986411c48cc4302910beaec159ec9bb6aa558/neutron/api/v2/resource_helper.py#L47, it states that the service name should not be fwaas but FIREWALL | 08:42 |
| reedip | see the third argument to build_resource_info | 08:42 |
| yushiro | reedip, OK, I'll look. | 08:45 |
| reedip | yushiro : I republished the patch https://review.openstack.org/443416 | 08:47 |
| yushiro | OK, | 08:49 |
| yushiro | thanks | 08:49 |
| yushiro | If this PS has passed, we should revert a patch and merge your service name change patch. | 08:50 |
| reedip | yushiro : this patch will fail but the failure may not be because of fwaas, but because of the load-synthetic-db issue already existing in midonet. | 08:50 |
| reedip | yushiro : If everything goes fine | 08:51 |
| reedip | a) We need to merge the Service Name revert | 08:51 |
| reedip | b) We need to merge the midonet firewall exception migration | 08:51 |
| reedip | c) We need to merge this patchset ( but I think this fix can be moved to the migrate firewall exception and this patch can just remain for testing) | 08:52 |
| yushiro | OK. | 08:54 |
| yushiro | So, after that, we should migrate all of definitions into neutron-lib finally. | 08:54 |
| reedip | Yes, | 08:55 |
| reedip | Ok, I am now taking a break, and waiting for theresults of this issue | 08:57 |
| yushiro | OK, I'll go for dinner now. | 08:59 |
| *** yushiro is now known as yushiro_dinner | 08:59 | |
| reedip | ok :) | 09:03 |
| *** yamamoto has quit IRC | 09:22 | |
| *** qiwei has quit IRC | 09:25 | |
| doude | Hi all! Just a question on the FWaaS v2 model. A port can be associated to only one fwg at a time? | 09:35 |
| yushiro_dinner | doude, yes. Only 1 firewall group can be associated with a port. | 09:41 |
| *** yushiro_dinner is now known as yushiro | 09:41 | |
| doude | why this limitation? | 09:41 |
| yushiro | doude, port : firewall group = 1 : 1 , firewall_group : port = 1 : n | 09:41 |
| yushiro | doude, If we support multiple firewall_groups for a port, considering an order for firewall group is necessary and it's too complexity. | 09:44 |
| doude | ok | 09:44 |
| yushiro | doude, that's why we should support 1 firewall group per port. | 09:44 |
| doude | thanks yushiro | 09:44 |
| yushiro | doude, np. | 09:44 |
| *** cuongnv_ has joined #openstack-fwaas | 09:45 | |
| reedip | yushiro : what about the firewall-policy to firewall group associattion | 09:46 |
| *** yamamoto has joined #openstack-fwaas | 09:46 | |
| yushiro | reedip, fwg and fwp = 1:2 for ingress/egress. | 09:47 |
| *** cuongnv__ has joined #openstack-fwaas | 09:47 | |
| *** cuongnv has quit IRC | 09:48 | |
| reedip | yushiro : you reported this : https://review.openstack.org/#/c/370731/ | 09:48 |
| reedip | https://launchpad.net/bugs/1623099 | 09:48 |
| openstack | Launchpad bug 1623099 in neutron "FWaaSv2 - 'firewall_policy_id' is missing in firewall_rule response body" [Low,New] - Assigned to Reedip (reedip-banerjee) | 09:48 |
| *** cuongnv__ is now known as cuongnv | 09:49 | |
| *** cuongnv_ has quit IRC | 09:50 | |
| yushiro | reedip, In my memory, in v2, firewall_rule can be associated with any firewall_policies. | 09:52 |
| reedip | but thats missing in the API ) | 09:52 |
| *** yamamoto_ has joined #openstack-fwaas | 10:09 | |
| *** yamamoto has quit IRC | 10:13 | |
| yushiro | reedip, In my early thinking, I filed above bug report. But.... | 10:13 |
| yushiro | reedip, I'll talk about next IRC meeting.(not sure in my memory ;)) | 10:14 |
| *** yamamoto_ has quit IRC | 10:30 | |
| *** yamamoto has joined #openstack-fwaas | 10:32 | |
| *** yamamoto has quit IRC | 10:33 | |
| *** cuongnv has quit IRC | 10:39 | |
| *** yamamoto has joined #openstack-fwaas | 10:43 | |
| *** yamamoto has quit IRC | 10:54 | |
| *** yamamoto has joined #openstack-fwaas | 11:24 | |
| *** yamamoto has quit IRC | 11:28 | |
| *** bzhao has quit IRC | 11:47 | |
| *** yushiro has quit IRC | 11:48 | |
| *** bzhao has joined #openstack-fwaas | 11:48 | |
| *** yamamoto has joined #openstack-fwaas | 11:54 | |
| *** yamamoto_ has joined #openstack-fwaas | 16:10 | |
| *** yamamoto has quit IRC | 16:13 | |
| *** bzhao has quit IRC | 16:19 | |
| *** bzhao has joined #openstack-fwaas | 16:20 | |
| *** yamamoto_ has quit IRC | 16:47 | |
| *** yamamoto has joined #openstack-fwaas | 16:49 | |
| *** Tim_Eberhard has joined #openstack-fwaas | 17:20 | |
| *** yamamoto has quit IRC | 17:42 | |
| *** yamamoto has joined #openstack-fwaas | 17:51 | |
| *** yamamoto has quit IRC | 17:56 | |
| *** yamamoto has joined #openstack-fwaas | 18:15 | |
| *** yamamoto has quit IRC | 18:44 | |
| *** yamamoto has joined #openstack-fwaas | 19:45 | |
| *** yamamoto has quit IRC | 19:52 | |
| *** amotoki is now known as amotoki_away | 20:52 | |
| *** Tim_Eberhard has quit IRC | 22:24 | |
| *** Tim_Eberhard has joined #openstack-fwaas | 22:26 | |
| *** lnicolas has joined #openstack-fwaas | 22:29 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!