At the Mitaka Summit we had a double session on the Service Catalog, where we stood, and where we could move forward. Even though the service catalog isn't used nearly as much as we'd like, it's used in just enough odd places that every change pulls on a few other threads that are unexpected. So this is going to be a slow process going forward, but I do have faith we'll get there.
Thanks much to Brant, Chris, and Anne for putting in time this cycle to keep this ball moving forward. Mitaka did a lot of fact finding. * public / admin / internal urls - mixed results The notion of an internal url is used in many deployments because they believe it means they won't be charged for data transfer. There is no definitive semantic meaning to any of these. Many sites just make all of these the same, and use the network to ensure that internal connections hit internal interfaces. Next Steps: this really needs a set of user stories built from what we currently have. That's where that one is left. * project_id optional in projects - good progress One of the issues with lots of things that want to be done with the service catalog, is that we've gone and hard coded project_id into urls in projects where they are not really semantically meaningful. That precluded things like an anonymous service catalog. We decided to demonstrate this on Nova first. That landed as microversion 2.18. It means that service catalog entries no longer need project_id to be in the url. There is a patch up for devstack to enable this - https://review.openstack.org/#/c/233079/ - though a Tempest patch removing errant tests needs to land first. The only real snag we found during this was that python Routes + keystone's ability to have project id not be a uuid (even though it defaults to one) made for the need to add a new config option to handle this going either way. This is probably easy to replicate on other projects during the next cycle. Next Steps: get volunteers from additional projects to replicate this. * service types authority One of the things we know we need to make progress on is an actual authority of all the service catalogue types which we recognize. We got agreement to create this repository, I've got some outstanding patches to restructure for starting off the repo - https://review.openstack.org/#/q/project:openstack/service-types-authority The thing we discovered here was even the apparently easy problems, some times aren't. The assumption that there might be a single URL which describes the API for a service, is an assumption we don't fulfil even for most of the base services. This bump in the road is part of what led to some shifted effort on the API Reference in RST work - (see http://lists.openstack.org/pipermail/openstack-dev/2016-March/090659.html) Next Steps: the API doc conversion probably trumps this work, and at some level is a requirement for it. Once we get the API reference transition in full swing, this probably becomes top of stack. * service catalogue tng schema Brant has done some early work setting up a schema based on the known knowns, and leaving some holes for the known unknowns until we get a few of these locked down (types / allowed urls). Next Steps: review current schema * Weekly Meetings We had been meeting weekly in #openstack-meeting-cp up until release crunch, when most of us got swamped with such things. I'd like to keep focus on the API doc conversion in the near term, as there is a mountain to get over with getting the first API converted, then we can start making the docs more friendly to our users. I think this means we probably keep the weekly meeting on hiatus until post Austin, and start it up again the week after we all get back. Thanks to folks that helped get us this far. Hopefully we'll start picking up steam again once we get a bit of this backlog cleared and getting chugging during the cycle. -Sean -- Sean Dague http://dague.net __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
