20:00:13 <blogan> #startmeeting octavia
20:00:16 <openstack> Meeting started Wed Jan 28 20:00:13 2015 UTC and is due to finish in 60 minutes.  The chair is blogan. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:19 <openstack> The meeting name has been set to 'octavia'
20:00:25 <xgerman_> o/
20:00:26 <a2hill> o/
20:00:28 <blogan> hello
20:00:28 <TrevorV_> ./
20:00:34 <barclaac> O/
20:00:36 <blogan> oh xgerman you're here!
20:00:47 <johnsom> o/
20:00:50 <jamiem> o/
20:01:06 <xgerman_> yep, I hate to miss this meeting :-0
20:01:19 <jorgem> o/
20:01:25 <blogan> good thing you're here then
20:01:52 <blogan> #link https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Meeting_2015-01-28
20:02:11 <blogan> i just added a short agenda for today
20:02:30 <xgerman_> awesome!
20:02:41 <johnsom> Thanks Brandon.  I also updated the standup etherpad: https://etherpad.openstack.org/p/octavia-weekly-standup
20:03:02 <blogan> johnsom: thanks, i always forget about that
20:03:27 <blogan> #topic progress reports
20:04:01 <jorgem> https://review.openstack.org/#/c/149789/
20:04:04 <blogan> i think gerrit has a good overview
20:04:08 <blogan> any blockers though?
20:04:12 <jorgem> Just need to unit test
20:04:13 <jorgem> nope
20:04:24 <jorgem> blocker: me slowly learning python
20:04:27 <jorgem> :)
20:04:28 <johnsom> I have made some slow progress on the controller worker.  Splitting my time getting ready for the hack-a-thon and LBaaS V2 client work
20:04:33 <a2hill> no progress from me for this week :/
20:04:50 <johnsom> #link https://review.openstack.org/149801
20:05:16 <johnsom> Min also has a review up:
20:05:19 <johnsom> #link https://review.openstack.org/149802
20:05:27 <TrevorV_> #link https://review.openstack.org/#/c/126801/
20:05:29 <blogan> so i think the necessary items are queue produce, queue consumer, deploy worker, haproxy amphora driver, amphora api
20:05:32 <TrevorV_> Could use some more reviews on this as well
20:05:46 <blogan> to get a simple end-to-end running
20:05:50 <blogan> did i miss something in that list?
20:06:17 <xgerman_> api manager + neutron driver
20:06:29 <johnsom> Do we have the code that goes into the amphora itself?
20:06:38 <blogan> oh duh neutron driver lol
20:06:48 <blogan> api manager = queue consumer
20:06:52 <xgerman_> dougwig's piece ;-)
20:06:57 <jorgem> johnsom: Do you know if min's review is a WIP?
20:07:07 <blogan> yeah dougwig, any updates on that?
20:07:17 <TrevorV_> johnsom, if you're asking about the amphoa API for modifying HA Proxy and such, then no, I'm working on that now
20:07:22 <mwang2> the api is wip
20:07:26 <TrevorV_> amphora API***
20:07:31 <mwang2> api doc v2.0 is wip
20:07:45 <blogan> mwang2: for neutron lbaas or octavia?
20:07:54 <blogan> neutron lbaas right?
20:08:01 <mwang2> yes
20:08:09 <mwang2> the documentation is for lbaas
20:08:13 <johnsom> I posted the health manager database work
20:08:24 <johnsom> I posted the link to Min's review that is...
20:08:49 <blogan> ah okay
20:09:01 <mwang2> feel free to review it:)
20:09:13 <blogan> will do
20:10:22 <blogan> okay looks like that is it for updates (until dougwig returns if he does)
20:10:37 <blogan> #topic HealthMixin in amphora driver
20:10:41 <bedis> ah
20:10:45 <bedis> o/
20:10:46 <blogan> min this is what we discussed yesterday a bit
20:10:49 <blogan> welcome bedis
20:10:59 <xgerman_> welcome
20:11:13 <xgerman_> can you please sum up the discussion
20:11:15 <blogan> minwang2: you want to explain this?
20:12:00 <blogan> or i can give a brief summary
20:12:23 <TrevorV_> blogan, her username is mwang2
20:12:28 <TrevorV_> not "minwang2" :D
20:12:48 <blogan> min was confused, and so I am now as well, about how the HealthMixin is to be used by the healthmanager, or vice versa
20:12:55 <blogan> TrevorV_: whoops, thanks
20:13:10 <TrevorV_> np :)
20:13:23 <blogan> xgerman: you might be able to answer the confusion
20:13:25 <xgerman_> ok, so the plan was to use the healthmixin so the amphora driver didn't have to write to the DB directly
20:13:58 <xgerman_> basically the amphora-driver will call the mixin and then the health-mamanger will update the DB, e.g. if a node is down, etc. and act on it
20:14:33 <xgerman_> what we need to decide is the format of the map and if we ant to use a map
20:14:53 <blogan> ah okay, so the healthmixin is really just going to be making the db calls, but the amphora driver will be responsible for spinning up another thread/process to listen for heartbeats from amphorae?
20:14:54 <a2hill> could the deploy worker call the health-manager?
20:15:09 <xgerman_> blogan correct
20:15:20 <a2hill> oh, nvm
20:15:59 <xgerman_> yeah, we leave it to the amphora-driver to gather the health (in case somebody wants to poll)
20:16:15 <blogan> i may be remembering something wrong here, but is every amphora driver implementation responsible for spinning up their own heartbeat listener or will that be done by common controller?
20:16:34 <johnsom> It's a driver responsibility
20:16:40 <xgerman_> we decided that every driver has to do that since that format is driver specific
20:16:56 <bedis> s/driver/vendor/
20:16:57 <bedis> :)
20:17:10 <bedis> or device specific
20:17:12 <blogan> okay thats what i thought, but felt like we decided somethign different at the seattle meetup, but i must have been thinking of something else
20:17:20 <blogan> quiet vendor!
20:17:23 <johnsom> The polling option was the part that pushed us to make it a driver responsibility
20:17:42 <xgerman_> yeah, we removed the polling from the API in Seattle
20:17:57 <xgerman_> so the driver has to run a thread no matter what
20:18:25 <blogan> what about getting heartbeats on spare amphorae?
20:18:37 <xgerman_> can'
20:18:44 <xgerman_> t the driver do that?
20:18:49 <a2hill> So will the deploy-worker call an agent of sort that is the driver, or will it instantiate a new one each call?
20:19:06 <a2hill> i may be thinking of different things, can ignore me
20:19:11 <blogan> isn't the amphora driver only used on configured amphorae?
20:19:35 <xgerman_> ok, I see what you mean --
20:20:07 <blogan> a2hill: deploy-worker will be in its own thread already and im guessing it will just instantiate a new driver in each worker
20:20:15 <a2hill> but
20:20:34 <a2hill> if the driver matintains a thread for the healthmanager and its instantiated each time
20:20:35 <xgerman_> well, there is a call finalize amphora
20:21:20 <xgerman_> so once an amp is build and before it ends up in the spare pool we will call that on the driver so the driver can do whatever it wants at deploy time
20:22:40 <blogan> so the deploy worker has the finalize amphora method, and thats the place to start a listener for heartbeats
20:22:54 <xgerman_> that would be a way
20:23:17 <johnsom> Hmmm, would it make sense for the health manager to call into the driver to spawn the listener?
20:23:28 <blogan> which driver?
20:23:36 <blogan> amphora driver?
20:23:42 <johnsom> amphora driver
20:23:49 <xgerman_> nah, I the  way the UDP stuff works you just need one htread per server
20:24:12 <johnsom> Right
20:24:32 <xgerman_> so I am confused why we need to spawn another thread
20:24:38 <blogan> but amphora driver woudl only be responsible for its implementation, i.e. the haproxy amphora driver should only deal with haproxy stuff
20:24:45 <xgerman_> yes
20:24:48 <johnsom> So we would not want the deploy worker finalize to spawn that thread
20:24:50 <blogan> or sending updates to a configured amphora
20:24:58 <blogan> so calling into an amphora driver doesn't make sense for a spare amphora
20:25:17 <blogan> which is what it hought the finalize_amphora method was for
20:25:43 <xgerman_> well, in haproxies case but if you think A10 nthey might need to do soemthing to make thir image "ready"
20:26:03 <xgerman_> finalize_amphora is really a hook for vendors
20:26:35 <bedis> and F5 too
20:26:36 <bedis> :p
20:26:41 <blogan> i know, im just saying amphora driver implementation shouldn't have to deal with health maintenance of spare amphora
20:26:52 <xgerman_> but if the driver is not monitoring spare amphoras we can only look at nova which might not be enough...
20:27:54 <johnsom> The amphora driver should be our interface to the amphora no matter what "state" it is in right?
20:28:14 <xgerman_> yeah, that would be my preference
20:28:50 <xgerman_> but I can see a case for saying spare meand we just check nova health and then throw it away once the driver barfs
20:29:18 <blogan> i guess ive always thought of the amphora driver only responsible for configuring the amphora to becoem a load balancer, but perhaps it would make sense to have it also do health maintenance on spare amphora
20:29:36 <blogan> it is called amphora driver lol
20:29:36 <xgerman_> yep, that was my thought
20:30:36 <johnsom> +1
20:30:38 <blogan> okay so call nova to create an instance, once that instance is activated, call into the amphora driver to spawn a heartbeat listener
20:30:55 <blogan> then whenever its time to configure that amphora, call the other amphora driver methods
20:31:12 <xgerman_> yeah, though with the UDP you just need one listener
20:31:16 <johnsom> There just needs to be one heartbeat listener per controller
20:31:47 <xgerman_> as long as the UDP package sends you some id you vcan just hand that straight to the health manager
20:32:10 <blogan> ah okay, just make a factory method to do it then and that method just checks whether the listener is active or not
20:32:21 <xgerman_> yep
20:32:34 <xgerman_> or activate it when the driver is first loaded
20:32:38 <xgerman_> ...
20:33:07 <blogan> even better, no need to have it in the workflow
20:33:08 <xgerman_> since you might come back from a crashed server
20:33:23 <blogan> deploy worker worfklow that is
20:33:26 <johnsom> I would just have the health manager process fire it up
20:33:54 <xgerman_> well, however the driver gets loaded...
20:34:11 <blogan> will the health manager load the amphora driver?
20:34:16 <blogan> obviously it can
20:34:22 <johnsom> It doesn't today, but it could
20:34:38 <xgerman_> I think the health manager is two pieces:
20:34:51 <xgerman_> 1) The mixin which updates the DB and puts stuff in queues
20:35:09 <xgerman_> 2) A process which checks that the stuff in the DB isn't stale
20:35:23 <blogan> well if it doesn't then it'd have to be the queue consumer that starts it because it is the agent that starts teh threads, the deploy worker will just be in one of those threads
20:35:25 <xgerman_> so the mixin would sort of run in the drivers haelth listener
20:35:42 <xgerman_> (1)
20:36:13 <xgerman_> deploy_worker might start it
20:36:31 <blogan> deploy worker only gets called by teh queue consumer, its not doesn't start itself
20:36:47 <johnsom> Health manager is a stand alone process
20:36:48 <blogan> so i think it makes better sense to put it in the health manager
20:36:52 <blogan> yeah
20:37:05 <blogan> that and it fits the the name
20:38:18 <xgerman_> johnsom for 2 we need that
20:38:35 <johnsom> Correct
20:38:42 <xgerman_> the mixin part can live wherever we want but health manager makes a lot of sense
20:39:02 <blogan> okay consensus between 3 ppl achieved
20:39:18 <xgerman_> yeah :-)
20:40:10 <blogan> but action from this is amphora driver interface needs to be updated to have a "start_health_manager" method or something like that
20:40:27 <xgerman_> yep
20:40:44 <xgerman_> or the driver comes in two parts ;-)
20:41:17 <johnsom> start_health_listener maybe?
20:41:39 <TrevorV_> Sorry I guess I was half paying attention, the health manager has become a component of an amphora?
20:41:48 <johnsom> No!
20:42:00 <xgerman_> +1
20:42:25 <TrevorV_> Sorry I meant of the amphora driver
20:42:30 <TrevorV_> ha even typed it half-assed... my bad
20:42:35 <TrevorV_> I'm so scattered right now
20:42:41 <xgerman_> we just will run the health listener part of the amphora-driver on the health manager
20:42:56 <johnsom> +1 xgerman_
20:43:11 <xgerman_> hence need a way to start the listener --
20:43:15 <blogan> when the health manager process starts it will call an amphora driver method that will start its custom health checking
20:43:23 <xgerman_> yep
20:43:26 <johnsom> yes
20:43:28 <blogan> it may poll or it may choose to receive, its up to the implementation
20:43:38 <mwang2> is that possible that update this part in the doc
20:44:05 <xgerman_> yeah, I can update next week -- if that's soon enough
20:44:08 <blogan> mwang2: we should definitely update the interface and cos for that
20:44:15 <blogan> docs
20:44:24 <mwang2> yep
20:44:35 <xgerman_> I kept it vague so we can revisit once the driver is more firm
20:44:44 <xgerman_> which we did right now ;-)
20:44:54 <blogan> yeah much more clear now
20:45:00 <blogan> and sounds like a good plan
20:45:44 <blogan> though i foresee problems if someone wants to poll, but i dont think they can be fixed
20:46:02 <blogan> #topic Meeting next week?
20:46:10 <blogan> should we have an octavia meeting next week?
20:46:13 <blogan> i dont think so
20:46:17 <blogan> but want other opinions
20:46:22 <johnsom> +1
20:46:24 * bedis wants to poll
20:46:31 <a2hill> i thought doug cancled them?
20:46:33 <xgerman_> are all the people who are Octavia also Neutron LBaaS
20:46:33 * blogan polls bedis
20:46:37 <bedis> I mean my driver
20:46:44 <xgerman_> ?
20:46:45 <blogan> dougwig canceled the neutron lbaas one
20:46:48 <a2hill> oh
20:46:51 <TrevorV_> Doug canceled the meeting he controls a2hill which is neutron lbaas :D
20:46:52 <blogan> xgerman_: pretty much
20:47:05 <xgerman_> yep, just trying to make sure ;-)
20:47:11 <TrevorV_> Either way I agree with holding off, since most of us are doing the neutron lbaas hackathon
20:47:39 <blogan> i hear no objections
20:47:40 <dougwig> control is a rather strong word.
20:47:52 <blogan> dougwig: go back to your pto hell
20:47:54 * dougwig goes back to his day off.
20:47:55 <TrevorV_> control == run == is organizer of?
20:48:09 <xgerman_> dougwig I am PTO and I am here
20:48:09 <bedis> octavia talk could happen in the evening, around a beer :)
20:48:33 <blogan> as we feed bedis to the riverwalk gators
20:48:38 <a2hill> or a fruifury cider for some :P
20:48:46 <johnsom> bedis is buying beer?
20:48:49 <blogan> okay meeting canceled then
20:48:53 <blogan> #topic Open Discussion
20:48:54 <xgerman_> +1
20:48:55 <bedis> I drink beer
20:49:03 <a2hill> So do I
20:49:04 <xgerman_> Any update on the Vancouver talk?
20:49:16 <bedis> HAProxy [beer] taskforce :)
20:49:20 <a2hill> :D
20:49:26 <xgerman_> the LBaaS/Octavia/... panel one
20:49:30 <xgerman_> ?
20:49:38 <dougwig> xgerman_: i suggest again that we merge the lbaas/octavia submission. i don't need 40 minutes.
20:49:46 * bedis gives a beer.rb to dougwig
20:49:57 <dougwig> .rb?  yes!  :)
20:50:20 <xgerman_> so we did submit? Links?
20:50:24 <blogan> dougwig spends his pto writing ruby code
20:50:34 <xgerman_> I need to prepare a campaign...
20:50:36 <blogan> i dont think anything has been submitted
20:50:36 <dougwig> my submission has a synopsis of "tbd".
20:50:45 <dougwig> i did submit a placeholder.
20:50:47 <blogan> oh dougwig did
20:51:02 <bedis> please vote for my haproxy submission ;)
20:51:10 <blogan> bedis link
20:51:15 <xgerman_> +1
20:51:26 <bedis> let me find it
20:52:09 <bedis> https://www.openstack.org/summit/vancouver-2015/call-for-speakers/TalkDetails/2656
20:52:52 <bedis> many cool tips to make your configuration sexy :)
20:53:09 <blogan> error
20:53:20 <xgerman_> same here
20:53:23 <bedis> mmhhh
20:53:28 <xgerman_> though I had to sign in first
20:53:39 <xgerman_> voting might not be open yet
20:53:40 <a2hill> Same, but even logged in its still an error
20:53:52 <xgerman_> especially logged in it's an error
20:54:39 <TrevorV_> Umm... I have no error
20:55:05 <xgerman_> lucky you :-)
20:55:07 <a2hill> Then youre doing it wrong
20:55:15 <xgerman_> +1
20:55:16 <bedis> :)
20:55:43 <xgerman_> ok, anyhthing else? T-5...
20:55:49 <bedis> how can we see the submissions?
20:55:54 <TrevorV_> Ooooh okay yeah, it did error... I didn't see xgerman say anything about logging in.
20:55:56 <TrevorV_> Mah bad.
20:55:56 <bedis> I can only see mine
20:56:05 <blogan> probably can't see it unless you're in it
20:56:16 <blogan> they'll post them when its time to vote on them
20:56:39 <xgerman_> likely
20:56:46 <blogan> so bedis, spam the channel when voting on talks happens
20:56:52 <a2hill> +1
20:57:01 <blogan> okay anyway, i think we are done here unless someone else has something
20:57:17 <xgerman_> +1
20:57:41 <blogan> goodbye!
20:57:43 <blogan> #endmeeting