20:00:18 #startmeeting Octavia 20:00:19 Meeting started Wed May 9 20:00:18 2018 UTC and is due to finish in 60 minutes. The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:22 The meeting name has been set to 'octavia' 20:00:24 Hi folks 20:00:27 o/ 20:00:30 ahoy! 20:01:08 Oye, the storyboard meeting.... 20:01:19 #topic Announcements 20:01:27 I don't have much here. 20:01:41 The summit in Vancouver is coming up quickly, just a few weeks out. 20:02:04 I will probably cancel the Octavia meeting the week of the summit unless others want run it. 20:02:44 Any other announcements I missed? 20:03:06 #topic Brief progress reports / bugs needing review 20:03:15 o/ 20:03:45 made progress on grenade support: https://review.openstack.org/#/c/549654/ 20:03:58 I have been a busy person and as of yesterday we have a fully functional (aside from bugs/cleanup ) provider driver for Octavia and interface for other drivers. 20:04:24 I'm working on one last patch for the cleanup/bugs/release notes, etc. now 20:04:40 it is now upgrading from stable/queens. post-upgrade octavia tempest was failing on 4 jobs. cause is known and rm_work has a patch up 20:04:53 o/ 20:05:00 Sorry I'm late. Lunch going long 20:05:27 Cool, I will check it out. I also promised a UDP protocol review that needs to happen soonish 20:06:43 rm_work has also been busy getting the tempest plugin in shape, so good stuff there too! 20:07:28 Any other updates? 20:07:43 #topic Default value for haproxy_amphora.connection_max_retries (300 at 5 seconds each) 20:07:44 stable/pike gates were broken because of tempest (brancheless) bumped ostestr from 0.8.x to 1.0.x. ostestr switched default from testr to stestr and with that broke stable/pike which was still expecting testr underneath. we've fixed stable/pike already 20:07:58 ? 20:08:14 This came in as a bug report and is worth a discussion 20:08:32 cgoncalves Cool, thanks for helping with that 20:08:46 +1 20:09:10 We currently set the connection timeouts super high to allow for super slow cloud infrastructure (virtualbox I look at you in shame). 20:09:39 This eases folks trying out octavia on these not-so-great hosts as when the nova instance eventually boots they will get a working LB. 20:10:09 However, it also has the side effect that things can take a long time to timeout and go into ERROR states if the cloud is broken 20:10:30 This default is 25 minutes. 20:11:05 Now, I know we need to keep this a bit high for some zuul gate hosts, but that can be configured in the gate job definition. 20:11:33 So, the question is, now that folks are running this more in production style deployments, should we consider lowering this default? 20:11:43 So things give up quicker 20:12:28 Thoughts? Comments? 20:12:28 yeah, that might be good 20:13:26 as long as it is configurable, I don't see reason not to lower timeout 20:13:51 yeah, makes sense to move this high value to the job config and have a more sane (lower) value as production default 20:14:04 It could lead to more folks complaining that LBs don't come up, especially if they are using virutalbox, etc. 20:14:38 Though they probably complain that it's "stuck in pending_create" now anyway... lol 20:15:14 ha. maybe we can provide a local.conf for slow testing envs? 20:15:34 Either way we need to write up a guide. The dev guide would mention needing it higher, the operator guide would say lower 20:17:00 Ok, so mostly hearing yes, our defaults should be more in line with production style use cases. 20:17:10 I agree, lower the default 20:17:10 I will comment on the story 20:17:23 johnsom, please link the story 20:17:38 #link https://storyboard.openstack.org/#!/story/2001982 20:17:42 Thanks for the reminder! 20:18:05 #topic New default RBAC roles 20:18:26 So, as some of you are aware we have "advanced" style RBAC defaults. 20:18:47 And the other two projects that were championing this never merged their patches. 20:18:57 Well, the spec and topic are still alive and well 20:19:05 #link http://lists.openstack.org/pipermail/openstack-dev/2018-May/130207.html 20:19:17 so advanced that users cannot CRUD resources out of the box :P 20:19:24 There is a new proposal for standard roles. It is pretty close to ours already. 20:20:03 cgoncalves Correct, the operator has to opt-in users or groups for load balancer features. 20:20:27 Easy way is to add LB member role to the non-admin user group and be done. 20:21:18 Anyway, keystone is moving forward with this, as is nova. They are talking about including us in the early adopter list as well. (I support, but not yet signed up to staff, this). 20:21:23 yup. I need to look at this again. but manually assigning roles for each new user is a pain. so hopefully groups makes it more sane 20:21:44 Yeah, don't do it per user, that would be un-pleasant 20:22:14 The current discussion is when a few projects do it, it would become a community goal for Stien or T 20:22:38 Any questions or comments on this? 20:23:06 I know we have customers asking for the more advanced roles, not sure if others are in the same camp or not 20:23:19 not at the moment, but I might have some after I learn more about how it works 20:23:38 I will also not, it is super easy to disable the advanced and go back to owner/admin by copying over the policy file 20:24:02 #link https://review.openstack.org/#/c/566377/ 20:24:04 yup. I double checked and it worked for me 20:24:08 That is the current home of the spec 20:24:15 (adding policy.json) 20:24:28 Yeah, some of our gate tests run with that enabled 20:24:45 The new tempest pluign does test the advanced roles as well 20:24:56 good to know. and in any case i think it's good that we have that option 20:25:10 Ok, I will communicate our general support for standardizing these roles. 20:25:54 Though I'm not sure I'm signing up right now to do the work. I have Rocky commitments to work on 20:26:02 we should update our devstack plugin to use role inheritance instead of manually assignment to user demo btw 20:26:19 Yeah it's good but with a personal history working on rbac, there is a lot of work they still need to do even in the design side 20:26:19 Sure if you would like. 20:26:19 s/manually/manual 20:27:12 #topic Open Discussion 20:27:30 BTW, the ticket price for the PTG goes up on the 18th of May 20:27:50 So if you are planning to go to Denver in Sept. you might want to get your ticket early 20:28:07 Other topics today? 20:28:44 yes 20:28:50 just to keep everyone posted. we had another discussion with the storyboard team 20:28:58 go on Nir 20:29:03 (you don't have to raise your hand, just jump in) grin 20:29:22 this will take time.. you can see some of their feedback in the etherpad 20:29:56 cgoncalves, I'm done :) 20:30:11 oh, the etherpad: 20:30:14 #link https://etherpad.openstack.org/p/storyboard-issues 20:30:23 we've had patches merged without stories or release notes included. I'd like to propose having at least one in 20:31:05 I'm not asking for trivial bugs (even though a release note would be nice and easier/less consuming than opening a story) 20:31:06 I just got an e-mail that 5 people have added the Octavia onboarding session to their summit schedule, so thanks folks for adding it to your schedule. grin 20:31:07 Oh yeah I need to get going on the ptg... Who else thinks they'll be there? 20:31:36 Johnsom do you want my help on that? Throw me on it if so 20:31:41 I'll probably be there regardless 20:31:46 cgoncalves Yes, please -1 all of the patches you see that should have release notes!!!!!! 20:31:56 It's just a talk? Or lab? 20:32:02 Just a talk 20:32:05 johnsom, duly noted :D 20:32:30 * rm_mobile prepares to hate cgoncalves 20:32:50 rm_mobile, I wasn't expecting anything less ;) 20:33:16 as soon as storyboard fix some key issues I think we'll need to improve the stories/patches ratio 20:33:31 Release notes are important for communicating out 20:33:38 so at the end of it, we'll have a proactive backports (driven by severity etc) process 20:33:43 rm_mobile, if you want make a git hook that takes the commit title and creates a reno note ('fixes' type by default) haha 20:34:02 cgoncalves, lol 20:34:05 Oh don't give him ideas 20:34:27 * johnsom has visions of the quality of our release notes sinking 20:35:11 Other items? 20:36:27 After this cleanup patch is in and the tempest patch is fixed (so the gates don't -1) I would really like to get some review time on provider drivers. It's a big chain so can be a conflict magnet. 20:38:07 Ok, either we had a net split again or that is it for today. 20:38:40 nothing on my end 20:38:41 :) 20:38:48 Thanks folks! 20:38:51 #endmeeting