18:01:43 <SumitNaiksatam> #startmeeting networking_policy
18:01:44 <openstack> Meeting started Thu Sep 14 18:01:43 2017 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:47 <openstack> The meeting name has been set to 'networking_policy'
18:01:59 * tbachman waves hand
18:02:03 <annakk> hi
18:02:08 <SumitNaiksatam> #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#Sept_14th.2C_7th_2017
18:02:09 <tbachman> annakk: hi!
18:02:14 <rkukura> hi
18:02:16 <SumitNaiksatam> tbachman: rkukura: hi
18:02:18 <tbachman> SumitNaiksatam: hi!
18:02:25 <tbachman> PTG West
18:02:51 <SumitNaiksatam> i guess we can go in the reverse order of the agenda since we didnt get enough time last week
18:03:07 <SumitNaiksatam> #topic py27 error messages and copious logs
18:03:39 <SumitNaiksatam> I was more concerned about exceptions I was seeing py27 job logs
18:03:52 <SumitNaiksatam> like “This handler is supposed to handle AFTER events, as in 'AFTER it's committed', not BEFORE. Offending resource event: security_group, after_create”
18:04:06 <SumitNaiksatam> “SubnetInUse: Unable to complete operation on subnet <subnet-id>: One or more ports have an IP allocation from this subnet”
18:04:11 <annakk> I though this was due to delayed notification
18:04:15 <SumitNaiksatam> there are a few others like this
18:04:49 <SumitNaiksatam> annakk: okay, i wasnt seeing this before, at least not in newton
18:05:12 <annakk> SumitNaiksatam: I think the warning was added in ocata upstream
18:05:22 <SumitNaiksatam> annakk: ah okay, that explains
18:05:39 <SumitNaiksatam> i guess if its a warning, its less alarming
18:05:52 <annakk> but it is spamming the logs..
18:06:01 <SumitNaiksatam> annakk: yes sure
18:06:28 <SumitNaiksatam> once we are able to determing that we can ignore it, i would suggest that we supress it for the py27 logs
18:06:46 <SumitNaiksatam> or rather at least for the py27 logs
18:07:10 <SumitNaiksatam> we consider supressing (or lowering to debug level) for normal operation too
18:07:30 <SumitNaiksatam> the SubnetInUse i think was definitely an exception
18:08:03 <annakk> I didn't see that one, is it always in the logs?
18:08:19 <SumitNaiksatam> yes, i saw a bunch of those at least when i last sample it
18:08:23 <SumitNaiksatam> *sampled
18:08:41 <SumitNaiksatam> btw, the list i prepared was not an exhaustive one
18:09:05 <SumitNaiksatam> there are probably like those
18:09:55 <SumitNaiksatam> just for ready reference, these were the ones I have enumerated in the meeting agenda topic:
18:09:56 <SumitNaiksatam> This handler is supposed to handle AFTER events, as in 'AFTER it's committed', not BEFORE. Offending resource event: security_group, after_create.
18:09:56 <SumitNaiksatam> No sqlalchemy event for resource <resource> found
18:09:58 <SumitNaiksatam> SubnetInUse: Unable to complete operation on subnet <subnet-id>: One or more ports have an IP allocation from this subnet.
18:09:58 <SumitNaiksatam> User: None dont have permissions
18:09:59 <SumitNaiksatam> Extension path 'neutron/tests/unit/extensions' doesn't exist!
18:10:44 <SumitNaiksatam> i guess we will need to individually investigate each of those, and determine if its a real problem or not
18:11:04 <annakk> agree
18:11:13 <SumitNaiksatam> i went through a couple of iterations like with the previous branches, and the logs were pretty clean on newton
18:11:23 <rkukura> SumitNaiksatam: right - some of these may be real issues, or things we will need to fix before some future upstream change
18:11:27 <annakk> I still don't see the SubnetInUse but I see abunch of others
18:11:38 <SumitNaiksatam> so i was pretty surprised to see these huge number of warnings/exceptions
18:12:05 <SumitNaiksatam> annakk: okay i will go back and verify
18:12:31 <SumitNaiksatam> annakk: the log i was looking at was this:
18:12:32 <SumitNaiksatam> http://logs.openstack.org/29/501529/1/check/gate-group-based-policy-python27-ubuntu-xenial/8ccf4ca/console.html
18:12:38 <annakk> we are looking in console log, correct?
18:12:55 <SumitNaiksatam> annakk: right, ^^^
18:13:58 <annakk> I'll try to clean some of those up
18:14:03 <SumitNaiksatam> annakk: thanks
18:14:24 <SumitNaiksatam> the log file takes a long time to load
18:14:46 <SumitNaiksatam> some of those you cant find until the whole file is loaded
18:15:05 <SumitNaiksatam> i remember i started looking from the bottom :-P
18:15:08 <SumitNaiksatam> anyway moving on
18:15:24 <SumitNaiksatam> #topic UI patches & state of UI on master/ocata
18:15:33 <SumitNaiksatam> #link https://review.openstack.org/#/q/status:open+project:openstack/group-based-policy-ui
18:15:46 <SumitNaiksatam> annakk: i think after your patch merged, the basic UI was working
18:15:49 <SumitNaiksatam> it worked for me
18:15:53 <annakk> yes
18:16:18 <SumitNaiksatam> annakk: so thanks for that fix
18:16:34 <SumitNaiksatam> after that we tested and merged this yesterday - #link https://review.openstack.org/#/c/493617/
18:16:56 <SumitNaiksatam> there was a small issue in there which, per the author, seemed to be getting fixed later
18:17:35 <SumitNaiksatam> i tested this one #link https://review.openstack.org/#/c/502223/ earlier today
18:17:41 <SumitNaiksatam> and that seems to be broken
18:17:49 <SumitNaiksatam> i didnt put a -1 since i had a question for the author
18:18:15 <SumitNaiksatam> annakk: you tested #link https://review.openstack.org/#/c/497235/ and the ‘+’ still seems to be broken, right?
18:18:25 <SumitNaiksatam> (i havent gotten to that patch yet)
18:18:25 <annakk> SumitNaiksatam: yes
18:18:39 <SumitNaiksatam> annakk: okay thanks for testing that as well
18:19:06 <annakk> SumitNaiksatam: np
18:19:07 <SumitNaiksatam> one thing is i think we need to check with the authors if there is an order in which we need to be testing these
18:19:33 <annakk> SumitNaiksatam: yes dependencies are not evident
18:19:39 <SumitNaiksatam> i will take an AI to email the authors and check
18:20:02 <SumitNaiksatam> in the second patch i tested it was dependent on the first one we merged
18:21:06 <SumitNaiksatam> and while i keep referring to them as “authors” i really want to thank Marek Lyčka, Aleš Křivák and viktor.krivak@ultimum.io for posting all these patches
18:21:31 <SumitNaiksatam> their work is really cleaning up a lot of cruft and long standing issues
18:22:08 <annakk> +1, the UI is looking better with transfer tables
18:22:51 <SumitNaiksatam> annakk: anything else you want to discuss about the UI patches in this meeting?
18:23:00 <annakk> no
18:23:13 <SumitNaiksatam> okay moving on
18:23:21 <SumitNaiksatam> #topic mitaka, newton DB migration backport strategy
18:23:34 <SumitNaiksatam> #link https://review.openstack.org/#/c/499185/
18:23:41 <SumitNaiksatam> #link https://review.openstack.org/#/c/499240
18:23:53 <SumitNaiksatam> we discussed at length in last week’s meeting
18:24:10 <SumitNaiksatam> it seemed like we have agreement on the short term plan
18:24:26 <SumitNaiksatam> the longer term strategy is still up for discussion
18:24:37 <SumitNaiksatam> i had a follow up email on the longer term startegy
18:25:10 <SumitNaiksatam> where a i proposed one possible approach
18:25:10 <rkukura> SumitNaiksatam: I put together a reply with another option, but then wasn’t convinced it would really work
18:25:16 <SumitNaiksatam> rkukura: okay
18:25:30 <SumitNaiksatam> might be worth sharing anyway in case it sparks some other ideas
18:26:21 <rkukura> I’ll revisit it
18:26:28 <SumitNaiksatam> annakk: tbachman: any fresh thoughts at your end (apart from not allowing migration backports)?
18:26:31 <SumitNaiksatam> rkukura: thanks
18:26:37 * tbachman has no thoughts
18:26:42 <SumitNaiksatam> tbachman: okay
18:26:49 <annakk> no ideas..
18:26:50 <tbachman> SumitNaiksatam: I’ll spend some time on it this week
18:26:52 <rkukura> it depended on having specific release points across all branches, which I’m not sure is viable
18:27:23 <SumitNaiksatam> rkukura: tbachman: do you have opinions on the proposal i made?
18:27:32 <tbachman> SumitNaiksatam: I need to think on it
18:27:41 * tbachman has been heads-down of late :(
18:27:49 <SumitNaiksatam> tbachman: np
18:27:56 <annakk> I feel another downside of heavy backporting might be that we'll be reluctant to move forward with the releases, since it multiplies backports..
18:28:24 <SumitNaiksatam> annakk: fair comment
18:28:56 <SumitNaiksatam> and its pretty accurate too
18:29:48 <SumitNaiksatam> but again the problem is that we are not able to push users to move between releases as fast we would like to
18:30:17 <SumitNaiksatam> i do agree its a chicken and egg situation; users will feel more compelled to move if we stop supporting
18:30:20 <rkukura> SumitNaiksatam: I guess the big question is whether that is a project-wide issue or a vendor-specific issue
18:31:24 <SumitNaiksatam> rkukura: i dont have comprehensive data across vendors
18:32:45 <SumitNaiksatam> i was anticipating we will have another long discussion on this today, but i guess we are still hung over from last week’s discussion ;-)
18:32:57 <SumitNaiksatam> #topic Open Discussion
18:33:16 <SumitNaiksatam> annakk: rkukura: tbachman: anything else you wanted to bring up?
18:33:23 <rkukura> not from me
18:33:26 <tbachman> SumitNaiksatam: not from me
18:33:33 * tbachman is still hung over from last week’s discussion :P
18:33:42 <SumitNaiksatam> tbachman: ;-)
18:33:44 <annakk> we can discuss SumitNaiksatam's double-chain suggestion :)
18:34:12 <SumitNaiksatam> annakk:  i think tbachman and rkukura mentioned that they need more time think over it
18:34:13 <rkukura> ok with me
18:35:05 <annakk> if upgrade skips a release, will we need to run the release-specific chain for the release that was skipped?
18:35:05 <rkukura> I haven’t looked into the mechanism supporting multiple chains, but it seems like it could help
18:35:24 <SumitNaiksatam> annakk: good point
18:35:30 <SumitNaiksatam> annakk: yes
18:36:02 <annakk> ok
18:36:14 <SumitNaiksatam> i dont know we can eforce that
18:36:33 <annakk> is there any infrastructure for upgrade tests? in openstack or in gbp..
18:36:42 <SumitNaiksatam> annakk: there is
18:36:48 <SumitNaiksatam> i mean there are UTs
18:36:56 <rkukura> are any migrations release-specific for the long term? I’m not sure what would go on the release-specific chains
18:37:56 <annakk> SumitNaiksatam: UTs for upgrade from prev version? I'll look for those..
18:38:01 <SumitNaiksatam> rkukura: what goes into a release-specific chain is what is present in a release X but cannot be backported to release < X
18:38:02 <rkukura> or maybe I should read “release” as “stable branch”
18:38:43 <SumitNaiksatam> but the assumption is that release X +1 will rely on that release-specific change from release X being present
18:38:54 <rkukura> but if its in X, it is also in X+1, so its not specific to X any more
18:39:01 <SumitNaiksatam> (basically restating annakk’s point)
18:39:32 <SumitNaiksatam> rkukura: sure, release-specific with respect to releases < X
18:39:49 <SumitNaiksatam> perhaps the terminology release-specific is not the most accruate
18:40:09 <SumitNaiksatam> didnt mean to imply changes only specific to a release
18:40:09 <annakk> if change X goes into release specific chain, and then comes change Y that goes to main chain, and those two conflict, change X will need to be rewritten since its timing is now changed?
18:40:18 <annakk> or should we disallow such scenarios?
18:40:51 <rkukura> not to confuse matters, but we probably should adopt the expand/contract stuff at some point, right?
18:41:04 <SumitNaiksatam> annakk: good point, yes we would have to mindful of the fact that the release-specific chain runs later
18:41:35 <SumitNaiksatam> rkukura: yes, but tackles a different issue about supporting rolling upgrades, right?
18:42:33 <rkukura> SumitNaiksatam: I think that was the motivation, along with OVO
18:44:36 <SumitNaiksatam> any more thoughts, or did we discuss enough to chew on this for a little more? ;-)
18:45:09 * annakk needs to chew more :)
18:45:09 * rkukura gags
18:45:25 <SumitNaiksatam> annakk: rkukura lol
18:45:38 <SumitNaiksatam> tbachman: thanks for earlier callout to the PTG
18:45:50 <tbachman> lol
18:45:59 <SumitNaiksatam> so this is our virtual PTG (should have been on our agenda)
18:46:00 <tbachman> SumitNaiksatam: welcome ;)
18:46:14 * tbachman has some catching up to do
18:46:21 <rkukura> we have more PTGs than upstream
18:46:40 <SumitNaiksatam> i belive some of the projects are living streaming from the PTG
18:47:09 <SumitNaiksatam> tbachman: okay, we will let you catch up on the PTG :-)
18:47:14 <tbachman> lol
18:47:16 <SumitNaiksatam> thanks all for joining
18:47:20 <tbachman> SumitNaiksatam: thx!
18:47:22 <rkukura> thanks SumitNaiksatam!
18:47:24 <SumitNaiksatam> keep discussion going on the emails
18:47:27 <SumitNaiksatam> bye!
18:47:30 <SumitNaiksatam> #endmeeting