00:00:17 <ekcs> #startmeeting congressteammeeting
00:00:18 <openstack> Meeting started Thu Jan  5 00:00:17 2017 UTC and is due to finish in 60 minutes.  The chair is ekcs. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:00:21 <openstack> The meeting name has been set to 'congressteammeeting'
00:00:39 <ekcs> Welcome back everyone! Hope everyone had a nice break.
00:01:03 <aimeeu> Hello all - Happy 2017!
00:01:50 <ekcs> hello aimeeu happy 2017!
00:02:07 <ekcs> Agenda items for today:
00:02:08 <ekcs> - Extra-ATC
00:02:08 <ekcs> - Ocata-3 schedule
00:02:10 <ekcs> - Ocata-3 QA
00:02:11 <ekcs> - Name and ID in API
00:02:11 <ekcs> - status and open discussion
00:02:17 <ekcs> anything else to add?
00:02:18 <masahito> hi
00:02:27 <masahito> happy new year
00:02:37 <thinrichs1> Happy New Year everyone!
00:02:37 <ekcs> happy new year masahito !
00:03:41 <ekcs> happy new year thinrichs1 !
00:04:11 <ekcs> ok then. let’s move right along  = )
00:04:18 <ekcs> #topic extra-ATC
00:04:23 <ekcs> Extra-ATC proposal is due Friday. My bad for not having brought it up earlier.
00:04:23 <ekcs> Anyone has an extra-ATC to propose?
00:05:02 <thinrichs1> Not me.
00:06:05 <ekcs> me neither. Well please let me know today or tomorrow if you do have someone to propose.
00:06:30 <ekcs> #topic Ocata-3 schedule
00:06:51 <ekcs> Ocata-3 release and final client release are officially due on the week of Jan 23.
00:07:11 <ekcs> #link https://releases.openstack.org/ocata/schedule.html
00:07:17 <ekcs> Here is a proposed schedule for us leading up to that.
00:07:35 <ekcs> 1. Submit/revise patches for review by Jan 12
00:07:35 <ekcs> 2. Target merging by Jan 16
00:07:36 <ekcs> 3. Ocata-3 QA and fixes Jan 16 - Jan 20
00:07:37 <ekcs> 4. Target Jan 23 for release (allowing a few days slack room if we experience delays like bug fixes that take longer)
00:07:57 <ekcs> Does that sound reasonable? Any thoughts or comments?
00:09:37 <thinrichs1> Sounds reasonable to me.
00:10:02 <ekcs> got it thinrichs1
00:10:04 <masahito> Sounds good to me.
00:10:10 <ekcs> Does anyone anticipate having difficulty getting Ocata patches submitted/revised by Jan 12?
00:10:11 <ekcs> Feel free to let people know so we can help = )
00:12:19 <ekcs> ok then. let’s aim to get our patches in by Jan 12 (next meeting).
00:12:40 <ekcs> #action everyone submit/revise ocata patches
00:13:08 <ekcs> any other comments on ocata-3 schedule before we move on?
00:14:15 <ekcs> #topic Ocata-3 QA
00:14:28 <ekcs> I've set up some QA related tasks for Ocata-3.
00:14:28 <ekcs> #link https://bugs.launchpad.net/congress/+bugs?field.tag=qa
00:15:04 <ekcs> Could we take a quick look and see if they make sense?
00:15:12 <ekcs> Any comments on what to add/remove/restructure?
00:17:37 <masahito> How about adding a test that check datasource failover?
00:18:29 <masahito> The list looks good to me. So this is an additional test for release.
00:18:33 <thinrichs1> Do we know what other teams do for QA?  Are they manually setting up different setups?  Or are they automating all that and putting it into the gate?
00:20:53 <ekcs> masahito: sounds like a good idea. you want to go ahead and add a task for that?
00:21:16 <ekcs> thinrichs1: I’m not sure. I imagine the more we can push into gate the better.
00:21:25 <masahito> ekcs: sure.
00:22:39 <ekcs> thinrichs1: I just know from last cycle that we needed additional testing to catch many of the bugs.
00:23:32 <thinrichs1> Agreed.  I was trying to figure out if it's feasible to move toward pushing more into the gate.
00:24:18 <ekcs> thinrichs1: so the thinking is we can do some manual tests and try to generalize that to gate. some we can do right away while testing for ocata-3. (say setting up devstack test with postgres should be straight forward). some we can do during RC period.
00:25:09 <ekcs> the task for collecting manual testing scripts would be a good start to strengthening integrated tests at gate.
00:25:26 <thinrichs1> All sounds good to me.
00:26:16 <ekcs> alright feel free to make additional comments/changes on the tasks and also to sign up.
00:27:15 <ekcs> let’s move on then.
00:27:41 <ekcs> #topic Name and ID in API
00:28:54 <ekcs> We had a discussion on this patch regarding accepting (policy & datasource) name and ID in API.
00:28:55 <ekcs> #link https://review.openstack.org/#/c/412303/
00:30:30 <ekcs> The main issue is that as implemented, names and UUIDs can clash, causing ambiguity and misinterpretation of caller intent.
00:31:16 <ekcs> I think everyone agrees we want to accept both name and UUID in the API calls, just not sure whether to disambiguate implicitly or explicitly.
00:31:41 <ekcs> From the discussion I think we may have the following consensus:
00:32:06 <ekcs> 1. legislate and enforce that names cannot have hyphens
00:32:46 <ekcs> 2. legislate and enforce that IDs must have hyphens (or be disjoint from the space of names another way)
00:33:49 <ekcs> 3. For historical and compatibility reasons, APIs will accept a name_or_id parameter and disambiguate based on which space the param belongs to (ie. whetehr it has hyphens)
00:34:21 <thinrichs1> I think that's right.  Though I don't know how high on the priority list this is.  The chances that someone wants to use something that looks like a UUID for a policy/datasource name is small IMO.
00:35:20 <thinrichs1> The part of this that I think is higher-priority is ensuring that policy names and datasource names are valid identifiers in the policy language.
00:35:44 <thinrichs1> There are tests in there now for the policy names, but they don't seem to reject what they should.
00:36:36 <ekcs> thinrichs1: got it. yes I agree that enforcing no-hyphens in identifiers is high priority. more likely to affect people. get it enforced sooner rather than later to avoid upgrade problems down the road.
00:37:25 <ekcs> masahito , aimeeu do you have any thoughts?
00:38:09 <masahito> it makes sense.
00:38:49 <aimeeu> I do agree with getting the no-hyphens enforced sooner rather than later
00:39:13 <ekcs> thinrichs1: and the discussion it’s only high priority because if we go a different way, we want to stop the spread of name_or_id use in the API right now.
00:40:38 <ekcs> the main argument I can see against this proposal is that it places restrictions on the form of the ID that we can’t change later without breaking API. So say openstack decides for some reason to universally adopt a different form of ID that doesn’t have dashes, then we have to break the API.
00:40:49 <ekcs> but it’s unlikely and even if it happens we can deal with it then.
00:41:22 <ekcs> anyway ok. sounds like we’re all on board. ramineni too judging from her patches.
00:41:38 <ekcs> thinrichs1: do you have any thoughts on how the hyphens are being let through in policy names?
00:42:50 <thinrichs1> No idea.  I imagine the check isn't running when new policies get created.
00:43:03 <thinrichs1> I'm pretty sure the check will fail if you give it a uuid
00:43:55 <ekcs> ok. well hopefully we can figure this out and patch it up for ocata-3. I’ll do some more testing.
00:44:01 <thinrichs1> To run that check on datasource creation too, we'll want to pull it out into somewhere that the datasource creation code can easily import it.
00:44:09 <thinrichs1> I'll try to take a look tonight after the meeting.
00:44:45 <ekcs> right. that’s a question: should the check be done via compiler code or another code or both.
00:44:58 <ekcs> ok then. let’s move on for now. thanks thinrichs1 !
00:45:07 <ekcs> #topic open discussion
00:45:38 <ekcs> any topics on your mind or statuses you’d like to update?
00:48:05 <ekcs> it’s still fairly rough right now, but if you get a chance, some early feedback on this patch would be helpful: #link https://review.openstack.org/#/c/416777/
00:48:32 <ekcs> I struggled with how to resolve this bug for quite a while. there are many many options and none of them really that great.
00:49:51 <ekcs> ok if there is nothing more to discuss, let’s end the meeting early. speak up in the next couple minutes if you want to talk about something  = )
00:50:39 <thinrichs1> Can you give an overview of what that patch is doing?
00:51:17 <ekcs> yup. two main things:
00:51:34 <ekcs> 1. lock rules table in DB
00:51:41 <ekcs> 2. synchronize rules
00:51:48 <ekcs> before each rule insert.
00:52:48 <ekcs> it’s conceptually the simplest solution. a little bit messy because of db sessions and db specific locks and unlocks and all that stuff.
00:53:21 <thinrichs1> That seems like it should work.  You said it wasn't great.  Is it just messy?  Or is there a problem it doesn't solve?
00:53:26 <ekcs> i don’t like ti because it requires locking and syncing before every rule insert in prevent something (recursion) that has very low chance of happening.
00:53:59 <ekcs> syncing is expensive, and locking prevents us from supporting multi-master HA DBs
00:54:17 <thinrichs1> Is it just recursion?
00:54:28 <ekcs> at this point it’s just recursion I think.
00:54:43 <ekcs> if we decided to allow recursion then there is stratification to check.
00:54:47 <ekcs> but there will always be something.
00:55:34 <thinrichs1> I guess recursion is a special instance of 2 people using the same table-name for different things. (Unless they're actively trying to break the system.)
00:56:34 <thinrichs1> If it's just recursion, we could change eval to fail when it recurses instead of infinite looping.
00:56:46 <thinrichs1> Then people would figure it out on their own.
00:56:54 <ekcs> yea that’s a possibility.
00:57:13 <thinrichs1> And then in this wacky case where 2 people accidentally create recursion, they'd end up having to dig into the problem anyway.
00:57:18 <thinrichs1> And someone trying to break the system couldn't.
00:57:44 <ekcs> downside there is it would look like your rule got in there and you may expect it is being used/enforced/monitored.
00:58:05 <ekcs> we could also back out the latest rule by timestamp when recursion detected.
00:58:08 <thinrichs1> Sure, but it's broken anyway b/c someone else used the same tablename for their own thing.
00:58:16 <thinrichs1> So you wouldn't get the results you want in any case.
00:58:38 <ekcs> actually people can use the same table for the same thing and still cause recursion.
00:58:59 <thinrichs1> It's just that on the off-chance 2 people use the same tablename for different things AND they happen to refer to each other's recursively that we catch the bug at the time the policy is inserted.
00:59:22 <ekcs> a may say p => q and b may say q => p. both meaning the same thing just defining in diff direction.
00:59:35 <thinrichs1> Not in datalog they can't.
00:59:58 <thinrichs1> p :- q and q :- p mean  different things.
01:00:12 <thinrichs1> Anyway, out of time.
01:00:21 <ekcs> yea.
01:00:39 <ekcs> ok then! maybe we can talk more about it outside.
01:00:41 <thinrichs1> I'm in #congress if want to continue
01:00:46 <ekcs> great.
01:00:52 <ekcs> thanks all! have a great week!
01:00:57 <ekcs> #endmeeting