20:00:29 <xgerman> #startmeeting octavia
20:00:30 <openstack> Meeting started Wed Jul 22 20:00:29 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:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:33 <openstack> The meeting name has been set to 'octavia'
20:00:41 <ajmiller> o/
20:00:44 <madhu_ak> hi
20:00:46 <bharath__> o/
20:00:50 <johnsom> o/
20:00:54 <TrevorV> o/
20:00:54 <jwarendt> o/
20:01:12 <xgerman> #topic Announcements
20:01:17 <xgerman> #chair blogan
20:01:18 <openstack> Current chairs: blogan xgerman
20:01:32 <sbalukoff> Howdy, howdy!
20:01:39 <TrevorV> I don't think blogan will be online for this.  He's off today
20:01:45 <xgerman> ok
20:01:49 <xgerman> GSLB - http://eavesdrop.openstack.org/meetings/gslb_discussion/2015/gslb_discussion.2015-07-21-16.04.html
20:02:18 <xgerman> dougwig asked me to mention that we need to review the spec https://docs.google.com/document/d/1nw5jVn0hjmhlhkZJAohx-gqRkkbVhMMJ79Pogd0ysEk/edit#heading=h.lcnfr8uk78d and provide an LBaaS perspective
20:02:34 <sbalukoff> Yep, we do.
20:02:45 <xgerman> :-)
20:03:07 <xgerman> we also had a chat about V2 Horizon Panels - http://eavesdrop.openstack.org/meetings/horizon_lbaas_v2_ui_discussion/2015/horizon_lbaas_v2_ui_discussion.2015-07-16-16.00.html
20:03:23 <TrevorV> #link https://docs.google.com/document/d/1nw5jVn0hjmhlhkZJAohx-gqRkkbVhMMJ79Pogd0ysEk/edit#heading=h.lcnfr8uk78d
20:03:41 <TrevorV> #link http://eavesdrop.openstack.org/meetings/horizon_lbaas_v2_ui_discussion/2015/horizon_lbaas_v2_ui_discussion.2015-07-16-16.00.html
20:04:17 <xgerman> Vivek volunteered to lead that effort and I think we are close to have a repo for it
20:04:34 <sbalukoff> Yay!
20:04:35 <xgerman> vivek-ebay
20:04:45 <TrevorV> Very cool.
20:05:09 <xgerman> Of course we had a great mid cycle :-)
20:05:39 <johnsom> Yeah, great to see everyone!
20:05:43 <sbalukoff> +1
20:05:45 <madhu_ak> +1
20:06:05 <TrevorV> Agreed.
20:07:13 <xgerman> #topic Brief progress reports
20:07:25 <sballe> o/
20:07:29 <minwang2> o/
20:07:39 <TrevorV> I have yet to fully test my review, but if anyone wants to do a review based on concepts or code layout please do:
20:07:49 <johnsom> I have mostly been catching up on reviews and having conversations about Active/Standby, Health Manager, and Housekeeping.
20:07:52 <TrevorV> #link https://review.openstack.org/#/c/202336/
20:08:07 <sballe> @TrevorV I can do that. Thanks for the link
20:08:15 <TrevorV> No problem sbadia
20:08:18 <TrevorV> sballe, ****
20:08:35 <minwang2> i will take a look at after the meeting
20:08:37 <johnsom> I plan on putting some time into the REST driver
20:08:48 <sbalukoff> I'm making good progress on the L7 functionality addition to the Neutron LBaaS reference driver (will tackle Octavia after this). Should have something semi-functional up for review later tonight. Have plans to go over this with TrevorV on Friday.
20:09:00 <sballe> Cool!
20:09:10 <xgerman> +1
20:09:17 <johnsom> +1
20:09:23 <minwang2> i am working on the heath check, still work in progress, and need to add 2 child thread later
20:09:40 <madhu_ak> Likewise, if anyone wants to do a review, please do:
20:09:46 <madhu_ak> #link https://review.openstack.org/#/c/196238/
20:09:50 <sbalukoff> Also, I hope to finally update roadmap documents either later this week or early next week. I have IBM engineers looking to get involved in the project, and I figure this is a good way to get them up to speed on where we're going. I'll be looking for a lot of feedback on this to make sure I'm still aware of where we're going .xD
20:10:00 <bharath__> I am writing unit tests for housekeeping to spin up spare amphora.
20:10:11 <sbalukoff> (You know, those reviews that have been in gerrit for... about a year now.)
20:10:40 <madhu_ak> Also, I am working on session persistence scenario tests for lbaasv2
20:10:45 <sbalukoff> Nice!
20:11:00 <TrevorV> Awesome madhu_ak
20:11:02 <johnsom> Yeah, those are really out of date now.  blogan and I took a pass on the 1.0 for review, but it still needs some work
20:11:22 <xgerman> yep
20:11:30 <sbalukoff> johnsom: Sounds good! I am a documentation fiend after all. XD
20:11:38 <xgerman> just got asked today for an architecture diagram :-)
20:11:54 <sbalukoff> Time to break out those graphviz skills for me again, I guess. XD
20:12:13 <johnsom> Ugh, graphviz, all yours!
20:12:15 <sballe> xgerman: We'll need to create a diagram tht fir our Security/arch reviews
20:12:36 <xgerman> yep
20:12:56 <sbalukoff> Also:  Um...  http://octavia.io/ appears to be down?
20:13:05 <sbalukoff> (I was going to see whether graphviz was rendering there...)
20:13:08 <johnsom> Yeah, we saw that oo
20:13:12 <sballe> sbalukoff: I would be happy to review or work with you on this if you are ok with that
20:13:24 <johnsom> I think it did render ok
20:13:29 <sballe> This being hte architecture diagram
20:13:37 <sbalukoff> sballe: Sure! Let me get a couple other things off my plate, and I'd be happy to do that, eh!
20:13:46 <sballe> sbalukoff: cool! thx
20:14:11 <TrevorV> sballe, sbalukoff I'm no slouch when it comes to docs either, so if you guys want any assistance there, hit me up as well :D
20:14:24 <sballe> :)
20:14:25 * TrevorV did make some of our diagrams and stuff :D
20:14:34 <sbalukoff> TrevorV: Bwahahaha! I'm so sending some of this your direction.
20:14:36 <xgerman> #action sballe, TrevorV, sbalukoff create architetcure diagram
20:15:18 <sbalukoff> Who is in charge of octavia.io? Can we get them to fix it, please? ;)
20:15:57 <dougwig> we're full-on openstack now, we could use the dev docs official site.
20:16:04 <johnsom> rm_work Run ocatvia.io I think
20:16:05 <sballe> +1
20:16:18 <johnsom> That would be nice
20:16:22 <sbalukoff> dougwig: That's also a good idea!
20:16:34 <xgerman> dougwig +1
20:16:41 <ajmiller> +1
20:16:47 <sbalukoff> I would still like to see octavia.io fixed...  as I mentioned it in my "Statement of Use" justification for the USPTO "Octavia" trademark...
20:17:05 <rm_work> johnsom: ptoohill and I run it
20:17:13 <rm_work> what is the issue?
20:17:19 <rm_work> sorry, distracted by internal stuff
20:17:25 <rm_work> oh it's down
20:17:27 <rm_work> yeah i'll look
20:17:27 <johnsom> Yep
20:17:45 <xgerman> cool
20:17:50 <xgerman> I guess we slid into
20:17:53 <sbalukoff> And the status of that is that it's gone through the hands of their paralegal assigned to review, and has been forwarded on to the official attorney who makes a decision on the validity of the trademark claim. It would be unfortunate to miss out on the trademark because one of the sites that shows Octavia in use is down.
20:18:03 <sbalukoff> Thanks, rm_work!
20:18:06 <rm_work> yeah
20:18:12 <xgerman> #topic Open Discussion
20:18:27 <xgerman> yeah, it feels we have been there for a while :-)
20:18:32 <ajmiller> There are some neutron-lbaas reviews that could use some love:
20:18:34 <sbalukoff> Haha
20:18:41 <TrevorV> So minwang2 and I were just having a discussion concerning health manager and housekeeping (yes, again).
20:18:59 <xgerman> enlighten us
20:19:04 <ajmiller> #link https://review.openstack.org/#/c/179818/
20:19:04 <ajmiller> Needs core reviewer love
20:19:04 <minwang2> https://review.openstack.org/#/c/160061/10
20:19:14 <ajmiller> #link https://review.openstack.org/#/c/180436/
20:19:14 <ajmiller> Likewise
20:19:23 <ajmiller> #link https://review.openstack.org/#/c/160460/
20:19:23 <ajmiller> xgerman & blogan gave -1, have those questions been answered?
20:19:24 <rm_work> ah I just submitted https://review.openstack.org/204744 so we can stop rechecking the py34 false-positives
20:19:25 <TrevorV> In min's review there is a line that sets the "busy" field back to "False" to insinuate that the amphora could be "failed-over again" after one failover has occurred
20:19:25 <sbalukoff> Cool!
20:19:30 <rm_work> #link https://review.openstack.org/204744
20:19:31 <johnsom> TrevorV Last time I looked it was pretty close to done
20:19:37 <ajmiller> #link https://review.openstack.org/#/c/193887/
20:19:37 <ajmiller> blogan gave -1, rebased, and fixed the CI problem.  Give him a chance to change his review?
20:19:42 <sbalukoff> I'll see what  I can do to spend some time on that.
20:19:44 <TrevorV> However, in the failover process, we delete the stale amphora and then create the new amphora.
20:19:55 <sbalukoff> (It's great to be working on this project again, BTW.)
20:20:13 <TrevorV> The problem here, the health table, if updated to "False" for busy would mean you could fail-over an amphora that now doesn't exists.
20:20:19 <TrevorV> exist***
20:20:28 <TrevorV> So, I don't particularly think that update needs to happen.
20:20:31 <TrevorV> That's one.
20:20:35 <johnsom> Ah, yes, the ID doesn't move.  Good point
20:21:00 <TrevorV> The other, the entry for the stale amphora in the amphora health table should be cleaned up by another thread/process/whatever in the housekeeping agent, not the amphora health agent.  Thoughts?
20:21:12 <xgerman> +1
20:21:16 <minwang2> +1
20:21:27 <crc32> We also need to dscuss moving to reddis instead of MySQL since it looks like udps start getting dropped after around 500 UDP packets per secnd
20:21:28 <sbalukoff> +1
20:21:46 <johnsom> Yes, we removed all of the database cleanup code from health manager
20:21:48 <xgerman> you did memory tables in mysql?
20:21:48 <crc32> I was doing some testing last night.
20:22:05 <crc32> yes I tried the engin=Memory and it still sucked
20:22:23 <xgerman> ok, I was afraid of something like that
20:22:33 <TrevorV> Just clearing that up johnsom.  So bharath__ did you want to add that in your review, or should someone make a dependent review on top of your housekeeping agent to add the bits for cleanup?
20:22:34 <sbalukoff> crc32: Not a bad idea for extremely active state storage in any case.
20:22:41 <johnsom> Yeah, we had planned on Reddis.  Didn't know we had to move to it so quickly
20:23:01 <xgerman> let’s get some more numbers
20:23:12 <crc32> I figured as well. I'm guessing we can turn persist off on reddis so it doesn't have to be burdened with flushing to disk
20:23:16 <sballe> xgerman: +1
20:23:17 <johnsom> I think minwang2 was going to give him the code
20:23:37 <sbalukoff> crc32: Are you looking on adding that functionality yourself?
20:23:49 <sbalukoff> Or just putting it out there as something that needs to be prioritized?
20:23:59 <xgerman> reddis is a big change for deployment
20:24:09 <xgerman> so I would rather do some tests on our side
20:24:17 <sbalukoff> xgerman: Action item that?
20:24:18 <minwang2> i talked to bharath_, he can put those dbcleanup code in housekeeping, likewise the unit test
20:24:36 <TrevorV> awesome johnsom minwang2 sounds good.
20:24:37 <xgerman> #action HP do performance tests with health manager and mysql in memory DB
20:24:42 <johnsom> crc32 Thanks for doing the testing!
20:24:44 <sballe> xgerman: +1
20:24:51 <crc32> I really wanted to write our distrubuted data structure but all the ACME wheel advocates here are claiming reinvention of their patent.
20:24:53 <xgerman> johnsom +!
20:24:54 <sbalukoff> minwang2: Great!
20:24:58 <sballe> Also I am assuming we could support both?
20:25:34 <sbalukoff> Er... was the suggestion to drop mysql entirely, or to just use redis for things like the very active amphora state information?
20:25:39 <johnsom> #action minwang2 to make sure the database cleanup code gets moved to housekeeping
20:25:46 <sbalukoff> Because I figure that configuration in mysql probably still makes the most sense.
20:25:48 <bharath__> TrevorV: minwang2 showed me the code from her previous patch. I could add include it in my review
20:26:00 <sballe> sbalukoff: +1
20:26:03 <xgerman> sbalukoff just use reds for high performance pieces
20:26:10 <johnsom> I only wanted the health table to move to Reddis.  The rest would stay with mysql
20:26:16 <sbalukoff> Ok, cool! That's what I would push for as well.
20:26:17 <xgerman> yep
20:26:32 <crc32> https://review.openstack.org/201882 <-- how do I reoncile this with mins code?
20:26:54 <sballe> xgerman: the problem is if we have to share infra and the rest of openstack is using a sahred mysql DB. We need to be able to plugin into that
20:27:05 <xgerman> yep
20:27:32 <xgerman> hence getting more numbers
20:27:33 <sballe> so to me reddis is an optimization
20:27:33 <johnsom> crc32 minwang2 is going to add the required fork code to health manager.  There will be a stub to plug in your code
20:27:54 <sbalukoff> sballe: It surely is. But it sounds like that optimization would not be premature.
20:28:02 <rm_work> sballe: not an optimization if it literally *won't work* with basic mysql, which seems to be the case from our testing
20:28:11 <rm_work> and Redis is already used other places in openstack
20:28:11 <sbalukoff> But we'll know more when we get a second opinion on the numbers.
20:28:17 <rm_work> so not really a concern IMO
20:28:23 <sbalukoff> rm_work: +1
20:28:35 <sballe> sbalukoff: xgerman +1 on getting the numbers to make a decision
20:29:11 <sbalukoff> In any case, crc32: Thanks for helping us not to shoot ourselves in the foot.
20:29:21 <xgerman> +1
20:29:22 <sballe> +1
20:29:33 <crc32> we knew it was comming.
20:29:38 <crc32> we just needed code to show it.
20:29:39 <johnsom> crc32 is there any test framework stuff you can share for the performance testing?
20:29:51 <rm_work> yes, have been saying for a long time that mysql will likely not work for this frequency
20:29:53 <rm_work> and scale
20:30:17 <crc32> no frame work. Just a loop that sends X udp packets per second.
20:30:19 <sbalukoff> rm_work: Well, I wasn't there, now was I? So it doesn't count. ;)
20:30:47 <johnsom> Ok
20:31:07 <sballe> crc32: Can you share your script or tests?
20:31:22 <crc32> sure I'll check it in on my review.
20:31:30 <rm_work> sbalukoff: heh
20:31:41 <sballe> crc32: great thanks
20:33:32 <xgerman> ok, more open questions?
20:33:56 <sbalukoff> Move to adjourn?
20:34:01 <dougwig> 2nd
20:34:03 <crc32> no keep talking
20:34:03 <xgerman> #endmeeting