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