20:00:17 <johnsom> #startmeeting Octavia
20:00:19 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:23 <openstack> The meeting name has been set to 'octavia'
20:00:30 <johnsom> Hi folks!  I'm back.....
20:00:33 <nmagnezi> o/
20:00:40 <jniesz> Hello, wb
20:00:40 <nmagnezi> johnsom, welcome back!
20:01:14 <johnsom> Let's get started
20:01:15 <johnsom> #topic Announcements
20:02:11 <johnsom> 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 <johnsom> 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 <johnsom> Also a reminder, Pike-2 milestone is next week.
20:03:25 <johnsom> #link https://releases.openstack.org/pike/schedule.html
20:03:39 <rm_mobile> o/
20:04:59 <johnsom> 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 <johnsom> Hopefully now that infra is managing DIB it will be handled in a more stable way
20:06:15 <johnsom> 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 <johnsom> Otherwise, I am still digging through a bunch of e-mail and patches.
20:06:42 <johnsom> Any other announcements today?
20:06:53 <nmagnezi> nop
20:07:09 <clarkb> johnsom: whats the issue with dib packaging?
20:07:16 <clarkb> (I'm not aware of it, not sure if others are)
20:07:17 <nmagnezi> just waiting for https://review.openstack.org/#/c/467473 to get merged already :)
20:08:11 <rm_mobile> Ugh our gates...
20:08:14 <rm_mobile> Make me cry
20:08:21 <johnsom> 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 <rm_mobile> Hopefully soon :P
20:08:57 <clarkb> johnsom: you mean it requires a proper pip install to function?
20:09:13 <johnsom> It was a good change, just makes managing stable branches interesting.
20:09:29 <johnsom> clarkb Yes, we had to add the new package to requirements.txt
20:09:43 <clarkb> gotcha
20:09:48 <johnsom> Which is not a good thing on stable branches
20:10:03 <clarkb> you could also just install it out of band wherever you were cloning it and using it before?
20:10:09 <johnsom> I will have a chat in the release channel and on the patch to figure out a path out of this
20:10:09 <clarkb> rather than making it a hard package dep?
20:10:13 <clarkb> ok
20:10:58 <johnsom> #topic Brief progress reports / bugs needing review
20:11:22 <johnsom> 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 <johnsom> It looks like there was a bunch of good stuff while I was on vacation
20:12:36 <rm_mobile> Yeah I have a ton of patches up
20:12:43 <rm_mobile> But on mobile so hard to link them all
20:12:45 <johnsom> Wow, ok.  I will promote my own then, the api-ref patches could use some reviews
20:12:55 <johnsom> #link https://review.openstack.org/458272
20:13:03 <johnsom> #link https://review.openstack.org/464095
20:13:09 <johnsom> #link https://review.openstack.org/464050
20:13:22 <rm_mobile> Jude's client stuff is done and good to review too
20:14:05 <johnsom> Ah yes, I need to go take a look at that.  Cool!
20:14:20 <johnsom> I think I have reviewed most of your stuff rm_mobile
20:14:43 <johnsom> #topic Flavors discussion (cpuga)
20:15:02 <cpuga> o/
20:15:03 <johnsom> cpuga The floor is yours.  You asked to have an agenda topic for flavors
20:15:46 <cpuga> yes was curios on the status of flavors
20:16:15 <cpuga> also a bit on the history
20:16:23 <johnsom> #link https://review.openstack.org/#/c/392485/
20:16:38 <cpuga> I see that lbaas-loadbalancer-create has a flavor option
20:16:43 <johnsom> We have a proposed spec with a lot of comments, but I think it is abandoned at the moment.
20:17:14 <johnsom> History is flavors were added to neutron and an initial implementation was added to neutron-lbaas but not advanced.
20:17:44 <johnsom> The current "flavors" in neutron-lbaas only really mirrors the "provider" selection (specifying a driver).
20:17:46 <cpuga> so is the --flavor option within lbaas-loadbalancer-create not operational?
20:18:48 <johnsom> 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 <johnsom> 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 <cpuga> a few weeks back I did email the author of the flavor spec about assisting with the implementing the spec
20:20:12 <cpuga> didn't hear back, but I'd like to run with it
20:20:21 <johnsom> cpuga I think the --flavor is barely operation in neutron-lbaas.
20:20:45 <cpuga> I do have a different data schema in mind
20:20:56 <johnsom> 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 <cpuga> would it be fine to start a fresh spec
20:21:57 <johnsom> Ok, feel free to propose an alternative.  Spec time is the right time to do that.
20:22:03 <cpuga> this way we can have comments that are more relevant to the new design
20:22:16 <cpuga> k, thx
20:22:27 <johnsom> Well, I would prefer we update the inital patch, just to respect the work that went into the original proposal.
20:23:25 <johnsom> If it is completely different I guess a second spec patch could be appropriate.
20:23:40 <cpuga> ok I can do that as well, as long as it is fine that I change things around quite a bit
20:23:47 <johnsom> I just hate to drop the comments and ideas that were already presented
20:23:55 <johnsom> Sure
20:24:50 <johnsom> Any other discussion on flavors?
20:24:53 <cpuga> k, that is it for me. thx for the time.
20:25:04 <johnsom> Sure, no problem and thanks for working on that!
20:25:28 <johnsom> #topic Discuss asynchronous API and response handling (updates) (rm_work / johnsom)
20:25:48 <johnsom> This has been on the agenda for a while and we didn't have quorum to fully discuss.
20:25:58 <johnsom> rm_mobile I think you had a proposal?
20:26:32 <rm_mobile> Yeah..
20:26:34 <johnsom> I think i put out three or four idea in previous meetings, interested to hear your perspective
20:26:55 <rm_mobile> Unfortunately trying to type up on mobile right now isn't happening, had the wrong meeting time
20:27:07 <rm_mobile> But probably you know the options
20:27:13 <rm_mobile> There are a couple
20:27:34 <johnsom> Should we discuss next week or do you want me to try to list them again?
20:28:11 <rm_mobile> You can probably list them
20:28:16 <johnsom> Ok
20:28:25 <rm_mobile> Or if you can stall for 8 min I'll be home :P
20:28:34 <johnsom> This is for update calls to the API
20:28:45 <johnsom> I will start and then you will be there.... grin
20:30:15 <johnsom> 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 <johnsom> 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 <johnsom> be passing traffic until the update completes.
20:34:20 <johnsom> 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 <johnsom> to the controller so it has an idea of what to go back to should something fail.
20:34:48 <johnsom> 4. Make the calls synchronous.  Probably not a good idea.
20:35:18 <nmagnezi> i think I agree with you about 4 :)
20:35:30 <johnsom> 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 <johnsom> (just throwing them out there for completeness)
20:36:26 <johnsom> Other options I am forgetting?
20:36:39 * nmagnezi reads again
20:37:02 <rm_mobile> Yes
20:37:06 <rm_mobile> But uhh
20:37:33 <rm_mobile> Actually no
20:37:42 <rm_mobile> I vote #1
20:38:17 <rm_mobile> Honestly wasn't even considering options at this level
20:38:32 <johnsom> 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 <rm_mobile> I was actually thinking of just proposing options for how to implement #1 lol
20:39:28 <rm_mobile> I had assumed that would be what we would do
20:39:32 <johnsom> Ha, ok.  Well, that should be fairly easy actually
20:39:41 <rm_mobile> Yes
20:39:47 <nmagnezi> #1 sounds right
20:40:02 <johnsom> However I'm pretty sure the current implementation is "mixed" and needs fixed.  I have an open but to fix it.
20:40:27 <nmagnezi> johnsom, do we know how it is done in other projects? nova, neutron etc?
20:40:47 <johnsom> #link https://bugs.launchpad.net/octavia/+bug/1676662
20:40:48 <openstack> Launchpad bug 1676662 in octavia "Octavia v2 API needs to update the return content on PUT" [High,Triaged]
20:41:35 <johnsom> 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 <rm_work> ok so i have some ideas
20:42:07 <rm_work> there's a few options
20:43:34 <rm_work> 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 <rm_work> what I propose we do
20:43:44 <rm_work> well, there's a couple options
20:44:23 <rm_work> 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 <rm_work> 2) we snapshot the object in another DB table and pass a reference to the snapshot through the queue
20:45:08 <johnsom> Your #1 is my #3 I think....
20:45:10 <rm_work> ^^ after updating the main object in the DB
20:45:37 <rm_work> AH yeah ok i misread in the car i think
20:45:49 <rm_work> then I vote #3
20:45:54 <rm_work> yeah i swapped them
20:46:01 <rm_work> #3 is what I was envisioning
20:46:36 <johnsom> Ok, so we have a longer conversation.
20:47:04 <jniesz> for #3 if something else queries the object during pending update it will not be able to determine the state
20:47:22 <johnsom> My issue with #3 is it's complicated and it returns data that may not actually be in effect yet.
20:48:07 <rm_work> it'll return the data the user intends to have, and is in PENDING_UPDATE for
20:48:14 <rm_work> yeah, it's a little more complex
20:48:14 <jniesz> #3 seems like it would be hard to determine actual truth during pending update
20:48:22 <rm_work> honestly I could be convinced to switch to #1
20:48:25 <rm_work> but i'll have to rethink
20:49:05 <jniesz> 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 <johnsom> 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 <johnsom> We had one more agenda item, should we move on to that?
20:53:33 <rm_work> yeah sorry i am ALSO in another meeting
20:53:34 <rm_work> where i'm a driver <_<
20:53:55 <johnsom> Opps, so we should probably defer your other agenda item too.
20:54:17 <johnsom> Let's talk more, maybe in the lbaas channel.
20:54:25 <johnsom> #topic Open Discussion
20:54:37 <johnsom> Other topics to discussion in the few minutes we have left?
20:54:41 <jniesz> https://review.openstack.org/#/c/466260/
20:54:46 <jniesz> agree with your comments
20:55:01 <johnsom> #link https://review.openstack.org/#/c/466260/
20:55:13 <johnsom> We link so they are links in the minutes
20:55:39 <jniesz> for fast reloads though
20:55:43 <jniesz> it doesn't look like we support server-state-file
20:55:58 <jniesz> which allows for preserving the backend states through reloads
20:56:06 <johnsom> 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 <jniesz> we can do server-state-file with custom template that is workaround
20:56:38 <jniesz> but that is something I noticed in my testing we needed
20:57:06 <jniesz> on 1 vCPU use case it is not an issue and will be more when we go to multi cpu
20:57:16 <jniesz> which ties into the flavor work
20:57:23 <johnsom> 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 <rm_work> yeah i would not recommend we pull in ruby <_<
20:58:38 <johnsom> 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 <jniesz> I think we are ok with not pulling in Ruby, since it is fixed in 1.8 with the -x option
20:59:37 <johnsom> 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 <nmagnezi> sorry my connection was dropped so i was out for the past 10 minutes
21:00:14 <jniesz> that is something we would want to test, especially with flavor support
21:00:20 <johnsom> Well, we are out of time.
21:00:26 <johnsom> Thanks folks!
21:00:32 <johnsom> #endmeeting