20:01:03 <dougwig> #startmeeting octavia
20:01:04 <openstack> Meeting started Wed May 18 20:01:03 2016 UTC and is due to finish in 60 minutes.  The chair is dougwig. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:06 <Frito> fnaval: You're on. But first after the openmeeting call is what you're looking for. YOu went before the green light
20:01:07 <openstack> The meeting name has been set to 'octavia'
20:01:07 <Frito> hey
20:01:08 <dougwig> o/
20:01:17 <fnaval> o/
20:01:21 <fnaval> =)
20:01:23 <Frito> hahahahaha. first by complete chance
20:01:30 <TrevorV> Looks like this meeting is going to be super organized, and totally useful :P
20:01:34 <blogan> hi
20:02:22 <dougwig> we have no agenda, since trevor reminded me of this meeting 1 minute ago, and i am horrible.
20:02:31 <dougwig> #topic Announcements
20:02:41 <dougwig> any announcements today?
20:03:08 <blogan> i have none
20:03:14 <dougwig> right, then.
20:03:20 <dougwig> #topic Brief progress reports
20:03:34 <TrevorV> I still need reviews on the following:
20:03:36 <TrevorV> #link https://review.openstack.org/#/c/306084/
20:03:38 <rm_work> o/
20:03:44 <TrevorV> #link https://review.openstack.org/#/c/257201/
20:03:45 <evgenyf> hi
20:03:56 <fnaval> likewise:
20:03:57 <fnaval> #link https://review.openstack.org/#/c/305525/
20:03:57 <fnaval> #link https://review.openstack.org/#/c/306182/
20:03:59 <TrevorV> The single-create in neutron lbaas is looking really solid now, thanks to ptoohill
20:04:06 <fnaval> those have +2's already
20:04:28 <dougwig> fnaval: how much time do those add to our jobs, and which jobs?
20:04:40 <blogan> TrevorV: you said that a month ago
20:04:44 <fnaval> those shouldn't affect the current jobs
20:04:46 <perelman> hi
20:04:59 <madhu_ak> o/
20:04:59 <TrevorV> blogan I never thanked ptoohill a month ago, quit bein so cynical and help review, you lazy core o_0
20:05:01 <dougwig> fnaval: then what do they affect?
20:05:06 <fnaval> since they're only functional tests
20:05:08 <rm_work> fnaval: what did you actually change on my review? lol
20:05:16 <fnaval> it looks like we only run the scenario tests
20:05:20 <ptoohill> :P
20:05:20 <blogan> core reviewers are supposed to review?
20:05:31 <dougwig> fnaval: so we're merging tests that don't get run?
20:05:35 <TrevorV> One more review that could use some attention:  (thanks dougwig)
20:05:38 <TrevorV> #link https://review.openstack.org/#/c/314665/
20:05:40 <rm_work> ah you added a closes-bug
20:05:45 <fnaval> i leave it up to individual groups/companies if they want to run the functional tests sepearately. but the functional tests aren't part of gate
20:05:56 <rm_work> they should be EVENTUALLY
20:06:14 <fnaval> Long term plan though, is to get the functional tests to run faster and in parallel - it's going to require some refactoring of the fixtures
20:06:18 <rm_work> but we need to get them in there, then add the job for them
20:06:18 <rm_work> then make sure it's stable, then gate on it
20:06:18 <rm_work> there's a .... process
20:06:24 <dougwig> what's to keep them from rotting?
20:06:32 <dougwig> is there an experimental job?
20:06:47 <rm_work> well there can't be an experimental job until there's something there for it to run, can there?
20:06:49 <blogan> those tests get run
20:07:00 * dougwig is confused.
20:07:16 <fnaval> I'd like at least the functional smoke tests to run in gate and run in parallel/concurrently
20:07:27 <fnaval> yeah what rm_work said
20:07:30 <rm_work> there are NEW tests aren't they?
20:07:38 <rm_work> err
20:07:38 <rm_work> *these are
20:07:43 <rm_work> completely new tests I thought
20:07:47 <blogan> the gate-neutron-lbaasv2-dsvm-* jobs run those tests
20:08:02 <perelman> hi all, i am new here, so sorry i dont know how i am supposed to raise things for discussion... hope the protocol is not too difficult :)
20:08:18 <blogan> perelman: there will be an open discussion at the end of the meeting
20:08:20 <fnaval> blogan: ah, so that doesn't run the scenario - dsvm runs functional?
20:08:21 <Frito> perelman: There will be a topic change to open discussoin
20:08:22 <dougwig> perelman: just shout it out, but preferably in open discussion
20:08:33 <rm_work> perelman: we have an agenda (theoretically) and then open discussion for stuff not added to the agenda ahead of time
20:08:38 <rm_work> that said, we are pretty freeform :P
20:08:45 <blogan> perelman: you got some good help there
20:09:03 <dougwig> alright, i'm too confused to continue with progress reports, a sign we are doing it right.
20:09:06 <madhu_ak> all the api functional tests are running at the gate using noop driver
20:09:11 <rm_work> hmm ok
20:09:13 <dougwig> #topic Open discussion
20:09:15 <rm_work> then i guess they are being run now? :P
20:09:18 <fnaval> ah ok thanks madhu_ak
20:09:18 <dougwig> perelman: welcome
20:09:19 <perelman> i am from ibm and we have a blueprint that is pending for reviews for N+1 LoadBalancer in Octavia project
20:09:19 * rm_work is also confused
20:09:24 <Frito> Re: billing. A group of us were talking and wondering how much billing stuff is reallly needed upstream since pretty much everyones billing process is going to be customized. Also, Neutron LBaaS doesn't really have any billing stuff in the codebase I'm told. In that light do we really want any billing framework in the upstream Octavia codebase?
20:09:47 <perelman> today i have pushed two initial commits to gerrit for review as well
20:09:57 <rm_work> perelman: ah hey, you're from the IBM active/active team :P welcome
20:10:00 <TrevorV> perelman can you give us a link?  Use "#link <link>" as the message and it'll get logged
20:10:06 <rm_work> did I meet you at the summit?
20:10:41 <blogan> lets take one topic at a time
20:10:49 <fnaval> yeah they did the flowershop demo - pretty cool
20:11:17 <perelman> ok, will wait for the discussion. sorry for the noise :)
20:11:27 <rm_work> nah, this IS the discussion
20:11:27 <blogan> perelman: you go first
20:11:30 <TrevorV> perelman you're in open discussion now homie, have at it :D
20:11:31 <blogan> Frito: you go after
20:11:32 <rm_work> we just need to figure out who's talking
20:11:46 * Frito has two things.
20:11:49 <rm_work> take-charge blogan is here today ^_^
20:12:03 <TrevorV> Frito quantity is not quality... OOOOH BURN
20:12:12 <blogan> perelman: can you paste a link?
20:12:32 <dougwig> i had a question about this one, which seems correct, but i have a funny feeling that port 0 might be used by some for special things: https://review.openstack.org/#/c/311631/
20:12:42 <Frito> yea, take me to the burn ward.</monotone>
20:12:53 <blogan> and there goes dougwig off on another topic
20:13:13 <dougwig> ok, then, active/active.  go.
20:13:36 <perelman> "#link https://review.openstack.org/#/c/234639" - this is the link to the Blue print
20:13:50 <dougwig> #link https://review.openstack.org/#/c/234639
20:14:20 <TrevorV> Yeah, sorry perelman I meant just what was in quotes, like dougwig did above.  My fault :)
20:14:22 <blogan> perelman: are you calling out for reviews, or do you have a questiona bout it?
20:14:52 <perelman> "#link https://review.openstack.org/#/c/313006/" - NoopDriver for distributor (entity that should distribute requests among amphorae)
20:15:14 <perelman> ok :)
20:15:16 <perelman> sorry
20:15:33 <bana_k> blogan: there are no any new reviews for the new patches.
20:15:34 <dougwig> #link https://review.openstack.org/#/c/313006/
20:15:36 <Frito> Don't be sorry. We're trying to figure out what you're asking or requesting.
20:16:06 <dougwig> ^^ are you calling attention to the reviews, or do you need to discuss anything?
20:16:12 <blogan> perelman: ^^
20:16:14 <perelman> #link https://review.openstack.org/#/c/317629/2
20:16:16 <bana_k> so we need to get the blueprint reviewed and approved so that we can go ahead with coding and all
20:16:26 <bana_k> calling attention for the review :)
20:16:33 <perelman> the last one is the nitial distributor driver
20:16:37 <rm_work> I'm not married to BPs
20:16:40 <rm_work> but yeah
20:16:46 <bana_k> hehehe
20:16:48 <rm_work> getting it updated and merged would be nice
20:16:51 <dougwig> does active/active still pull in heat and ceilometer?
20:16:51 <blogan> well in this case the bp is nice
20:17:06 <rm_work> but if the code is there then it's there and i'll look at it, the BP just might help me know what i'm looking at
20:17:23 <bana_k> oh thats awesome.
20:17:39 <perelman> no, we now work on static N+1
20:17:50 <perelman> initial version is without elasticity
20:17:59 <dougwig> ok, reviews are up, lets get them some eyes.
20:18:03 <dougwig> next up, billing.  go.
20:18:06 <Frito> yea
20:18:08 <Frito> Re: billing. A group of us were talking and wondering how much billing stuff is reallly needed upstream since pretty much everyones billing process is going to be customized. Also, Neutron LBaaS doesn't really have any billing stuff in the codebase I'm told. In that light do we really want any billing framework in the upstream Octavia codebase?
20:18:39 <perelman> thanks :))))
20:19:08 <blogan> Frito: my initial idea has been that octavia would gather metrics and shunt them off to some pluggable layer
20:19:08 <dougwig> i'm not hearing a lot of desire for billing being included.
20:19:21 <dougwig> there we go, he waits until the last second.
20:19:24 <Frito> blogan: yea, the data is being captured.
20:19:36 <Frito> just the aggregation and other parts would be non upstream :-)
20:20:10 <blogan> where's it currently being captured, on the controller right?
20:20:18 <Frito> I'm thinking there's going to be enough differences in each groups billing implementations that having a common / core set of code would be difficult and more cumbersom to each group than is really worth it.
20:20:22 <rm_work> basically, the heartbeat table
20:20:24 <TrevorV> blogan its through the heartbeat mechanism.
20:20:25 <Frito> Right now the heart beats
20:20:48 <blogan> which is on the controller, well most likely
20:20:55 <TrevorV> Its in the o-hm
20:21:08 <blogan> which usually will reside on the controller
20:21:10 <Frito> Right. And o-hm should be very lean / quick
20:21:49 <Frito> but the aggregation / pushing to whatever billing system in each corporation would slow that heartbeat stuff down. Probably considerably considering the scales that can be run.
20:22:15 <blogan> so shouldn't that piece do the aggregation then by listener?
20:22:28 <rm_work> yeah honestly i think a lot of people ALREADY have their billing stuff started / completed
20:22:29 <blogan> or are you worried some people may want stats by amphora?
20:22:40 <ptoohill> the 'pusher' part should ceratinly be separate
20:23:01 <rm_work> i don't feel like making a billing framework exist upstream where the only pluggable method is "calculate_billing()" is very useful
20:23:08 <rm_work> the data is there to read
20:23:09 <blogan> it pushes to some pluggable layer, we could jsut make it push to a queue
20:23:12 <Frito> +1 to rm_work
20:23:23 <rm_work> it's easy to make a daemon to just read what you want, process it how you want, and push it where you want
20:23:31 <TrevorV> ^^ this
20:23:33 <Frito> I think what should be in upstream is just making sure the data exists for us
20:23:37 <TrevorV> I'm on board for a separate daemon
20:23:38 <rm_work> and there's no point trying to standardize something that's 90% boilerplate and 10% custom logic
20:23:39 <blogan> i'm not suggesting billing, i'm suggesting some central place where the metrics are sent
20:23:41 <rm_work> err
20:23:43 <rm_work> sorry flip that
20:23:49 <rm_work> 10% boilerplate and 90% custom logic
20:23:52 <Frito> Right
20:23:58 <rm_work> the metrics ARE in a central place
20:24:01 <rm_work> the heartbeat table
20:24:02 <ptoohill> oh, not the 'pusher' im thinking of then blogan
20:24:27 <ptoohill> Yea, i dont see need for another layer
20:24:41 <ptoohill> though there should be a way to get that data easily and not have to plug into db directly maybe?
20:24:43 <blogan> okay and we're storing all the metrics in that table, for every heartbeat?
20:24:52 <ptoohill> api call/mgmt api? :)
20:24:59 <rm_work> all of the ones we collect, yes
20:25:06 <rm_work> because the only metric collection is via heartbeat
20:25:20 <dougwig> is that table named, "die_you_frigging_index_cache" ?
20:25:36 <rm_work> the lines aren't additive, there's one line and it's absolute data
20:25:41 <rm_work> not diffs
20:25:46 <dougwig> oh, that's less fun.
20:25:49 <rm_work> *one line per amp
20:26:04 <ptoohill> yea, upstream probably wont have same requirements as we would internally, so maybe it should just have a mech to send them off to another storage area for deployers to handle as needed?
20:26:08 <rm_work> so you can look at the number for the last time you calculated a diff, look at the new number, and make your new diff
20:26:11 <Frito> So correct me if I'm wrong but it seems like the consensus right now is no real value in having a billing template in upstream? I just state this b/c I don't want to dominate the discussion if there are other topics.
20:26:15 <blogan> yeah that table is going to get large fast, so then its up to the deployers to make sue they scrape teh data from that table and then purge it?
20:26:27 <rm_work> doesn't matter how often you read from it
20:26:32 <dougwig> i would also expect large public operators to customize their amps, and could do a custom billing offload.
20:26:45 <dougwig> i'm not sure private clouds care much about billing.
20:26:53 <Frito> dougwig sounds like you're in agreement with me. Custom billing.
20:26:55 * ptoohill Shouts, "Billing is Fun!"
20:27:05 * TrevorV slaps ptoohill
20:27:10 <ptoohill> o.o
20:27:10 <Frito> Lol. Is everyone cool with opening the floor for the next topic?
20:27:18 <TrevorV> Yes, you have a second, right?
20:27:23 <Frito> Yes
20:27:44 <Frito> I think we should have another section to this meeting. One where we nominate topics for open discussion then the actual open discussion.
20:27:59 <Frito> So we don't crunch on time or someone gets left out or whatnot.
20:28:14 <Frito> Not a decision that needs to be made now but I wanted to bring it up as food for thought
20:28:28 <TrevorV> That's your second topic, or do you still have a second topic?
20:28:29 <TrevorV> o_0
20:28:31 <ptoohill> lol
20:28:35 <Frito> That's my second topic
20:28:39 <Frito> :-D
20:28:41 <TrevorV> Just wanted to be clear.... ha ha ha
20:28:43 <Frito> I now yield the floor.
20:28:59 <TrevorV> I think that's a valid thing to consider... someone should remember that and bring it up when our PTL is here.
20:29:08 <dougwig> umm, you can just edit the wiki during the week, Frito.
20:29:14 <dougwig> next up, port 0
20:29:14 <Frito> TrevorV: I'll sync with johnsom
20:29:16 <TrevorV> That's true... The "agenda" right?
20:29:22 <dougwig> is port 0 a legit value on a member???
20:29:28 <TrevorV> Uh, no?
20:29:33 <Frito> dougwig: Got ya. Will look for that.
20:29:37 <Frito> thx
20:29:41 <fnaval> port 0 should be reserved - I have a test that expects an error if port is 0 (in review)
20:29:46 <rm_work> yeah the agenda comes from whatever people put in the wiki during the week
20:29:49 <rm_work> and then we run through it
20:30:13 <dougwig> or the chair fills it with germane things, if they're doing a good job.
20:30:15 <TrevorV> dougwig https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
20:30:24 <TrevorV> According to this, "0" is reserved for UDP
20:30:52 <dougwig> my appliance also accepts it for some weird reason.  i wanted to make sure i wasn't going insane.
20:30:54 <TrevorV> Of course, Wiki is not the end-all, be-all, but hey
20:31:05 <TrevorV> Well, this and that are different topics dougwig
20:31:15 <TrevorV> You're probably still going insane
20:31:18 <ptoohill> i see that some oses will take 0 as default and select a positive port based on a few algos :)
20:31:28 <ptoohill> ive never used port 0, i have no idea ><
20:31:41 <TrevorV> In other words, 0 is NOT acceptable, because they give you a different one lulz
20:31:46 <dougwig> i wonder if it could also mean "just use the dang listener port" on some backends. i'm ok with the change in theory, but just a touch leery of backwards compat.
20:32:20 <TrevorV> Yeah, that's a concern.  I wonder how we can check...
20:32:51 <dougwig> perhaps by asking our community at our meeting?
20:32:55 <fnaval> see if there's a precendence
20:33:36 <dougwig> ok, any other topics for today?
20:33:38 <TrevorV> Yeah, so, I guess we can accept 0 == not good port?
20:33:44 <TrevorV> I really really need single-create reviews
20:33:52 <TrevorV> NOt a new topic, I just need people to hook it up
20:33:53 <blogan> ptoohill has a reivew up i think that he wanted to discuss
20:34:09 <fnaval> in this review, JingLiu says that 0 is reserved: https://review.openstack.org/#/c/309635/
20:34:24 <ptoohill> not really o.O
20:34:53 <fnaval> from ZTE
20:35:05 <ptoohill> ok, i suppose: https://review.openstack.org/#/c/317236/
20:35:14 <TrevorV> don't twist his arm, blogan
20:35:28 <dougwig> i think single-create is likely to be an octavia beastie.
20:35:38 <blogan> beastie?
20:35:41 <blogan> beastie boy?
20:35:44 <TrevorV> dougwig its already IN octavia
20:35:45 <ptoohill> Im adding amphora to haproxy templater, this can be used in custom templates, right now theres no need for upstream to use the data, but Im hoping we can agree this is something that upstream would find useful
20:35:52 <TrevorV> I need the nlbaas one reviewed
20:36:19 <fnaval> please review any of my stuffs too
20:36:21 <fnaval> #link https://review.openstack.org/#/q/owner:%22Franklin+Naval+%253Cfranklin.naval%2540gmail.com%253E%22+status:open
20:36:26 <dougwig> TrevorV: does it have an approved newton spec?
20:36:33 <TrevorV> Does what?
20:36:35 <blogan> ptoohill: depending on the active/active implementation, it could be useful
20:36:35 <ptoohill> its the 'host amphora' so that way data thats specific to the host itself can be used if needed, dougwig do you have any thoughts here?
20:36:36 <TrevorV> Neutron lbaas?
20:36:41 <TrevorV> Oh, probably not... heh
20:36:50 <rm_work> https://review.openstack.org/#/c/318290/ will hopefully pass tests and scenario will fail but in the way that isn't because LBs won't build at all >_>
20:36:56 <ptoohill> Yea, just right now its not for upstream, we will use this internally blogan
20:37:40 <rm_work> i gotta run >_>
20:37:42 <rm_work> bbl
20:38:16 <dougwig> ptoohill: i'd need to see a review or something written down to have a comment.
20:38:18 <TrevorV> dougwig I don't have a spec for it in Neutron LBaaS.  I wrote one up for Octavia.  I can write one up for NLBaaS if we think I need that.
20:38:22 <dougwig> i'm fried today.
20:38:29 <ptoohill> https://review.openstack.org/#/c/317236/
20:38:33 <dougwig> TrevorV: nl requires neutron approval.
20:38:33 <ptoohill> #Link: https://review.openstack.org/#/c/317236/
20:38:38 <TrevorV> #link https://review.openstack.org/#/c/317236/
20:38:42 <ptoohill> oh
20:38:44 <ptoohill> mybad
20:38:46 <TrevorV> ha ha ha
20:38:50 <TrevorV> All good ptoohill
20:38:51 <TrevorV> :D
20:38:57 <TrevorV> dougwig alright, I'll write up a spec.
20:38:59 <TrevorV> :(
20:39:17 <dougwig> TrevorV: there likely already is one, and it just needs re-proposing for newton
20:39:25 <TrevorV> Good call.
20:39:35 <ptoohill> dougwig: https://review.openstack.org/#/c/317236/ is the patch in question for me
20:40:27 <dougwig> ptoohill: thanks
20:40:36 <dougwig> on my list.
20:40:38 <dougwig> anything else today?
20:41:08 <ptoohill> Thanks dougwig, i have like 40 other items to add to your plate, you ready?
20:41:36 <ptoohill> Just kidding, but hope it made you smash something
20:41:40 <dougwig> lol
20:41:53 <dougwig> alright, let's get 20 minutes back.
20:41:56 <dougwig> #endmeeting