20:00:08 <xgerman> #startmeeting Octavia
20:00:12 <openstack> Meeting started Wed Nov  4 20:00:08 2015 UTC and is due to finish in 60 minutes.  The chair is xgerman. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:16 <johnsom> o/
20:00:16 <openstack> The meeting name has been set to 'octavia'
20:00:19 <sbalukoff> Howdy folks!
20:00:26 <TrevorV> o/
20:00:27 <xgerman> #chair blogan johnsom
20:00:28 <crc32> hello
20:00:28 <openstack> Current chairs: blogan johnsom xgerman
20:00:48 <xgerman> Agenda: https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Meeting_2015-11-04
20:00:52 <blogan> hello
20:00:54 <xgerman> #link https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Meeting_2015-11-04
20:01:05 <xgerman> #topic Announcements
20:01:06 <bana_k> hi
20:01:28 <xgerman> Great summit!!
20:01:35 <xgerman> Design session: #link https://etherpad.openstack.org/p/mitaka-neutron-next-adv-services
20:01:49 <Aish> o/
20:01:58 <ajmiller> hi
20:02:13 <bharathm> o/
20:02:39 <johnsom> #link https://www.openstack.org/summit/tokyo-2015/videos/presentation/load-balancing-as-a-service-liberty-and-beyond
20:02:40 <xgerman> Talk #link https://www.openstack.org/summit/tokyo-2015/videos/presentation/load-balancing-as-a-service-liberty-and-beyond
20:02:40 <blogan> someone added that they wanted the ability to specify vip_port_id
20:02:42 <sbalukoff> Short agenda today, eh.
20:02:59 <blogan> i don't like that ability
20:03:00 <johnsom> #link https://www.openstack.org/summit/tokyo-2015/videos/presentation/rsvp-required-hands-on-lab-install-and-configure-openstack-octavia
20:03:30 <TrevorV> #link https://etherpad.openstack.org/p/mitaka-neutron-next-adv-services
20:03:39 <sbalukoff> blogan: So the idea is that they specify the VIP by assigning it to a port first?
20:04:14 <xgerman> sounds like OpenDiscussion topic?
20:05:03 <blogan> yeah lets shelve until open discussion
20:05:11 <xgerman> #topic Brief progress reports
20:05:24 <sbalukoff> Not a whole lot to report from my front since the summit.
20:05:30 <xgerman> same here
20:05:41 <sbalukoff> Trying to finish up some documentation before I go on vacation.
20:05:50 <sbalukoff> Also, I will be on vacation for the next week starting Friday.
20:05:52 <sbalukoff> So... yeah.
20:05:59 <crc32> I'm finishing the neutron-lbaas side of the event stream. nothing to report. I'm looking for more stuff to work on after this if any one has some suggestions.
20:06:00 <johnsom> #link https://wiki.openstack.org/wiki/Mitaka_Release_Schedule
20:06:11 <johnsom> FYI, Mitaka 1 is coming up very soon
20:06:18 <johnsom> Week of Dec 1
20:06:18 <xgerman> yeah, indeed
20:06:27 <sbalukoff> Oh, wow.
20:06:30 <blogan> geez
20:06:39 <blogan> i alwasy forgot how close -1 is to the summit
20:06:42 <sbalukoff> Ok...  time to get some of those delayed features landed.
20:06:59 <xgerman> and also the release is in Feb — so not a ton of time
20:07:06 <sbalukoff> Yep.
20:07:08 <minwang2> i made the tempest scenario test for octavia work and a lot of patches need to be reviewed by you guys
20:07:19 <johnsom> Yeah, I plan to be aggressive at getting the VRRP bugs fixed so we can get it in
20:07:22 <sbalukoff> minwang2: Can you link some of them here?
20:07:24 <minwang2> #link https://review.openstack.org/#/c/240616/2
20:07:25 <minwang2> #link https://review.openstack.org/#/c/224929/
20:07:26 <minwang2> #link https://review.openstack.org/#/c/215359/
20:07:26 <minwang2> #link https://review.openstack.org/#/c/182554/
20:07:28 <sbalukoff> Thanks!
20:07:29 <blogan> samew ith teh container flows
20:07:38 <xgerman> they are also M1?
20:07:51 <sbalukoff> I'll be aggressive about shared pools and L7 once I'm back from vacation.
20:07:56 <minwang2> #link https://review.openstack.org/#/c/240616/2
20:08:00 <xgerman> do we even have a devstack to test them in — or do I need to take you word for it?
20:08:02 <sbalukoff> (Which will give me about 2 weeks before the M1 deadline)
20:08:06 <minwang2> #link https://review.openstack.org/#/c/224929/
20:08:06 <minwang2> #link https://review.openstack.org/#/c/215359/
20:08:07 <minwang2> #link https://review.openstack.org/#/c/182554/
20:08:15 <blogan> i told you, this will work in devstack
20:08:22 <minwang2> #link https://review.openstack.org/#/c/224929/
20:08:26 <sbalukoff> blogan: awesome!
20:08:27 <blogan> we'll certainly need a job setup for it
20:08:30 <minwang2> #link https://review.openstack.org/#/c/215359/
20:08:37 <minwang2> #link https://review.openstack.org/#/c/182554/
20:08:37 <xgerman> yeah, do I need magnum?
20:08:50 <blogan> now they'll work in devstack VMs, we will need to spend some time on actuallyg etting some kind of container compute set up
20:09:00 <xgerman> oh, ok
20:09:03 <blogan> xgerman: no just use regular nova, the gist of it is that its just rebuilding VMs
20:09:09 <blogan> instead of hot plugging
20:09:17 <xgerman> understood
20:09:30 <sbalukoff> We should also start figuring out the time and location for the mid-cycle hack-a-thon.
20:09:42 <xgerman> +1
20:09:49 <sbalukoff> (Which I guess isn't "progress reports" so... whatever.)
20:09:53 <xgerman> yeah
20:09:57 <xgerman> Open Discussion
20:10:00 <johnsom> On other progress, Canonical backported the keepalived version we need at our request, so we don't have to build it anymore.  We will work on updating that too
20:10:08 <xgerman> so it seems lot’s of reviews are need
20:10:11 <sbalukoff> johnsom: Rad!
20:10:20 <xgerman> +!
20:10:21 <xgerman> +1
20:10:23 <sbalukoff> Yeah.
20:10:23 <blogan> yes lets of reviews, reviewing is the bottleneck
20:10:47 * blogan is guilty of being a bottleneck
20:10:51 <johnsom> Agreed, there are a bunch of reviews that need to get done.
20:10:57 * johnsom Slaps his wrist
20:11:07 <sbalukoff> Haha!
20:11:14 * xgerman gets popcorn to start a big review party
20:11:27 <sbalukoff> So.... action item for next week:  Everyone reviews everything.
20:11:28 <TrevorV> As long as we have those listed, I can help by jumping on those from a pedantic point of view as well :P
20:11:49 <xgerman> yep, that would be good
20:11:58 <sbalukoff> TrevorV: I will be sorely disappointed if I don't see a bunch of -1's.
20:12:14 <TrevorV> Its nice to see I've set an expectation to say the least :P
20:12:19 <johnsom> #link https://review.openstack.org/#/q/openstack/octavia+status:open,n,z
20:12:27 <johnsom> Just a reminder of the summary link....
20:12:38 <xgerman> thanks
20:12:57 <xgerman> ok, it seems that the member status topic disappeared
20:13:02 <xgerman> so
20:13:12 <xgerman> #topic Open Discussion
20:13:17 * dougwig waves from Seattle
20:13:35 <sbalukoff> dougwig: You're here?
20:13:36 <blogan> okay so while dougwig is here, hackathon location
20:13:48 <blogan> or midcycle meetup
20:13:51 <blogan> or whatever its called
20:14:17 <sbalukoff> Ok! I checked with my management and the response I got back was that they'd rather send me to Ireland than host it at our offices (which are getting *very* crowded just now)...  I'm trying to figure out whether that was a backhanded insult.
20:14:18 <dougwig> blogan: let me sync up with mugsie first
20:14:19 <blogan> options are? i've heard london and ireland, both of which are uncertain if many can go
20:14:25 <crc32> https://review.openstack.org/#/c/218735/ <-- can I get more reviews on this?
20:14:28 <sbalukoff> In any case, I'm up for whatever, eh.
20:14:42 <johnsom> Dublin was proposed so it could overlap with designate/kosmos.  I think that was possibly changing due to the travel overhead.
20:14:44 <xgerman> Ireland would be Galway --
20:14:46 <dougwig> Let's talk in channel on Friday.
20:14:55 <dougwig> I'm about to deplane and hit customs.
20:14:58 <blogan> okay
20:15:02 <xgerman> not Dublin
20:15:11 <xgerman> which makes it less attractive for me ;-)
20:15:13 <sbalukoff> dougwig: Sounds good.
20:15:20 <sbalukoff> Ok, table this for now?
20:15:20 <xgerman> +1
20:15:30 <johnsom> I suspect we could still host in Seattle
20:15:43 <xgerman> probably
20:15:44 <TrevorV> #link https://review.openstack.org/#/c/218735/
20:15:50 <blogan> dougwig should host in boise
20:16:00 <sbalukoff> I have one awkward question to ask y'all HP folks:  I hear that HP public cloud is shutting down in a few months. Is this true? And if so, will it affect your ability to contribute to these projects?
20:16:09 <johnsom> Umm, yeah, Boise...
20:16:12 * blogan feels awkward
20:16:22 <xgerman> yes, we are shutting down; no we will keep contributing
20:16:29 <sbalukoff> xgerman: Yay!
20:16:29 <johnsom> http://www.hpcloud.com/
20:16:36 <sbalukoff> On the keep contributing part.
20:16:45 <xgerman> we are now 100% focused on our distro
20:16:49 <johnsom> Sorry you can't get rid of us....
20:16:57 <sbalukoff> Fine by me!
20:17:06 <blogan> rackspace's public cloud grows stronger (kind of)
20:17:29 <TrevorV> Pedantically incorrect blogan
20:17:31 <TrevorV> just saying
20:17:31 <xgerman> yeah, we might need some cloud accounts
20:17:46 <johnsom> We may need to talk with you guys about moving the Sonar gate.  That isn't clear yet.
20:18:27 <blogan> just host a publicly accessible private cloud
20:19:00 <sbalukoff> Heh!
20:19:07 <xgerman> well, we might do that ...
20:19:14 <sbalukoff> I'll poke my management about that.
20:19:25 <blogan> anywho, i'd like to bring up that I think we should start being more strict about having smaller LOC in reviews
20:19:34 <sbalukoff> LOC?
20:19:38 <blogan> lines of code
20:19:42 <sbalukoff> Oh.
20:19:43 <xgerman> blogan +!
20:19:45 <johnsom> After these patches merge right?  grin
20:19:47 <ajmiller> +1
20:19:49 <blogan> yes after
20:20:03 <johnsom> +1
20:20:07 <sbalukoff> Well...  there are a few that won't be very possible with. (Shared pools touches a lot of stuff, for example... and can't easily be broken up.)
20:20:22 <blogan> probably too much to ask people to split them up now, but any new patches that happen should start being relatively smaller
20:20:23 <xgerman> nobody said it would be easy ;-)
20:20:28 <johnsom> I have enough headaches to get VRRP in for M1 than to try to break up Sherif's patch
20:20:35 <blogan> sbalukoff: wehre there's a will, there is a way
20:20:49 <xgerman> ok, so there was the vip topic from earlier
20:20:56 <sbalukoff> blogan: Isn't it more of a pain to do dependent patches?
20:21:14 <blogan> sbalukoff: it only becomes a pain when there are many people involved
20:21:21 <blogan> sbalukoff: if its just yours then its not a pain
20:21:24 <crc32> sbalukoff: yes. For me at least.
20:21:32 <sbalukoff> crc32: +1
20:21:41 <sbalukoff> Still a pain when it's just me.
20:22:07 <blogan> well its a pain to review 1000+ lines in one review, and code starts getting in because of just reviewer attrition
20:22:32 <blogan> i'm guilty of doing this too, i know, we all are, but really i totally get why smaller reviews are better
20:22:34 <sbalukoff> I also dislike how that encourages shorting tests and whatnot...  if I think I can sneak in a 500-line change by skipping 3 or 4 tests I really ought to do...
20:23:02 <sbalukoff> I agree that big patches are a pain.
20:23:05 <crc32> I agree 1000+ lines suck but trying to diff between multiple commit points is confusing.
20:23:11 <sbalukoff> I'm just saying: Sometimes they can't easily be made shorter.
20:23:18 <johnsom> We are trying to be pretty strict with the test coverage too.  The Sonar gate helps with that
20:23:19 <blogan> wlel you could say having a huge review encourages shorting tests too because when its that much code no one will notice missing test cases
20:23:20 <TrevorV> Is there another team that has a defined limit or a guideline we SHOULD be following?
20:23:20 <xgerman> yep, and big patches I will definitely install and test in devstack
20:23:55 <xgerman> I don’t think there are hard and fast rules and some patches are also too small and too focused
20:24:16 <blogan> well neutron tends to go with 500 but there's always exceptions, but not like the exceptions we've allowed
20:24:26 <johnsom> I agree with blogan we have had some monster patches.  I will try to work on making that not happen.
20:24:43 <xgerman> yep
20:24:49 <TrevorV> So we should *try* to limit to 500 as well?
20:25:00 <TrevorV> I'm asking more so we can establish some sort of acceptable limit or something
20:25:00 <xgerman> absolutely - preferably less
20:25:03 <TrevorV> I've only ever worked on this project
20:25:10 <sbalukoff> I just think "tl;dr" is a bad excuse for not reviewing.
20:25:11 <TrevorV> So I don't know what is "normal" ha ha
20:25:19 <blogan> i woudl say thats a good guideline for now, just try to split it up into chunks like that, or somewhere around that
20:25:26 <xgerman> +1
20:25:37 <johnsom> +1
20:25:44 <blogan> sbalukoff: bad excuse yes, but that doesn't take away from the fact that it does happen
20:25:50 <ajmiller> The problem I have as a reviewer is when patches end up addressing more than one major theme.  It isn't so much size as it is mental complexity.  It also isn't fun to have to be jumping between interrelated patches either -- so its more than just size.
20:25:52 <TrevorV> Alright.  I think that can make things difficult when you're talking about inter-dependent code changes, but sure.
20:26:01 <sbalukoff> ajmiller: +1
20:26:06 <xgerman> #decision try to limit patches to 500 LOC
20:26:31 <johnsom> Yes, patches addressing more than one issue is a problem.
20:26:39 <ajmiller> 500 LOC is probably a good point to stop and think about what the patch is doing.
20:26:45 <minwang2> what if you import a third party library which has more than 500 LOC?
20:26:45 <sbalukoff> I would rather "keep patches to one major code theme" be the rule.
20:27:31 <blogan> minwang2: what when woudl that happen?
20:27:34 <johnsom> minwang2 Something is wrong if we are importing third party libraries into our code base
20:27:56 <crc32> minwang2: You included the source of the library in our code base?
20:27:59 <sbalukoff> Just like it doesn't usually make sense to address more than one bug in a patch-- unless the fix for two bugs ends up touching the same bit of code.
20:28:01 <xgerman> import is one line — or am I missing something?
20:28:15 <minwang2> blogan, for instance in the tempest-lib we need to rewrite some of the functions, which turned out to be a lot of LOC
20:28:34 <blogan> minwang2: so break the it by a group of functions
20:28:40 <blogan> break it up
20:28:54 <xgerman> +1
20:29:15 <sbalukoff> What if you can't pass CI with only half the required changes in your patch?
20:29:20 <crc32> +1: A seperate commit for tempest sounds easy enough to seperate.
20:29:21 <minwang2> there will be a lot of dependences
20:29:30 <xgerman> sbalukoff chains are made for that
20:29:32 <dougwig> With the tempest plugin mechanism, we should be able to stop the duo
20:29:39 <dougwig> Dip
20:29:43 <dougwig> Dup
20:29:45 <dougwig> Fuck
20:29:54 <xgerman> well, Rally might not have that problem
20:30:02 <blogan> sbalukoff: there are ways to decompose into smaller reviews to make sure your patch is testing what it needs to and passes the tests
20:30:39 <blogan> sbalukoff: i'm sure there are crazy edge cases where its not possible, but those are exceptions
20:31:02 <blogan> sbalukoff: i'm not saying its easy, but i think its better for the project overall
20:32:26 <sbalukoff> It just seems really ridiculous to me to split up code having to do with one theme into multiple patches just to keep them under an arbitrary line count limit, especially when it involves a lot of work setting up a dependency chain and must be all merged at about the same time. This doesn't actually reduce reviewer workload and just makes things more difficult for the person doing the coding.
20:32:32 <sbalukoff> And that slows velocity.
20:33:06 <blogan> it really doesn't take a lot of work setting up a dependency chain, its just adding commits on top of commits
20:33:34 <xgerman> I also think things can be split intelligently with the right effort
20:33:36 <blogan> now how to split them up so that the tests and the code are i the same commits will take some thought
20:33:37 <sbalukoff> Right. Until you need to modify something at the start. I've had nothing but trouble trying to keep the rest of the chain in sync.
20:33:46 <blogan> git rebase -i
20:33:58 <blogan> everyone's gitfu will improve!
20:34:01 <crc32> I find it hard to imagine how I would be able to assocate lines from one commit with that of another future commit and keep them straight in my head.
20:34:39 <blogan> crc32: if its in a chain your future commit will have those lines from all previous commits
20:34:51 <sbalukoff> That's my point: Y'all probably have no idea how many tests needed to be futzed with to get shared pools working with Neutron LBaaS...  there was *no way* to split that work up into multiple patches.
20:35:02 <sbalukoff> And it's still not merged because we have to make this work with Octavia, too.
20:35:03 <xgerman> also if you have trouble splitting things we might not have a very maintainable design
20:35:41 <TrevorV> http://www.explainxkcd.com/wiki/images/4/4d/git.png
20:35:44 <sbalukoff> xgerman: Yes, Neutron LBaaS is laid out poorly.
20:35:46 <crc32> blogan: yea but then when I fix those lines of code. Poof I fixed them in the future commit. Oops. Now the switch back to the old commit those lines get lost. I'll try my best but I see more errors happening/
20:35:52 <blogan> sbalukoff: its just an something i'm askign for to improve overall quality, there will always be exceptions but i do believe in 95% of cases there are ways to do it logically
20:35:59 <johnsom> The problem here is patches that are 1000's of lines take well over an hour to review.  So you either have to have multiple review sessions, or put it off until you have a big block of time.
20:36:18 <xgerman> sbalukoff so maybe we should have refactored it in the light of the pools
20:36:43 <xgerman> TrevorV +1
20:36:46 <sbalukoff> xgerman: So... you're suggesting I make an even bigger change?
20:36:55 <xgerman> yes
20:37:00 <blogan> crc32: once you get the gitfu down then its not that hard
20:37:19 <sbalukoff> xgerman: It would be quicker to scrap Neutron LBaaS entirely.
20:37:27 <blogan> lol
20:37:34 <blogan> +1?
20:37:37 <blogan> j/k
20:37:57 * xgerman wonders who wrote LBaaS V2
20:38:08 * johnsom wonders the same
20:38:11 <sbalukoff> xgerman: Seriously, your suggestion makes me think you either want to shut down all work on the project, or simply want me to leave.
20:38:14 <blogan> refactorign the neutron-lbaas tests haev always been a want of mine
20:38:35 <crc32> I'll just work to keep commits smaller period. The less I change the less risk I see.
20:38:48 <blogan> sbalukoff: how did you interpret that way?
20:39:07 <sbalukoff> "In order to get your change in, please rewrite the entire project"
20:39:32 <xgerman> oh, no — that’s not what I meant
20:39:44 <blogan> sbalukoff: i read it as maybe the neutron-lbaas code should be targeted for refactor
20:39:44 <xgerman> I just think if something is broken we should aim to fix it
20:39:55 <xgerman> blogan +1
20:40:26 <blogan> anyway we've spent a lot of time on this, i'd say just do a best effort from now on, if it can't be done it can't be done
20:40:30 <sbalukoff> Of course, if someone wants to tackle that, that's great. I don't want it to obstruct key features.
20:41:08 <xgerman> blogan +1
20:41:09 <blogan> though i will of course attempt to break some big ones up that come in just to show it can be done or prove that my 99% rule is totally wrong
20:41:14 <sbalukoff> Also, I'd love to see you refactor that in less than 500 lines of change.
20:41:17 <sbalukoff> Good fucking luck.
20:41:55 <xgerman> well, I am hoping we can do it in small steps as we touch code and don’t need a big swoop
20:42:25 <blogan> i think it could be done in a series of 500 lines of code patches
20:42:30 <dougwig> What color is this shed? :)
20:42:38 <xgerman> still painting
20:42:38 <blogan> clear
20:42:41 <sbalukoff> Right. In the mean time, please don't obstruct my 750-line change because it's basically impossible to split up given the current state of the code tree (if you want, you know, tests written)
20:42:53 <xgerman> we excluded current patches
20:43:00 <xgerman> from the new rule
20:43:16 <xgerman> so there was a VIP discussion we wanted to have
20:43:25 <xgerman> blogan?
20:43:37 <johnsom> New guidelines I think...
20:43:41 <blogan> oh i was just mentioning that someone wanted vip_port_id to be POSTable
20:44:02 <blogan> as in someone can create a port first and then give that port_id and that is used to become their VIP
20:44:18 <blogan> v1 allowed this, but i remember we shot that down in like the first v2 meeting we had here at rackspace
20:44:19 <TrevorV> pros/cons blogan ?
20:44:30 <xgerman> mmh, didn’t we do a patch so users can provide their own VIP
20:44:35 <sbalukoff> I'm trying to remember why it was shot down.
20:44:54 <xgerman> which should address that use case
20:45:14 <xgerman> that you need a port to get a VIP is just how Neutron is broken
20:45:21 <blogan> well one reason is probably how do we know if neutron-lbaas created it and if it shoudl be clenaed up or not
20:45:36 <sbalukoff> Right.
20:45:53 <sbalukoff> We'd have to store that information on how it was created, which we don't want to do.
20:45:58 <blogan> yeah
20:46:15 <TrevorV> The alternative being don't do cleanup... which is worse IMO
20:46:20 <sbalukoff> I guess we could give the user the option of leaving the VIP alone when the loadbalancer is deleted.
20:46:37 <blogan> anotehr is there will be drivers for octavia taht do vip allocation without a neutron port, and that port will just be an unused resource, or we can't use it at all
20:46:41 <xgerman> well, if the user gives us a VIP we don;t need the port
20:46:59 <sbalukoff> So, if the user is advanced enough to provide a VIP at loadbalancer creation, they ought to be advanced enough to tell Neutron LBaaS not to clean up the VIP when it's deleted.
20:47:20 <xgerman> well, we only need to clean up if we allocated a port
20:47:33 <xgerman> if the user gives us the address ge can clean up his port himself
20:47:45 <blogan> in this case the user gives us the port
20:47:47 <TrevorV> sbalukoff so like "vip_port_id=IAMID, vip_cleanup=True"?
20:48:04 <xgerman> blogan and I think we don’t do that and ask him to give us the VIP instead
20:48:05 <sbalukoff> TrevorV: something like that, yes.
20:48:10 <blogan> but there's no discernible difference between a user creating the port an neutron-lbaas creating the port on the user's behalf
20:48:19 <sbalukoff> thought the default ought to be to clean up the port, IMO.
20:48:26 <blogan> xgerman: ok well thats already tehre
20:48:29 <TrevorV> Sure, that'd be fine too sbadia
20:48:31 <TrevorV> sbalukoff
20:48:34 <TrevorV> (ugh)
20:48:42 <sbalukoff> strongbadia?
20:48:46 <xgerman> blogan hence I like it ;-)
20:49:27 <blogan> my opinion is to wait and see if that is somethign a lot of people want
20:49:40 <blogan> instead of one comment made on the etherpad
20:50:03 <xgerman> I am inclined to ask them to manage port themselves and just provide VIP
20:50:15 <sbalukoff> Also, if whoever wants that feature *really* wants it... well, they have access to gerrit / git, too.
20:50:23 <johnsom> +1 wait and see if an RFE is filed
20:50:33 <xgerman> johnsom +1
20:50:37 <sbalukoff> +1
20:50:47 <xgerman> we can always mark the RfE as opinion ;-)
20:51:33 <xgerman> ok, anything else?
20:52:07 * blogan shaves a yak
20:52:27 <TrevorV> \o
20:52:40 <xgerman> #endmeeting