20:00:00 <sbalukoff> #startmeeting Octavia
20:00:01 <openstack> Meeting started Wed Oct 29 20:00:00 2014 UTC and is due to finish in 60 minutes.  The chair is sbalukoff. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:04 <openstack> The meeting name has been set to 'octavia'
20:00:06 <sbalukoff> #topic Roll Call
20:00:14 <sbalukoff> howdy folks!
20:00:15 <dougwig> o/
20:00:18 <xgerman> o/
20:00:20 <ajmiller> 0/
20:00:21 <ptoohill> o/
20:00:37 <TrevorV> o/
20:00:38 <sbalukoff> Here's the agenda for today: https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Agenda
20:01:14 <sbalukoff> #topic Announcements and Updates
20:01:26 <rohara> o/
20:01:30 <sballe> o/
20:02:04 <sbalukoff> The only announcement that I have is that I'm thinking next week's meeting will probably be cancelled, as half of us will be at the summit next week (and probably in the UDP load balancing session, given the usual time for this meeting in Paris)
20:02:08 <rm_work> o/
20:02:17 <dougwig> seconded
20:02:41 <sbalukoff> If someone not going to the summit wants to run an Octavia meeting, y'all should feel free. Otherwise, I'm hoping we can collaborate with y'all online as we discuss things and hack code throughout the week.
20:02:57 <sbalukoff> Does anyone else have announcements they'd like to share?
20:03:23 <sballe> how about the neutron lbaas meeting next week?
20:03:24 <TrevorV> sbalukoff I think just keeping us in the loop with conversations is a great idea
20:03:26 <rm_work> I just had an AWESOME german sausage sandwich
20:03:30 <rm_work> that's my only announcement
20:03:34 <dougwig> sballe: planning to cancel that as well, but will ask tomorrow
20:03:35 <sbalukoff> :)
20:03:42 <sballe> :) ok
20:04:00 <sbalukoff> Ok, on to the next topic...
20:04:05 <sbalukoff> #topic Reviews Needing Attention ( https://review.openstack.org/#/q/stackforge/octavia+status:open,n,z )
20:04:53 <blogan> i think we've gotten some good comments on most of those that aren't WIP
20:05:01 <sbalukoff> We've actually got quite a few in there that don't have "-1" workflow, and also don't have enough "-1" love for actual reviews.
20:05:16 <sbalukoff> Yes-- that's true.
20:05:20 <dougwig> i can do some tomorrow, and more on saturday (in transit)
20:05:30 <sbalukoff> Definitely more activity this last week (thanks y'all!)
20:05:54 <blogan> i still need to push the docstring updates tot eh operator-api code, but probably won't get that done until this weekend or next
20:06:03 <ajmiller> Regarding https://review.openstack.org/#/c/130002/, I am actively working on addressing the comments, will have another patch later today.
20:06:14 <sbalukoff> Things are going to be a little chaotic with the summit, but let's please keep up the momentum in reviewing, eh!
20:06:17 <TrevorV> awesome ajmiller, looking forward to it!
20:06:35 <sballe> I'll do more reviews tomorrow too. I have some time again
20:06:49 <blogan> sballe: did you get a chacne to look at seqdiag?
20:06:53 <TrevorV> I'm gone for most of this weekend, but I'll have a significant amount of work to do while you guys are at the summit.  After you return I might start pestering again for reviews on the new content though :D
20:06:56 <sbalukoff> I've got a couple things to say about the Amphora API as well, but I'll wait until a little later for that.
20:06:57 <sballe> I am doing that next
20:07:21 <sballe> blogan: should be done before lunch tomorrow
20:07:40 <sbalukoff> Cool.
20:07:50 <blogan> great
20:07:57 <sbalukoff> Ok, we'll get updates on specific reviews a little later in this meeting.
20:08:06 <sbalukoff> For now, let's move on to the next topic
20:08:12 <rm_work> sballe: this is super useful for debugging/learning: http://blockdiag.appspot.com/seqdiag/
20:08:12 <sbalukoff> #topic Octavia hack-a-thon in December (sbalukoff)
20:08:24 <sbalukoff> Ok, so!
20:08:30 <blogan> no rackers :(
20:08:31 <sbalukoff> Let's do a hack-a-thon on Octavia in December.
20:08:41 <sbalukoff> I was thinking the week of Dec 8th.
20:08:41 <rm_work> sbalukoff: I'll probably be in WA in december
20:08:46 <rm_work> though not that early
20:08:55 <sbalukoff> And in Seattle.
20:08:58 <sballe> +1 on the Hackathon
20:09:04 <sballe> Seatlle +1
20:09:07 <xgerman> +1 and HP can host
20:09:10 <jorgem> lol
20:09:14 <sballe> sbalukoff: HP is happy to host it
20:09:17 <sbalukoff> Blue Box could host it, or if HP wants to, I'm game for either.
20:09:22 <blogan> Rackspace is happy not to attend
20:09:26 <TrevorV> ha ha ha
20:09:29 <dougwig> i'll do to whichever site has cold red bull.
20:09:32 <xgerman> blogan: Roadtrip?
20:09:33 <rm_work> I can be up there starting the 8th if Rackspace has no problem letting me work up there through January (I was planning to take several weeks vacation there anyway)
20:09:33 <dougwig> /do/go/
20:09:35 <jorgem> unless HP acquires us
20:09:40 <sballe> dougwig: We do! :)
20:09:46 <sbalukoff> blogan: Your budgets are freed up after the new year, right?
20:09:47 <dougwig> sballe: :)
20:09:57 <sbalukoff> maybe we can do another hack-a-thon in late January / early February.
20:10:04 <blogan> sbalukoff: more so than this year, but who knows what will be approved
20:10:16 <blogan> jorgem needs to look into that
20:10:18 <sbalukoff> Right.
20:10:19 <ptoohill> yea, not something to count on unfortunately
20:10:34 <sbalukoff> Well, or we could all head down to San Antonio again then or something.
20:10:47 <rm_work> heh
20:10:50 <ptoohill> :/
20:10:55 <blogan> out of pure principal I would not want that
20:10:59 <sbalukoff> Anyway, other than the RAXers not having budget to travel, any objections to that week or location?
20:10:59 <rm_work> just because Rackspace is cheap...
20:11:06 <rm_work> i don't recommend caving to them being stingy <_<
20:11:08 <dougwig> tax charity...
20:11:08 <ptoohill> lol
20:11:10 <rohara> warmer there in Dec compared to here
20:11:11 <dougwig> /tax/rax/
20:11:13 <dougwig> dya
20:11:30 <rm_work> I'll try to work out being there sbalukoff <_<
20:11:38 <sbalukoff> That would be great, Adam!
20:11:45 <blogan> you dont want him there
20:11:57 <sbalukoff> Ok, Suzanne and German: Shall we work out the details offline?
20:12:07 <sballe> sbalukoff: I would like to do Tues, Wed so we can travel on Mon
20:12:08 <dougwig> i'm in, at either location.
20:12:10 <TrevorV> If you waited for the week of the 15th my birthday would be rolled in :P
20:12:13 <sballe> sbalukoff: yes
20:12:22 <xgerman> yes
20:12:32 <sballe> dougwig: good. it about 1/2 mile from each other :)
20:12:44 <dougwig> heh, i meant seattle or san antonio.
20:12:47 <rm_work> lol
20:12:51 <sbalukoff> #action Hack-a-thon to be in Seattle during week of Dec. 8. sbalukoff, sballe, and xgerman to work out specifics and announce on mailing list
20:12:51 <rohara> haha
20:13:03 <sballe> dougwig: Oh I thougth you meant BlueBox or HP :)
20:13:14 <dougwig> that too.
20:13:20 <sbalukoff> TrevorV: Yeah, my birthday is the 17th.
20:13:27 <TrevorV> YOU LIAR!!!!
20:13:27 <xgerman> we will attach a Google Map with driving directions San Antonio - Seattle :-)
20:13:33 <TrevorV> sbalukoff and I have the same birth date
20:13:53 <sballe> Cool!
20:13:53 <rm_work> day, not date, I would assume :)
20:13:54 <rohara> my birthday is today. for real.
20:13:57 <sbalukoff> TrevorV: I'm not sure you want to advertise that. You know, having the same birthdate as a despot.
20:13:57 <blogan> mine is the 18th
20:14:01 <rm_work> happy birthday rohara :)
20:14:01 <blogan> happy birthday rohara!!
20:14:04 <TrevorV> happy birthday rohara !!
20:14:06 <rohara> thanks. 40.
20:14:12 <sbalukoff> Happy birthday, rohara!
20:14:16 <xgerman> happy b-day
20:14:18 <sbalukoff> Over the hill, even.
20:14:20 <rohara> sbalukoff: was birthdays on the agenda?
20:14:23 <rm_work> ah, and it's a milestone birthday to boot!
20:14:24 <dougwig> nice, happy bday
20:14:25 <sbalukoff> rohara: It is now.
20:14:29 <rohara> sweet
20:14:32 <TrevorV> Honestly though, I will probably go to that hackathon on my own dime since I want to go see seattle
20:14:33 <sbalukoff> #topic Happy Birthday rohara
20:14:37 <rohara> hahaha
20:14:41 <sballe> lol
20:14:48 <sbalukoff> Ok, next topic!
20:14:52 <sbalukoff> #topic Discussion with API working group (jaypipes)
20:14:54 <rohara> no i liek this one
20:14:56 <sbalukoff> Is jaypipes present?
20:15:42 <dougwig> he's on the channel list.
20:15:50 <sbalukoff> This is going to be more difficult to discuss with him not active.
20:15:55 <dougwig> maybe move ahead, and we can come back to this if he appears.
20:16:01 <blogan> i looked at some of their requirements
20:16:03 <sballe> good strategy
20:16:05 <sbalukoff> Well, first of all, has everyone ready the ML discussion on this?
20:16:22 <sbalukoff> Actually, that's a good plan.
20:16:30 <sbalukoff> We'll come back to this if he shows up.
20:16:40 <sbalukoff> #topic Progress reports
20:17:02 <sbalukoff> blogan: Update on the operator API?
20:17:31 <blogan> still need to add and push the docstrings but teh code can be reviewed
20:17:53 <blogan> the docstrigns update probably won't be pushed until this weekend or next week, lots to do
20:18:22 <sbalukoff> Cool. I will say: If you haven't looked yet, it's basically the Octavia variant of the LBaaS v2 user API right now. The idea here is to get a base to start from and flesh out operator specifics in later updates.
20:18:34 <sbalukoff> blogan: I hear you.
20:18:39 <sbalukoff> Ok, let's see...
20:18:42 <sbalukoff> Amphora API
20:18:50 <sbalukoff> Ok, that's me and davidlenwell
20:18:51 <blogan> i wantt o finish the amphora lifecycle doc first because a lot of work can come out of that
20:19:07 <sbalukoff> Oh, ok.
20:19:14 <sbalukoff> (Sorry, didn't mean to cut you off there.)
20:19:20 <blogan> oh i cut you off
20:19:21 <blogan> but im done now
20:19:24 <blogan> proceed
20:19:26 <sbalukoff> Heh
20:19:47 <sballe> blogan: I am interested inthe amphora lifecycle. How can I participate?
20:20:05 <blogan> sballe: https://review.openstack.org/#/c/130424/
20:20:10 <blogan> thats a WIP but you can add feedback
20:20:11 <sballe> thanks
20:20:12 <sbalukoff> Ok, so Amphora API: The spec is in, please review. Only major plan I have to change it right now (unless I hear back from y'all otherwise) is to remove the TLS certificate retrieval methods.
20:20:39 <sbalukoff> There's no reason the Amphora should ever send the private key data over the wire again once it has it.
20:20:42 <blogan> what abouto the /action?
20:20:51 <blogan> vs the query parameter
20:21:05 <blogan> its minor i nkow
20:21:11 <dougwig> network driver and neutron implementation (dougwig) - same as last week; expect something this weekend or early next week.
20:21:20 <rm_work> sballe: there's also stuff about the Amphora lifecycle in the TLS Data Security CR (look at the seqdiags): https://review.openstack.org/#/c/130659/
20:21:22 <sbalukoff> But! We might replace it with a method which allows the amphora to print the modulus of the key/cert and other meta-data, so the driver can query this without having to just overwrite what's there every time.
20:21:37 <rm_work> sbalukoff: ^^ to what you were saying, that stuff is detailed in the review i just linked
20:21:51 <sbalukoff> blogan: I like that suggestion too, and am planning on making that change per your suggestion.
20:22:00 <blogan> yes do my bidding
20:22:12 <sbalukoff> Hah!
20:22:23 <blogan> oh and 409 instead of 503?
20:22:32 <sbalukoff> Never let it be said that this dictator didn't listen to his peons.
20:22:34 <sbalukoff> ;)
20:22:43 <blogan> im just a serf
20:22:48 <rm_work> https://www.youtube.com/watch?v=xKKP_cZuk54
20:22:54 <sbalukoff> blogan: I'm still thinking 503 is appropriate for those particular scenarios.
20:23:13 <jorgem> what does nova do?
20:23:19 <sbalukoff> (ie. topology transition in progress should be a 503 error)
20:23:21 <jorgem> err…return?
20:23:24 <rm_work> nova is 409
20:23:30 <jorgem> ah well then
20:23:37 <jorgem> consistincy?
20:23:40 <sbalukoff> Does nova have a congruent scenario?
20:23:44 <xgerman> jorgem +1
20:23:51 <blogan> 503 says its unavailable bc of overload or maintenance, to me thats server maintenacne, doesn't ahve anythign to do with teh actual entity
20:23:54 <dougwig> this is octavia, it must be time for a vote.
20:24:04 <sbalukoff> Haha
20:24:12 <sballe> lol
20:24:25 <blogan> sbalukoff: yeah when a server is in a state not ACTIVE, it can be rebooted, restarted, etc, so it returns 409
20:24:25 <sbalukoff> Seriously, what does Nova actually return when an asynchronous command is in progress?
20:24:32 <sbalukoff> Aah.
20:24:35 <xgerman> 202
20:24:35 <blogan> it can't be rebooted
20:24:38 <jorgem> are you advocating using the retry-after header as well sbalukoff?
20:24:58 <sbalukoff> jorgem: I hadn't mentioned that specifically, but it's not a bad idea.
20:25:17 <blogan> 409 is consistent, and makes the most sense
20:25:24 <jorgem> sbalukoff: That would be nice but very hard to implement I would say
20:25:31 <rm_work> 409 is for when this happens on non-aynch
20:25:39 <rm_work> *non-asynch
20:25:41 <blogan> adn this is one of thos minor things that can take a while to agree on, but the Amphora API is an interface that the controller will be talkign to, so it has to be right
20:26:00 <dougwig> yeah, because we don't control both halves.
20:26:06 <sbalukoff> haha
20:26:41 <sbalukoff> I'm not vehemently opposed to 409 here... it makes little difference to the workflow, in my mind.
20:26:49 <sbalukoff> So, sure... I'll change it to a 409 error.
20:27:06 <sbalukoff> Anything else?
20:27:12 <jorgem> you buckle fast :)
20:27:15 <ptoohill> The little people do have a voice!
20:27:18 <blogan> im satisfied with my wins, i will shut up now
20:27:20 <jorgem> lol
20:27:29 <sballe> BTW Thanks to everybody who gave https://review.openstack.org/#/c/101281/10 a +1. It merged!
20:27:37 <sbalukoff> jorgem: I pick my battles. This one isn't that important in the long run. :)
20:27:49 <jorgem> sbalukoff: touche sir...touche
20:28:08 <sbalukoff> Ok!
20:28:13 <sbalukoff> dougwig: network driver and neutron implementation
20:28:18 <sbalukoff> Status update/
20:28:19 <sbalukoff> ?
20:28:23 <dougwig> look up about 30 status codes ago.
20:28:24 <blogan> he gave it up
20:28:29 <blogan> i mean he gave it up top
20:28:41 <sbalukoff> Aah, ok.
20:28:44 <sballe> :)
20:28:58 <sbalukoff> Is johnsom here today?
20:29:17 <xgerman> he has been pulled for a week long special project
20:29:39 <sbalukoff> Ok.
20:29:43 <xgerman> but will be back Monday
20:29:56 <sbalukoff> So, I know that davidlenwell has some ideas which should speed development of that part.
20:30:03 <blogan> xgerman: is this frankenlibra?
20:30:17 <xgerman> in a sense...
20:30:35 <sbalukoff> I'm concerned that it's been weeks since we've heard from him. I'll try contacting him directly.
20:31:02 <sbalukoff> (Because this is very quickly going to become a blocker for the amphora API work.)
20:31:16 <sbalukoff> Anyway, next...
20:31:20 <davidlenwell> sbalukoff: are you referring to the creating an image task using disk image builder ?
20:31:20 <sbalukoff> xgerman: amphora-driver-interface
20:31:28 <sbalukoff> davidlenwell: yes.
20:31:33 <xgerman> yes, we started implementation work
20:31:37 <davidlenwell> want me to just do that?
20:31:55 <sbalukoff> xgerman: We've yet to see any code committed.
20:32:08 <xgerman> yes, we will commit before the week ends
20:32:10 <sbalukoff> xgerman: And little communication
20:32:23 <davidlenwell> in a distributed project sometimes others have to puck up the slack
20:32:31 <davidlenwell> no hard feelings
20:32:50 <xgerman> amphora-driver-interface: code is coming
20:32:57 <sbalukoff> Also, I think this problem has mostly been solved by other projects.
20:33:29 <sbalukoff> Welcome, johnsom_!
20:33:46 <sbalukoff> I imagine you've just heard we were talking about the base image progress.
20:33:48 <johnsom_> I heard you were looking for me...  Sweet to be missed....
20:34:32 * blogan misses his johnsom bear
20:34:33 <johnsom_> Ah, spec is done, I have done some exploratory work.  Is it blocking someone?
20:34:36 <sbalukoff> johnsom_: So the base image stuff is going to become a blocker for the amphora API work fairly soon. And David has been able to find how the diskimagebuilder stuff has been handled in other projects.
20:34:42 <sbalukoff> How far along are you on the code?
20:35:00 <sbalukoff> I'm inclined to just have David take a crack at it at this point.
20:35:07 <johnsom_> Yeah, I am leveraging Sahara's scripts and adapting for our needs
20:35:12 <jaypipes> sbalukoff: sorry, here now :(
20:35:17 <davidlenwell> johnsom_: did you see this ? https://git.openstack.org/cgit/openstack/tripleo-image-elements/tree/elements/haproxy
20:35:21 <sballe> hi jaypipes
20:35:26 <sbalukoff> jaypipes: Sounds good. We'll come back to your topic in a few minutes.
20:35:41 <jaypipes> sbalukoff, sballe: cheers
20:36:46 <dougwig> little did i think that meant no one typing for a few minutes.
20:36:51 <johnsom_> Yes, I have seen the tripleo elements, which we will borrow from.  I have not looked at the haproxy element yet.
20:37:15 <sbalukoff> johnsom_: Can you commit the code you've written thus far this week?
20:37:42 <johnsom_> No, I'm not ready to commit code on this.
20:38:17 <blogan> thats what WIP is for really
20:38:24 <sbalukoff> Ok, then please don't be offended if I ask David to take a crack at it as soon as we need it for the amphora API code.
20:38:43 <johnsom_> I put it on the back burner while getting a first draft of a controller spec drafted.  I wanted to have a starting point for that spec out and getting chewed up while I did the code on disk image
20:39:06 <johnsom_> I'm not sure I see the dependency
20:39:38 <johnsom_> So, help me help you.  When do you think you need the disk image code?
20:40:05 <sbalukoff> David, when do you think you'll need it?
20:41:43 <blogan> davidlenwell?
20:41:53 <sbalukoff> Also, johnsom_: I'm mostly concerned that you've had this blueprint for weeks and we've not heard or seen any progress on it until now. I've got a couple people from EMC and elsewhere interested in working on Octavia, and we can't have people effectively squatting on blueprints or code.
20:42:11 <rm_work> oh snap
20:42:19 <sbalukoff> Again, in a distributed project sometimes others have to pick up the slack--  there's no offense meant by this.
20:42:24 <intr1nsic> I'd like to volunteer to help if needed.
20:42:28 <johnsom_> That was certainly not my intention sbalukoff
20:42:31 <sbalukoff> Very few of us do Octavia full-time, or as a primary role of our job.
20:42:46 <blogan> i think iterating in gerrit with WIPs would solve a lot of this
20:43:04 <sbalukoff> And people disappear unexpectedly because the circumstances of their involvement change.
20:43:15 <johnsom_> I am happy to prioritize it, I just need to understand the dependency and timing
20:43:30 <sbalukoff> And people disappear unexpectedly because the circumstances of their involvement change. This was the reason, in last weeks meeting, I brought up the the point "If it's not in gerrit, it doesn't exist."
20:43:31 <xgerman> we still haven't heard when you exactly need it
20:44:43 <jorgem> Remember the neutron lbaas weekly standup doc I made a long time ago? That identified blockers which will help identify "when" in a relative sense.
20:44:49 <jorgem> WIP will work too for this I think
20:45:00 <sbalukoff> I don't have an exact date on when we'll need it for the amphora API. We probably won't be able to effectively test the amphora API without it.
20:45:03 <jorgem> I actually think WIP makes the most sense
20:45:04 <johnsom_> I understand sbalukoff.  I am sure you can understand the amount of effort going into the controller spec design work.  I made the trade off because I didn't see any burning need for the diskimage code and I expect the spec will need a lot of discussion time.
20:45:42 <xgerman> jorgem, I only saw one blocker -- that the image script is neede now is news to me
20:46:08 <sballe> xgerman: +1
20:46:20 <jorgem> xgerman: This is all news to me since I've been working on other stuff I'm just stating what I see from an outside perspective. Will WIP not work?
20:46:21 <johnsom_> So, heard, people are interested in this code.
20:46:22 <sbalukoff> johnsom_: My impression is that you're being pulled into other things at HP. I've got people wanting to work on both of these things now, and I'm in the position of trying not to offend you by saying "if you don't have time to work on it right now, I'd rather have people who do have time right now work on it."
20:46:25 <blogan> xgerman: I think just getting code up where everyone can see progress is beneficial int he logn run for everyone.  Feedback is great to have
20:46:37 <rm_work> i think the point is that there are new people looking for stuff to do, and if you're not actively working on something for a while, someone else could be doing it instead
20:46:46 <sbalukoff> It's not a matter of deadlines, per se-- it's a matter of taking advantage of developer time while we've got it.
20:46:53 <rm_work> why complain about someone taking your work? so you have... less work to do? :P
20:46:55 <dougwig> can i suggest that the folks involved in this scheduling/priority thing talk about this offline, and we move on to other topics?
20:47:09 <xgerman> dogwig +1
20:47:14 <xgerman> dougwig +1
20:47:17 <johnsom_> Last I looked, there are still a lot of un-assigned blueprints
20:47:24 <rm_work> oh man i need a minute to photoshop a dogwig
20:47:25 <jorgem> dougwig: +1 I think we've identified a communication topic
20:47:27 <blogan> dougwig: +1 need to get jaypipes topic here
20:47:42 <rm_work> also mine:
20:47:43 <rm_work> TLS Data Security overview is up and ready for review -- need lots of eyes on it since it's about security :) https://review.openstack.org/#/c/130659/
20:47:59 <sbalukoff> Ok, let's go back to jaypipes' topic for now.
20:48:05 <johnsom_> I'm not complaining about anything rm_work.  Just news to me that this was an issue.
20:48:23 <rm_work> and I'm actually close to finished with the actual interface and implementation for CertManager -- which I'll hold off on posting until the spec gets solidified more
20:48:24 <xgerman> johnsom_ +1
20:48:27 <sbalukoff> #topic Discussion with API working group (jaypipes)
20:48:58 <sbalukoff> jaypipes? You have the floor.
20:49:31 <jaypipes> sbalukoff: hi :) so really I just wanted to know if the Octavia LBaaS API spec was published somewhere that the API WG can take a look at ..
20:49:47 <blogan> jaypipes: i sent you the spec for it in the ML
20:49:58 <blogan> jaypipes: docs have not been created though
20:50:15 <sballe> blogan: have about the doc Min created?
20:50:22 <blogan> jaypipes: is this up-to-date? https://github.com/openstack/api-wg
20:50:32 <sbalukoff> It's pretty close to Neutron LBaaS v2, with the exception of not having a ton of root-level objects.
20:50:33 <blogan> sballe: no that was for the neutron lbaas v2
20:50:35 <jaypipes> blogan: https://review.openstack.org/#/c/122338/1/specs/version0.5/operator-api.rst is just the operator API, though, no?
20:50:37 <sbalukoff> Er... methods.
20:50:59 <sballe> sbalukoff: +1
20:51:25 <blogan> jaypipes: well it'll be a superset of the user api, so thats why right now it only has user api calls
20:51:38 <blogan> jaypipes: it is just a starting point to iterate off of
20:51:58 <jaypipes> gotcha
20:52:30 <jaypipes> blogan: this is a big spec... :)
20:52:43 <jaypipes> kind of an all-in-one spec...
20:52:47 <dougwig> blogan never sleeps, near as i can tell.
20:53:01 <sbalukoff> Haha
20:53:03 <blogan> jaypipes: indeed, and really probably missing details you might need
20:53:45 <jaypipes> blogan: well, there's lots of details, which is great... I'd love to see the proposal use JSONSchema and JSONHome for payload and route discovery, respectively, but this is a good start,.
20:54:04 <blogan> jaypipes: we're using wsme for the json deserialization
20:54:19 <jaypipes> blogan: do you and the Octavia community mind if the API WG adopt the Octavia API as the first API we actively advise on and use as an example?
20:54:20 <blogan> jaypipes: that seemed to be the way openstack projects were going (ironic)
20:54:30 <blogan> jaypipes: would be great
20:54:39 <blogan> well i dont object, anyone else?
20:54:52 <jaypipes> blogan: yeah, the API WG is more concerned about the structure of the REST API resources, not as much (right now at least) on what libs or whatever is used for implementation.
20:54:54 <sbalukoff> I don't object either.
20:55:24 <jaypipes> blogan: things like terminology, response code standards, payload structure, etc... those are the things we're interested in maintaining (or forcing I guess) some consistency on.
20:55:32 <dougwig> i think it's a good idea, as long as we don't get pulled into political ratholes.  then, i would object.
20:55:39 <sbalukoff> jaypipes: What would you say their timeline is on providing feedback?
20:55:43 <rohara> haha
20:55:43 <jaypipes> blogan: however, we're not an enforcing agency as yet :) just advisory.
20:55:46 <sbalukoff> dougwig: +1
20:55:47 <blogan> jaypipes: okay sounds good, that'll definitely help with consistency across all openstack apis
20:56:12 <blogan> jaypipes: i'm sure most advice that is given will be accepted
20:56:18 <TrevorV> jaypipes forgive me, but are you saying it doesn't REALLY matter if we use WSME as long as the behavior according to the API is consistent with other openstack APIs?
20:56:51 <jaypipes> sbalukoff: well, I think within the next few weeks, definitely. basically, we're just now starting to create proposals for these REST API standards, and since Octavia's API is newly-proposed, it's a good one to pick as a joint "let's see where this goes" effort
20:57:27 <dougwig> jaypipes: doubly so for us, since everyone on this team is a relative newcomer to openstack.
20:57:42 <jaypipes> TrevorV: correct. AFAIK, the API WG isn't making any stand on particular libraries to use. The standard in OpenStack broadly is WSME/Pecan, though. I'm just saying that's not of concern for the API WG.
20:57:46 <xgerman> as long as we are not guinea pigs :-)
20:57:58 <TrevorV> Alright, that's great
20:58:03 <TrevorV> thanks for the clarification jaypipes
20:58:34 <jaypipes> xgerman: no, it's more the other way arouind... we're asking permission to use the things that come up in the Octavia API design conversations as ways for *us* to derive standards discussions.
20:58:40 <rm_work> dogwig: http://i.imgur.com/3Z0Tey0.jpg (shitty photoshop)
20:58:51 <sbalukoff> Heh!
20:58:53 <xgerman> jaypipes I like that :-)
20:59:02 <jaypipes> xgerman: so it's more like *we're* the guinea pigs, not the other way round.
20:59:09 <blogan> jaypipes: how will future collaboration happen?
20:59:11 <rohara> rm_work: octavia mascot imho
20:59:11 <xgerman> cool :-)
20:59:13 <sbalukoff> Ok, we're almost out of time here. Anyone else have something they want to say in the last 30 seconds?
20:59:25 <jaypipes> xgerman: basically, we have this openstack/api-wg repo that members of the WG are proposing standards as Gerrit patches/reviews to.
20:59:28 <dougwig> happy halloween.
20:59:40 <jorgem> yes
20:59:41 <rohara> sbalukoff: i have code for client lib/tool
20:59:46 <rohara> that is all
20:59:49 <TrevorV> https://www.youtube.com/playlist?list=PLD19BCF9D57320E03
20:59:53 <sbalukoff> rohara: Nice!
20:59:55 <blogan> rohara: push it ot gerrit as a WIP
20:59:58 <jaypipes> and we're looking to "resolve" all the controversial questions that often come up in API designs by submitting proposals to that repo that get voted on.
21:00:02 <sbalukoff> Yes, please push it!
21:00:06 <jorgem> xgerman: sballe: and really everyone, could you all respond to the usage ML thread I have going on please?
21:00:17 <jaypipes> blogan: see above...
21:00:18 <xgerman> yes, will do!
21:00:26 <sbalukoff> Ok, thanks folks!
21:00:28 <sbalukoff> #endmeeting