14:02:35 <mestery> #startmeeting networking
14:02:36 <openstack> Meeting started Tue Nov 18 14:02:35 2014 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:39 <tomoe> hello
14:02:41 <openstack> The meeting name has been set to 'networking'
14:02:43 <beagles> hi!
14:02:50 <SumitNaiksatam> hi all!
14:02:51 <mestery> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda
14:02:51 <russellb> o/
14:02:54 <dkehn> hi
14:03:04 <marun> hi
14:03:07 <pc_m> hi
14:03:18 <SridarK> Hi
14:03:22 <mestery> Welcome back folks! I missed everyone in Paris, hope everyone had a great trip :)
14:03:39 <dougwig> we did, and congrats to you.
14:03:43 <mestery> Thanks dougwig.
14:03:51 <mestery> Sounds like a lot of really great discussions happened.
14:03:52 <nati_ueno> congrats!
14:04:01 <mestery> #link https://wiki.openstack.org/wiki/Kilo_Release_Schedule
14:04:06 <regXboi> +1 for the new mestery - hope all are doing well :)
14:04:09 <mestery> I wanted to make sure people are aware of the Kilo release schedule.
14:04:21 <mestery> Thanks nati_ueno and regXboi. :)
14:04:34 <mestery> #info Kilo-1 date: 12-18-2014
14:04:43 <mestery> That's the first date of importance for folks.
14:04:54 <amuller_> mestery: Do we have the spec proposal freeze and spec approval freeze dates?
14:05:10 <mestery> amuller_: I will have those by EOD today and send email to the list.
14:05:15 <amuller_> Great :)
14:05:17 <amuller_> thanks
14:05:18 <mestery> And document them as well.
14:05:38 <mestery> Also, one more announcment
14:05:43 <mestery> #link https://wiki.openstack.org/wiki/Sprints/NeutronKiloSprint Mid-Cycle
14:06:00 <mestery> Please note if you're attending, send your contact information to Jun from Adobe so he can presetup your wifi access
14:06:06 <mestery> Any other announcements for the team?
14:06:55 <mestery> #topic Bugs
14:06:59 <mestery> enikanorov_: Hi there!
14:07:01 <enikanorov_> hi
14:07:55 <mestery> enikanorov_: How current is the bug section of the meeting page?
14:08:11 <enikanorov_> mestery: it's not actual, i'll update
14:08:31 <enikanorov_> so the update for today
14:08:51 <mestery> #action enikanorov_  to update the bugs section of the meeting page.
14:08:53 <enikanorov_> there is a bug in tempest or neutron that is being hit in the gate quite often
14:09:00 <enikanorov_> let me find the link
14:09:29 <enikanorov_> https://bugs.launchpad.net/tempest/+bug/1357055
14:09:31 <uvirtbot> Launchpad bug 1357055 in tempest "Race to delete shared subnet in Tempest neutron full jobs" [Undecided,Confirmed]
14:09:40 <mestery> enikanorov_: I recall discussing this bug with armax or markmcclain yesterday
14:10:31 <mestery> Looks like this is assigned to salv-orlando at the moment.
14:10:35 <enikanorov_> yep
14:10:48 <enikanorov_> so I guess he's not here right now
14:10:55 <mestery> Commment #29 indicates it's a Tempest bug as well.
14:11:10 <mestery> Yes, salv-orlando must be predisposed at the moment.
14:11:16 <enikanorov_> another bug which has raised quite a bit of discussion is https://bugs.launchpad.net/neutron/+bug/1382064
14:11:17 <uvirtbot> Launchpad bug 1382064 in neutron "Failure to allocate tunnel id when creating networks concurrently" [High,In progress]
14:11:43 <enikanorov_> this one was discovered during cuncurrent api tests (via rally)
14:11:58 <enikanorov_> and revealed major flaw in id allocation logic
14:12:09 <mestery> enikanorov_: Yiikes! Are you looking into this one?
14:12:12 <salv-orlando> mestery: that bug from what I gather is a tempest thing, but in the past two weeks I did not find time to look at it.
14:12:31 <mestery> salv-orlando: Thanks for the update there!
14:12:36 <enikanorov_> mestery: the fix is on review and we have quite long discussion there with amuller_
14:13:03 <enikanorov_> actually the discussion spans beyong particular fix
14:13:08 <amuller_> enikanorov_: mestery: I think Eugene, Mike and myself showed our perspectives clearly and we probably need 3rd party feedback on the patch
14:13:12 <mestery> Excellent! Thanks for tackling that one enikanorov_ and amuller_!
14:13:17 * markmcclain sneaks in late due to traffic
14:13:37 <enikanorov_> i hope we'll get a few minutes at the end of the meeting to describe underlying problem
14:13:38 <mestery> amuller_: All the comments are in the review for this one then?
14:13:41 <enikanorov_> *to discuss
14:13:44 <amuller_> mestery: yeah
14:13:45 <mestery> enikanorov_: We can do that right here if you want.
14:13:54 <mestery> We can use 5-10 minutes now.
14:14:20 <enikanorov_> well, it's general question about getting rid of with_lockmode('update') (for the sake of galera/mysql) and related diffuculties
14:14:37 <enikanorov_> i think it's better to postopne in to the end of the meeting
14:14:45 <mestery> enikanorov_: OK, that sounds fine.
14:15:19 <mestery> enikanorov_: I just wanted to also highlight the email you sent to the list last week on neutron bugs:
14:15:21 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2014-November/049975.html
14:15:36 <mestery> Have you had much luck in getting additional people to signup for triage, recreationg, etc?
14:15:51 <enikanorov_> yes, I've got a couple of contacts
14:16:00 <mestery> enikanorov_: Perfect, glad to hear that!
14:16:23 <mestery> enikanorov_: Also, what are your thoughts on doing a bug-day in the coming weeks? I'm thinking it would be a good thing for the community to partake in and help clear the bug count a bit.
14:16:31 <enikanorov_> i'm planning to go over some open bugs that don't have updates for last couple of weeks, probably reassigning them to other people
14:16:58 <enikanorov_> enikanorov: yes, i think we need to have it as a regular event
14:17:05 <mestery> #action mestery to work with enikanorov_ on a bug day in the coming 2 weeks.
14:17:12 <mestery> enikanorov_: Agreed, we'll make it happen.
14:17:14 <HenryG> How many bugs have assignees but they have effectively abandoned work on them?
14:17:31 <enikanorov_> HenryG: i don't know
14:18:31 <mestery> OK, thanks for the updates on the bugs enikanorov_, and we'll get a bug day rolling soon.
14:18:42 <enikanorov_> mestery: cool
14:19:05 * mestery doesn't see emagana around for a docs update ...
14:19:17 <mestery> #topic Docs
14:19:23 <mestery> #action emagana to update docs section of meeting page
14:19:39 <mestery> #topic Technical Debt in the Agents
14:19:50 * mestery isn't sure who added this to the agenda ...
14:19:58 <marios_> i did on behalf of carl_baldwin
14:20:08 <mestery> marios_ and carl_baldwin: Excellent!
14:20:10 <mestery> #link https://etherpad.openstack.org/p/kilo-neutron-agents-technical-debt
14:20:10 <marios_> it came up at the end of last week's l3... carl_baldwin ?
14:20:28 <dkehn> maybe a good point to mention the possibility of DHCP sub-group
14:20:29 <mestery> marios_: I'll let you and carl_baldwin lead us through this discussion then if you guys are ready.
14:20:49 <marios_> so i really haven't prepared anything. it was mostly for a discussion point about where/how to organise the work
14:20:51 <carl_baldwin> marios_: Go for it.
14:21:32 <marios_> so all the agents are discussed together in the etherpad. for example, the l2 fixes, should they be discussed under ml2 subgroup?
14:21:36 <marios_> or do we need a new group etc
14:21:56 <markmcclain> please no more groups
14:21:57 <marun> I can imagine it needing to be separate
14:22:02 <marun> but I'm not suggesting how
14:22:06 <mestery> markmcclain: +1
14:22:07 <marun> ml2 -> integration point
14:22:11 <marun> agents -> control plane
14:22:34 <salv-orlando> what would be the reason for a sub group? a regular weekly meeting?
14:23:24 <dkehn> salv-orlando: all those reason and focus
14:23:26 <carl_baldwin> Wondering specifically about how to organize the L2 agent improvements discussed in the etherpad above.  Attaching to some weekly meeting could help get things started.
14:23:27 <marios_> salv-orlando: i guess so, somewhere to discuss progress on that work
14:23:51 <dkehn> salv-orlando: & accountablility
14:23:59 <regXboi> can we carve out some time at the end of this meeting to start with before spinning a new group?
14:24:20 <rkukura> we could include L2 agent discussion in the weekly ML2 agenda as needed
14:24:23 <mestery> carl_baldwin: I would propose we coudl use part of the weekly Neutron meeting for this as well in the on-demand agenda, especially to bootstrap.
14:24:58 <marios_> +1 I think this was suggested by someone last week too, perhaps carl
14:25:05 <carl_baldwin> mestery: rkukura:  I’d be fine with either.
14:25:14 <russellb> if it's high priority core neutron work, seems to make perfect sense to discuss here
14:25:19 <russellb> which it sounds like it is
14:25:24 <mestery> russellb: ++
14:25:29 <russellb> it's really hard to follow all of these groups
14:25:33 <markmcclain> russellb: agreed
14:25:38 <dougwig> we need a new subgroup to discuss adding new groups.
14:25:43 <marios_> lol
14:25:45 <sballe> dougwig: +1
14:25:50 <russellb> basically, i'm not even trying, because there's too many :)
14:25:53 <salv-orlando> if you want to have a task force focused on repaying debt in any agent for this release cycle and set up a meeting for it I’m ok with it. I just don’t want to create permanent sub groups of subject matter experts
14:25:53 <lukasa> dougwig: +1
14:25:55 * dougwig ducks
14:26:00 <regXboi> oh please dear lord, no!
14:26:04 <glebo> dougwig: +1
14:26:04 <mestery> Yes, we have too many subgroups without clear charters or missions.
14:26:09 * regXboi runs screaming from the chat room
14:26:37 <mestery> So, lets discuss the agent things each week in this meeting.
14:26:39 <salv-orlando> for instance in the last releae cycle we did this “db meetings” but at the end of the day it was just a bunch of folks (4 maybe 5) syncing up on a task of making migrations idempotent
14:26:39 <mestery> Sound good to everyone?
14:26:50 <regXboi> mestery:+1
14:26:53 <salv-orlando> sounds good to me
14:26:54 <lukasa> mestery: +1
14:27:03 <carl_baldwin> mestery: +1
14:27:05 <amotoki_> sounds good to me
14:27:08 <glebo> wfm
14:27:10 <marios_> yup
14:27:13 <mestery> #info Agent refactoring discussion to happen in weekly neutron meeting going forward
14:27:13 <salv-orlando> anything that needs more bandwidth… use #openstack-neutron or the mailing list
14:27:21 <mestery> salv-orlando: +1
14:27:22 <markmcclain> salv-orlando: ++
14:27:40 <mestery> As a team, we need to refocus to having these discussions in the team meeting, and use ML and IRC for higher bandwidth discussions as needed.
14:27:53 <russellb> mestery: +1
14:28:06 <mestery> We can't scale with 10s of sub-teams meetings all the time. :)
14:28:07 <amotoki_> In addition, regarding subgroup meeting, all meetings listed at https://wiki.openstack.org/wiki/Meetings#OpenStack_Networking_.28Neutron.29 will be held in Kilo cycle? If not, please update.
14:28:35 <mestery> amotoki_: I'm going to request sub-teams to have a clear charter by next week's neutron meeting, and if htey don't, they should disband.
14:28:47 <mestery> We need to be having discussions in the broader meeting and not require people to attend all these other meeitngs.
14:28:50 <mestery> It's not scalable.
14:29:08 <ajo> +1
14:29:08 <dougwig> mestery: +1
14:29:13 <dkehn> mestery: +1
14:29:15 <amotoki_> mestery: +1
14:29:19 <markmcclain> mestery: +1
14:29:29 <mestery> I'll send email to the list post meeting on this, and add agenda item for next week.
14:29:29 <regXboi> mestery: +1
14:30:00 <mestery> Anything else to discuss on the agent item today?
14:30:06 <glebo> mestery: +1
14:31:01 <mestery> #topic Services Split Update
14:31:03 <carl_baldwin> mestery: marios_:  We need to identify who will be working on this.  Maybe a mail to the ML could help bootstrap this?
14:31:06 <mestery> #undo
14:31:07 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x1bf9410>
14:31:16 <mestery> carl_baldwin: I think that would be ideal, yes.
14:31:26 <marios_> carl_baldwin: people have claimed stuff in the ehterpad but we can make sure they are still up for it
14:31:27 <mestery> #action carl_baldwin to send email to list to get a quorum of folks for agent refactoring.
14:31:35 <mestery> carl_baldwin: I know in the past banix has expressed interest here as well.
14:32:02 <carl_baldwin> Will do.  I think we can move on.
14:32:10 <mestery> Thanks carl_baldwin!
14:32:15 <mestery> #topic Services Split Update
14:32:21 <mestery> So, the short story here is there is no update yet. :)
14:32:31 <blogan> lol
14:32:32 <mestery> markmcclain and I are working on this with the TC at the moment.
14:32:52 <blogan> any idea when the TC will be able to have an official meeting about it to decide?
14:32:53 <mestery> From a proposal perspective. markmcclain, did I miss anthing else?
14:33:10 <markmcclain> blogan: likely next week
14:33:30 <mestery> #info TC to have services split discussion next week
14:33:37 <markmcclain> because of the async way we consider items… I'll propose for this week and for adding to next week's agenda
14:33:37 <SumitNaiksatam> mestery markmcclain: thanks, whats the proposal that is put in front of the TC?
14:34:08 <russellb> markmcclain: should probably have a ML thread to introduce it first, with about week lead time before it hits TC agenda
14:34:24 <markmcclain> SumitNaiksatam: to divide the main neutron repo into two that are managed by the networking program
14:34:27 <mestery> #action markmcclain and mestery to send email to ML prior to TC agenda addition
14:34:30 <mestery> russellb: Good idea
14:34:49 <markmcclain> russellb: right wanted to wait until folks were back to introduce so that the thread didn't get skipped
14:34:57 <russellb> col
14:34:58 <russellb> cool, too
14:35:03 <mestery> lol :)
14:35:25 <mestery> So, that's the update on services split. Look for the ML discussion soon.
14:35:27 <blogan> anything we can do in the meantime?
14:35:42 <salv-orlando> blogan: you can wait for a message on the ml ;)
14:35:47 <mestery> lol
14:35:50 <dougwig> lol
14:35:50 <blogan> lol thanks salv
14:36:13 <mestery> #topic Open Discussion
14:36:20 * mestery notes we may end a bit early today.
14:36:24 <markmcclain> blogan: dougwig has been working on the proposed code organization item
14:36:30 <mestery> enikanorov_: This is your slot! :)
14:36:35 <mestery> enikanorov_: For the previous discussion.
14:36:39 <enikanorov_> ok
14:36:49 <blogan> mestery: can we talk about the meetup as well after?
14:36:50 <dkehn> DHCP direction, or god forbid I say sub-grou[
14:37:04 <enikanorov_> so here's the issue, we're trying to get rid of locking tables (with_lockmode)
14:37:39 * regXboi listens
14:37:41 <enikanorov_> in some cases consistency can't be achieved without that, so retries need to be used to achieve the result
14:38:00 <markmcclain> dkehn: you have to file the form for the subgroup on subgroups :)
14:38:08 <dkehn> markmcclain: thanks
14:38:24 <enikanorov_> the problem is that such operations are performed under transactions which in mysql have 'repeatable read' isolation level
14:38:43 <enikanorov_> and hence retry logic just don't work because the code fetches the same values over and over again
14:38:45 <regXboi> enikanorov_ are the cases where consistency can't be achieved corners or are they in the main space?
14:38:54 <markmcclain> enikanorov: the API refactoring plus separation into tasks should remove much of the need for the locking we're doing now
14:39:04 <rkukura> shouldn’t the transaction be inside the retry loop?
14:39:32 <enikanorov_> rkukura: that seems to be an obvious solution, but that just a small method called by, say, create_network, that has one big transaction
14:40:29 <enikanorov_> markmcclain: can you explain about the tasks?
14:40:48 <markmcclain> enikanorov_: it was a bit about what we talked about in the sessions in Paris
14:40:51 <salv-orlando> markmcclain: since that’s not happening tomorrow it still makes sense fixing in the existing code base
14:40:52 <enikanorov_> markmcclain: i mean how it helps
14:41:03 <enikanorov_> salv-orlando: agree
14:41:16 <markmcclain> salv-orlando: yeah… not sure we'll be able to make a meaning lock_mode fix for Juno
14:41:18 <salv-orlando> enikanorov_: what markmcclain is saying is that we’ll pretty much rewrite eveyrthing
14:41:38 <enikanorov_> salv-orlando: i like rewriting stuff :) but...
14:41:43 <salv-orlando> everything… even ourselves ;)
14:41:48 <marios_> lol
14:41:49 <amuller_> In the mean time we have https://bugs.launchpad.net/neutron/+bug/1382064 (Concurrent network creations all try to use the same segmentation ID, and the retry loop just tries the same number 10 times and fails)
14:41:50 <uvirtbot> Launchpad bug 1382064 in neutron "Failure to allocate tunnel id when creating networks concurrently" [High,In progress]
14:41:55 <enikanorov_> you know, we're dealing with issues that appear in distributed environment
14:42:00 <amuller_> We need a short term solution to that bug
14:42:06 <enikanorov_> retry logic is a correct way to deal with those
14:42:36 <marun> can we special case things that need to retry like this to use a different isolation mode?
14:42:39 <enikanorov_> if we somehow serialize access - that would mean we create contention point
14:43:04 <enikanorov_> marun: exactly. that is a proposed solution
14:43:19 <marun> enikanorov_: are there any drawbacks to that approach?
14:43:53 <enikanorov_> marun: potentially, in 'update' operations, but anyway, postgress already uses 'read committed' isolation level that is fine for retry logic
14:44:28 <amuller_> marun: In my mind it destroys my ability to reason about the code base. If a subtransaction deep in the stack (Such in the patch proposed) sets a different transaction level, I have no way of knowing that unless I'm just familiar with the entire code base.
14:44:40 <enikanorov_> so for now the solution for mysql is to change tx isolation level from default to 'read committed'
14:44:46 <amuller_> I no longer know what transaction level each transaction uses
14:44:58 <amuller_> And I have to constantly check and think about what that means for every flow
14:45:04 <enikanorov_> amuller_: you don't know it anyway, because it is backend-dependent right now
14:45:16 <amuller_> each DB has a default
14:45:17 <marun> enikanorov_: That would seem to be pretty dangerous if code has been written to assume 'consistent read' :/
14:45:21 <amuller_> at least it's consistent
14:45:38 <amuller_> if different parts of the code base use different levels... I don't know, that seems insane to me to be honest
14:45:39 <enikanorov_> marun: correct
14:45:53 <marun> or are we safe there?  I mean, postgres uses read committed and the code is fine, right?
14:45:54 <enikanorov_> marun: good news is that 'create' operations are safe for that
14:45:56 <dkehn> enikanorov_: I would leave the isolation where it is, becuase its the default for everyone, and look at the length the lock is there
14:46:29 <enikanorov_> marun: we don't have anough concurrent api testing to say that code is fine with postgres
14:46:35 <enikanorov_> *enough
14:46:37 <marun> enikanorov_: fair enough
14:47:02 <enikanorov_> so if any call chain issues the same query twice for the same object, that is a potential issue
14:47:13 <yamamoto> either way it's better to use the same isolation level for mysql and postgres
14:47:29 <marun> yamamoto: well, that implies a pretty significant change then.
14:47:34 <enikanorov_> yamamoto: i tend to agree.
14:47:36 <amuller_> I proposed an alternate on the patch
14:47:38 <enikanorov_> marun: agree as well
14:47:50 <amuller_> https://review.openstack.org/#/c/129288/4//COMMIT_MSG
14:48:40 <carl_baldwin> Random will be fine as long as the available space is sparsely consumed. As soon as the space is not sparsely consumed then it will be terrible. Won't this be the case for VLAN ids?
14:48:51 <enikanorov_> carl_baldwin: exactly
14:49:00 <amuller_> carl_baldwin: We can provide a different solution for tunneling and VLANs, since, they're different..
14:49:10 <emagana> emagana won the prize for being the one confusing the time for the networking meeting.. DLT!!!! I hate you!!
14:49:12 <marun> What about writing tests that attempt to validate concurrency of the operations in question?
14:49:39 <enikanorov_> marun: well... wei use rally in our lab
14:49:40 <marun> We can debate the merits of an approach in theory, but unless we're validating our assumptions the debate will have to continue into production environments.
14:49:42 <enikanorov_> *we
14:49:56 <mestery> emagana: lol
14:50:00 <carl_baldwin> Won’t it also be the case if the configured available range of ids (regardless of type) is small?
14:50:04 <ajo> emagana, not sure if you won ;), I was here 1 hour before ;D, and missed the last one
14:50:07 <enikanorov_> the issue was found with rally, and that's how i validated the fix
14:50:27 <emagana> mestery: sorry.. and I thought I was early!!  LOL
14:50:29 <enikanorov_> carl_baldwin: for tunnels there is not much sense to configure small ranges
14:50:29 <marun> enikanorov_: Hmmm, so rally is sufficient testing then?
14:50:53 <marun> enikanorov_: Can we change the transaction isolation to 'read committed' for mysql and retest to see if issues appear?
14:51:00 <enikanorov_> marun: it's load/concurrency/performance testing framework for which a couple of api tests for neutron is written
14:51:03 <marun> globally, I mean
14:51:04 <marun> Or have you already done so?
14:51:13 <ajo> enikanorov_but people tend to do, for some reason, so could be an issue, or we'd need to state clearly that they need to use broad tunnel id ranges
14:51:15 <enikanorov_> marun: that's what i did. it fixes the issue
14:51:26 <enikanorov_> ah, globally
14:51:40 <enikanorov_> yeah, we can test that.
14:51:56 <marun> enikanorov_: It is a small change with a potentially big impact.
14:52:02 <marun> enikanorov_: But at least it has consistency on its side.
14:52:18 <marun> Does anyone have any objection to attempting to move to the new isolation level?
14:52:26 <marun> It could cause problems, but we're early in the cycle.
14:52:44 <enikanorov_> and also, postgres is already 'read committed'
14:52:50 <markmcclain> Has jaypipes looked at it?
14:52:52 <marun> Also, has anyone consulted mike bayer on the issue?
14:53:03 <rossella_s> marun: let's test that at least...the lock wait timeout bugs are hitting us anyway
14:53:18 <carl_baldwin> marun: I think it is worth some testing.
14:53:19 <marun> rossella_s: agreed, testing is the first step.
14:53:19 * regXboi wonders if we have to back off and treat concurrent access like we would treat multi-master
14:53:32 <markmcclain> Jay and I talked about this class of problem before and he had some feedback
14:53:44 <carl_baldwin> enikanorov_: Yes, postgres is using ‘read committed’ but we’re not testing that as much.
14:53:53 <enikanorov_> carl_baldwin: true
14:54:20 <enikanorov_> carl_baldwin: i just mean that at the level of confidence that gates give us, it was fine at times we tested neutron with postgres
14:54:59 <rossella_s> maybe it's worth writing to the ML so that other people can give their feedback? They might have tried it in other projects...
14:55:08 <enikanorov_> rossella_s: will do
14:55:10 <ajo> rossella_s: +1
14:55:10 <mestery> rossella_s: That's a good idea actually
14:55:41 <ajo> trying "READ COMMITED" globally sounds like a good approach to me from the consistency point of view, ...
14:55:50 <ajo> but it will be good to hear other's experiences on that.
14:56:16 <carl_baldwin> enikanorov_: Fair enough.  I just wanted to point out that it won’t necessarily be a slam dunk.
14:56:42 <mestery> enikanorov_: Are you going to send the mail to the list?
14:56:53 <enikanorov_> mestery: yes
14:57:06 <glebo> enikanorov: ought we time bound the ML + responses time, and set a target date for decision?
14:57:12 <mestery> #action enikanorov_ to send mail to ML around locking issues with bug https://bugs.launchpad.net/neutron/+bug/1382064
14:57:14 <uvirtbot> Launchpad bug 1382064 in neutron "Failure to allocate tunnel id when creating networks concurrently" [High,In progress]
14:57:28 <mestery> OK, 3 minutes left folks.
14:57:29 <regXboi> I'd like to point out that a solution to that problem may also buy you multi-master for essentially free
14:57:32 <mestery> Anything else quick this week?
14:57:33 <glebo> enikanorov: decision specifically for if we do the test or not
14:57:44 <marios_> i have a quick question/clarification
14:57:54 <marios_> wrt the functional tests coverage for technical debt - we *are* talking about in-tree functional tests right (not tempest). I have starting poking at the dhcp_agent (non-existant in-tree functional tests afaics) testing and want to make sure I don't go off on a tangent
14:57:55 <ajo> regXboi: +1 I was thinking of that, but at cost of higher query inter-locking...
14:57:59 <SridarK> mastery: we could continue the planning for the adv services spinout meetup while the TC deliberation is happening.
14:58:06 <enikanorov_> glebo: we will do such test, by sayin 'we' i mean, me and my colleauges
14:58:11 <salv-orlando> I just want to throw this bombshell… I think the application should not make assumptions on the underlying database isolation mode. But don’t take me seriously I just want to stir up the discussion.
14:58:17 <SridarK> mestery: #link https://etherpad.openstack.org/p/advanced-services-kilo-midcycle
14:58:21 <mestery> salv-orlando: lol
14:58:21 <amuller_> marios_: in-tree, yes
14:58:24 <regXboi> ajo: I think we can avoid the query inter-locking at the cost of "eventual consistency" :(
14:58:27 <marios_> amuller_: thx :)
14:58:29 <salv-orlando> I want to make sure the meeting finishes at 15GMT
14:58:31 <mestery> SridarK: That's ongoing yes, we'll get that sorted out, expect email soon
14:58:34 <glebo> enikanorov: ah, cool. Thx.
14:58:41 <enikanorov_> salv-orlando: somewhat true, somewhat not ;)
14:58:43 <SridarK> mestery: thanks
14:58:54 <glebo> enikanorov: so we'll do in parallel then. Good to know.
14:58:55 <amuller_> marios_: Please add me as a reviewer as soon as you have something up :) It should be similar to the L3 agent functional testing I think?
14:59:02 <mestery> OK, we're winding down now.
14:59:08 <marios_> amuller_: indeed and will do
14:59:11 <mestery> If you got an action item, please review post meeting.
14:59:14 <glebo> mestery: action to enikanorov for doing the test in parallel and reporting back?
14:59:16 <mestery> I'll walk through those next week at the meeting.
14:59:23 <ajo> marios_, add me too ;)
14:59:26 <marios_> ajo: ack
14:59:42 <blogan> mestery: lbaas feature branch reviews
14:59:42 <mestery> We'll see you all next week!
14:59:47 <mestery> #endmeeting