20:01:14 <xgerman> #startmeeting Octavia
20:01:15 <openstack> Meeting started Wed Feb 25 20:01:14 2015 UTC and is due to finish in 60 minutes.  The chair is xgerman. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:17 <mwang2> hi
20:01:19 <openstack> The meeting name has been set to 'octavia'
20:01:19 <Aish> o/
20:01:24 <xgerman> #chair blogan
20:01:25 <openstack> Current chairs: blogan xgerman
20:01:30 <johnsom> o/
20:01:34 <rm_mobile> o/
20:01:34 <jwarendt> o/
20:01:36 <sballe__> o/
20:01:41 <xgerman> yeah rm_work said RAX might be delayed
20:01:43 <barclaac> \o/
20:01:51 <rm_mobile> I'm currently riding in blogan's truck
20:02:01 <rm_mobile> Can relay :)
20:02:03 <johnsom> Oh no, towed again?
20:02:06 <xgerman> I was afraid you guys got towed again
20:02:09 <rm_mobile> Lol
20:02:12 <johnsom> You all had to take him out to get it?
20:02:15 <TrevorV> o/
20:02:16 <ajmiller> o/
20:02:19 <rm_mobile> Fortunately not, lol
20:03:42 <xgerman> anyhow, you guys are close?
20:04:06 <johnsom> We can always give status updates and let them catch up
20:04:15 <xgerman> #topic  Brief progress reports
20:04:30 <xgerman> yep, was moving on to that ;-)
20:05:23 <johnsom> Controller worker is progressing.  A bit slower than I had hoped, but moving forward.  It does build an amp instance.
20:05:24 <xgerman> johnsom? mwang?
20:05:47 <xgerman> hooray!!
20:05:49 <johnsom> german worked on the networking tasks this week
20:05:58 <xgerman> :-)
20:06:02 <mwang2> health manager database model is on review, health manager service is wip
20:06:15 <rm_mobile> I don't think anyone in the group with me has anything for Octavia... We've been working mostly on neutron-lbaas this sprint
20:06:25 <xgerman> yeah, I figured
20:06:53 <johnsom> Yeah, a lot of good stuff for LBaaS v2
20:07:17 <xgerman> +++
20:07:31 <sballe__> I have a couple of questions around the Amphora driver which I believe is this review: https://review.openstack.org/#/c/144348/
20:07:41 <sballe__> but will keep that to open discussions
20:07:48 <xgerman> ok, cool
20:08:04 <xgerman> rm_work are you guys close or should we do some other topic (next one needs blogan)
20:08:26 <johnsom> Don't encourage him to get a ticket too.....
20:08:36 <xgerman> ok, will do the other topic
20:08:43 <xgerman> #topic Mention other taskflow/serviceVM efforts
20:08:50 <rm_mobile> We're back
20:08:52 <TrevorV> blogan walked in right now
20:08:55 <blogan> im back
20:08:56 <fnaval> o/
20:08:57 <TrevorV> At his desk
20:08:57 <xgerman> ok cool
20:09:29 <xgerman> the stuff now is more informational:
20:09:53 <ptoohill> o\
20:10:11 <xgerman> Cue - jas some flows they like to donate to oslo for starting vms, plugging network, etc:
20:10:17 <xgerman> #link https://github.com/stackforge/cue/tree/master/os_tasklib
20:10:30 <xgerman> we have permission yo borrow/use/etc.
20:10:44 <blogan> ah awesome
20:11:06 <xgerman> and I think akanda is moving there, too --
20:11:13 <blogan> yeah i think so too
20:11:33 <xgerman> I am hoping to have more info next meeting
20:11:45 <sballe__> Oh BTW I talked to markmclain and he says Akanda should be ready for us to use. http://www.akanda.io/
20:12:16 <sballe__> He is gettign a demo ready to show us how it could speed up octavia developement
20:12:21 <blogan> sweet
20:12:25 <xgerman> +1
20:12:36 <blogan> is it configurable to meet our needs though, thats the main question
20:12:56 <barclaac> we'll find out on Friday
20:13:01 <blogan> but its probably in a more mature state that we can add that in if allowed
20:13:05 <sballe__> yes. That is the talk we are having. We want to make sure it can do what we need it to do.
20:13:26 <blogan> is the demo going to be some kind of hangout or irc thing?
20:13:38 <sballe__> He told us thta it is running in production at customers so it must be mature
20:13:54 <rm_work> not sure that's a strictly accurate assumption... :P
20:14:02 <sballe__> right now it is an HP demo. We could have him do a second one for the community
20:14:08 <blogan> well im sure ti is for routers, which it was built for
20:14:25 <blogan> well that would be nice to see it in action
20:14:59 <sballe__> rm_work: I am giving him the benefit of the doubt on the maturaty until proven otherwise. I am tired of being a pesimist
20:15:31 <blogan> its a far more mature state than what we have, i just remember it being tightly coupled with building routers
20:15:57 <sballe__> yep and we wold him taht is not what we want to see.
20:16:03 <sballe__> s/told
20:16:09 <blogan> oh of course, im sure he alreayd knew that
20:16:24 <sballe__> he did ;-) but we just made sure he remembered ;-)
20:16:29 <blogan> and im sure akanda doesn't want that either, their whole point is to be able to spin up a service vm for anything
20:16:38 <sballe__> agreed.
20:17:36 <xgerman> moving on
20:17:41 <xgerman> #topic Continue status discussion from LB meeting and how it impacts octavia
20:18:21 <xgerman> to sum up the proposal was to not bubble up statuses in the DB but when we show them
20:18:24 <blogan> i wasn't heref or that discussoin yesterday
20:18:29 <blogan> but i read through it
20:18:37 <blogan> but yeah thats what i gathered
20:19:37 <blogan> the octavia driver that will live in neutron shouldn't have a problem with this because it can decide to focus on the statuses it needs to
20:19:40 <blogan> neutron-lbaas
20:19:42 <xgerman> ok, if this is the way forward we will mimick it in Octavia and expeically not have the health manager update pools if a member is down
20:19:43 <blogan> sorry
20:19:56 <sballe__> dougwig: suggested to aggregate the status on the fly. Is that what we are talkign about?
20:20:00 <blogan> yep
20:20:03 <xgerman> yep
20:20:46 <rm_work> yeah, dynamically calculated status make sense to me
20:20:47 <blogan> which i have a minor uneasiness with that not being what is actually in the db, but it's faster to do right now and i honestly can't think of any issues, other than my uneasiness
20:21:40 <TrevorV> I actually disagree with the dynamic loading of the statuses in general.
20:21:45 <xgerman> yeah, I feel uneasy, too, but have trouble finding valid reasons against it
20:21:51 <johnsom> Yeah, should we drop the pool health from the db?
20:21:57 <blogan> TrevorV: any concrete reasons?
20:22:24 <blogan> johnsom: i dont think so right now, but that is something we should think about
20:22:32 <blogan> well operating status at lesat
20:22:33 <TrevorV> Aside from multiple people involved in the project being uneasy?  (which becomes a valid reason)  I think there are problems involved with computing a status tree rather than storing and updating it accordingly.
20:22:37 <blogan> provisioning status should remain
20:22:51 <johnsom> yes, operating status only
20:22:59 <xgerman> +1
20:23:03 <TrevorV> One being, while building a tree after getting health of one piece of the puzzle, that health could change before the response is given, meaning its inaccurate
20:23:14 <blogan> that coul dhappen anyway
20:23:22 <xgerman> +1
20:23:26 <johnsom> +1
20:23:47 <TrevorV> Then I feel like we should keep it the way we've designed it and remove the uneasiness people are feeling.
20:23:56 <dougwig> so, the argument against updating the db is that if we do M:N sharing, those db constructs become logical entities, not operational.  that we have status on them now is a convenience.  if we teach people to rely on it instead, those will always be operation objects.
20:24:17 <blogan> we haven't really designed it in any way, the reason it came up is there was major uneasiness with not nkowing and the alternative
20:24:36 <TrevorV> with not knowing what?
20:25:12 <blogan> not knowing how the statuses should be handled with the possibility of sharing objects, and how they should trickle up to the parent
20:25:19 <xgerman> well, we haven't though through it so it feels uneasy but I don't have a good reason for not doing it
20:25:22 <blogan> was never actually discussed
20:25:52 <blogan> i feel the same as xgerman, which is why im fine with doing it dynamically and if it becomes a problem we can easily add a helper method that does it in the db
20:26:16 <johnsom> +1
20:26:16 <dougwig> if we teach people to look at the status of individual objects (and that's the *only* reason to update the db directly with the three), we will be shooting ourselves in the foot if we switch to a tree/logical entity model.
20:26:44 <TrevorV> I feel like updating the DB is more safe since we'll be able to lock tables while updating state, removing some erroneous reports via the dynamic loading in the first place.
20:27:01 <blogan> we'll still be updating the state of teh load balancer's provisioning status
20:27:15 <dougwig> reading all the objects via a transaction versus building a tree is roughly equivalent from an "this might be out of date" perspective, IMO.
20:27:18 <crc32> It feels like a derived type to me not a statefull status field from a database.
20:27:20 <rm_work> in my experience, the more state you store that's easily calculable, the more often you end up with stale data
20:27:27 <TrevorV> Provisioning status isn't the same as operational status.  To some degree I care less about provisioning status than operating status.
20:27:30 <blogan> its just in the event of an error or a member going offline
20:27:39 <crc32> rm_work: Agreed.
20:27:48 <xgerman> rm_work +1
20:28:31 <TrevorV> I'm the only one on this side of the line eh?  Alrighty, we'll go with group consensus here.
20:28:37 <blogan> lol
20:28:39 <TrevorV> (this is how we got the damn name amphora by the way)
20:28:42 <johnsom> Calculating it also opens the opportunity for operators to define "degraded"
20:28:56 <xgerman> great point!
20:29:29 <xgerman> Anyhow, I think we have consensus - though we could always vote...
20:29:36 <blogan> we have consensus
20:29:38 <blogan> -1
20:29:46 <blogan> we have majority
20:29:53 <blogan> unless someone is being quiet who disagrees
20:29:59 <xgerman> yeah, and I don't know the vote syntax
20:30:05 <TrevorV> #startvote
20:30:06 <openstack> Only the meeting chair may start a vote.
20:30:07 <TrevorV> I think
20:30:09 <TrevorV> Yep
20:30:12 <TrevorV> It yelled at me :P
20:30:26 <xgerman> ok, I guess we are good :-)
20:30:26 <blogan> #startvote should the operating status be dynamically generated on GETs?
20:30:27 <openstack> Begin voting on: should the operating status be dynamically generated on GETs? Valid vote options are Yes, No.
20:30:28 <TrevorV> Though you shouldn't worry about it, since I'm the only nay-sayer
20:30:28 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:30:35 <xgerman> #topic Open Discussion
20:30:40 <blogan> #endvote
20:30:41 <openstack> Voted on "should the operating status be dynamically generated on GETs?" Results are
20:30:46 <johnsom> #vote Yes
20:30:53 <dougwig> looking at the topic, isn't octavia the same either way?
20:30:56 <xgerman> #vote yes
20:30:56 <dougwig> #vote Yes
20:31:01 <blogan> vote closed
20:31:03 <barclaac> #vote Yes
20:31:04 <fnaval> #vote yes
20:31:05 <TrevorV> Uhm... brandon ended the voting... lulz
20:31:06 <mwang2> #vote yes
20:31:06 <rm_work> #vote yes
20:31:07 <johnsom> He closed it
20:31:09 <sballe__> #vote yes
20:31:17 <xgerman> ok
20:31:21 <barclaac> Looks pretty unanimous to me?
20:31:22 <rm_work> #vote I don't care, yes
20:31:24 <crc32> #vote abstein
20:31:30 <TrevorV> #vote no please god no
20:31:32 <blogan> i think we need some kind of counting software to figure this one out
20:31:38 <xgerman> lol
20:31:59 <dougwig> carlos hatees he process and trevor is against the group.  feels like home.
20:32:05 <dougwig> /he/the/
20:32:07 <rm_work> heh
20:32:12 <TrevorV> Sshhh... I haven't foosballed yet today
20:32:13 <TrevorV> Not home yet
20:32:16 <barclaac> @TrevorV - your only choices were yes and no ;-)
20:32:42 <crc32> #vote gumbi
20:32:43 <blogan> btw crc32 has volunteered to do the status changes in neutron-lbaas
20:32:43 <TrevorV> barclaac no one could vote anyway since brandon closed the vote before a single vote went in, so I went "funny" rather than "serious"
20:33:28 <dougwig> i think this horse is glue.
20:33:36 <xgerman> +100
20:33:42 <xgerman> moving on...
20:33:43 <TrevorV> I don't quite understand one thing that was said with this topic though
20:33:56 <TrevorV> <johnsom>	Calculating it also opens the opportunity for operators to define "degraded"
20:34:16 <TrevorV> What does this mean exactly?  Are we not going to have a list of appropriate statuses to respond with?
20:34:29 <TrevorV> We'll return whatever they want to give us?
20:34:34 <crc32> Yea I don't see operators writing code to do this.
20:34:48 <johnsom> For example: is one member down DEGRADED vs 80% members down DEGRADED
20:35:05 <TrevorV> I still don't follow johsnom.
20:35:09 <TrevorV> johnsom **
20:35:16 <xgerman> but what crc32 said that would require a hook for custom code
20:35:17 <johnsom> Could be a configurable setting.
20:35:28 <xgerman> ok, that makes sense
20:35:35 <dougwig> umm, the operator that wrote their own neutron thinks operators won't write code?  (though i believe that's orthogonal to the question.)
20:35:35 <crc32> I think he's implying each operator would define a "def is_degraded()' method
20:35:36 <johnsom> We can chat after the meeting
20:35:54 <TrevorV> Okay
20:35:55 <TrevorV> Sorry
20:36:08 <blogan> it would require hooks, but we're not there yet
20:36:56 <blogan> we're getting in the weeds here though because the main argument for it still stands
20:37:54 <johnsom> +1
20:38:01 <blogan> so next topic?
20:38:01 <xgerman> yeah, let's move on
20:38:04 <crc32> waiting for conversation to move on
20:38:15 <xgerman> alreday switched topic
20:38:24 <blogan> oh lol its open discussion
20:38:28 <dougwig> let's argue about how to end arguing.
20:38:34 <xgerman> lol
20:38:43 <sballe__> perfect.  I am confused about the use of taskflow in: http://www.octavia.io/review/master/specs/version0.5/amphora-driver-interface.html
20:38:43 <sballe__> It says: "The controller will heavily utilize taskflow [2] to accomplish its goals so it is highly encouraged for drivers to use taskflow to organize their work, too." I thought we went away from taskflow.
20:39:13 <sballe__> could somebody help clarify?
20:39:18 <ptoohill> i like the idea of that argument, but not sure its the arugment we should be arguing
20:39:36 <ptoohill> i had nothing else to add, srry :/
20:39:37 <xgerman> ah, that one. We decided to leave it up to each driver to use taskflowor not
20:40:04 <blogan> yeah, but that might change if we start using akanda
20:40:05 <johnsom> The controller is using TaskFlow
20:40:11 <blogan> depends on how we would hook into akanda
20:40:41 <johnsom> akanda is a whole new deal, so TBD in my book.  Current code is using TaskFlow
20:40:47 <ptoohill> we had agreed to let the controller do tasks and call the specific driver methods.
20:40:54 <ptoohill> at one point in time
20:41:05 <xgerman> yep, and the driver can use whatever flow engine they see fit
20:41:13 <ptoohill> ^
20:41:39 <xgerman> but we encourage taskflow since that opens up some synergies
20:41:57 <xgerman> (aka as an operator I hate to run two different engines)
20:43:10 <sballe__> ok thx. I was still back in the days where "we had agreed to let the controller do tasks and call the specific driver methods". If we now have changed strategy taht is fine too
20:43:58 <xgerman> no, we still have that but calling say: start_listener could again fire up it's own taskflow engine to do things
20:44:29 <ptoohill> the controller will have the 'base' behaviour if im understanding that correctly
20:44:35 <ptoohill> in taskflow
20:45:00 <ptoohill> the driver could optionally augment its methods with taskflow
20:45:19 <xgerman> +1
20:46:19 <sballe__> that make sense
20:46:20 <xgerman> controller has flows and task which call driver methods which could then again fire of flows and tasks inise the driver
20:47:10 <blogan> tell mark to stream his demo
20:47:30 <xgerman> in ASCII art ;-)
20:47:36 <ptoohill> +1
20:47:38 <ptoohill> :)
20:48:10 <xgerman> ok, other things to discuss?
20:48:55 <xgerman> more Vancouver info? When do we need to sign up for the brownbag?
20:50:00 <dougwig> folks need to come up with an agenda for the octavia part of the talk, if the main lbaas talk is accepted.
20:50:33 <sballe__> dougwig: I am sure there will be plenty to talk about
20:50:34 <johnsom> I figured I was on the hook for the octavia part of the talk.
20:50:57 <xgerman> yep, blogan is the client guy
20:51:07 <johnsom> +1
20:52:22 <blogan> noooo
20:52:56 <dougwig> johnsom: ok, super.
20:53:18 <dougwig> blogan is the main MC.  he needs to carry the talk.
20:53:22 <dougwig> because he loves doing that.
20:53:26 <blogan> go to hell
20:53:35 <dougwig> bless your heart.
20:54:36 <blogan> one day ill do it enough and be numb to my own sound of stupidity
20:55:19 <xgerman> ok, I think we can likely close the meeting...
20:55:28 <dougwig> +1
20:55:37 <dougwig> #endmeetingwithprejudice
20:55:41 <xgerman> #endmeeting