20:01:14 #startmeeting Octavia 20:01:15 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:17 hi 20:01:19 The meeting name has been set to 'octavia' 20:01:19 o/ 20:01:24 #chair blogan 20:01:25 Current chairs: blogan xgerman 20:01:30 o/ 20:01:34 o/ 20:01:34 o/ 20:01:36 o/ 20:01:41 yeah rm_work said RAX might be delayed 20:01:43 \o/ 20:01:51 I'm currently riding in blogan's truck 20:02:01 Can relay :) 20:02:03 Oh no, towed again? 20:02:06 I was afraid you guys got towed again 20:02:09 Lol 20:02:12 You all had to take him out to get it? 20:02:15 o/ 20:02:16 o/ 20:02:19 Fortunately not, lol 20:03:42 anyhow, you guys are close? 20:04:06 We can always give status updates and let them catch up 20:04:15 #topic Brief progress reports 20:04:30 yep, was moving on to that ;-) 20:05:23 Controller worker is progressing. A bit slower than I had hoped, but moving forward. It does build an amp instance. 20:05:24 johnsom? mwang? 20:05:47 hooray!! 20:05:49 german worked on the networking tasks this week 20:05:58 :-) 20:06:02 health manager database model is on review, health manager service is wip 20:06:15 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 yeah, I figured 20:06:53 Yeah, a lot of good stuff for LBaaS v2 20:07:17 +++ 20:07:31 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 but will keep that to open discussions 20:07:48 ok, cool 20:08:04 rm_work are you guys close or should we do some other topic (next one needs blogan) 20:08:26 Don't encourage him to get a ticket too..... 20:08:36 ok, will do the other topic 20:08:43 #topic Mention other taskflow/serviceVM efforts 20:08:50 We're back 20:08:52 blogan walked in right now 20:08:55 im back 20:08:56 o/ 20:08:57 At his desk 20:08:57 ok cool 20:09:29 the stuff now is more informational: 20:09:53 o\ 20:10:11 Cue - jas some flows they like to donate to oslo for starting vms, plugging network, etc: 20:10:17 #link https://github.com/stackforge/cue/tree/master/os_tasklib 20:10:30 we have permission yo borrow/use/etc. 20:10:44 ah awesome 20:11:06 and I think akanda is moving there, too -- 20:11:13 yeah i think so too 20:11:33 I am hoping to have more info next meeting 20:11:45 Oh BTW I talked to markmclain and he says Akanda should be ready for us to use. http://www.akanda.io/ 20:12:16 He is gettign a demo ready to show us how it could speed up octavia developement 20:12:21 sweet 20:12:25 +1 20:12:36 is it configurable to meet our needs though, thats the main question 20:12:56 we'll find out on Friday 20:13:01 but its probably in a more mature state that we can add that in if allowed 20:13:05 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 is the demo going to be some kind of hangout or irc thing? 20:13:38 He told us thta it is running in production at customers so it must be mature 20:13:54 not sure that's a strictly accurate assumption... :P 20:14:02 right now it is an HP demo. We could have him do a second one for the community 20:14:08 well im sure ti is for routers, which it was built for 20:14:25 well that would be nice to see it in action 20:14:59 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 its a far more mature state than what we have, i just remember it being tightly coupled with building routers 20:15:57 yep and we wold him taht is not what we want to see. 20:16:03 s/told 20:16:09 oh of course, im sure he alreayd knew that 20:16:24 he did ;-) but we just made sure he remembered ;-) 20:16:29 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 agreed. 20:17:36 moving on 20:17:41 #topic Continue status discussion from LB meeting and how it impacts octavia 20:18:21 to sum up the proposal was to not bubble up statuses in the DB but when we show them 20:18:24 i wasn't heref or that discussoin yesterday 20:18:29 but i read through it 20:18:37 but yeah thats what i gathered 20:19:37 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 neutron-lbaas 20:19:42 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 sorry 20:19:56 dougwig: suggested to aggregate the status on the fly. Is that what we are talkign about? 20:20:00 yep 20:20:03 yep 20:20:46 yeah, dynamically calculated status make sense to me 20:20:47 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 I actually disagree with the dynamic loading of the statuses in general. 20:21:45 yeah, I feel uneasy, too, but have trouble finding valid reasons against it 20:21:51 Yeah, should we drop the pool health from the db? 20:21:57 TrevorV: any concrete reasons? 20:22:24 johnsom: i dont think so right now, but that is something we should think about 20:22:32 well operating status at lesat 20:22:33 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 provisioning status should remain 20:22:51 yes, operating status only 20:22:59 +1 20:23:03 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 that coul dhappen anyway 20:23:22 +1 20:23:26 +1 20:23:47 Then I feel like we should keep it the way we've designed it and remove the uneasiness people are feeling. 20:23:56 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 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 with not knowing what? 20:25:12 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 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 was never actually discussed 20:25:52 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 +1 20:26:16 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 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 we'll still be updating the state of teh load balancer's provisioning status 20:27:15 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 It feels like a derived type to me not a statefull status field from a database. 20:27:20 in my experience, the more state you store that's easily calculable, the more often you end up with stale data 20:27:27 Provisioning status isn't the same as operational status. To some degree I care less about provisioning status than operating status. 20:27:30 its just in the event of an error or a member going offline 20:27:39 rm_work: Agreed. 20:27:48 rm_work +1 20:28:31 I'm the only one on this side of the line eh? Alrighty, we'll go with group consensus here. 20:28:37 lol 20:28:39 (this is how we got the damn name amphora by the way) 20:28:42 Calculating it also opens the opportunity for operators to define "degraded" 20:28:56 great point! 20:29:29 Anyhow, I think we have consensus - though we could always vote... 20:29:36 we have consensus 20:29:38 -1 20:29:46 we have majority 20:29:53 unless someone is being quiet who disagrees 20:29:59 yeah, and I don't know the vote syntax 20:30:05 #startvote 20:30:06 Only the meeting chair may start a vote. 20:30:07 I think 20:30:09 Yep 20:30:12 It yelled at me :P 20:30:26 ok, I guess we are good :-) 20:30:26 #startvote should the operating status be dynamically generated on GETs? 20:30:27 Begin voting on: should the operating status be dynamically generated on GETs? Valid vote options are Yes, No. 20:30:28 Though you shouldn't worry about it, since I'm the only nay-sayer 20:30:28 Vote using '#vote OPTION'. Only your last vote counts. 20:30:35 #topic Open Discussion 20:30:40 #endvote 20:30:41 Voted on "should the operating status be dynamically generated on GETs?" Results are 20:30:46 #vote Yes 20:30:53 looking at the topic, isn't octavia the same either way? 20:30:56 #vote yes 20:30:56 #vote Yes 20:31:01 vote closed 20:31:03 #vote Yes 20:31:04 #vote yes 20:31:05 Uhm... brandon ended the voting... lulz 20:31:06 #vote yes 20:31:06 #vote yes 20:31:07 He closed it 20:31:09 #vote yes 20:31:17 ok 20:31:21 Looks pretty unanimous to me? 20:31:22 #vote I don't care, yes 20:31:24 #vote abstein 20:31:30 #vote no please god no 20:31:32 i think we need some kind of counting software to figure this one out 20:31:38 lol 20:31:59 carlos hatees he process and trevor is against the group. feels like home. 20:32:05 /he/the/ 20:32:07 heh 20:32:12 Sshhh... I haven't foosballed yet today 20:32:13 Not home yet 20:32:16 @TrevorV - your only choices were yes and no ;-) 20:32:42 #vote gumbi 20:32:43 btw crc32 has volunteered to do the status changes in neutron-lbaas 20:32:43 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 i think this horse is glue. 20:33:36 +100 20:33:42 moving on... 20:33:43 I don't quite understand one thing that was said with this topic though 20:33:56 Calculating it also opens the opportunity for operators to define "degraded" 20:34:16 What does this mean exactly? Are we not going to have a list of appropriate statuses to respond with? 20:34:29 We'll return whatever they want to give us? 20:34:34 Yea I don't see operators writing code to do this. 20:34:48 For example: is one member down DEGRADED vs 80% members down DEGRADED 20:35:05 I still don't follow johsnom. 20:35:09 johnsom ** 20:35:16 but what crc32 said that would require a hook for custom code 20:35:17 Could be a configurable setting. 20:35:28 ok, that makes sense 20:35:35 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 I think he's implying each operator would define a "def is_degraded()' method 20:35:36 We can chat after the meeting 20:35:54 Okay 20:35:55 Sorry 20:36:08 it would require hooks, but we're not there yet 20:36:56 we're getting in the weeds here though because the main argument for it still stands 20:37:54 +1 20:38:01 so next topic? 20:38:01 yeah, let's move on 20:38:04 waiting for conversation to move on 20:38:15 alreday switched topic 20:38:24 oh lol its open discussion 20:38:28 let's argue about how to end arguing. 20:38:34 lol 20:38:43 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 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 could somebody help clarify? 20:39:18 i like the idea of that argument, but not sure its the arugment we should be arguing 20:39:36 i had nothing else to add, srry :/ 20:39:37 ah, that one. We decided to leave it up to each driver to use taskflowor not 20:40:04 yeah, but that might change if we start using akanda 20:40:05 The controller is using TaskFlow 20:40:11 depends on how we would hook into akanda 20:40:41 akanda is a whole new deal, so TBD in my book. Current code is using TaskFlow 20:40:47 we had agreed to let the controller do tasks and call the specific driver methods. 20:40:54 at one point in time 20:41:05 yep, and the driver can use whatever flow engine they see fit 20:41:13 ^ 20:41:39 but we encourage taskflow since that opens up some synergies 20:41:57 (aka as an operator I hate to run two different engines) 20:43:10 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 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 the controller will have the 'base' behaviour if im understanding that correctly 20:44:35 in taskflow 20:45:00 the driver could optionally augment its methods with taskflow 20:45:19 +1 20:46:19 that make sense 20:46:20 controller has flows and task which call driver methods which could then again fire of flows and tasks inise the driver 20:47:10 tell mark to stream his demo 20:47:30 in ASCII art ;-) 20:47:36 +1 20:47:38 :) 20:48:10 ok, other things to discuss? 20:48:55 more Vancouver info? When do we need to sign up for the brownbag? 20:50:00 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 dougwig: I am sure there will be plenty to talk about 20:50:34 I figured I was on the hook for the octavia part of the talk. 20:50:57 yep, blogan is the client guy 20:51:07 +1 20:52:22 noooo 20:52:56 johnsom: ok, super. 20:53:18 blogan is the main MC. he needs to carry the talk. 20:53:22 because he loves doing that. 20:53:26 go to hell 20:53:35 bless your heart. 20:54:36 one day ill do it enough and be numb to my own sound of stupidity 20:55:19 ok, I think we can likely close the meeting... 20:55:28 +1 20:55:37 #endmeetingwithprejudice 20:55:41 #endmeeting