20:00:10 <johnsom> #startmeeting Octavia
20:00:11 <openstack> Meeting started Wed Apr 19 20:00:10 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:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:14 <openstack> The meeting name has been set to 'octavia'
20:00:18 <rm_work> o/
20:00:22 <johnsom> Hi folks
20:00:32 <nmagnezi> o/
20:00:54 <johnsom> #topic Announcements
20:01:00 <johnsom> TC voting is open, check your email for the link
20:01:13 <johnsom> I think today might be the last day to vote.
20:01:22 <nmagnezi> xgerman, is running :-)
20:01:41 <johnsom> Yeah, crazy person...  Grin
20:01:48 <nmagnezi> :)
20:02:07 <johnsom> He is still on vacation, so I can get away with that
20:02:31 <johnsom> Also, our third party sonar gate is no more
20:02:48 <nmagnezi> yup, it's not like the meeting is logged or anything :-)
20:03:08 <johnsom> It got accidentally deleted, so....
20:03:22 <nmagnezi> will it get restored?
20:03:37 <johnsom> I am setting up a coverage gate with infra that should at least give us the coverage information.
20:03:48 <johnsom> #link https://review.openstack.org/457819
20:04:00 <johnsom> We needed it anyway, but sad to see the sonar gate go.
20:04:19 <johnsom> I still have the setup instructions so maybe sometime in the future we will build another one.
20:04:54 <nmagnezi> ack
20:05:12 <rm_work> yes, very sad
20:05:33 <johnsom> Also of note, Mitaka is officially EOL.  ( think I mentioned this last week too)
20:05:42 <rm_work> probably partially my fault for not insisting the person who created the VM name it more appropriately >_<
20:06:04 <johnsom> You will see the stable/mitaka branch go away soon.  There will be a tag "mitaka-eol" with the last "release"
20:06:31 <johnsom> A, well, that poor gate has had a rough life anyway.....
20:06:40 <rm_work> ok, hopefully our mitaka stable is fully working... i noticed some weirdness with some of the stable branch scenarios recently
20:06:41 <rm_work> but
20:06:44 * rm_work shrugs
20:07:25 <rm_work> I really liked sonar, it was a good canary T_T
20:07:26 <johnsom> Yeah, we have had to do a number of stable branch fixes recently due to projects that run without stable branches, namely devstack and diskimage-builder.
20:07:42 <rm_work> finished in like ... 2 minutes
20:08:03 <rm_work> ... send me those instructions again, maybe I can get it set up here
20:08:20 <rm_work> Rackspace HP Sonar Gate (by GoDaddy)
20:08:27 <johnsom> rm_work Sure, I can dig those out.  I also still own the domain.
20:08:29 <johnsom> Ha
20:08:40 <rm_work> tempted to do it just for the name
20:08:43 <johnsom> Yeah, like I said, rough life
20:09:04 <johnsom> Ironically, the domain is registered through my personal godaddy account.....
20:09:42 <rm_work> lol
20:09:51 <rm_work> maybe I can get them to credit you for it
20:10:18 <johnsom> Ha, it's not much so probably not worth the effort.  I have other domains so I think it was discounted.
20:10:42 <johnsom> It's not like the old .io domain which was surprisingly expensive
20:10:51 <rm_work> yeah O_o
20:10:57 <rm_work> those run like $60/year
20:11:14 <johnsom> It was $70 when I thought about registerting it
20:11:26 <johnsom> #link http://www.octavia.cloud
20:11:33 <johnsom> It still goes to our docs page...
20:12:01 <nmagnezi> .cloud ... lol
20:12:06 <rm_work> :P
20:12:10 <johnsom> Any other announcements today?
20:12:51 <johnsom> #topic Brief progress reports / bugs needing review
20:13:17 <johnsom> Ok, thanks to rm_work our py3 and scenario gates are fully functional now.
20:13:43 <rm_work> \o/
20:13:48 <nmagnezi> kudos rm_work!
20:13:52 <rm_work> also, our v2 API patches are ALMOST done
20:13:59 <rm_work> just HM and then paging/sorting
20:14:06 <rm_work> and some work around single-create and cleanup
20:14:09 <johnsom> I released our milestone pike-1 packages last week and registered out community goals
20:14:13 <rm_work> but the majority is complete
20:14:19 <rm_work> HM could use review
20:14:25 <johnsom> Yeah, stats and status still too
20:14:30 <rm_work> ah yeah T_T
20:14:35 <johnsom> But the majority is done
20:14:49 <rm_work> all of the objects, so you can create a fully hydrated LB
20:14:51 <johnsom> I have started on the pools API docs.
20:15:14 <johnsom> Should be able to get those finished this week.
20:15:58 <johnsom> I also did the quotas for the v2 API, though it needs some minor updates after this weeks changes
20:16:56 <johnsom> My plan for the next week is to keep cranking through API docs.
20:17:30 <johnsom> nmagnezi how is the user_group patch going?
20:18:09 <nmagnezi> johnsom, pretty good. tested okay with Ubuntu amp. tomorrow I'm going to test agains a centos amp
20:18:32 <johnsom> Ok, so should be good for review/testing tomorrow then?
20:18:33 <nmagnezi> johnsom, and if that passes it should be the final version of the patch (pending reviews)
20:18:40 <nmagnezi> yup
20:18:48 <johnsom> Excellent, looking forward to it.
20:19:19 <nmagnezi> I'll post detailed test results (manual tests I ran) in the patch as soon as it is ready :)
20:19:46 <johnsom> I know Jude has done some good work on getting the HM/HK processes to exit faster (not stuck sleeping).
20:19:51 <johnsom> That is good too
20:20:15 <johnsom> Ok, moving on
20:20:20 <JudeC> Still needs a review though
20:20:29 <johnsom> #topic Plan to make scenario gates voting
20:20:56 <johnsom> Now that we have a break in the OpenStack storm and our scenario gates are functioning I plan to make them voting.
20:21:05 <johnsom> This is part of our py3 goal for Pike.
20:21:24 <rm_work> which ones?
20:21:41 <johnsom> The new infra images have resolved our OVH issues, so things should be in good shape
20:21:42 <rm_work> I assume *not* anything n-lbaas (please T_T)
20:22:31 <johnsom> I plan to do all except centos (pending user_group patch) and lxd
20:22:56 <johnsom> Why not the n-lbaas scenarios?
20:23:23 <rm_work> because n-lbaas needs to die
20:23:30 <clarkb> what were the ovh issues? (I'm not aware of any changes to specifically address anything in ovh)
20:23:41 <rm_work> and also, having a voting dependency on n-lbaas could be problematic
20:23:45 <johnsom> clarkb libvirt was crashing
20:23:47 <rm_work> because we could run into a circular merge issue
20:23:57 <clarkb> johnsom: oh,thats actually a change to devstack, but good to know
20:24:25 <johnsom> I posted a "thank you" in the infra channel yesterday.
20:25:10 <johnsom> rm_work We are still going to make sure we function behind neutron-lbaas for Pike....
20:25:57 <rm_work> yes, but
20:26:01 <rm_work> non-voting is fine >_>
20:27:09 <johnsom> I think we need to make it voting, we kind of have a contract for our users that neutron-lbaas will still work with the octavia driver
20:28:12 <clarkb> note that the change to use UCA doesn't currently affect stable branches. Its master and going forward
20:28:20 <rm_work> and we can make sure we watch for issues, but if we have a gate problem in octavia because of neutron-lbaas I am going to start throwing things
20:28:30 <johnsom> Ha
20:29:06 <johnsom> clarkb Yeah, we will live the recheck life in stable like we had been
20:29:11 <rm_work> if it's a vote, i'm going to -1, if it's your decision as PTL, that's fine
20:29:36 <johnsom> Well, I wanted discussion (thus the agenda item)
20:30:00 <rm_work> just yesterday we had an issue where we needed to merge something in both repos because both had distinct gate issues
20:30:23 <rm_work> it SEEMS like that would have been more of a PITA if we have a voting gate between them
20:30:53 <johnsom> Until we officially deprecate neutron-lbaas we need to make sure we have a fully functional stack
20:31:42 <rm_work> sure, so procedurally, let's make sure we look and see the check is green before we +A :)
20:32:36 <johnsom> Agreed, these outside changes breaking us are a huge pain, but that shouldn't stop us from making sure we have functional and quality code merged.
20:33:00 <rm_work> and having voting *octavia* scenario gates should do that
20:33:27 <johnsom> I will compromise.  I will go voting on octavia and leave neutron-lbaas non-voting a while longer to see it's stability.
20:34:00 <rm_work> that's all I want :)
20:34:10 <johnsom> Yeah, but octavia gates go direct to the octavia API which is not how most of our deployments are setup.
20:34:47 <johnsom> Ok, next up.
20:34:52 <johnsom> #topic Boston Summit planning
20:35:13 <rm_work> I just booked travel... I *can* make it on Monday in time for the lab
20:35:16 <rm_work> and I can help on talks
20:35:21 <johnsom> Which unfortunately German is still on vacation so we have the opposite half of the conversation this week
20:35:24 <rm_work> but I don't have time to do much work preparing for either
20:35:42 <rm_work> so I am happy to show up and help
20:35:43 <rm_work> and review slides or something
20:35:45 <johnsom> That was what I wanted to discuss.  Should we cancel some of the talks?
20:35:57 <rm_work> I am not sure what we will have time to prepare for
20:36:02 <rm_work> we NEED the project update one
20:36:07 <johnsom> I will not be able to attend, but can help with slides and such.
20:36:09 <rm_work> and probably we should do the main LBaaS one
20:36:16 <rm_work> what was the third talk?
20:36:24 <rm_work> the lab is ... we should discuss the lab, but need xgerman
20:36:27 <johnsom> Load balancing 101
20:36:57 <johnsom> It seems like the main LBaaS talk and the project update could overlap content.
20:37:12 <rm_work> hmm
20:37:15 <rm_work> yeah mayhaps
20:37:25 <rm_work> I feel like... is LB101 the same thing we've done every year?
20:37:29 <johnsom> I had planned project update to talk about the new project and the roadmap, where the main one would be about the merge details
20:37:43 <rm_work> is that useful?
20:37:45 <johnsom> No, LB101 is like "A network load balancer is..."
20:38:06 <johnsom> Like basics and cookbook content.
20:38:17 <rm_work> right ... haven't we done that before?
20:38:18 <rm_work> or no
20:39:10 <johnsom> We have done small segments, but not in a while or to the depth I was going to go in this session.  It's one we could cancel and just post a youtube for as well
20:39:41 <rm_work> k
20:39:42 <rm_work> I mean... I can try to give any amount of talks
20:39:48 <rm_work> I just *can't* plan for them
20:39:49 <rm_work> so
20:40:26 <johnsom> Ok, if you are up for them, I can help with slides.  Most of those were my talks so I didn't want to dump the presentation job on other folks.
20:40:59 <rm_work> also I can't guarantee I can be as thorough as you could for description or questions
20:41:07 <rm_work> but I can disclaimer up front that I'm a backup :P
20:41:23 <johnsom> Yeah.  Or phone-a-friend
20:41:24 <johnsom> HA
20:41:42 <rm_work> the lab is what I'm worried about the most
20:41:43 <rm_work> lol yeah I could Zoom/Skype you in on my Laptop
20:41:55 <rm_work> Giant head on a projector
20:41:57 <rm_work> wouldn't that be fun
20:42:01 <johnsom> Yeah, if the wifi is good enough
20:42:07 <rm_work> yeah we can test and see
20:42:40 <johnsom> Anyway, ok, so current plan, without German here, is to still do all four, but we need to create slides
20:42:48 <johnsom> right?
20:42:51 <rm_work> I guess
20:42:56 <johnsom> Ok
20:42:57 <rm_work> I am concerned about the lab
20:43:02 <rm_work> because with just two of us
20:43:07 <rm_work> it will be difficult as-is
20:43:11 <rm_work> and i don't know what his plan for it is
20:43:13 <rm_work> or if he has one
20:43:15 <johnsom> Yep, agreed
20:43:35 <nmagnezi> just play the recording of past years :D
20:43:42 <rm_work> it took a lot of prep last time that I did on the technical side
20:43:43 <rm_work> so I hope he isn't just planning to wing that the night before
20:44:00 <rm_work> in addition to the actual content of the talk
20:44:04 <johnsom> We can have it on next weeks agenda as well
20:44:08 <rm_work> ok
20:44:20 <rm_work> cutting it close though
20:44:24 <johnsom> #topic Discuss asynchronous API and response handling
20:45:05 <johnsom> This was discussed last week in depth.  Do we want to try to discuss more in 15 minutes, or just give some open discussion time and put it on next weeks agenda?
20:45:46 <johnsom> crickets
20:45:59 <rm_work> hmm
20:46:07 <rm_work> i missed last week
20:46:10 <rm_work> maybe i should catch up
20:46:19 <johnsom> I think we need some time on this, so let's move it to next week but plan to decide a path forward then.
20:47:00 <johnsom> #link http://eavesdrop.openstack.org/meetings/octavia/2017/octavia.2017-04-12-20.00.log.html#l-69
20:47:19 <johnsom> #topic Open Discussion
20:47:29 <johnsom> Other topics for today?
20:47:49 <JudeC> I am taking over the python-octaviaclient
20:48:04 <johnsom> Ah, yes, Excellent!
20:48:09 <JudeC> just a general fyi
20:48:13 <rm_work> ^^ along with possibly another resource here
20:48:24 <rm_work> we'll see if he is able to come on
20:48:31 <johnsom> I should probably look at the state of the SDK work as well
20:48:56 <JudeC> Yeah, we dont have a fully fleshed out spec for it though but I am using https://docs.openstack.org/developer/python-octaviaclient/decoder.html#lbaas-v2-cli as aguide
20:49:28 <johnsom> Yeah, any time you have questions please ask in the channel.
20:49:46 <JudeC> Perfect ty
20:49:51 <johnsom> The old client was not as good as we can make the OSC plugin so
20:50:29 <johnsom> If you would like me to put tracking bugs in or something like that, let me know.
20:50:56 <JudeC> That would be useful IMO.
20:51:51 <johnsom> Ok, I will make some time to enter those.  I will create a new tag
20:52:15 <johnsom> Probably "octavia-osc"
20:53:25 <johnsom> Any additional items today?
20:54:12 <johnsom> Ok, thanks folks!  Chat with you in the normal channel
20:54:16 <rm_work> o/
20:54:20 <nmagnezi> o/
20:54:22 <johnsom> #endmeeting