16:00:40 <elmiko> #startmeeting api wg
16:00:41 <openstack> Meeting started Thu Feb 11 16:00:40 2016 UTC and is due to finish in 60 minutes.  The chair is elmiko. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:45 <openstack> The meeting name has been set to 'api_wg'
16:00:49 <elmiko> #chair cdent etoews
16:00:53 <openstack> Current chairs: cdent elmiko etoews
16:00:58 <elmiko> hi
16:00:59 <gouthamr> hello o/
16:01:03 <etoews> hello
16:01:09 <cdent> howdy
16:01:14 * elmiko hands mic to etoews
16:01:51 * etoews drops mic
16:01:59 * cdent was waiting for that
16:02:05 <elmiko> haha
16:02:15 <elmiko> #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
16:02:25 * etoews fumbles about for mic
16:02:29 <elmiko> #topic previous meeting action items
16:02:30 <cdent> so: we had disco balls and glitter in the service catlog meeting, this meeting has a high bar to meet
16:02:34 <annegentle_> ha
16:02:40 <elmiko> lol, nice
16:02:59 <elmiko> #link http://eavesdrop.openstack.org/meetings/api_wg/2016/api_wg.2016-01-28-16.00.html
16:03:30 <etoews> well the summit submission is done so +1
16:03:31 <elmiko> so, i got all of mine. the server-side traceback guideline merged today
16:03:43 <etoews> \o/
16:03:49 <elmiko> huzzah!
16:03:59 <cdent> motion
16:04:19 <annegentle_> nice!
16:04:20 <elmiko> it actually got a really solid response since the rework, nicely done jaypipes
16:04:23 <etoews> ah i haven't reached out directly to the CPLs about the errors guideline but have been working with the magnum team.
16:04:32 <elmiko> cool
16:04:38 <etoews> more on that later (if we get to it)
16:04:45 <elmiko> k
16:04:55 <elmiko> let's dig in to the meat and potatoes
16:04:57 <elmiko> #topic service type vs. project name for use in headers
16:05:03 <elmiko> #link http://lists.openstack.org/pipermail/openstack-dev/2016-January/085145.html
16:05:12 <elmiko> #link http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-02-02-20.01.log.html#l-263
16:05:21 <elmiko> etoews
16:05:41 <etoews> i managed to read through the email thread yesterday
16:05:47 <elmiko> \o/
16:06:20 <annegentle_> that's an accomplishment
16:06:21 <cdent> the first three agenda items are all really a piece of the same thing
16:06:32 <elmiko> cdent: yea, pretty much
16:06:32 <etoews> ya
16:06:51 <etoews> i'm in agreement with cdent on that thread fwiw
16:06:56 <cdent> So I would be curious to get etoews' reaction to the whole pile
16:07:05 <etoews> :)
16:07:12 <cdent> \o/
16:07:14 <annegentle_> heh there you have it
16:07:25 * etoews warms his hands on the fire in cdent's belly
16:07:32 <elmiko> so, basically, we should have a registry based on service types and that we should curate it?
16:07:36 <elmiko> lol
16:08:01 * cdent has been experiencing a bit of discomfort lately
16:08:05 <etoews> hold on. let me check something.
16:08:42 <elmiko> or am i jumping ahead?
16:08:45 <etoews> i was thinking primarily of this
16:08:57 <etoews> "I think that's pretty weak sauce and we need to take both a more assertive and more aggressive stance with regard to achieving quality and consistency in the APIs[1]. Reaching consistency is the primary mission of the group but consistent crap is still crap and our API consumers deserve better."
16:09:23 <elmiko> ok, cool
16:09:37 <elmiko> and yea, i agree with cdent on this one too. i'm just timid about how we achieve it...
16:09:41 <cdent> that statement puts us oh so mildly in conflict with sdague's belly's fire
16:10:11 <annegentle_> What I keep sensing is "if we had a good API docs site we would have discoverability of conflicts"
16:10:13 <cdent> If I understand him correctly he doesn't want us striving for purity for purity's sake at the cost of "breaking" existing things.
16:10:19 <annegentle_> but can't boil the ocean of course
16:10:20 <sdague> cdent: right
16:10:30 <sdague> we did that once
16:10:35 <sdague> it was called Nova v3.0
16:10:54 <sdague> after two years we had to throw the whole thing out because no one was ever going to drop v2 if we did that
16:10:57 <elmiko> the real question then becomes, where to draw the line between purity and absurdity
16:11:12 <cdent> yeah, I think we can find a middle ground
16:11:30 <cdent> What's important to me is that we don't _always_ use precendent as truth
16:11:32 <elmiko> imo, we have been trying to do that by doing api evaluations before we create guidelines
16:11:34 <cdent> there's a lot of stuff that is just wrong
16:11:40 <cdent> elmiko: yes
16:11:41 <elmiko> agreed
16:12:07 <sdague> right, but my particular point here was the 4 characters coming out of the header we being deleted for no real reason than purity
16:12:15 <etoews> it's the standard deprecation dance. right it comes down to a question of how long anyone is willing to support previous versions.
16:12:35 <sdague> etoews: it's not standard deprecation dance when it comes to APIs
16:13:00 <etoews> in what regrad?
16:13:05 <sdague> you can use the original ec2 api as it was in 2006
16:13:19 <annegentle_> heh sdague well.
16:13:54 <cdent> sdague: I'm not disputing the truth of that, but I guess why we've decided replicating that behavior is a goal?
16:13:55 <etoews> right. aws has the willingness (and developer workforce) to more or less indefinitely support apis.
16:13:57 <sdague> if we are looking for adoption on the openstack front, compatibility is key
16:14:13 <etoews> i'm in full agreement.
16:14:34 <annegentle_> totally agree, what would change that would be concerning sdague?
16:14:47 <sdague> annegentle_: the mailing list post I had
16:14:51 <etoews> a v3 is conceivable as long as we're willing to support v2 (ideally indefinitely)
16:15:07 <sdague> about changing a header name for no good reason
16:15:11 <annegentle_> sdague: ah ok
16:15:20 <elmiko> i'm a little stumped on the whole "remove API_" issue, it makes sense to me to remove it from an outside perspective, but i acknowledge sdague's point as well. it's not clear for me how to draw the line.
16:15:31 <sdague> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085670.html
16:15:41 <annegentle_> we're in a different world though where contributors want to have experimental APIs. what can we do about that?
16:16:04 <etoews> can we save experimental apis for a bit later?
16:16:12 <annegentle_> etoews: sure
16:16:14 <elmiko> +1
16:16:23 <sdague> yeh, lets sort this one on the microversion spec
16:17:00 <annegentle_> sdague: so the other side that I see tho is "just cuz nova did it first we all have to agree?"
16:17:01 <cdent> I feel like etoews has more to say on the general topic. Do you?
16:17:04 <sdague> basically I didn't want gratuitious header change. I agree service type instead of code name is important, but dropping API- is gratuitious
16:17:09 <annegentle_> sdague: I'm not arguing, I'm pointing out the other view
16:17:10 <elmiko> annegentle_: yea, that's kinda my question too
16:17:34 <etoews> let me start by saying i'm willing to back off on having to remove API-
16:17:45 <annegentle_> sdague: but I can't tell from reading if it's the four characters or the nova start point?
16:17:51 <elmiko> etoews: agreed, but i think it makes a good pinata for now
16:18:05 <sdague> annegentle_: it's because we have multiple things out in the field that do it.
16:18:14 <etoews> but it really point to what annegentle_ brought up above "just cuz nova did it first we all have to agree?"
16:18:23 <sdague> telling released services you have to break your users needs a real benefit
16:18:35 <sdague> not just cuz someone thinks it's nicer
16:18:59 <elmiko> i don't feel like we're advocating for a reverse in direction for those who implement it with the API-
16:19:08 <elmiko> we're trying to forge a new way forward
16:19:09 <annegentle_> sdague: so, I'm working with SDK devs who are implementing microversions now
16:19:19 <sdague> elmiko: so instead you'll have to keep a decoder ring of headers
16:19:39 <annegentle_> sdague: it's going fine but we are having to explain in one:one conversations. This spec helps immensely of course.
16:19:48 <elmiko> sdague: i feel like we'll have to do that either way, imo it's part of the evolutionary process
16:19:55 <sdague> because you can't OpenStack-%s-API-Minimum-Version % service
16:19:56 <cdent> #idea: For future reference resist standardizing on header types with meaingful and changeable identifiers in the header left hand side. Bad for flexibility and bad HTTP.
16:20:37 <sdague> elmiko: see, I feel like this was going to be  OpenStack-%s-API-Minimum-Version % service in the code, which is fine.
16:20:43 <elmiko> interesting though cdent, how do we write guidelines then?
16:20:45 <etoews> sdague: nope. step 1. add new header to nova. step 2. remove all documentation on old header. step 3. likely nothing (support both headers server side forever)
16:21:02 <sdague> etoews: you *CAN'T* removal all documentat
16:21:20 <sdague> there are clouds out there, publicly deployed, where this is the interface
16:21:21 <cdent> elmiko: generic left hand side, multi-variant right hand side
16:21:27 <sdague> and the other header isn't accepted
16:21:56 <sdague> this is a key part of the bootstrapping
16:22:08 <elmiko> cdent: maybe, probably, i'm missing something but how would we avoid the API- no API- question?
16:22:27 <cdent> (elmiko let's punt on that for a minute)
16:22:32 <elmiko> k
16:22:51 <cdent> sdague: I think part of the thinking here is that the number of user and clouds that don't exist yet are much bigger than those that do
16:23:06 <sdague> cdent: that's always the theory
16:23:14 <cdent> hope, perhaps?
16:23:18 <elmiko> lol
16:23:26 <elmiko> definitely hope ;)
16:23:29 <sdague> until you piss off all your current users and they go elsewhere and take your future users with them
16:23:29 <cdent> (btw, I'm not really arguing against sdague, just trying to flesh out the concerns)
16:23:48 <annegentle_> sdague: thing is, we don't have a docs site that can document microversions yet.
16:23:53 <elmiko> same, i'm not opposed to what sdague is talking about. but i want to better understand the problem space.
16:23:59 <cdent> github keeps changing shit in their api and I haven't left yet?
16:24:02 <annegentle_> sdague: so to me, and I sound like I'm single minded, the docs space is the problem space.
16:24:21 <annegentle_> sdague: we can't support without docs
16:24:24 <sdague> annegentle_: we also have a docs issue, and I'll agree with that
16:24:26 <etoews> it's a significant aspect of it for sure
16:24:29 <sdague> annegentle_: we're already supporting it
16:24:34 <elmiko> annegentle_: agreed to a large extent, having good, *fresh*, api docs help alleviate some of these issues.
16:24:35 <sdague> people are already writing software using this
16:24:44 <sdague> we're already using it between services today
16:24:44 <annegentle_> sdague: yes, I talk to them a lot :)
16:24:52 <annegentle_> sdague: about how hard it is to find out what to do :)
16:24:56 <cdent> :)
16:25:02 <sdague> annegentle_: sure
16:25:36 <sdague> but a huge part of fixing all of that has been held up on getting this base spec sorted out, which is hung up on breaking users that have figured out how to use our stuff
16:26:36 <sdague> anyway, the point is, in this case, this is a really really critical part of the bootstrapping process. There will be production clouds which don't work with the new header out there for the next 5+ years
16:26:41 <cdent> I think we have general consensus that we can be flexible abot the -API thing, but the more general issue is still live.
16:26:54 <elmiko> cdent: +1
16:26:57 <sdague> even though documentation hasn't fully caught up, when it does, it's important it works for all clouds
16:27:06 <sdague> cdent: the more general issue being?
16:27:07 <etoews> cdent: +1
16:27:08 <elmiko> i'm still struggling to figure out how we guide this process in future
16:27:33 <elmiko> are we allowed to advise changing the namespace for a header, etc...
16:27:53 <elmiko> do we need a header registry guideline of some sort?
16:28:16 <cdent> elmiko: no, we need to not promulgate headers easily
16:28:23 <elmiko> or even a header name guideline, it just feels kind murky to me
16:28:24 <cdent> there are much better and correct ways to do http
16:28:38 <elmiko> cdent: ok, interesting. i'd like to hear more about that
16:29:00 <elmiko> (also, meeting halfway point approaching)
16:29:21 <annegentle_> is the general issue nova instead of compute? or header names changing generally?
16:29:25 <etoews> i've been working with swift metadata lately and the headers are an dumping ground of inconsistency.
16:29:27 <cdent> it's too late to go back in time, but the correct way to have done microversions could have been content-type parameters or a single headler incidcating microversion with the service type on the rhs
16:29:38 <cdent> etoews: all bets are off with swift
16:29:43 <cdent> we shouldn't even try there
16:29:43 <etoews> true
16:29:45 <cdent> :(
16:29:56 <elmiko> annegentle_: my issue was header names in general
16:30:08 <annegentle_> also swift has over 70 headers and nova has 2
16:30:19 <elmiko> cdent: so, are you saying we should back off header advise in general, when possible?
16:30:31 <cdent> for existing headers we should advise
16:30:46 <notmyname> ?
16:30:57 <cdent> and when new ones are proposed we should consider ways to avoid the creation of more headers, or ways to consolidate multiple header propositions under one header
16:31:18 <annegentle_> we do already advise against the X- naming
16:31:20 <elmiko> cdent: maybe a general header guideline to address some of these thoughts would be helpful?
16:31:26 <annegentle_> so we are in there doing this as guideance
16:31:28 <elmiko> annegentle_: right, i was kinda thinking about that
16:31:37 <annegentle_> heh I said swift which is "accio notmyname!"
16:31:46 <notmyname> heh, yeah
16:31:53 <notmyname> just checking IRC before I get on the bus :-)
16:31:54 <sdague> cdent: I'm totally open if you'd like to propose content type negotiation as a follow on instead of changing to OpenStack-[Service-Type]-API-Min-Version
16:32:05 <elmiko> i like the idea of capturing the thoughts cdent is talking about, namely alternative to headers and why you would/should use them
16:32:08 <sdague> but I don't think we should go from name -> service type -> something else
16:32:19 <cdent> I can write up the resist-headers idea
16:32:23 <sdague> we get kind of one correction, and carrying around the 2 things forever
16:32:39 <sdague> correction, then another correction, and that's just churn
16:32:46 <cdent> sdague: I don't think we should change the mechanics of microversions now, I'm just saying for other headers people might like to come up with there are other ways
16:32:53 <sdague> cdent: ok
16:32:53 <etoews> that all sounds reasonable to me.
16:32:58 <elmiko> sdague: agreed, and i'm happy to decide on one direction for the microvers. headers and not changing that (header naming-wise)
16:32:59 <cdent> so just  name -> service-type
16:33:04 <annegentle_> sdague: it's only 2 not 72
16:33:20 <annegentle_> and a pattern
16:33:21 <etoews> we actually have a start on header guidelines here http://specs.openstack.org/openstack/api-wg/guidelines/headers.html
16:33:23 <sdague> annegentle_: sure, but I'm not using 70 as my success bar :)
16:33:29 <annegentle_> hell to the no :)
16:33:37 <sdague> cdent: ok, I'm fine with that then
16:33:39 <cdent> #action: cdent writes up his ideas on resist headers
16:33:50 <elmiko> etoews: yea, i was thinking about capturing the more indepth ideas that cdent is talking about
16:34:26 <elmiko> should we talk about the registry then?
16:34:44 <elmiko> or get more into naming?
16:34:59 <etoews> one sec.
16:35:09 <elmiko> i feel like we are agreed about the service_type being the choice for naming
16:35:15 <etoews> so do we comment on https://review.openstack.org/#/c/243429/4/guidelines/microversion_specification.rst and ask to put API- back in?
16:35:34 <elmiko> sadly, i feel like we have to for consistency sake
16:35:43 <cdent> I think that's the compromise we reached
16:35:49 <annegentle_> I ... Uh.
16:35:55 <annegentle_> an API is a collection of operations?
16:35:57 <elmiko> i hate to make alex_xu_  go through that again...
16:36:02 <annegentle_> or is an API a single interface to the service?
16:36:18 <annegentle_> our precision with this term "API" is odd.
16:36:20 <sdague> I think it will be fine, I can respin for him even
16:36:29 <sdague> though, the experimental thing is still the problematic one
16:36:36 <annegentle_> and honetly to me it's about nova/compute
16:36:41 <annegentle_> honestly even
16:36:42 <elmiko> annegentle_: i think the feeling on the review was that adding API- to the header was kind of redundant
16:36:52 <annegentle_> elmiko: ok wasn't just me then
16:37:07 <annegentle_> sdague: yeah... that design space without breaking users is really where the conflict lies
16:37:15 <sdague> because I *really* don't think we should be endorsing putting experimental things into the APIs, once things are out in the world, they are used
16:37:20 <elmiko> the main problem with that is that it thrashes the few microversion impls that are actually out there
16:37:51 <elmiko> sdague: i have an issue about the experimental stuff
16:37:51 <annegentle_> sdague: Me. too.
16:37:58 <etoews> can we nail down exactly what the action is on moving forward on https://review.openstack.org/#/c/243429/4/guidelines/microversion_specification.rst and who will take that action?
16:37:59 <sdague> annegentle_: right, this is just a case where we did it already one way. And the only harm was 4 bytes.
16:38:23 <annegentle_> four nova bytes or api- four bytes?
16:38:23 <elmiko> etoews: it sounds like sdague volunteered to adjust the spec by adding API- back in
16:38:31 <cdent> I concur with elmiko
16:38:33 <elmiko> annegentle_: api- , as i understand
16:38:33 <sdague> elmiko: yes +1
16:38:36 <annegentle_> ok
16:38:54 <elmiko> #action sdage to update https://review.openstack.org/#/c/243429 by adding API- back in
16:39:00 <etoews> #action sdague to
16:39:06 <elmiko> sorry
16:39:06 <etoews> oops.
16:39:20 <annegentle_> that Dage guy will be busy
16:39:23 <etoews> no no. i meant to delete that and hit enter instead
16:39:24 <elmiko> do we need an undo on the last one?
16:39:34 <etoews> thanks and let's carry on to a new topic
16:39:55 <cdent> we seemed to be naturally veering into experimental territory or shall we go to registry?
16:39:55 <elmiko> ok, experimental apis isn't on the agenda, but i feel like we should discuss
16:40:01 <elmiko> yea..
16:40:09 <gouthamr> +1
16:40:11 <etoews> #undo
16:40:12 <elmiko> #topic experimental api inclusion
16:40:12 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x90811d0>
16:40:23 <elmiko> ok, experimental stuffs
16:40:36 <gouthamr> #link: https://review.openstack.org/#/c/273158/
16:40:47 <elmiko> i like this, because i'm working a new api version for sahara and it helps. but i could live without it
16:41:08 <elmiko> i can also see how having pieces of experimental stuff in a fully production api might be discordant
16:41:08 <cdent> It is absoluately critical to the health of openstack that there is a way to make experimental apis available to real users. The mechanism of how that is done is what's up for discussion, right?
16:41:26 <elmiko> cdent: i feel so, but i think sdague has other ideas
16:41:34 * cdent looks at sdague
16:41:40 * elmiko looks at sdague
16:41:43 <elmiko> ;)
16:41:48 <etoews> i think one of the reasons we have suboptimal api designs is because openstack projects seemingly have to come to the table with a fully baked api.
16:42:07 <cdent> etoews: yeah, my belly wrote about that too. It's a huge problem.
16:42:15 <sdague> it feels to me that experimental API should hang off a different endpoint
16:42:20 <elmiko> and i agree with cdent's position
16:42:23 <cdent> I'm okay with different endpoint
16:42:24 <etoews> without getting an api infront of users in some beta form that's just not doable.
16:42:37 <elmiko> i'm fine with advising different endpoint as well
16:42:51 <annegentle_> new endpoint ++
16:42:52 <gouthamr> cdent: yes, before we allow for bad API evolution with the guise of microversions.... Some projects would want APIs for an entire feature to be experimental until they get feedback and the feature stabilizes..
16:42:55 <sdague> like 'compute' is nova API. There could be a 'compute-experimental' that only advertizes experimental resources
16:42:56 <elmiko> but, i really like the header option too because it forces acknowledgement
16:43:21 <etoews> agreed
16:43:24 <cdent> elmiko: if people are using service catalog to find endpoints, isn't it the same thing?
16:43:31 <cdent> and we want them to use service catalog...
16:43:43 <sdague> it is a different amount of work
16:43:47 <annegentle_> there's more acknowledgement from a new entry in the service catalog in my mind
16:43:48 <elmiko> cdent: would the experimental api have a separate entry in the catalog?
16:43:55 * cdent considers making endpoints have opaque urls :)
16:44:01 <sdague> and different than bob in IT setting experimental true in their shade fork
16:44:32 <elmiko> i'm trying to think from a development standpoint here.
16:44:36 <sdague> I also think that experimental in the main API is going to be just like javascript github projects
16:44:43 <sdague> meh, why release, just pull from master
16:44:47 <elmiko> if i am working on a experimental feature, would i need to adjust the service catalog to acces it?
16:44:48 <cdent> when we say "different endpoint" doesn't that imply a different entry in the catalog?
16:44:51 <etoews> how about identifing the experimental nature in the service catalog?
16:44:53 <sdague> cdent: yes
16:44:56 <elmiko> sdague: lol!
16:45:27 <etoews> type: compute
16:45:27 <etoews> beta: true
16:45:30 <elmiko> cdent: i guess it didn't for me
16:45:53 <elmiko> i was thinking different endpoint like using /v2/... instead of /v1.1/....
16:46:05 <cdent> etoews: that came up at summit and was considered...dangerous?
16:46:09 <sdague> elmiko: no, this needs to be != existing service types
16:46:16 <cdent> where "that" == "beta: true"
16:46:26 <annegentle_> can you give the sahara example?
16:46:28 <sdague> yeh, that means different things to different people
16:46:35 <sdague> right, an example might be helpful
16:46:39 <elmiko> sdague: service catalog would be like, type="data-processing-experimental" ?
16:46:44 <sdague> elmiko: yeh
16:46:52 <elmiko> interesting, and i like it
16:47:03 <sdague> and, importantly, that endpoint *should not* include resources in the main API
16:47:09 <etoews> suffix is better than a separate field in the structure?
16:47:10 <elmiko> i definitely agree that driving folks to the service catalog is better than gating through headers
16:47:24 <cdent> etoews: yeah, because of the lookup process
16:47:32 <sdague> etoews: it should not be discoverable as a data-processing endpoint
16:47:33 <sdague> it is not
16:47:55 <elmiko> ok, this makes sense to me
16:48:00 <annegentle_> "hey I want to do some data processing, whatcha got?"
16:48:06 <cdent> this aligns with my growing sense of service catalog uber alles
16:48:07 <sdague> realistically this should be about many many many signals that this bit isn't ready
16:48:12 <etoews> ah. it's the namespace collision that's the concern. got it.
16:48:44 <elmiko> sdague: service catalog entry and header... ;)
16:49:03 <sdague> elmiko: and it doesn't contain the main API resources
16:49:07 <elmiko> you have to unlock all the deadbolts
16:49:10 <sdague> so you can't just point your app at the other endpoint
16:49:13 <elmiko> sdague: yup, agreed
16:49:19 <sdague> you have to explicitly be calling both
16:49:20 <SergeyLukjanov> ++ for data-processing-experimental
16:49:26 <elmiko> here's a real world example
16:49:27 <etoews> gouthamr: thought?
16:49:30 * elmiko waves at SergeyLukjanov
16:49:33 <etoews> thoughts?
16:49:42 <elmiko> we have old sahara at http://host:port/v1.1/...
16:49:52 <elmiko> we have new sahara at http://host:port/v2/...
16:50:00 <gouthamr> etoews: I'm still racking my brains about how resource isolation can be achieved.. what if a feature has DB implications..
16:50:10 <elmiko> service catalog shows the first for data-processing, the second for data-processing-experimental
16:50:13 <elmiko> does that sound right?
16:50:22 <annegentle_> are we sorta letting teams be bad at API design a little longer? Or is it not really like that?
16:50:23 <sdague> elmiko: you could do it that way
16:50:43 * annegentle_ recalls the termie talk in Vancouver was it?
16:50:51 <sdague> but, honestly, I also think that major API revisions are things projects should just not do any more
16:51:05 <elmiko> sdague: why not?
16:51:14 <sdague> we're 3 years into migrating from cinder v1 -> v2, glance v1 -> v2, keystone v2 -> v3
16:51:20 <etoews> annegentle_: in some sense i guess. give them space/time to figure out better designs without having to worry about backwards compat.
16:51:20 <annegentle_> sdague: yeah I feel like we don't have that luxury because our users lose
16:51:43 <annegentle_> sdague: We can be 10 years in and have good user outcomes though.
16:51:46 <elmiko> sdague: fair point, but our api could really use some major overhauls...
16:51:56 <annegentle_> sdague: it's not a time concern as it is a "does it work well" concern
16:52:04 <sdague> elmiko: right, but if you can get to it in steps, that's what microversions let you do
16:52:08 <elmiko> and following semver, i can't see how to get use there from here
16:52:18 <sdague> trust me, we went down this road in Nova
16:52:22 <cdent> so... I think we are be far to accepting of what the past has shown and letting us drive decision too much. It should certainly inform, but should not control
16:52:22 <sdague> spent 2 years on it
16:52:26 <sdague> then lit it all on fire
16:52:37 <elmiko> hmm
16:52:39 <cdent> Nova is a nightmare of horrible process that should not control the rest of the projects
16:52:50 * elmiko thinks "is sdague predicting my next 2 years"
16:53:00 <sdague> cdent: sure, many things aren't great
16:53:07 <cdent> Desperately unhealthy is nova. Other projects may be better.
16:53:08 <sdague> however, glance v2
16:53:18 <cdent> yeah, all these "old" projects
16:53:21 <sdague> cinder v2
16:53:25 <sdague> keystone v3
16:53:36 <elmiko> i feel like we can get away with this in sahara though
16:53:43 <sdague> elmiko: sure, maybe
16:53:54 <cdent> sometimes evolution needs to be revolutionary.
16:53:58 <etoews> show us the way elmiko :)
16:54:00 <sdague> no project every has though in openstack
16:54:02 <cdent> Different contexts have different concerns
16:54:04 <elmiko> i totally understand how migrating nova or keystone might be really tough
16:54:18 <elmiko> etoews: i'm trying... ;)
16:54:25 <elmiko> ok, 5 min left
16:54:28 <etoews> i think magnum is looking at a v2 too
16:54:31 <elmiko> and we are way  off in left field
16:54:42 <elmiko> do we want to talk registry quickly?
16:54:44 <cdent> so yeah: we should talk naming registry stuff a little bit
16:54:49 <cdent> jinx buy me a cooke
16:54:51 <etoews> i think it was a necessary detour.
16:54:54 <elmiko> #topic service type name registry
16:54:54 <etoews> ya
16:54:57 <elmiko> etoews: agreed
16:55:17 <elmiko> ok, so yes, registry, woo, party-time, excellent!
16:55:21 <cdent> seque here is that an experimental api should never show up in the service registry...
16:55:33 <elmiko> haha!
16:55:37 <elmiko> sigh...
16:55:59 * elmiko labels cdent "habitual line-stepper"
16:56:06 <annegentle_> I still want to ask, if we had our docs ducks in a row, would we need this separate registry?
16:56:17 <cdent> sorry, I like continuity
16:56:22 <sdague> annegentle_: yes
16:56:24 <elmiko> i think yes, if only to help new projects
16:56:27 <annegentle_> or could the docs site discover / preach truth
16:56:30 <sdague> no, yes entirely
16:56:35 <annegentle_> heh
16:56:43 <annegentle_> so the service registry is a pre-doc doc
16:56:48 <annegentle_> lookup list
16:56:53 <sdague> congress grabbed 'policy' as service type
16:57:00 <sdague> which is just crazy
16:57:20 <sdague> we do need to mitigate "good names" here
16:57:33 <sdague> otherwise we preclude future services in openstack
16:57:40 <sdague> a registry here is important
16:57:40 <annegentle_> now, if a team grabs a name and takes on a mission, what if they don't deliver on it?
16:57:43 <elmiko> i can't remember how the email chain ended, sdague were you planning on generating a spec for the registry or is this something we could work on through the api-wg?
16:58:01 <elmiko> annegentle_: i liked the idea about checking the registry at regular intervals to drop kruft
16:58:11 <sdague> elmiko: I ended with I would create this repo - https://review.openstack.org/#/c/278612/
16:58:22 <elmiko> also, cdent's idea about projects only grabbing the name when they acutally *need* it
16:58:33 <elmiko> sdague: oh, awesome!
16:58:45 <sdague> in the service catalog tng group we're sketching basic format
16:58:48 <elmiko> and thank you =)
16:58:54 <annegentle_> ok, yeah, the timing is good too. Only take a name when you really have a service running
16:58:55 <sdague> and I think we'll just review bits in
16:59:05 <annegentle_> yeah that was the happy dance party
16:59:06 <elmiko> annegentle_: right, no squatting
16:59:38 <elmiko> 1min
16:59:52 <sdague> http://lists.openstack.org/pipermail/openstack-dev/2016-February/086269.html
17:00:00 <elmiko> #link https://review.openstack.org/#/c/278612/
17:00:02 <etoews> no squatting, no cookie licking
17:00:11 <elmiko> definitely no cookie licking lol
17:00:18 <elmiko> ok, thanks everybody!
17:00:20 <cdent> we're still kind of dancing around the problem of an API needing to be something close to done before being able to be "real" (where real means persisting in the registry and the service catalog)
17:00:35 * cdent takes it to #openstack-sdks
17:00:37 <elmiko> i'm more on your side with that one cdent
17:00:42 <annegentle_> cdent: yeah it's about getting better at API design, yep yep
17:00:45 <elmiko> and yea, we're out of time
17:00:51 <elmiko> take it top -sdks
17:00:56 <elmiko> #endmeeting