Open Stack

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