15:02:57 <sdague> #startmeeting service-catalog-tng
15:02:58 <openstack> Meeting started Thu Feb  4 15:02:57 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:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:01 <openstack> The meeting name has been set to 'service_catalog_tng'
15:03:18 <bknudson_> they can check the logs later
15:03:19 <sdague> Agenda is - https://wiki.openstack.org/wiki/Meetings/ServiceCatalogTNG#Next_Agenda
15:03:35 <sdague> #topic Project Id Optionality in projects
15:03:54 <bknudson_> anne said there was some problem with optional project id.
15:04:04 <sdague> #info nova patch to make project id optional has landed - https://review.openstack.org/#/c/233076
15:04:15 <sdague> bknudson_: do you remember what that was?
15:04:24 <bknudson_> she didn't say what it was.
15:04:38 <bknudson_> I figured you'd know
15:05:17 <sdague> I guess not
15:05:44 <sdague> I have a patch up to make this default configuration in devstack, however there are Tempest tests blocking that
15:06:07 <sdague> those are proposed for removal - https://review.openstack.org/#/c/271467/ - ETA TBD
15:06:18 <bknudson_> the tempest change has a -2 so I guess that needs to be resolved
15:06:25 <sdague> it has a procedural -2
15:06:33 <sdague> because there is a tempest test removal process
15:06:44 <sdague> I think it's resolvable
15:07:19 <bknudson_> shouldn't be any objection to removing this one
15:07:34 <sdague> agree
15:07:46 <annegentle> here! Sorry.
15:08:00 <sdague> annegentle: bknudson_ said you had said there was a problem with optional project id
15:08:12 <sdague> before we move on I wanted to figure out what that issue was
15:08:13 <annegentle> sdague: yes I might just be behind
15:08:21 <annegentle> sdague: I read your note to the mailing list
15:08:30 <annegentle> sdague: so maybe I misunderstood
15:08:32 <sdague> annegentle: ah, right, about routing overlap
15:08:33 <bknudson_> might be nice to be able to test the same thing somehow, but then the test would have to build the URL itself.
15:08:53 <annegentle> right
15:09:02 <sdague> which we solved with specifying a project id regex
15:09:06 <annegentle> sdague: did you find a workournd?
15:09:11 <annegentle> sdague: ah ok
15:09:27 <sdague> yes, the nova solution is a default project id regex which is [0-9a-f]+
15:09:29 <bknudson_> since I assume a user with a token in one project won't even see an instance in another project
15:09:54 <sdague> bknudson_: right, all decisions in nova are based on the context value of project_id
15:10:01 <annegentle> bknudson_: well, some providers can set up projects as billing dividers
15:10:08 <annegentle> bknudson_: so a scientist might have two projects
15:10:25 <sdague> annegentle: sure, but they have to specify which project they are acting in when they get the token
15:10:28 <annegentle> bknudson_: but, the token would not be scoped for only two projects.
15:10:42 <annegentle> sdague: yeah, is there still a super-admin token?
15:10:51 <annegentle> sdague: those calls might require indicating which project
15:10:56 <bknudson_> keystone doesn't support getting a token scoped to 2 projects.
15:10:57 <sdague> annegentle: I'm not sure I know what that means?
15:11:29 <bknudson_> in order to operate in nova you need a token scoped to a project
15:11:32 <annegentle> bknudson_: sdague: just a sec I'll find the super token ref I'm thinking of
15:11:41 <sdague> bknudson_: right
15:12:14 <annegentle> bknudson_: as a cloud provider sometimes you need to shut down someone else's server. Is that a scoped project token an admin gets?
15:12:15 <sdague> and admistrative commands that operate on resources either take the resource id, and admin is allowed to do things because they have the admin role
15:12:35 <sdague> or there is an all_tenants param for display on list things
15:12:40 <sdague> which again, requires admin role
15:13:11 <sdague> without which the user would just get their own tenant
15:13:18 <annegentle> bknudson_: ah, I'm thinking of a domain scoped token, http://docs.openstack.org/developer/keystone/configuration.html#keystone-api-protection-with-role-based-access-control-rbac
15:13:30 <bknudson_> is there an example api? I'm not familiar enough with the nova apis
15:13:40 <sdague> bknudson_: for which?
15:14:11 <bknudson_> sdague: an admin shutting down a compute in a different project
15:14:18 <annegentle> http://developer.openstack.org/api-ref-compute-v2.1.html#os-admin-actions-v2.1
15:14:35 <annegentle> specifically, http://developer.openstack.org/api-ref-compute-v2.1.html#resetState
15:15:42 <sdague> yeh, but DELETE is also admin_or_owner in policy
15:15:44 <bknudson_> so in the case of these admin actions the new project ID is in the URL.
15:16:23 <sdague> the project_id in the url is never actionable
15:16:28 <annegentle> ok
15:16:36 <sdague> if there is something specifically about a new project_id, it's passed as a query param
15:16:37 <bknudson_> the old request would be POST http://openstack/compute/{tenant_id_1}/v2.1/​{tenant_id}​/servers/​{server_id}​/action
15:16:51 <sdague> not quite
15:16:54 <bknudson_> and the new one is POST http://openstack/compute/v2.1/​{tenant_id}​/servers/​{server_id}​/action
15:16:59 <sdague> http://openstack/compute/v2.1/​{tenant_id_1}​/servers/​{server_id}​/action
15:17:05 <sdague> and new one is
15:17:13 <sdague> http://openstack/compute/v2.1/​servers/​{server_id}​/action
15:17:32 <bknudson_> oh, the first tenant_id was in the catalog?
15:17:49 <sdague> the catalog entry returned today is
15:17:52 <annegentle> right
15:17:54 <sdague> http://openstack/compute/v2.1/​{tenant_id_1}​
15:18:04 <bknudson_> I assume the server_id is unique across projects
15:18:13 <sdague> server_id is globally unique
15:18:21 <bknudson_> so nova doesn't look in the project to find the server
15:18:27 <sdague> correct
15:18:36 <bknudson_> is that only for the admin actions?
15:18:42 <sdague> no, for everything
15:19:10 <sdague> this is part of why removing project id was pretty sensible and easy, it's not really a first order construct in our resources
15:19:15 <bknudson_> all these docs will have to change!
15:19:18 <sdague> bknudson_: yep
15:19:31 <sdague> but, they will be massively less confusing
15:20:10 <sdague> swift is really the only project where tenant_id is really a container
15:20:15 <bknudson_> hopefully nova has some code to verify that the user access to the server
15:20:41 <annegentle> bknudson_: it's funny, WADL has a wrapper, so the docs aren't too hard to change
15:20:53 <sdague> yes, admin_or_owner policy enforcement
15:21:24 <sdague> https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L253
15:21:46 <annegentle> good
15:22:07 <sdague> ok, we good with all that and can move on?
15:22:16 <bknudson_> yes, thanks for the explanation
15:22:17 <sdague> it was a good summary of some of where we stand
15:22:18 <sdague> yep
15:22:37 <sdague> annegentle: lastly, were you building the list of projects that would also need this?
15:22:56 <annegentle> sdague: I only got so far
15:23:03 <annegentle> sdague:thinking, just a se
15:23:04 <annegentle> sec
15:23:44 <sdague> well, if we start from oldest projects first and move forward we can hopefully at least reset expectations a bit, I still expect that to be a Newton thing at this point
15:24:28 <annegentle> sdague: yeah, this is the list that is not investigated https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog#Projects_that_I_couldn.27t_find_in_a_service_catalog_and_will_need_to_investigate_further
15:24:39 <sdague> ok, great!
15:25:00 <annegentle> sdague: so does anything need to happen with this list? https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog#These_projects_have_a_TENANT_ID_in_one_of_the_example_service_catalogs
15:25:37 <sdague> I think for Mitaka we are probably out of runway, but we should come up with a Newton push plan. We can wait until M3 for that
15:26:05 <bknudson_> we can put nova in a new category -- projects that have tenant_id in the catalog but it's optional
15:26:08 <sdague> #action around M3 revisit how we'll push for project_id optionality in projects for Newton
15:26:15 <sdague> bknudson_: yep
15:26:21 <annegentle> bknudson_: ok, that's for mitaka right?
15:26:30 <sdague> annegentle: yes, we've landed the code
15:26:34 <annegentle> sdague: ok
15:26:39 <sdague> ok, moving on....
15:26:50 <bknudson_> I'll make that change in the wiki
15:26:55 <annegentle> bknudson_: sounds goo
15:26:58 <annegentle> good even
15:27:07 <sdague> #topic Service Common Names
15:27:30 <sdague> I kicked this one off on the list this morning, it's been bubbling about recently quite a bit
15:27:36 <sdague> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085748.html
15:28:04 <sdague> I think we can mostly drive the discussion there and let people settle on the fact that we need to do this thing
15:28:12 <sdague> which is the way the wind is blowing now
15:28:36 <sdague> I think there is just a mechanics issue of where the registry actually is
15:28:55 <annegentle> sdague: do you think there's pushback on where?
15:29:07 <annegentle> sdague: or "who will do the work and be responsible?" <-- that's more my take
15:29:32 <bknudson_> I always thought the name registry should be in projects.yaml or some TC repo, not keystone.
15:29:38 <sdague> I think the question seemed to be whether etowes was ok with it being part of API-WG repo
15:29:44 <bknudson_> keystone just stores whatever you put in it.
15:29:54 <sdague> bknudson_: right, definitely agree with that
15:30:15 <sdague> it's just whether the TC does this directly, or basically gives API WG authority to do it
15:30:36 <sdague> I figured I'd let that one just simmer a bit
15:30:58 <sdague> personally, mostly don't care, as long as we get vague concensus
15:31:08 <bknudson_> it'll be interesting to see how keystone gets at the info if we think we need keystone to enforce it.
15:31:20 <sdague> bknudson_: I don't think keystone should enforce it
15:31:38 <sdague> I'm ok with keystone being dumb store for what people say
15:32:05 <bknudson_> works for me
15:32:22 <sdague> ok, that was mostly an FYI, please get onto the thread and we'll drive discussion there
15:32:38 <sdague> #topic JSON Schema for SC
15:32:53 <sdague> bknudson_: I think 2 weeks ago you said you'd take a first swipe at such a thing
15:32:59 <sdague> any progress so far?
15:33:07 <bknudson_> y, I didn't get this done.
15:33:12 <sdague> ok, no prob
15:33:14 <bknudson_> didn't happen at the keystone meetup
15:33:24 <bknudson_> I'll throw it at the top of my work queue
15:33:35 <sdague> I'll keep it as standing item on the agenda so we don't forget
15:33:41 <annegentle> sounds good
15:33:45 <sdague> #topic Open Discussion
15:33:54 <annegentle> I got nuthin'
15:34:11 <bknudson_> I'm actually pretty familiar with the JSONSchema spec now since I was reviewing some changes.
15:34:15 <annegentle> I can talk to Everett etowes this morning
15:34:47 <sdague> the only thing there is I've been bad advertising this meeting. So if anyone knows anyone that wants to help step up as meeting promoter for this, let me know. I'll put a call out to a few folks as well.
15:34:53 <annegentle> sdague: I think some of the discussion also is in https://review.openstack.org/#/c/273158/
15:35:15 <sdague> annegentle: yeh, the experimental APIs one
15:35:17 <annegentle> sdague: as far as differentiation at the resource level
15:36:00 <annegentle> sdague: I'm not sure we should offer experimental at all
15:36:12 <sdague> annegentle: I mostly agree
15:36:19 <annegentle> sdague: most API designs have to be fully baked to be competitive in the market
15:36:21 <sdague> but if people want to, it shouldn't be in the same API
15:36:22 <bknudson_> keystone as JSONHome and that's where we specify experimental.
15:36:23 <annegentle> it's a trust thing
15:36:39 <annegentle> sdague: yeah we need to be precise -- API or endpoint?
15:36:47 <sdague> endpoint
15:36:48 <annegentle> sdague: I'm all for a second experimental endpoint, I think.
15:36:51 <annegentle> sdague: ok yeah
15:37:04 <annegentle> and the API is the GET /blah/resources right? In that spec ^^
15:37:11 <bknudson_> we also called some APIs extensions and they could be disabled
15:37:14 <annegentle> sdague: I need to write a review there
15:37:22 <sdague> yeh, I'll go pile on a bit later on that
15:37:23 <annegentle> bknudson_: ugh those are the worst to document and use tho
15:37:25 <annegentle> sdague: ok
15:37:43 <annegentle> "If you're going to experiment, put it on a separate endpoint"
15:37:44 <bknudson_> I agree that it's not fun to have optional apis.
15:37:53 <sdague> ok, anything else from folks?
15:37:56 <annegentle> nopety
15:38:03 <sdague> great, thanks folks
15:38:07 <annegentle> heh a nope and a thank you combo
15:38:07 <sdague> #endmeeting