15:02:12 <sdague> #startmeeting service-catalog-tng
15:02:12 <openstack> Meeting started Thu Mar  3 15:02:12 2016 UTC and is due to finish in 60 minutes.  The chair is sdague. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:15 <openstack> The meeting name has been set to 'service_catalog_tng'
15:02:18 <cdent> o/
15:02:41 <sdague> I will admit, due to the release crunch I have not looked at bknudson's json schema
15:02:49 <sdague> #topic service catalog json schema
15:03:09 <bknudson> I updated the schema with what we discussed a couple of weeks ago
15:03:10 <sdague> so I'm not sure if there is any progress we can get there until things calm down on the release front
15:03:30 <bknudson> doesn't need to be done today
15:03:36 <sdague> ok, cool.
15:03:50 <sdague> I mostly just wanted to checkpoint on one other thing in this meeting
15:03:58 <sdague> #topic service types authority
15:04:10 <sdague> https://review.openstack.org/#/q/project:openstack/service-types-authority
15:04:17 <sdague> I started trying to put patches up there
15:04:27 <sdague> doing so did raise a few interesting issues
15:05:07 <sdague> #1 - the value of the projects field. Is this the reference implementation or a list of all implementations, and how do we verify that if it's more than one
15:05:13 <sdague> #2 - api_reference
15:05:22 <sdague> because keystone has no single url for API reference
15:05:37 <sdague> and I thought that nova and keystone would be easy ones
15:05:42 <cdent> heh
15:05:48 <cdent> that sounds like a keystone bug
15:06:00 <cdent> it's okay if the entry point points to multiple places
15:06:03 <cdent> but there should be one entry point
15:06:17 <cdent> and the schema should reflect that (the #2 part)
15:06:22 <sdague> bknudson: how are you feeling about that?
15:06:23 <cdent> s/scheme/authority
15:06:40 <bknudson> I think it has to do with how the api / wadl generator works?
15:06:49 <sdague> cdent: I tend to agree, I didn't even think of the thing as an issue until I tried to do this thing
15:06:54 <bknudson> whatever it is that creates http://developer.openstack.org/api-ref.html
15:06:54 <jroll> cdent ++ for single entry point
15:07:12 <sdague> bknudson: would you be able to research that in the next week and figure out what it would take?
15:07:30 <sdague> maybe annegentle knows more on that
15:07:35 <annegentle> holla
15:07:42 <bknudson> Block Storage / Cinder has the same issue
15:07:53 * annegentle is tripled booked at this time, what's the question?
15:08:02 <bknudson> glance, neutron, shared file systems
15:08:25 <annegentle> wadl creates api-ref.html yes
15:09:08 <annegentle> sdague: what do you mean by "keystone has no single url for API reference"
15:09:22 <jroll> annegentle: in comments here: https://review.openstack.org/#/c/286089/2
15:09:23 <sdague> annegentle: what url describes the keystone api?
15:09:32 <sdague> what *single* url
15:10:05 <annegentle> so, we've given projects a lot of leeway to define that themselves
15:10:18 <annegentle> keystone likes specs. nova does not. etc.
15:10:31 <annegentle> I agree with you sdague for what it's worth
15:10:55 <bknudson> if it's the keystone spec then it's http://specs.openstack.org/openstack/keystone-specs/index.html#identity-api-specification
15:11:03 <sdague> annegentle: I think we need to reel that leeway in if we are trying to give a consistent stopping off point
15:11:17 <annegentle> I think now's the time then
15:11:31 <bknudson> maybe the conversion to swagger will make it easier to have a single api spec
15:11:41 <annegentle> bknudson: +
15:11:56 <bknudson> I'm working on getting keystone to generate a swagger file from the routes that are registered
15:12:04 <sdague> ok, so I guess are we saying we start with http://specs.openstack.org/openstack/keystone-specs/index.html#identity-api-specification
15:12:22 <sdague> and say we really want this as something on docs.openstack.org in the future
15:12:30 <annegentle> developer.openstack.org
15:12:37 <sdague> right, that
15:12:45 <sdague> I can live with that
15:12:57 <annegentle> sdague: bknudson: tell me, if this is right, I also believe the keystone spec docs are rather narrative in nature?
15:13:06 <sdague> annegentle: they seem to be
15:13:08 <annegentle> ideally it'll be swagger on developer.openstack
15:13:14 <bknudson> annegentle: they are not machine readable
15:13:21 <annegentle> http://developer.openstack.org/draft/swagger/
15:13:32 <sdague> bknudson: machine readable is less important to me personally
15:14:02 <annegentle> where the swagger is sourced I can not care about
15:14:03 <sdague> but where would you point an end user developer that will never read keystone code
15:14:12 <annegentle> where it's published, let's standardize
15:14:25 <bknudson> I would point developers to http://specs.openstack.org/openstack/keystone-specs/index.html#identity-api-specification
15:15:14 <sdague> and you aren't concerned that you are pushing a random end user developer into all the other specs listed there
15:15:34 <annegentle> bknudson: which devs?
15:15:52 <annegentle> bknudson: you don't know the devs I know :)
15:15:57 <bknudson> annegentle: anyone wanting to use the rest api
15:16:04 <annegentle> bknudson: nah, they don't want your specs page
15:16:10 <annegentle> bknudson: they want swagger and SDKs
15:16:24 <sdague> ok, so can we compromise and say for the purposes of moving the authority forward
15:16:25 <annegentle> bknudson: and really only one call matters to them
15:16:34 <annegentle> "get me a token"
15:16:42 <bknudson> if they wanted a python SDK I'd point them to keystoneauth1 docs.
15:16:51 <sdague> the keystone api_reference as current specs page is a starting point
15:16:51 <bknudson> or keystoneclient docs
15:17:08 <sdague> and we'd like to get all these over to developer.openstack.org
15:17:11 <bknudson> there are devs who want to know how to create users or projects.
15:17:59 <annegentle> argh, and now a phone call brb
15:17:59 <sdague> because if we don't move type registration forward with some compromises, we won't get the types nailed down until my daughter is in college :)
15:18:47 <sdague> bknudson: is that good for you?
15:18:53 <bknudson> sdague: yes
15:18:58 <sdague> cdent: ?
15:19:12 * stevemar sneaks in
15:19:24 <cdent> sdague: yes, that's a reasonable starting point
15:19:28 <sdague> ok
15:20:01 <sdague> #agreed keystone api_reference will be http://specs.openstack.org/openstack/keystone-specs/index.html#identity-api-specification to start - with the intent that a developer.openstack.org url is coming in the next cycle
15:20:10 <sdague> ok, that was point #2
15:20:22 <sdague> now, point #1
15:20:28 <sdague> the project: field
15:20:49 <sdague> the way I was thinking about this is that projects that are creating APIs effectively claim a type
15:20:58 <cdent> yeah, I think I was the one who moaned that it needs to be a list
15:21:05 <cdent> not because I think that is the _right_ thing
15:21:17 <sdague> and the project is a reference to the project you would change to change the api for that type
15:21:20 <cdent> but because it represents the desires of the TC, which is that it is possible to have two different implementations of the same service
15:21:38 <sdague> cdent: right, and in those cases, there would still need to be a shared specification
15:21:40 <sdague> which would be a repo
15:21:55 <cdent> I see project as: where the code lives
15:22:01 <cdent> docs: as the specification
15:22:16 <cdent> which may be the source of confusion
15:22:19 <sdague> ok
15:22:30 <sdague> I was thinking of project: is where the definition is, which might be code
15:22:33 <bknudson> the example was keystone, which is openstack/keystone, not openstack/keystone-specs
15:22:38 <sdague> api_reference is where the user docs is
15:22:48 <sdague> for the purposes of nicely reading about it
15:23:06 <cdent> I'm not wed to any particular way of doing it but I feel given the mission provided to the group by the TC...
15:23:06 <sdague> because I think that's our reality today
15:23:42 <sdague> and I think the moment we actually hit having 2 projects trying to both implement the same API it will drive out some details
15:23:51 <sdague> I'm not sure I know how to anticipate that
15:25:17 <sdague> like, should ceilometer and monasca actually come together on a common api, what artifacts here do we need to describe that?
15:25:22 <sdague> I don' tknow until I see it
15:25:39 <sdague> here is another real world scenario I think we're going to see
15:25:47 <sdague> type: placement, project: openstack/nova
15:26:07 * cdent nods
15:26:18 <sdague> and in 2 cycles time, project: will change
15:26:23 <cdent> to use an sdague idiom:
15:26:41 <cdent> honestly, I think we should structure the thing for the reality we want to create which is to ignore this crap about two projects on the same service
15:26:42 <bknudson> so it would be better to point to the api spec rather than the project that implements the api
15:27:05 <sdague> bknudson: part of this was about giving ownership of a type to a project
15:27:30 <sdague> so that they would use that in their docs and defaults, and when I'm talking to neutron I know what to call it
15:29:20 <sdague> so, I guess, is that a thing we can move on for now, with a note about "we might have to reconsider some thing if we get 2 projects on one api"
15:29:37 <cdent> sdague++
15:29:49 <bknudson> we're not going to anticipate everything today anyways so just go with what works and be flexible
15:30:09 <cdent> at the moment we are not machine reading the file anyway, so it's structure being machine readable is just a bonus. We can change it.
15:30:11 <sdague> #agreed for now project will refer to a single project that owns the type
15:30:18 <sdague> right
15:30:46 <sdague> ok, so with that, I think I can redo the first 3 patches in this stack - https://review.openstack.org/#/c/286091 and get them agreed upon and landed
15:31:13 <sdague> the last patch is about restrictions for people putting things in their service catalog that isn't in our list
15:31:32 <sdague> and I proposed x- which I know is ripe with challenges
15:32:08 <sdague> perhaps we should open that up to the market place of ideas ... i.e. ops mailing list
15:32:13 <bknudson> I like the rax: or whatever: prefix
15:32:17 <sdague> and see what people are feeling
15:32:33 <sdague> prefixing might be fine, we did exclude : in our normal bit
15:32:54 <sdague> cdent: how do you feel about prefixing?
15:32:55 <bknudson> every provider will have to use their own prefix for these nonstandard services
15:33:13 <cdent> sdague: I wrote on that yesterday, I think prefix/namespace better than x-
15:33:20 <cdent> but I went on at some length on the review
15:33:30 <cdent> probably a bit rambling and confused..
15:33:38 <cdent> I agree that getting a feel from the field is a good idea
15:33:39 <cdent> however
15:33:50 <sdague> right, I think we have 2 classes of issues
15:33:52 <cdent> I'm also not certain that the services types needs to register anything that isn't upstream
15:34:15 <sdague> cdent: right, I don't want *us* to register them
15:34:18 <bknudson> use dns
15:34:21 <cdent> but the service-catalog should specify that namespaces are appropriate for things
15:34:27 <cdent> that are local
15:34:48 <sdague> but, I do want *us* to make it clear that you aren't allowed to make catalog entries that look official, that aren't in this list
15:35:09 <sdague> so some indicator that this thing is definitely not in the authority
15:35:19 <sdague> prefixing is good for the vendor case
15:35:29 <sdague> for the "I'm a new service" case, I don't know
15:35:37 <sdague> would we recommend x- for that?
15:35:54 <cdent> this is the catch 22 on the _entire_ API problem space
15:36:00 <cdent> we've made it entirely too difficult to experiment
15:36:01 <sdague> cdent: sure
15:36:13 <sdague> cdent: well x-
15:36:26 <sdague> and hey, we give you a standard name when we stamp you in
15:36:28 <bknudson> I think until they're official it should have a provider: prefix in the catalog
15:36:42 <sdague> bknudson: what if there is no provider
15:36:57 <sdague> it's just a new project in github that's working towards openstack inclusion
15:36:57 <bknudson> somebody's got to be serving up the api
15:37:05 <cdent> whether we use x- or prefix: we still present the same problem as ever: client code will already be out there
15:37:12 <sdague> cdent: sure
15:37:18 <bknudson> they could use my: if they want
15:37:42 <cdent> sdague: I actually think the concern about extant code is overblown, but if we are concerned about it, it definitely applies here
15:38:00 <sdague> cdent: ok, I guess we can also punt
15:38:03 <cdent> I think we should just not be too precious about names: don't use one that is already registered
15:38:18 <cdent> and don't use one that is in the do-not-use list
15:38:18 <sdague> cdent: maybe
15:38:42 <sdague> except when we have 3 projects building a backup service and all use the same non official name up front
15:38:46 <bknudson> is "placement" on the do-not-use list?
15:38:53 <cdent> sdague: that's why we have the registry
15:39:03 <bknudson> is that too generic and it should instead be "compute-placement" ?
15:39:03 <cdent> you can't use a name and be openstack unless you register
15:39:10 <sdague> right, but we said you can't squat
15:39:11 <cdent> but registration doesn't make you official
15:39:20 <cdent> it just means you got the name
15:39:36 <sdague> ok, lets solve the prefix bit for vendors first
15:39:37 <cdent> right, so we evaluate on a first come first serve basis: if the api actually exists, they can probably have it
15:39:51 <sdague> and maybe circle around after we've gone through the service list
15:39:54 * cdent nods
15:40:43 <bknudson> ok
15:40:51 <sdague> ok, that gets us those patches landed, and hopefully lets us start grinding through more services
15:41:13 <sdague> #action sdague to respin patch series for landing based on aggreements
15:41:21 <sdague> ok, anything else?
15:41:35 <bknudson> nothing else from me
15:41:37 <cdent> nada
15:41:45 <sdague> cool, thanks folks, that was super helpful
15:41:51 <sdague> and we're slowly moving this ball forward
15:42:04 <sdague> thanks for coming
15:42:08 <sdague> #endmeeting