Thursday, 2016-08-18

*** padkrish has joined #openstack-fwaas00:38
*** padkrish_ has joined #openstack-fwaas00:39
*** padkrish has quit IRC00:42
*** padkrish_ has quit IRC00:56
*** padkrish has joined #openstack-fwaas01:25
*** padkrish has quit IRC01:32
*** padkrish has joined #openstack-fwaas01:43
SridarKnjohnston: whenever u get a chance to read this: fixed 4 more02:02
SridarKlast few: http://paste.openstack.org/show/560707/02:03
SridarKwill need to step out for some time02:03
*** diogogmt has joined #openstack-fwaas02:17
*** diogogmt has quit IRC02:18
*** vishwanathj has quit IRC02:39
*** padkrish has quit IRC03:05
*** padkrish has joined #openstack-fwaas03:05
*** padkrish has quit IRC03:12
*** padkrish has joined #openstack-fwaas03:17
*** padkrish has quit IRC03:28
yushiroHi SridarK , I just wrote UTs for https://review.openstack.org/#/c/356306/ .  Can I update it?03:36
yushiroIf there is no problem, I'll put the patch and add njohnston as a reviewer.03:37
*** mickeys has joined #openstack-fwaas03:42
*** mickeys has quit IRC03:51
*** vishwanathj has joined #openstack-fwaas03:56
*** padkrish has joined #openstack-fwaas04:11
yushiroI've added UTs for https://review.openstack.org/#/c/356306/  and logic has no difference.04:15
*** vishwanathj has quit IRC04:17
*** chandanc_ has joined #openstack-fwaas04:21
*** vishwanathj has joined #openstack-fwaas04:38
*** padkrish has quit IRC04:44
*** mickeys has joined #openstack-fwaas04:52
*** mickeys has quit IRC04:56
SridarKyushiro: thx for the additional UT on the patch05:00
yushiroSridarK, No problems.05:01
*** vishwanathj is now known as vishwanathj_zzz05:08
*** padkrish has joined #openstack-fwaas05:28
*** padkrish has quit IRC05:45
*** SarathMekala has joined #openstack-fwaas05:47
*** padkrish has joined #openstack-fwaas05:53
*** padkrish has quit IRC06:09
*** yamamoto has quit IRC06:21
yushiroHi SarathMekala, thanks for your review.06:26
SarathMekalayou are welcome :)06:27
*** mickeys has joined #openstack-fwaas06:41
*** mickeys has quit IRC06:47
*** yamamoto has joined #openstack-fwaas07:00
*** yamamoto has quit IRC07:38
yushiroHi, fwaas team. Are you there?08:01
SarathMekalaI am around :)08:02
yushiroSarathMekala: hi.08:02
SarathMekalahi08:03
yushiroSarathMekala: I'd like to confirm the attributes of firewall_rule08:03
SarathMekalasure08:03
yushiroSarathMekala: In v2 SPEC(http://specs.openstack.org/openstack/neutron-specs/specs/newton/fwaas-api-2.0.html#firewall-rules)08:03
SarathMekalayes..tell me08:04
yushiroSarathMekala: we've skip service_group_id, source_address_group_id and destination_address_group_id.08:04
SarathMekalaOk. Is it for the current cycle or for the release?08:05
yushiroSarathMekala: I think current cycle is.  We should support ASAP.08:06
yushiroSarathMekala: current extension dictionary(https://review.openstack.org/#/c/264489/15/neutron_fwaas/extensions/firewall_v2.py)08:06
SarathMekalayeah.. i see that the parameters are missing08:07
SarathMekalayou want to ping Shweta reg this?08:08
SarathMekalawe need this info for the driver implementation as well08:08
yushiroSarathMekala: 'action' is required.08:09
SarathMekalayes08:09
SarathMekalait one of the main attributes08:09
yushiroHowever, the SPEC is 'Action to be performed on the traffic matching the rule (ALLOW, DENY, REJECT). Default: DENY.'08:09
yushiroHmm, I think I should align the SPEC.  How do you think?08:10
SarathMekalayeah.. right08:10
SarathMekalathis has to be a required attribute08:10
SarathMekalaOne more thing.. in V1 a rule can be shared between policies08:11
yushiroyes08:11
SarathMekalai dont see the 'shared' attribute in the spec08:12
yushiroAh, 'shared' is changed into 'public'.08:12
yushiroWe can use 'public' same as 'shared'08:12
SarathMekalaoh.. ok08:12
yushiroSarathMekala: Oh, sorry. I forgot.  'action' has been set a default value on L.21008:18
SarathMekalahow about the CLI?08:19
yushiroin V1 CLI?08:20
SarathMekalaV2 CLI... we will need to handle it08:20
yushiroV2 CLI is what I'm implementing now.08:20
yushiroThat's why I'd like to confirm about that :)08:21
SarathMekala:) ok.. I think in UI its a drop down field set to deny by default.. so no problem08:21
yushiroYes, default is DENY.  I think so too.08:22
yushiroThank you, SarathMekala.08:22
SarathMekalayou are welcome08:22
*** yamamoto has joined #openstack-fwaas08:39
*** mickeys has joined #openstack-fwaas08:49
*** yamamoto has quit IRC08:52
*** mickeys has quit IRC08:54
*** yamamoto has joined #openstack-fwaas08:56
*** yamamoto has quit IRC08:56
*** yamamoto has joined #openstack-fwaas08:56
*** yamamoto has quit IRC09:10
*** chandanc_ has quit IRC09:12
*** yamamoto has joined #openstack-fwaas09:12
*** yamamoto has quit IRC09:12
mfranc213Hi yushiro and everyone.  I'm here.09:30
*** yamamoto has joined #openstack-fwaas09:30
*** yamamoto has quit IRC09:30
*** yamamoto has joined #openstack-fwaas09:30
yushiromfranc213: Hi.  Long time no see.09:30
*** yamamoto has quit IRC09:30
mfranc213yushiro i am looking at your CLI patch now (https://review.openstack.org/#/c/351582)09:31
*** yamamoto has joined #openstack-fwaas09:31
mfranc213i hope to post my comments in an hour (a guess)09:31
yushiromfranc213, Thank you so much.  I'm fixing UT now.09:33
mfranc213yushiro: excellent09:33
mfranc213once i'm done with the comments on the CLI i'll move to the UTs for the oslo version object changeset (https://review.openstack.org/#/c/342476)09:34
*** yamamoto has quit IRC09:36
yushiromfranc213: OK.  ah, please let me confirm.09:41
mfranc213yushiro: confirm?09:41
yushiromfranc213: are you going to move CLI UTs into versioned object patch?09:41
mfranc213yushiro: nope!09:42
mfranc213yushiro: the ovo patch will have its own.09:42
yushiromfranc213: OK.09:42
*** yamamoto has joined #openstack-fwaas10:01
*** yamamoto has quit IRC10:01
*** yamamoto has joined #openstack-fwaas10:32
*** yamamoto has quit IRC10:37
*** yamamoto has joined #openstack-fwaas10:41
*** SarathMekala has quit IRC10:57
*** padkrish has joined #openstack-fwaas10:58
*** padkrish has quit IRC11:22
mfranc213yushiro: i just realized that i have more feedback you on the CLI patch.  would it be better if i gave it now or waited?11:27
yushiromfranc213: OK. Please review it now :)11:28
mfranc213ok, doing that now.  thank you!11:30
mfranc213yushiro: done for real this time.  now there are comments on PS3 along with the ones i gave on PS2.  i hope they are helpful.11:40
yushiromfranc213: Thank you so much.  I'll confirm it.11:41
yushiroEspecially, English grammar review is very helpful :)11:42
SridarKhi all12:04
SridarKsorry could not stay up last night12:04
SridarKyushiro: i think u had some q12:04
yushiroSridarK, Hi.12:05
njohnstonhi all12:05
SridarKyushiro: service_group_id, source_address_group_id and destination_address_group_id - we are not supporting that12:05
njohnstonSridarK: Sorry I didn't get to work on the DB patch more last night, family issues.12:05
yushiroSridarK, yes.12:05
yushironjohnston, hi :)12:06
SridarKnjohnston: ok no worries - i have one  more UT done12:06
SridarKnjohnston: i too had to be out and could not stay up very late12:06
SridarKlet me push that out too12:06
yushiroSridarK, currently, I'm OK now.  Thank you.12:09
SridarKi think we are now down to 712:09
SridarKyushiro: ok cool12:09
njohnstonSridarK: But let me run something by you to be sure.  The question came up, what is the difference between 'public' and 'shared'.12:09
SridarKnjohnston: no difference12:09
njohnstonMy reply was that 'shared' is a FWaaS v1 term, and it was replaced by 'public' in v2.  I just wanted to be sure I am correct.12:09
SridarKnjohnston: yes exactly12:10
njohnstonWhy the change in vernacular?12:10
yushironjohnston,  SridarK  I'd like to know it too.12:10
SridarKnjohnston: actually i dont know either - i cant recall but someone pushed that in the spec12:10
mfranc213i posed that question to yushiro earlier because i wasn't sure.12:10
mfranc213and i'm afraid that the change in vernacular will be confusing, prompting in others the same question that i had.12:10
SridarKnjohnston: actually i kind of found tht annoying12:11
njohnstonprobably only in those migrating from v1 to v212:11
SridarKmfranc213: i am with u12:11
mfranc213yushiro and njohston had the same response as one another, by the way!12:11
mfranc213is it possible to move to "public" at this time?12:11
mfranc213s/public/shared12:11
SridarKit also causes kind of busy work12:11
mfranc213doh!!!12:11
mfranc213see?12:11
mfranc213SridarK: busy work?12:12
SridarKno making sure we dont have some stale12:12
njohnstonmfranc213: In order to re-use the UTs from v1 there are a l;ot of 'shared' to 'public' changes to be made12:12
njohnstonfor example12:12
mfranc213njohnston: i'm afraid there would need to be changes in a LOT of modules12:12
SridarKi think we have kind of taken care of s/shared/public12:12
mfranc213this stinks12:12
SridarKmfranc213: sigh yes -12:13
njohnstonI am afraid it's a done deal now12:13
mfranc213is is possible just to change the CLI for now?12:13
SridarKmfranc213: i think we have already changed it12:13
njohnstonWe could make 'shared' a synonym to 'public' in the CLI perhaps12:13
mfranc213i don't like introducing 'shared' to the users12:13
mfranc213so CLI and REST12:14
njohnstonmfranc213: you mean 'public' ;-)12:14
mfranc213see?12:14
mfranc213i can't stop doing this myself.  sorry.12:14
yushiro(nova or glance uses 'public', neutron uses 'shared' and these are almost same usage)12:15
njohnstonWell we're going to have enough trouble delivering core functionality as it is, so I'd say we need to suck this one up and call it a user documentation issue12:15
mfranc213okay njohnston.12:15
SridarKnjohnston: +112:15
mfranc213yushiro: thanks for checking out the other projects12:15
mfranc213i like njohnston's idea to make 'shared' a synonym for 'public' in the CLI, and including information about this in the help.12:16
mfranc213what do you think, yushiro? ^^12:16
yushiromfranc213: that make sense.12:17
yushiroexcuse me, please let me confirm.12:19
yushiro'sysnonym' means12:19
yushiroCLI can specify not only 'public' but 'shared' ?12:20
mfranc213yushiro: 'synonyms' are two different words that mean the same thing.12:21
mfranc213yushiro: i think that we could change the CLI so that it accepts either 'public' or 'shared' as arguments. or, to make things much simpler for now, just change the help so that it says something about 'public' meaning what 'shared' means elsewhere.12:23
njohnstonSridarK: Did you have changes to 311159 you needed to push before I get working?12:23
yushiromfranc213: OK. Thanks for your help.  I understand.12:25
*** padkrish has joined #openstack-fwaas12:26
SridarKnjohnston: yes just getting it out12:28
mfranc213i have an appointment to go to.  i will be back in 2-3 hours.  when i get back i will work on the UTs for the oslo versioned objects, unless someone wants me to do something else.12:28
yushiroSridarK, njohnston Thanks for your quick review!!12:29
SridarKnjohnston: http://paste.openstack.org/show/560792/12:31
SridarKif u can start with looking into the one i have '*' at the end12:32
SridarKactually 2 of them12:32
njohnstonYep, I'm digging in now12:32
SridarKit seems like a the call is not formed correctly - it does not show up on the db12:32
SridarKi think the top 3 can be marked for a next rev12:33
njohnstonI don't see a test named 'test_update_firewall_with_fwp'12:35
njohnstonsearching for that gives no results in https://review.openstack.org/#/c/311159/45/neutron_fwaas/tests/unit/db/firewall/v2/test_firewall_db_v2.py12:36
njohnstonso I will work on test_update_firewall12:36
SridarKsorry back - the dog calls12:39
SridarKhmm ok12:39
SridarKoh that became 'test_update_firewall_group_with_fwp'12:40
SridarKi was debugging that12:40
SridarKbut yes the other is fine12:40
SridarKthe top 3 with the rule show, we can defer - another contributor has picked up insert_rule and remove_rule - i deferred them as they need more careful testing12:42
SridarKhe will need to set things with the rule position - i will req him to pick up the top 312:42
SridarKyushiro: what are things u would like me to look into before u sign off for the night12:44
SridarKyushiro: i have been looking at the emails - just did not want to distract from the db patch uts12:45
yushiroSridarK: let me see... my e-mail about 'status' for firewall_group is still under discussion.12:47
*** chandanc_ has joined #openstack-fwaas12:48
yushiroSridarK: OK, nothing from me.  Please let me inform to you my progress.12:48
yushiroahhahaa, sorry.  s/inform/report12:49
yushiro#link https://review.openstack.org/#/c/323971/12:49
yushiroI've updated l2-agent patch.  But unfortunately,  I've changed topic branch name with mistake so I'll revert the branch name.12:50
yushiroCLI patch https://review.openstack.org/#/c/35158212:51
njohnstonyushiro: You can change the topic name from within the gerrit web UI12:52
yushiroYesterday night, I updated.  Today, I'm updating mfranc213's comment.12:52
yushironjohnston, Yes, thank you :)12:52
yushiroTomorrow, I'll update CLI patch about today's discussion('shared' and 'public')12:54
SridarKyushiro: ok thx - i responded to the email12:55
SridarKyushiro: also i am hoping that as u start ur day - u will be able to do a scan of the db patch - i am hoping the UT will all be done12:55
SridarKyushiro: i know u have been reviewing it constantly12:56
yushiroSridarK, Of course. In fact, I'm watching/writing/confusing/reviewing....  community contribution is very fun :)12:57
njohnstonyushiro: I love the way you put that! :-)12:58
njohnstonvery well said12:58
yushironjohnston, :-)12:58
SridarKyushiro: i had to revert back one of the changes i did for ur comment in https://review.openstack.org/#/c/311159/46/neutron_fwaas/db/firewall/v2/firewall_db_v2.py L#53812:58
*** padkrish has quit IRC12:58
SridarKthis is because when the method is called for an UPD - then it is not guaranteed that the ingress_firewall_policy and egress_firewall_policy keys will be present12:59
SridarKso i revert back to checking if the key exists13:00
SridarKyushiro: :-) on ur comment above - it has been so helpful13:00
yushiroSridarK, ooooooh, you're right.  Please revert it.13:00
njohnstonSridarK: fixed the two starred UTs, moving on to the next13:03
yushiroSridarK, ah, after reverted the code, I think some fix is necessary.13:03
SridarKnjohnston: ok cool13:04
SridarKyushiro: ok pls comment on the patch when u get a chance13:04
yushiroAfter key check, second check fwg['ingress_firewall_policy_id'] is None or not.13:04
yushiroSridarK, yes.13:04
yushiroBTW, is anyone working for API-reference?  I think priority is not so high but necessary for user.13:06
SridarKyushiro: ok sorry slow response in another discussion13:07
yushiroSridarK, no problems.13:07
SridarKyushiro: ok got it - to ensure for CR13:30
SridarKwhen u have time pls put a comment on gerrit13:30
SridarKand i will pick it up13:30
yushiroSridarK, Sure.13:30
SridarKyushiro: thx13:30
SridarKnjohnston: u can comment out the the top 3 tests in the paste (with a TODO)13:31
SridarKold model - rule cannot be shared, and the rule had the policy and position in that policy13:32
SridarKi have refactored the code in that area so rules can be shared across policy - some clean up is needed on the show rule - which will fix those UT13:32
SridarKnjohnston: if u are good - i will get back to the plugin patch13:33
njohnstonback, call of the dog13:33
njohnstonSridarK: Will do.  Yep, I think I am good.  I'll report when I have all of the UTs except for the top 3 fixed, or if I hit a block.13:33
SridarKnjohnston: sounds good13:34
SridarKnjohnston: aha i think now my dog heard ur dog ;-)13:34
njohnstonheh13:34
*** padkrish has joined #openstack-fwaas14:01
*** chandanc_ is now known as chandanc_afk14:03
*** SridarK has quit IRC14:08
njohnstonSridarK: When you get back... I am trying to locate precisely the place where the logic is located that decides that a public=True firewall policy from another tenant can be assigned to a firewall group.  I think it's in _check_rules_for_policy_is_valid.14:13
njohnstonBut the problem is that I am working on the unit test test_update_firewall_group_with_public_fwp, and when contact is tenant1 non-admin, and I try to assign a firewall policy that is public=True from tenant2, I get FirewallPolicyNotFound.14:14
njohnstonWhat vexes me about this is that FirewallPolicyNotFound looks like it is only generated from within _get_firewall_policy when a NoResultFound occurs when pulling from the DB model... but I don't see anything in the DB model that enforces this.14:16
njohnstonIf it was really _check_rules_for_policy_is_valid then I would expect a FirewallRuleSharingConflict exception, or a FirewallPolicyConflict exception if the logic involved comes from _validate_fwg_parameters14:18
njohnstonI posted my changes to 311159 so far14:30
njohnstonmoving on to test_update_firewall_rule_associated_with_other_tenant_policy14:36
*** padkrish has quit IRC14:41
*** yamamoto has quit IRC15:01
*** yamamoto has joined #openstack-fwaas15:04
*** yamamoto has quit IRC15:09
*** yushiro has quit IRC15:12
*** mickeys has joined #openstack-fwaas15:59
*** yamamoto has joined #openstack-fwaas16:06
*** padkrish has joined #openstack-fwaas16:08
*** yamamoto has quit IRC16:11
*** chandanc_afk has quit IRC16:14
*** padkrish has quit IRC16:25
*** xdcc has joined #openstack-fwaas16:25
*** padkrish has joined #openstack-fwaas16:41
njohnstonpadkrish: How's it going?16:51
padkrishnjohnston# hi, not too bad :)16:51
padkrish#njohnston# hoping to get some time at night for writting some mock cases for VO....need to sync up with mfranc213..how about you....16:53
mfranc213hello16:54
njohnstonpadkrish: I was just curious, who do you work for?  Stackalytics shows you as 'independent'.16:54
njohnstonpadkrish: Oh, grinding on some truculent unit tests for the DB patch.16:54
padkrishnjohnston# i work for Cisco :)....my user ID is my personal one i created a while ago...when i tried to change it to my company's in git/gerrit, that gave me lot of grief, so sticking with my personal id16:55
padkrishbut didn't check Stackalytic16:56
mfranc213padkrish how are you?  i can continue to look at the test cases for VO (i've done only a very little bit) or do something else if you would like.16:56
padkrishmfranc213# i was just looking at the QoS examples again for the VO test cases16:57
mfranc213excellent.  so i'll pass the baton for VO back to you then and will get started on something else.16:57
padkrishmfranc213# doing allrite...i was planning to start on it tonite...16:58
padkrishmfranc213# ok sure, thanks for addressing the comments, going little crazy with my regular job :)16:58
padkrishthat really helped16:58
mfranc213very happy to help.  let me know if you would like me to do anything further with the VO changeset, for the tests or anything else.16:59
padkrishmfranc213# sure, i had some questions on Ihar's comments for the address_group VO, not super urgent since that got removed for now :)17:00
padkrishi will ping you sometime later, we can discuss about that17:00
mfranc213sounds perfect.  and if it turns out you can't get to the UTs, holler and hopefully i can help out with that, too.17:01
padkrishsure, will do...thanks again..17:01
*** vishwanathj_zzz is now known as vishwanathj17:04
njohnstonHmm, I seem to have introduced an error to the user tests for the db patch, causing the issue:     {"NeutronError": {"type": "FirewallPolicyNotFound", "detail": "", "message": "Firewall Policy None could not be found."}}17:24
*** SumitNaiksatam has joined #openstack-fwaas17:26
njohnstonmfranc213: When you have a moment, could I ask for your help on that?17:29
mfranc213yep17:29
mfranc213thinking17:29
mfranc213do you want to push the PS with a workflow -1 so i can grab it?17:30
njohnstongood example of that... grab 311159 and tox -e py27 neutron_fwaas.tests.unit.db.firewall.v2.test_firewall_db_v2.TestFirewallDBPluginV2.test_list_firewall_groups17:30
njohnstonyou should be able to grab it now17:30
mfranc213okay, getting it now.  i'll ping you once i have something, or know that i don't, etc.17:30
njohnstonthere is no magic to the workflow bit that would prevent you from grabbing it17:30
njohnstonthanks much!17:30
njohnstonI know it wasn't doing this a couple of days ago17:31
mfranc213no, i know.  didn't know though if your stuff was available for me to grab.17:31
mfranc213oh, really?  this is a new thing?17:31
njohnstonyep, you can do `git review -d` pretty much anything17:31
mfranc213yes, just wasn't sure if what you had was up in gerrit, is all.17:32
njohnstonyes, I believe it is new, but please don't let me prejudice your investigation unduly17:32
mfranc213:)17:32
mfranc213just to be sure, it's this one, right: 311159 ?17:32
njohnstonyes17:32
mfranc213ty17:33
njohnstonno, thank you!17:33
mfranc213@padkrish: i have some changes to the VO patchset to push.  i forgot that i had dealt with some of the nullability issues that ihar raised.17:34
mfranc213i will push those up now.17:34
padkrishmfranc213# sure, sounds good17:34
njohnstonbrb17:37
mfranc213@njohnston, could you rebase against master and then push a new PS?17:37
mfranc213well, i guess i don't really need you to do that.  i'll fix up that part of things locally.17:40
njohnstonHmm, I get 'up to date' when I rebase against master.17:43
mfranc213neutron changed.17:47
mfranc213okay, i've replicated the error.17:48
*** SridarK has joined #openstack-fwaas17:50
SridarKnjohnston: give me  few mins - looking at ur question on email17:52
njohnstonSridarK: Thanks!17:53
mfranc213njohnston: fwg1 has no egress_firewall_policy_id.  i know that a fw allows either (perhaps both) the egress_policy_id and the ingress_policy_id to be null17:53
mfranc213s/fw/fwg above17:54
njohnstonif that is true, should the migration say 'nullable=False' for both ingress_firewall_policy_id and egress_firewall_policy_id?17:55
mfranc213thinking17:55
mfranc213i believe nullable=True actually.  but that is a recent change on the db side, i think, right?17:55
njohnstonIt's a foreign key relation, but I think it may be an error to say nullable=False, as well as to have ondelete cascade17:55
mfranc213not sure17:56
mfranc213well, wait.17:56
mfranc213the current state of the code is that nullable=True?17:56
mfranc213(i could look, but you're here :) )17:56
mfranc213okay, i believe cascading delete is wrong.17:57
mfranc213at least the db schema that i have indicates this.  that that is a 1:m relationship between a FP and a FWG.  so a FP can survive the deletion of its FWG.17:57
-njohnston- .17:58
njohnston        sa.Column('egress_firewall_policy_id', sa.String(length=36),17:58
njohnston                  sa.ForeignKey('firewall_policies_v2.id', ondelete='CASCADE'),17:58
njohnston                  nullable=False, unique=True),17:58
njohnston        sa.Column('ingress_firewall_policy_id', sa.String(length=36),17:58
njohnston                  sa.ForeignKey('firewall_policies_v2.id', ondelete='CASCADE'),17:58
njohnston                  nullable=False, unique=True))17:58
mfranc213so stepping back.17:58
njohnstonthat is from the definiton of firewall_groups_v217:58
mfranc213you can have a fwg with just an egress policy, for instance, right?17:58
njohnstonyes, I believe that is correct17:59
mfranc213okay, and the cascading delete thing is an orthogonal issue.17:59
mfranc213so if it is the case that a fwg can exist without one or the other (or both?) of ingress policy and egress policy, then i think nullable=True is correct18:00
mfranc213and if a FP can be attached to multiple FWG, then cascading delete should not be specified18:00
SridarKmfranc213: if it is associated with multiple groups - delete is not allowed18:00
mfranc213but there is ondelete='CASCADE'18:01
mfranc213i actually think that these particular issues are separate from the bug we're seeing.  let me check.18:01
SridarKL#515 in https://review.openstack.org/#/c/311159/47/neutron_fwaas/db/firewall/v2/firewall_db_v2.py18:02
mfranc213so the info you sent me njohnston is in alembic which means that it shouldn't affect the unit test results, right?18:04
njohnstonSridarK: That's the call to _get_firewall_policy, yes?18:04
SridarKOn the FirewallPolicyRuleAssociation we should do a cascade delete if the policy we have a cascade delete but really there too if a rule is associated with a pol del is not allowed18:04
SridarKnjohnston: that would be in the delete path18:05
mfranc213SridarK i believe the issue here is the relationship between a firewall group and its policies.18:05
SridarKmfranc213: pls go ahead18:05
SridarKnjohnston: mfranc213: may be a quick call with screen share ?18:06
mfranc213sure18:06
mfranc213do you want to set it up?18:06
njohnstonmfranc213 and SridarK: Just to make sure evryone is clear, I emailed SridarK with a question (copied you mfranc213) but then I asked mfranc213 to look at something else.  Just didn't want people to think they were talking about the same thing when they might not be.18:06
mfranc213since i'm hopeless at that18:06
mfranc213ahhh18:06
mfranc213so sorry18:06
SridarKlet me go find a room18:06
SridarK:-)18:06
SridarKno worries - i will set it up18:06
mfranc213so i won't do a screenshare.18:06
SridarKnjohnston: ok cool18:06
mfranc213the screenshare18:06
mfranc213i'll just keep looking at the issue nate asked me about18:07
SridarKmfranc213: no it will be good to nail this down too on the relationship btwn tables18:07
mfranc213okay, sounds good.18:08
*** xdcc has quit IRC18:31
*** xdcc has joined #openstack-fwaas18:31
*** mickeys has quit IRC18:33
*** mickeys has joined #openstack-fwaas18:34
*** mickeys has quit IRC18:39
*** xdcc has quit IRC18:43
*** xdcc has joined #openstack-fwaas18:43
*** padkrish has quit IRC18:51
*** padkrish has joined #openstack-fwaas19:17
*** xdcc has quit IRC19:34
njohnstonSridarK: I filed https://bugs.launchpad.net/neutron/+bug/1614673 for those methods that need to be looked at as far as positioning19:40
openstackLaunchpad bug 1614673 in neutron "[FWaaS] Rule position testing is insufficient" [Wishlist,Confirmed]19:40
SridarKnjohnston: many thx - will keep track of this19:44
njohnstonSridarK: New version of https://review.openstack.org/311159 uploaded.20:06
njohnstonI added a second bug, covering 2 tests, that also needs follow-up: https://bugs.launchpad.net/neutron/+bug/161468020:06
openstackLaunchpad bug 1614680 in neutron "In FWaaS v2 cross-tenant assignment of policies is inconsistent" [Undecided,New]20:06
njohnstonso those 2 are skipped, as well as the original 320:06
njohnstonand now UTs pass.  I also got it in shape for pep8 and removed some of the debugging hacks.20:07
njohnstonSo please take a look, and if it looks good to you then we can let xgerman and yushiro know20:07
SridarKnjohnston: aah great20:08
SridarKi will run thru the latest PS in a bit20:08
SridarKyushiro will be in bed - but we can try to coordinate with xgerman & yushiro as the day starts in Japan20:09
xgermansounds good20:10
*** padkrish has quit IRC20:13
*** padkrish has joined #openstack-fwaas20:17
*** diogogmt has joined #openstack-fwaas20:27
*** SumitNaiksatam has quit IRC20:55
*** yamamoto has joined #openstack-fwaas21:09
*** yamamoto has quit IRC21:09
njohnstonSridarK: Does the fwaas l3 agent need access to an instance of RouterInfo, or just to the RouterInfo class?  Based on the calls, I think the latter, but I want to be sure.21:12
njohnstonAlso, you mentioned a step before RouterInfo was consulted, which is a method whereby, using the port, one could look up the router attached to that port.  What datastructure or functionality is consulted to make that lookup?21:14
SridarKnjohnston: if u are in the context of L3Agent, u should have access to the router info as self.ri21:35
njohnstonHmm, I'll test that21:44
njohnstonOnce we undo armax's change so the fwaas l3 extension no longer inherits from L3Agent, then we won't have access to router info anymore I believe, because we will be outside the L3Agent context21:46
njohnstonThis was the point where I got confused before when making the l3 agent extension code, and didn't include the agent extension api.21:47
SridarKnjohnston: with L3 Agent ext piece - i thought this will give us access to the router info21:51
SridarKdo the callbacks for the router create etc give u this ?21:52
njohnstonThat was what I thought initially.  But after looking at it, I don't think the router namespace is in the callback, since I believe that info never goes over the wire.21:53
SridarKnjohnston: that could be an issue22:04
njohnstonI think that the new patch will give us access to what we need; I just need to know what we use to take the port and look up the id of the router that is attached, to make sure that functionality is also included.22:05
SridarKfrom the port_id - we can find the owner and the router_id should be an index into the ri22:06
SridarKwe can also send in the router_id from the plugin22:07
SridarKfor the ports22:07
njohnstonok, so then all we would need access to is the router info22:17
SridarKyes22:17
*** padkrish has quit IRC22:17
njohnstongood.  Let me see if I can short-cycle this patch; my brain is a bit fried, so tomorrow i will look at setting up tests for it that will ensure that the fwaas agent extension will be able to get the things it needs.22:18
SridarKok cool, i am adding UT and if i get the plugin set - i will get freed up too22:18
SridarKi will follow up with yushiro tonight22:19
njohnstonExcellent.22:20
njohnstonThanks!22:20
SridarKno worries22:20
SridarKfingers crossed :-)22:20
*** padkrish has joined #openstack-fwaas22:21
njohnstonall right, now I'm off - Nate needs to step away from the keyboard...22:31
*** padkrish has quit IRC22:35
*** yamamoto has joined #openstack-fwaas22:42
*** padkrish has joined #openstack-fwaas22:46
*** mickeys has joined #openstack-fwaas22:48
*** mickeys has quit IRC23:04
*** vishwanathj has quit IRC23:29

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