20:00:17 #startmeeting Octavia 20:00:19 Meeting started Wed May 31 20:00:17 2017 UTC and is due to finish in 60 minutes. The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:23 The meeting name has been set to 'octavia' 20:00:30 Hi folks! I'm back..... 20:00:33 o/ 20:00:40 Hello, wb 20:00:40 johnsom, welcome back! 20:01:14 Let's get started 20:01:15 #topic Announcements 20:02:11 Recently we had some breakage with the image. It turns out the pyroute2 package released with a bug that caused it to not allow interface renames, which we use to manage the network namespace. 20:02:52 I isolated that yesterday and the main developer fixed it last night. We also excluded that version in global-requirements. So that is now resolved. 20:03:19 Also a reminder, Pike-2 milestone is next week. 20:03:25 #link https://releases.openstack.org/pike/schedule.html 20:03:39 o/ 20:04:59 I have a few stable releases going, but hit a snag with the diskimage-builder changes, so I need to work through that with the release/stable team. Since DIB changed their packaging, it added a requirement, which the stable folks don't like (for good reason). I'm just not sure we have a choice here. 20:05:20 Hopefully now that infra is managing DIB it will be handled in a more stable way 20:06:15 Also of note, the docs team has a discussion about the future structure of documentation going on the dev list. I plan to respond today. It's in favor of our desire to have docs in-tree 20:06:36 Otherwise, I am still digging through a bunch of e-mail and patches. 20:06:42 Any other announcements today? 20:06:53 nop 20:07:09 johnsom: whats the issue with dib packaging? 20:07:16 (I'm not aware of it, not sure if others are) 20:07:17 just waiting for https://review.openstack.org/#/c/467473 to get merged already :) 20:08:11 Ugh our gates... 20:08:14 Make me cry 20:08:21 clarkb DIB changed to only allowing install via a package where there was none previously. So we had to add the requirement to pull in the new package. Since DIB does not have stable branches it means our stable branches need to change..... 20:08:21 Hopefully soon :P 20:08:57 johnsom: you mean it requires a proper pip install to function? 20:09:13 It was a good change, just makes managing stable branches interesting. 20:09:29 clarkb Yes, we had to add the new package to requirements.txt 20:09:43 gotcha 20:09:48 Which is not a good thing on stable branches 20:10:03 you could also just install it out of band wherever you were cloning it and using it before? 20:10:09 I will have a chat in the release channel and on the patch to figure out a path out of this 20:10:09 rather than making it a hard package dep? 20:10:13 ok 20:10:58 #topic Brief progress reports / bugs needing review 20:11:22 Ok, any bugs patches to highlight? I'm working though them as I can. I'm looking at the HM changes now. 20:11:35 It looks like there was a bunch of good stuff while I was on vacation 20:12:36 Yeah I have a ton of patches up 20:12:43 But on mobile so hard to link them all 20:12:45 Wow, ok. I will promote my own then, the api-ref patches could use some reviews 20:12:55 #link https://review.openstack.org/458272 20:13:03 #link https://review.openstack.org/464095 20:13:09 #link https://review.openstack.org/464050 20:13:22 Jude's client stuff is done and good to review too 20:14:05 Ah yes, I need to go take a look at that. Cool! 20:14:20 I think I have reviewed most of your stuff rm_mobile 20:14:43 #topic Flavors discussion (cpuga) 20:15:02 o/ 20:15:03 cpuga The floor is yours. You asked to have an agenda topic for flavors 20:15:46 yes was curios on the status of flavors 20:16:15 also a bit on the history 20:16:23 #link https://review.openstack.org/#/c/392485/ 20:16:38 I see that lbaas-loadbalancer-create has a flavor option 20:16:43 We have a proposed spec with a lot of comments, but I think it is abandoned at the moment. 20:17:14 History is flavors were added to neutron and an initial implementation was added to neutron-lbaas but not advanced. 20:17:44 The current "flavors" in neutron-lbaas only really mirrors the "provider" selection (specifying a driver). 20:17:46 so is the --flavor option within lbaas-loadbalancer-create not operational? 20:18:48 This spec is intended to figure out the details of a fully functional flavors implementation for Octavia that would encompass more that just the driver. 20:19:21 We just need a resource that is willing to step forward and take over the spec such that it can get approved. 20:19:52 a few weeks back I did email the author of the flavor spec about assisting with the implementing the spec 20:20:12 didn't hear back, but I'd like to run with it 20:20:21 cpuga I think the --flavor is barely operation in neutron-lbaas. 20:20:45 I do have a different data schema in mind 20:20:56 That is all I ask. That you reached out to the author and didn't hear back is good enough to me. Feel free to adopt and update that patch 20:21:45 would it be fine to start a fresh spec 20:21:57 Ok, feel free to propose an alternative. Spec time is the right time to do that. 20:22:03 this way we can have comments that are more relevant to the new design 20:22:16 k, thx 20:22:27 Well, I would prefer we update the inital patch, just to respect the work that went into the original proposal. 20:23:25 If it is completely different I guess a second spec patch could be appropriate. 20:23:40 ok I can do that as well, as long as it is fine that I change things around quite a bit 20:23:47 I just hate to drop the comments and ideas that were already presented 20:23:55 Sure 20:24:50 Any other discussion on flavors? 20:24:53 k, that is it for me. thx for the time. 20:25:04 Sure, no problem and thanks for working on that! 20:25:28 #topic Discuss asynchronous API and response handling (updates) (rm_work / johnsom) 20:25:48 This has been on the agenda for a while and we didn't have quorum to fully discuss. 20:25:58 rm_mobile I think you had a proposal? 20:26:32 Yeah.. 20:26:34 I think i put out three or four idea in previous meetings, interested to hear your perspective 20:26:55 Unfortunately trying to type up on mobile right now isn't happening, had the wrong meeting time 20:27:07 But probably you know the options 20:27:13 There are a couple 20:27:34 Should we discuss next week or do you want me to try to list them again? 20:28:11 You can probably list them 20:28:16 Ok 20:28:25 Or if you can stall for 8 min I'll be home :P 20:28:34 This is for update calls to the API 20:28:45 I will start and then you will be there.... grin 20:30:15 1. We return the data in the pre-update form but with provisioning status "PENDING_UPDATE". i.e. If they update the name field, the data the API will return will still have the old name but reflect that a change is in progress. This means we return the user accurate data at all times, but can be confusing. 20:32:05 2. We return the data with "faked" updates and "PENDING_UPDATE". This way the user gets back what they just changed, but the changes may not yet actually be applied yet. Followup GET calls will reflect the accurate state and not the "faked" data. For example, setting the LB to admin_state_up=False would show false in the response, but the LB would still 20:32:05 be passing traffic until the update completes. 20:34:20 3. We change our revert models such that we actually update the database with their requested changes. This means the result and future GET calls reflect the requested change, even though they may not yet be in effect. "PENDING_UPDATE" would still apply. To enable proper rollback to "actual state" we would need to pass the previous state data model over 20:34:20 to the controller so it has an idea of what to go back to should something fail. 20:34:48 4. Make the calls synchronous. Probably not a good idea. 20:35:18 i think I agree with you about 4 :) 20:35:30 5. Don't return anything on an Update call. This is how the new OSC commands behave. It would mean breaking the API though, so rolling the version, etc. 20:35:57 (just throwing them out there for completeness) 20:36:26 Other options I am forgetting? 20:36:39 * nmagnezi reads again 20:37:02 Yes 20:37:06 But uhh 20:37:33 Actually no 20:37:42 I vote #1 20:38:17 Honestly wasn't even considering options at this level 20:38:32 I also vote #1 actually. It is slightly confusing to the user, but is the most accurate view of the situation IMO. 20:38:58 I was actually thinking of just proposing options for how to implement #1 lol 20:39:28 I had assumed that would be what we would do 20:39:32 Ha, ok. Well, that should be fairly easy actually 20:39:41 Yes 20:39:47 #1 sounds right 20:40:02 However I'm pretty sure the current implementation is "mixed" and needs fixed. I have an open but to fix it. 20:40:27 johnsom, do we know how it is done in other projects? nova, neutron etc? 20:40:47 #link https://bugs.launchpad.net/octavia/+bug/1676662 20:40:48 Launchpad bug 1676662 in octavia "Octavia v2 API needs to update the return content on PUT" [High,Triaged] 20:41:35 nmagnezi I'm not 100% sure. I knew at one point, but it was too nice of weather on my vacation and I can't say 100% 20:42:04 ok so i have some ideas 20:42:07 there's a few options 20:43:34 so right now what we do is update just the status in the DB, and then pass the update-dict through the queue 20:43:37 what I propose we do 20:43:44 well, there's a couple options 20:44:23 1) we update the db and send the OLD object state through the queue -- this is easy, but if something dies in the queue, we lose the old object state, which is bleh 20:44:44 2) we snapshot the object in another DB table and pass a reference to the snapshot through the queue 20:45:08 Your #1 is my #3 I think.... 20:45:10 ^^ after updating the main object in the DB 20:45:37 AH yeah ok i misread in the car i think 20:45:49 then I vote #3 20:45:54 yeah i swapped them 20:46:01 #3 is what I was envisioning 20:46:36 Ok, so we have a longer conversation. 20:47:04 for #3 if something else queries the object during pending update it will not be able to determine the state 20:47:22 My issue with #3 is it's complicated and it returns data that may not actually be in effect yet. 20:48:07 it'll return the data the user intends to have, and is in PENDING_UPDATE for 20:48:14 yeah, it's a little more complex 20:48:14 #3 seems like it would be hard to determine actual truth during pending update 20:48:22 honestly I could be convinced to switch to #1 20:48:25 but i'll have to rethink 20:49:05 something else could come along and read state and get invalid values or at the very best would be left to undefined 20:49:27 It is the admin_state_up case that sways me towards #1. The user will get back an accurate snapshot of the state with the PENDING_UPDATE state. 20:53:12 We had one more agenda item, should we move on to that? 20:53:33 yeah sorry i am ALSO in another meeting 20:53:34 where i'm a driver <_< 20:53:55 Opps, so we should probably defer your other agenda item too. 20:54:17 Let's talk more, maybe in the lbaas channel. 20:54:25 #topic Open Discussion 20:54:37 Other topics to discussion in the few minutes we have left? 20:54:41 https://review.openstack.org/#/c/466260/ 20:54:46 agree with your comments 20:55:01 #link https://review.openstack.org/#/c/466260/ 20:55:13 We link so they are links in the minutes 20:55:39 for fast reloads though 20:55:43 it doesn't look like we support server-state-file 20:55:58 which allows for preserving the backend states through reloads 20:56:06 Ok, cool. Yeah, I have been following this for a while. I just want to be careful before we pull in ruby and that other code. 20:56:25 we can do server-state-file with custom template that is workaround 20:56:38 but that is something I noticed in my testing we needed 20:57:06 on 1 vCPU use case it is not an issue and will be more when we go to multi cpu 20:57:16 which ties into the flavor work 20:57:23 So the way that used to work (maybe changed) is when the second process is spawned (for the new connections) it does a table sync with the old process finishing the existing connections. Is that not the case? 20:57:34 yeah i would not recommend we pull in ruby <_< 20:58:38 Yeah, I know there were a number of issues that came up if you enabled the nproc mode. That is why we didn't do it originally. I know in recent releases they work working to resolve a number of those. 20:58:38 I think we are ok with not pulling in Ruby, since it is fixed in 1.8 with the -x option 20:59:37 It would be great if someone can dig through that again and see if the problems with nproc >1 are now resolved. I know stick table was one, config reloads was another. 20:59:58 sorry my connection was dropped so i was out for the past 10 minutes 21:00:14 that is something we would want to test, especially with flavor support 21:00:20 Well, we are out of time. 21:00:26 Thanks folks! 21:00:32 #endmeeting