21:02:40 <mestery> #startmeeting networking
21:02:41 <openstack> Meeting started Mon Nov 24 21:02:40 2014 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:44 <carl_baldwin> mestery: pong
21:02:45 <openstack> The meeting name has been set to 'networking'
21:02:50 <mestery> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda
21:02:53 <SumitNaiksatam> hi all!
21:02:58 <mestery> #topic Announcements
21:03:09 <mestery> I'll reiterate the Kilo Schedule to folks this week once again:
21:03:10 <mestery> #link https://wiki.openstack.org/wiki/Kilo_Release_Schedule
21:03:18 <mestery> #info Kilo-1 date is 12-18-2014
21:03:28 <mestery> We're still a few weeks away from that, but it will come faster than you think :)
21:03:43 <lukasa_home> Hi all. =)
21:03:48 <mestery> I also wanted to highlight the following spec review
21:03:49 <mestery> #link https://review.openstack.org/#/c/136514/
21:04:02 <mestery> The purpose is to codify in the repository the priorities for Kilo in Neutron
21:04:16 <mestery> Rather than a wiki, following what nova is doing and putting it in the specs repository seemed like a good idea.
21:04:43 <mestery> One more spec announcement for everyone
21:04:44 <mestery> #link https://review.openstack.org/#/c/136823/
21:04:58 <mestery> That review adds an "IPv6 Impact" section to the template, so any in-flight specs will need to be respun to add that.
21:05:19 <mestery> #info https://review.openstack.org/#/c/136823/ adds "IPv6 Impact" section, requiring a re-spin of in-flight specs
21:05:28 <mestery> Any questions on the spec updates?
21:06:11 <mestery> #topic Bugs
21:06:11 <enikanorov> mestery: please shift bugs to the end of the meeting
21:06:17 <mestery> enikanorov: Ha! :)
21:06:19 <mestery> OK, will do sir.
21:06:20 <mestery> #undo
21:06:21 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x1f11f90>
21:06:30 <mestery> #topic Docs
21:06:31 <enikanorov> thanks, for some reason i thought the meeting 1 hour later
21:06:34 <mestery> emagana: You're up early today sir :)
21:06:42 <mestery> enikanorov: Happens to the best of us :)
21:06:46 <emagana> mestery: Nice!
21:07:04 <emagana> Last friday we have the networking guide meeting
21:07:19 <emagana> The most important is the agreement on pushing all DVR and L3 HA documentation
21:07:49 <mestery> emagana: Pushing, as in merging, or pushing as in doing it later?
21:08:05 <emagana> The expect deadline for that the networking will be January, 30 2014
21:08:16 <emagana> sorry, pushing as in merging
21:08:18 <emagana> :-)
21:08:25 <mestery> #info Networking Guide deadline is 1-30-2015
21:08:32 <mestery> emagana: thanks for clarifying
21:08:47 <emagana> but those features will be explain as new functionality not ready for production
21:08:58 <mestery> emagana: Have you pulled in carl_baldwin and armax for the DVR work, and amuller for L3 HA?
21:09:07 <emagana> I told the Docs guys that we should change that as soon as we have Kilo out of the door  ;-)
21:09:28 <mestery> emagana: Makes sense
21:09:54 <emagana> Admin guide will be fixed once we complete the networking one
21:10:05 <emagana> (a bunch of copy & paste)
21:10:20 <armax> emagana, mestery: there’s quite a bit of material already
21:10:28 <armax> it just needs to be put together
21:10:39 <mestery> armax: Most of thati s on the wikis, right?
21:10:39 <emagana> armax: I do agree!
21:10:45 <armax> mestery: correct
21:10:59 <emagana> swami and vinod are helping on the DVR staff
21:11:08 <mestery> #info DVR sections of the Networking Guide can be pulled from the DVR wiki pages
21:11:12 <mestery> emagana: Excellent!
21:11:41 <emagana> I haven't reviewed and updated the bug list in our wiki but I will do this week
21:11:58 <mestery> emagana: Excellent!
21:12:06 <mestery> #action emagana to update bug list for docs on the meeting wiki page
21:12:10 <emagana> nothing else in the top of my mind
21:12:24 <mestery> Thank you for the update emagana.
21:12:30 <mestery> Any questions around docs from anyone?
21:12:38 <emagana> If someone wants to attend the networking guide meeting just let me know, we want to keep the team small but we can welcome more hands
21:13:16 <mestery> #info Anyone interested in attending Networking Guide meeting, reach out to emagana
21:13:54 <swami> hope i have already mentioned my interest in reviewing the network guide
21:14:21 <emagana> swami: you will be added in the review list  ;-)
21:14:44 <swami> emagana: thanks
21:14:58 <mestery> Thanks for the update emagana!
21:15:06 <mestery> #topic Services Split Update
21:15:09 <mestery> #link https://review.openstack.org/136835
21:15:17 <mestery> Thanks to dougwig, we have a spec proposed now!
21:15:18 <mestery> Thanks dougwig!
21:15:32 <markmcclain> awesome
21:15:36 <SumitNaiksatam> dougwig: nice!
21:15:37 * dougwig zips up asbestos underwear
21:15:51 * mestery hands dougwig an extra pair
21:16:09 <mestery> You want to double layer when services are involved dougwig. :)
21:16:13 <dougwig> lol
21:16:29 <mestery> So, I encourage reviews by folks on this one.
21:16:48 <mestery> markmcclain: This is on the TC agenda, though the consensus from ttx and russellb at least was support for this move on the ML.
21:17:17 <markmcclain> yeah.. I think at this point it is up to us to figure out the repo re-org plan
21:17:26 <markmcclain> and then execute and update the metadata
21:17:32 <mestery> markmcclain: Ack
21:18:44 <mestery> #topic Sub Team Charters
21:18:51 <mestery> So, per the meeting last week, I've written a wiki page on this:
21:18:52 <mestery> #link https://wiki.openstack.org/wiki/NeutronSubteamCharters
21:19:06 <mestery> Thanks to dougwig for updating hte LBaaS one in there already.
21:19:17 <mestery> #info Sub-teams to add their Kilo charter on the sub-team charter page.
21:20:08 <mestery> Any questions?
21:20:30 <markmcclain> I think this is a good step to help focus us and better explain to entire community what we're working on
21:20:31 <rkukura> When are these due?
21:21:10 <mestery> rkukura: Good question, I know it's a holiday week in the US, but ideally by next week if that's possible.
21:21:58 <mestery> #info Sub-teams to fill in their charters by next week's Neutron meeting
21:22:04 <rkukura> mestery: Thanks
21:22:09 <mestery> rkukura: yw
21:22:28 <mestery> #topic Bugs
21:22:30 <mestery> enikanorov: You're on now. :)
21:22:35 <enikanorov> ok
21:22:43 <mestery> enikanorov: Also, thank you for running hte bug day last week!
21:22:56 <enikanorov> so we've had bug day on last Friday
21:23:26 <enikanorov> got some numbers decreased. also, it appears that most of the bugs of total 1100 are of low importance
21:24:05 <enikanorov> i just didn't get there to look through them, i think we could get rid of much more and reduce those bug count even more
21:24:08 <enikanorov> anyway
21:24:24 <enikanorov> there is a few issues that worth attention
21:24:39 <enikanorov> https://bugs.launchpad.net/neutron/+bug/1359523
21:24:40 <uvirtbot> Launchpad bug 1359523 in neutron "Security group rules errorneously applied to all ports having same ip addresses in different networks" [High,In progress]
21:24:57 <enikanorov> that one has a patch that introduces conntrack zones
21:25:33 <enikanorov> i believe salv-orlando or salv-mobile has suggested to file a spec and then fix it
21:26:02 <salv-orlando> the thing is that if you add conntrack support it’s not really just a bug fix
21:26:04 <salv-orlando> is it?
21:26:06 <enikanorov> i'm just afraid the person working on the issue will not be following that process. so we might need someone else to do that
21:26:25 <enikanorov> salv-orlando: we already have conntrack support
21:26:33 <enikanorov> we add zones and net-to-zone mapping
21:26:43 <enikanorov> which is kind of similar to local vlan mapping
21:26:49 <salv-orlando> enikanorov: sorry, conntrack zones. Talking about pedantry...
21:27:26 <salv-orlando> anyway, if you think we don’t need a spec because it’s something rather simple anybody will understand that’s fine for me.
21:27:28 <mestery> I havne't reviewed the bug, but I'd tend to agree with salv-orlando's assessment here.
21:27:41 <salv-orlando> I am dumb and I would like to see how these zones work.
21:28:04 <enikanorov> I mean that the issue is severe. Basically it means that network isolation is fundamentally broken, would you agree?
21:28:22 <salv-orlando> said that, either you give me a spec or give me directly the patch, i’m fine either way. But it won’t be fair to the people that have written spec for more trivial piece of work
21:28:48 <armax> I think we’re splitting hair
21:28:58 <enikanorov> salv-orlando: well, it just may be that we don't need to demand specs for trivial work? :)
21:29:17 <salv-orlando> enikanorov: is there a patch ready?
21:29:27 <marios_> https://review.openstack.org/#/c/118274/
21:29:28 <enikanorov> I'm fine having a spec for anything, I'm just afraid that we will loose volutneer that submitted a patch
21:29:32 <enikanorov> salv-orlando: yes
21:29:51 <enikanorov> marios_: thanks
21:29:54 <marios_> np
21:30:33 <armax> enikanorov: my fear is that having double standars sends the wrong message
21:30:42 <salv-orlando> enikanorov: pyeah I even reviewed that
21:31:04 <armax> someone else more eager to participate can always take over
21:31:12 <enikanorov> armax: agree
21:31:29 <enikanorov> but I also don't like this road of 'someone else more eager'
21:31:39 <armax> so let’s determine if a spec is really appropriate for that work
21:31:44 <enikanorov> especially after going over 200 bugs
21:31:50 <mestery> armax: ++
21:31:55 <armax> if it isn’t fine, if it is, I wouldn’t worry about losing the volunteer
21:32:17 <enikanorov> well, in fact, fixing this is what matters, of course
21:32:26 <armax> enikanorov: so volunteer?
21:32:26 <armax> :)
21:32:39 <enikanorov> ok, why not :)
21:32:53 <armax> seriously though, I’d say let’s move on
21:33:06 <mestery> enikanorov: Any other bugs to highlight this week?
21:33:08 <armax> we can take this offline
21:33:20 <enikanorov> https://bugs.launchpad.net/neutron/+bug/1332450
21:33:22 <uvirtbot> Launchpad bug 1332450 in neutron "br-tun lost ports/flows if openvswitch restart" [High,Confirmed]
21:33:30 <otherwiseguy> I'm generally ok with fixing horribly broken security-related bugs without specs even if things are a little complicated. That is why we have leadership. To make calls on things that might be exceptions to more general rules. :)
21:33:43 <enikanorov> quite old bug, still happens though
21:33:59 <enikanorov> and i think it fits in general direction of this release cycle
21:34:58 <mestery> enikanorov: Wasn't there a ML thread on this very topic recently?
21:35:29 <enikanorov> yes, i think I saw something related. unfortunately there are too many threads nowadays
21:35:33 <russellb> git diff
21:35:42 <russellb> gah ... 2nd time i did that today.
21:35:42 <mestery> enikanorov: Ack on that :)
21:35:46 <mestery> enikanorov: I'll follow up on this one
21:35:51 <mestery> russellb: :P
21:35:52 <enikanorov> mestery: thanks
21:35:57 <dougwig> russellb: next time, i want to see a password
21:36:05 <enikanorov> the rest of bugs remain the same from the last meeting
21:36:13 <enikanorov> no new failures in the gates
21:36:33 <mestery> enikanorov: Thanks for the update!
21:36:34 <russellb> dougwig: maybe that is my password ... cleverly disguised to look like a simple git command
21:36:46 <mestery> #topic Open Discussion
21:37:01 <mestery> Anything else folks, or shall we close early and give everyone back 24 minutes or so?
21:37:09 <enikanorov> mestery: may I borrow some time for the old topic of transaction isolation?
21:37:16 <mestery> enikanorov: Absolutely!
21:37:52 <enikanorov> ok, so far we have a consensus on the fact that changing tx isolation level to READ COMMITTED makes retry logic work for mysql
21:38:17 <enikanorov> so I'd like to ask cores opinion on moving to this isolation level project-wise
21:38:35 <enikanorov> (given the fact that it is already a default level for postgres)
21:39:12 <dougwig> jaypipes had a pretty strong objection on the ML.
21:39:22 <salv-orlando> I think somebody pointed out this really is something that you want to control on a transaction bases
21:39:23 <enikanorov> dougwig: i believe he has agreed in the last emails
21:39:25 <salv-orlando> basis
21:39:34 <jaypipes> dougwig: actually, my objection was rescinded :)
21:39:41 <mestery> lol
21:39:47 <enikanorov> salv-orlando: no, the question is really to move to another level, not on ber tx basis
21:40:00 <dougwig> ahh, ok.  must be my dislike of nested transaction spaghetti had me tune out all but what i wanted.  :)
21:40:18 <jaypipes> dougwig: and I just noted that the implementation as proposed by enikanorov would be problematic because it would apparently affect the *next* DB transaction isolation level, not the current one.
21:40:33 <enikanorov> jaypipes: that's true.
21:40:36 <dougwig> right, that was my issue as well.  the side effects.
21:40:58 <enikanorov> but aside of that, i think we're in early release  cycle now where we can test new isolation level for mysql
21:41:03 <enikanorov> and move back if needed
21:41:05 <salv-orlando> if you globally move to read committed, than every trans behaviour changes - and you’ll read the values as being changed by other transactions. Generally this should not be a problem, but can we be sure of that? I think there might be a few transactions which depend on the assumption that the values they handle won’t change during the transaction
21:41:12 <enikanorov> especially given that the change is trivial
21:41:25 <salv-orlando> but I am happy to experiment
21:41:27 <enikanorov> salv-orlando: correct.
21:42:58 <enikanorov> fine then, let's experiment :)
21:43:22 <salv-orlando> jaypipes: what’s your opinion on read committed and tipical isolation as for ACID properties?
21:43:56 <salv-orlando> I’m asking because they thought me in school that read committed is not real isolation for ACID transations....
21:44:18 <salv-orlando> but perhaps they thaught me wrong ;)
21:44:20 <enikanorov> salv-orlando: that's also true
21:44:22 <enikanorov> but
21:44:22 <jaypipes> salv-orlando: it doesn't affect ACID properties other than the "I" in ACID, just what you can "see" within a transaction
21:44:35 <carl_baldwin> Remember that just because Postgres does it, doesn’t mean we’ve given it enough testing already.  Just saying.
21:44:47 <jaypipes> salv-orlando: if you are wondering if it's dangerous or something, then the answer is no, it's not.
21:45:15 <jaypipes> or at least, not in the way that enikanorov's proposed code is doing
21:45:28 <salv-orlando> jaypipes: not dangerous. definetely not. It’s just that I usually design transactions with repeatable read isolation in mind… that’s it.
21:46:05 <enikanorov> the general problem is brobably that HA and ACID can't be achieved simultaneuosly
21:46:17 <armax> salv-orlando, jaypipes I would imagine that the application code need to make up for the fact that there’s been a change n isolation level, if stronger isolation is exceptionally required
21:46:18 <salv-orlando> anyway, let’s put the code in operation, let’s spin it through the gate a few times, and see if there are unexpected surprises
21:46:40 <jaypipes> salv-orlando: nope, there's nothing wrong with enikanorov's approach. it's a good strategy. I tested it pretty thoroughly, and the retry loop works properly with READ COMMITTED mode, whereas the SELECT would return the same thing if REPEATABLE READ were used.
21:47:31 <jaypipes> armax: READ COMMITTED can be used for these situations where a retry loop was used to replace a SELECT FOR UPDATE ... UPDATE strategy in the previous code.
21:48:04 <salv-orlando> jaypipes: indeed I am not worried at all about enikanorov’s code… but about all the other transactions which might not work with READ COMMITTED. On the other hand postgres has been actually already running these transactions in read committed mode, so we might be talking about a problem that does not exist
21:48:06 <armax> jaypipes: makes sense
21:48:48 <jaypipes> salv-orlando: yeah, I think it's probably fine to make everything READ COMMITTED mode, to be honest.
21:49:04 <salv-orlando> jaypipes: If you think that, I am with you.
21:49:12 <jaypipes> salv-orlando: since it's easier than trying to solve the long-running transaction change isolation level problem
21:49:31 * salv-orlando can relax because now has someone to blame
21:49:35 <jaypipes> :)
21:49:57 <jaypipes> salv-orlando: good, relax. because I'm just about to push Review on your micro-versions bp. :)
21:50:29 <salv-orlando> jaypipes: my micro-version bp just pretty much says “sorry we can’t do micro versions for kilo"
21:51:08 <salv-orlando> usually people write spec to justify what they want to do. I write specs for justifying why I won’t do something I am supposed to do
21:51:15 <salv-orlando> the apotheosis of the procrastinator
21:51:24 <jaypipes> hehe
21:51:32 <enikanorov> at least you write specs!
21:52:16 <marios_> (since we said we'd visit agent tech debt stuff here for now) just wanted to mention i made a start on the in-tree dhcp agent functional tests @ https://review.openstack.org/#/c/136834/1 EOF
21:52:32 <mestery> marios_: Thanks for starting that! :)
21:52:58 <mestery> OK, thanks for dropping by today folks!
21:52:58 <marios_> mestery: thanks, grateful for reviews/sanity check - not sure if I've understood the mandate correctly ;)
21:53:10 <mestery> For those in the US, enjoy Thanksgiving this week!
21:53:28 <mestery> marios_: lol :)
21:53:28 <mestery> #endmeeting