20:00:10 #startmeeting Octavia 20:00:10 Meeting started Wed Mar 30 20:00:10 2016 UTC and is due to finish in 60 minutes. The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:13 The meeting name has been set to 'octavia' 20:00:15 o/ 20:00:15 Hello, folks! 20:00:18 o/ 20:00:31 o/ 20:00:35 o/ 20:00:41 #topic Announcements 20:00:45 Hello Everyone 20:00:52 Newton timeline announced 20:00:59 #link http://releases.openstack.org/newton/schedule.html 20:01:03 Yay! 20:01:12 I have updated the launchpad milestones to reflect these dates 20:01:30 Also 20:01:32 Docs gate and periodic liberty/mitaka gates added to Octavia project 20:01:50 Cool 20:01:57 +1 20:02:02 We now have a docs check gate on the Octavia project and periodic checks for liberty/mitaka bitrot 20:02:30 Tip for those that don't know, you can preview the docs changes by clicking on the docs gate results in gerrit 20:02:46 Very handy, especially since we are trying to work on docs updates. 20:02:58 Yes! 20:02:59 Nicee 20:03:11 Any other announcements? 20:03:33 #topic Docu-geddon 20:03:38 Haha 20:03:41 Speaking of docs... 20:03:51 #link https://bugs.launchpad.net/octavia/+bugs?field.tag=docs 20:03:57 Documentation bugs (we need your help) 20:03:57 Sorry--- haven't made much progress on my end there. (Been busy with internal and personal stuff.) 20:04:10 And yes, we need help with the docs! 20:04:45 Please take a look at the docs and contribute if you can. Partials/starts are ok with me. 20:05:02 If you don't have time to write the whole thing 20:05:18 * xgerman wonders if RAX is being towed away 20:05:19 Shameless plug: Taskflow documentation demo available 20:05:26 #link http://13.91.98.5/devref/flows.html 20:05:42 Cool! 20:05:45 I wrote a script that builds docs for the key taskflows. 20:06:12 Please review. We can't merge it as it required a fix in TaskFlow for a python library change. 20:06:17 Nice! 20:06:31 those graphs are epic 20:06:47 TaskFlow can't release until after the 8th at the earliest for the Mitaka/Newton release freeze window. So, that is why I have a preview up. 20:07:09 Anyway, welcome comments so we can merge with TaskFlow releases. 20:07:24 Anything else on our push for docs? 20:08:08 Ok, I don't see fnaval here, so skipping the test topic again. I think he is traveling 20:08:22 #topic Brief progress reports - reviews needed, etc. 20:08:30 actually I don;t see anyone form RAX 20:08:32 o/ 20:08:35 sorry, late 20:08:37 meeting going long still 20:08:52 TrevorV|Home just on cue 20:09:21 could use some comments on this: https://review.openstack.org/#/c/232173/ 20:09:29 I have been working on getting the nova console logs archived in the gates should something go wrong (namely our session persistence issue) 20:09:30 https://review.openstack.org/#/c/298915 20:09:33 I got single-create written for "/lbaas/loadbalancers" but we want it for "/lbaas/graphs" or something along those lines, and its proven infinitely more confusing for me to make that change, so for me progress is "slow" still, but the logic was working at least :( 20:09:37 I suspect I'm missing important stuff in that. 20:09:39 #link https://review.openstack.org/#/c/298915 20:09:42 Just gotta figure out neutron lbaas extension bullsh** 20:09:53 this patch needs review #link https://review.openstack.org/#/c/288208/ 20:10:07 #link https://review.openstack.org/#/c/232173/ 20:10:13 #link https://review.openstack.org/#/c/288208/ 20:10:51 Another note on the console logs patch. Once that is in it will only archive the logs if the instance is still running at the gate cleanup time. 20:11:39 minwang2: you may have to update the permissions in that patch.. check my comment 20:11:46 If there is value in keeping the logs otherwise, you can copy them into a -archive folder before you delete the instance in your scenario test. That way they will be picked up and saved. 20:11:57 johnsom: Does that substantially impact our ability to troubleshoot? 20:12:11 Aah, ok. 20:12:36 Yes, we can see what nova did for our image booting. I have seen bug reports where nova took 23 MINUTES to boot an amp. 20:12:45 I think it was under powered hardware. 20:12:50 bharathm i saw that, sbalukoff can you review this patch please https://review.openstack.org/#/c/288208/ 20:13:01 But, I think there is value in seeing what the gates hosts are up to 20:13:08 minwang2: Sure! 20:13:34 yeah, since i changed the content of base.j2, you used to work on this file 20:13:44 johnsom: +1 20:13:56 +1 20:13:57 Anyway, it might help us understand what happened with amps that can't be reached for a long period of time 20:14:18 yeah, especially with all this random new hardware coming online 20:14:24 Yep 20:14:43 Yeah. 20:14:43 Any other progress updates? 20:15:01 #topic Open Discussion 20:15:13 I will be on vacation all next week, starting this Friday. 20:15:23 Nice sbalukoff ! 20:15:24 needs review https://review.openstack.org/#/c/286365/ 20:15:29 I am supposed to be on vacation right now :D 20:15:40 Ok, I have one topic. We merged a fix for failover to be able to use spares (actually two, because I made a mistake). 20:15:44 Will be back for a couple weeks, then I think Dustin and I are planning on making a road trip of the summit (meaning I will probably missing the meeting just before the summit and just after) 20:15:45 I've been "off" since yesterday.. but I've worked almost every day :D 20:15:54 yeah, I am on vacation next Wednesday but will try to attend 20:16:00 Do we want to push to backport these to stable/mitaka and cut another Mitaka release? 20:16:10 johnsom: Yes, I think so. 20:16:15 +1 20:16:17 johnsom, is failover broken without them? 20:16:30 It's broken in stable, this is a "pure bug" with no additional features added, and it's fairly significant. 20:16:35 failover likely works but you can’t use the spares pool 20:16:38 Totally a good candidate for a backport. 20:16:42 TrevorV|Home No, it will failover, but it will always build a new amp 20:16:43 Yeah, I'm okay with that 20:17:01 I have zero issue with backporting that 20:17:04 +1 for backport 20:17:08 Was just looking for context :D 20:17:16 Sure, NP. 20:17:28 Ok, looks like another task on my list. 20:17:38 Heh! 20:18:12 TrevorV|Home do we have clarity on the cascade create/delete API? Do we need to paint more? 20:18:24 more painting is needed 20:18:34 johnsom, I'm not sure if we "need" to paint more. 20:18:41 Darn (not the word I used verbally) 20:18:44 I'd like an official agreement 20:19:11 Me too as I have the neutron client patch just hanging out waiting 20:19:16 To be honest, johnsom , I have a preference, but both ways make sense with certain considerations 20:19:36 Is blogan here or at the tow yard? 20:19:45 I think dougwig wants lb_tree which is misleading since it’s a graph... 20:19:52 Can we finish this in the 40 minutes left? 20:20:02 absoluitely 20:20:02 new endpoint makes sense because neutron likes bad designs. Additional change to /lbaas makes sense because its creating an existing object, a loadbalancer. Sooo, idk 20:20:03 i want any separate endpoint, i don't care what it's called. 20:20:13 Seriously? We are going back and forth on tree vs. graph? 20:20:36 nope, dougwig just agreed to graph 20:20:56 * sbalukoff just pulls out the popcorn. 20:21:08 btw, "TrevorV|Home> new endpoint makes sense because neutron likes bad designs." <-- uncool. 20:21:14 Sorry... 20:21:16 TrevorV|Home can you present "sample" URL paths for the two options you think are on the table? You can star your favorite if you would like. 20:21:26 I actually agree with that statement 20:21:28 Oh, uh, sort of. 20:21:51 wsgi? 20:21:51 POST to "../lbaas/loadbalancers" is the current "Create" endpoint, and I have single-create working off that endpoint. 20:22:18 POST to "../lbaas/graph" is what I've been told is the way neutron will want it, and I'm having a lot of trouble getting that to work. 20:22:53 blogan, informed me that I have a poor understanding of how extensions work in Neutron, causing the confusion for me, which is probably true 20:23:40 What are the other proposed options? 20:23:40 blogan also thinks a loadbalancer with it’s children becomes a complete new object :-) 20:23:43 So it's down to extending "../lbaas/loadbalancers" or "../lbaas/graph"? 20:23:54 i'm here now 20:24:06 * johnsom passes a brush 20:24:16 well, its extending ../lbaas/loadbalancers or making a new extension ../lbaas/graph 20:24:27 sbalukoff: either we redefine create on the existing endpoint to mean more than one object maybe, or we have a new endpoint that has the new create semantics. 20:24:42 I want a decision on the cascade create/delete endpoint in the next 35 minutes so we can get on with our lives.... 20:24:45 /lbaas/graph DONE 20:24:49 The only GOOD thing I say we get from adding the endpoint "../lbaas/graph" is the additional behavior.. FOr example, we could then have the status tree returned on a GET to that endpoint 20:24:58 rest-wise, overload is DWIM, but worse sins have occurred. i dont' get the love for reusing old endpoints. 20:25:02 /lbaas/graphs sorry 20:25:37 I'm cool with /lbaas/graphs. 20:25:41 dougwig having tow endpoints which do the same can be confusing 20:25:41 Also, the "cascade_delete" will just be a "delete" to that endpoint followed by a LB id 20:25:48 I suspect we're going to want that status graph sooner rather than later anyway. 20:25:51 GET /lbaas/graphs returns a list of load balancers with graphs which has th eadded benefit of a UI being ablet o show as much information in a list view instead of making multiple API calls 20:26:01 xgerman: not when they're different. 20:26:02 DELETE /lbaas/graphs/ would be cascade delete 20:26:08 Right 20:26:12 That's what I said just now blogan :D 20:26:20 sbalukoff status is already there, with the appended path. 20:26:30 oh well i'm just typing without eading 20:26:30 so how is a single_create where I just define a loadbalancer different from creating it the other way? 20:26:31 reading 20:26:39 all good blogan 20:27:00 xgerman, the only difference is the nested objects. 20:27:20 Either you're creating an LB alone, or an LB with listener, or an LB with listener with pool, etc etc etc. 20:27:29 sbalukoff /v2.0/lbaas/loadbalancers/​{loadbalancer_id}​/statuses 20:27:46 johnsom: Aah. 20:27:50 yep, so creating just one LB is a special case of single_create… hence my argument we now have two endpoints doing the same thing 20:28:07 but like dougwig I have seen worse 20:28:32 if we simply renamed loadbalancer to vip, and graph to loadbalancer, this would all make sense 20:28:36 teh separate endpoint 20:28:41 xgerman: Different semantics, but operating on the same underlying objects... in the interests of not messing with old functionality, I don't have a problem with this. 20:28:53 * johnsom gives blogan a VIP 20:29:02 * blogan takes johnsom's VIP 20:29:10 blogan, it still doesn't make sense in that way either 20:29:12 VIP sandwich 20:29:26 I was talking this through with a third party, and I forgot my own argument, but that STILL didn't make sense. 20:29:33 TrevorV|Home: There's no perfect solution here. 20:29:36 yeah, blogan just use LBaaS V1 — they have VIPS 20:29:41 dougwig, how mcuh resistance would we get to having the single create call and cascade delete call off the /loadbalancers endpoint? 20:30:00 especially considering we already have the statuses off the /loadbalancers endpoint 20:30:09 just sayin 20:30:11 perfect solution: lbaas v3 20:30:20 Even BETTER solution... Octavia replacing neutron lbaas 20:30:25 but i guess its not perfect bc more work and screws users over 20:30:34 blogan: Until we discover something else we didn't consider correctly from the get-go. ;) 20:30:43 haha 20:31:09 I think we have the same headache with neutron_lbaas or octavia being the API 20:31:12 I hope by then we have microversioniung 20:31:17 It'd be nice to have micro-versioning figured out someday. ;) 20:31:24 microversioning would solve this, yes. 20:31:26 jinx! 20:31:37 microversioning wouldn't really solve this either 20:31:40 i dont think it would 20:31:40 dougwig How so? 20:31:45 johnsom, we don't have extension issues in Octavia. Adding single-create functionality in octavia was relatively simple, with me only having issues with sql alchemy strange-ness 20:31:51 can’t micro versioning cure cancer? 20:31:51 we're still bike shedding 20:32:14 xgerman: Much like windex. 20:32:18 Yep. 20:32:20 Alright, none of this conversation has gotten us to "which endpoint is the group decision" 20:32:28 It's going to be a beautiful shed. 20:32:30 i suspect a vote coming 20:32:57 #startvote Do you support going with /lbaas/graph? Yes, No, Abstain 20:32:58 Begin voting on: Do you support going with /lbaas/graph? Valid vote options are Yes, No, Abstain. 20:32:59 Vote using '#vote OPTION'. Only your last vote counts. 20:33:00 i'm voting for "/fuckthisshitiwanttodorealwork" 20:33:17 #vote yes 20:33:23 #vote No 20:33:31 #vote No 20:33:34 #vote yes 20:33:44 that's actually not "entirely" accurate, but its the MOST accurate for me, so whatever :D 20:33:46 the only thing i care about is path of least resistance, and /graphs has that 20:34:03 blogan, so vote 20:34:13 it’s a tie right now 20:34:15 #vote Yes 20:34:19 #vote yes 20:34:30 Yeah, graph/graph(s) don't care. This is just getting to a concept. 20:34:38 Yeah. 20:34:47 we'll revisit it next week, dont worry 20:34:51 You've yet to vote, johnsom 20:34:57 Haha 20:35:05 #vote getonwithitalready 20:35:05 johnsom's dilemma 20:35:05 johnsom: getonwithitalready is not a valid option. Valid options are Yes, No, Abstain. 20:35:09 I'm glad I'll be off the grid in Myanmar, then. XD 20:35:22 Haha 20:35:24 #vote yes 20:35:33 insubordinate! 20:35:38 Ok, anyone else? 20:35:43 Alright, I guess enough people abstain that its in favor of /graphs 20:35:43 #vote Yes 20:35:46 Decision made 20:35:55 #endvote 20:35:56 Voted on "Do you support going with /lbaas/graph?" Results are 20:35:57 Yes (6): johnsom, sbalukoff, dougwig, bharathm, crc32|znc, blogan 20:35:58 No (2): xgerman, TrevorV|Home 20:36:10 Shed painted 20:36:16 Ok, we have an answer. 20:36:16 Voting No doesn't guarantee it's gonna pass with others later. So as blogan said path of least resistance 20:36:44 TrevorV|Home Let me know when you have your side with cascade delete cooked and I will update my neutron client patch. 20:37:06 we don;t need to live in fear of who-should-not-be-named and his iron -2 fist 20:37:22 True, but at least we aren't standing around saying "I don't know, what do you think?" in a big circle. 20:37:34 Haha 20:37:43 johnsom, I don't have anything with cascade delete... 20:38:02 I'm doing single-create 20:38:03 :D 20:38:04 that’s blogan — he wants to hang that off graph as well 20:38:25 Ah, ok, so someone will have to come along after your patch and update the cascade delete code. Fair enough 20:38:30 if we have a /graphs endpoint it makes the most sense 20:38:35 it’s WIP anyway 20:38:37 +1 20:39:10 Ok, ten more endpoints and we will have folks covered for this cycle. 20:39:24 Any other open discussion topics? 20:39:39 can i ask a question, guys? 20:39:47 of course 20:39:49 Impossible. Can't be done. 20:39:52 ;) 20:39:54 kong, this is the PERFECT time to ask a question 20:39:59 What's your question, kong? 20:40:02 do you think octavia is production-ready in mitaka? 20:40:24 if you use it off the shelf - NO 20:40:43 sorry that wa sliberty 20:40:45 Tentative yes? I mean-- you'll have to set up your own monitoring and other glue. 20:40:48 mitaka should be fine 20:40:59 mitaka is definitely much better than liberty. 20:41:07 Yeah, don't use liberty 20:41:11 +1 20:41:14 It also depends somewhat on your cloud use case. 20:41:19 some blocks in liberty? 20:41:31 Lots of bugs in liberty 20:41:33 critical bugs? 20:41:34 ok 20:42:12 It does work, but there are a bunch of bugs we fixed in Mitaka that make the user experience a lot better. 20:42:20 Right. 20:42:31 ok, thanks for so many answers :-) 20:42:40 and will you focus on installation in Newton? 20:42:45 i mean, ansible or puppet 20:43:11 We've yet to really outline the main development initiatives for Newton... but... 20:43:32 I know that the operators present here are probably already working on installation for their specific cloud environments (I know we are) 20:43:34 because we don't want to install it via devstack for production :-) 20:43:36 I don't think this team has plans to do anything with ansible or puppet. There is another openstack team doing ansible work for LBaaSv2 and Octavia. 20:44:06 kong: We will definitely have docs describing the process (there are some under review right now) 20:44:07 We are working on installation documentation 20:44:13 Yep. 20:44:18 Yeah, what he said... 20:44:23 johnsom: yes, i know. someone familiar with ansible and octavia both 20:44:42 we do have plans for ansible for the amphora image building portion 20:44:47 yeah, installation tools is not really put scope here 20:44:48 just to throw that out there 20:45:04 #link https://specs.openstack.org/openstack/openstack-ansible-specs/specs/mitaka/lbaasv2.html 20:45:13 that is the group working on ansible 20:45:20 and then there is heat as well 20:45:27 ok, thanks guys, sorry for chiming in 20:45:32 :-) 20:45:38 No worries. 20:45:47 I know Blue Box uses the public 'ursula' project for cloud installations. I suspect very much in the next month you're going to see ansible playbooks in there for installing Octavia / Neutron LBaaSv2. 20:45:48 No "sorry" mang, its a good question :D 20:45:56 Mostly because I'm working on them right now. 20:46:11 Alright guys, I'm bowing out. I haven't eaten all day, if anyone needs some info from me, PM me or email me, ttyl! 20:46:21 Thanks 20:46:28 Anything else for today? 20:47:06 #endmeeting