Open Stack

On 3/29/2016 2:30 PM, Sean Dague wrote:
> 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
>

Thanks for the write up.

-- 

Thanks,

Matt Riedemann