On 05/04/2017 06:58 AM, Sean Dague wrote:
On 05/03/2017 11:56 PM, Monty Taylor wrote:
On 05/03/2017 03:47 AM, Thierry Carrez wrote:
Monty Taylor wrote:
On 05/01/2017 10:44 AM, Ben Swartzlander wrote:
On 04/28/2017 06:26 PM, Monty Taylor wrote:
[...]
Thoughts? Anyone violently opposed?

I don't have any problems with this idea. My main concern would be for
backwards-compatibility and it sounds like that's pretty well sorted
out.

I do think it's important that if we make this improvement that all the
projects really do get it done at around the same time, because if we
only implement it 80% of projects, it will look pretty weird.

I could not possibly agree more strongly with both points.

"All the projects [should] really [...] get it done at around the same
time, because if we only implement it 80% of projects, it will look
pretty weird" sounds pretty much like the definition of a good
cross-community goal. Can we afford to wait for Queens to implement this
? If yes it feels like this would make a great goal.


We could - and I agree with you ... but there is actually not work that
needs to be done in all of the projects. To support this from the
openstack side - we mostly need to land a patch to keystoneauth. (patch
already written) I will go check the other clientlibs, but I'm pretty
sure everyone has been updated to use keystoneauth at this point- except
swiftclient, but there is a patch up already to handle that. (also, nova
is working on consuming services via the catalog, but that patch is also
in flight and that work already has a local version of this done)

We also want to add support both for consuming this and testing it in
tempest - but that probably wants a deeper conversation with the tempest
team about the right way to do it.

In any case - I think the hardest part is ensuring consensus that it's a
good path forward, and a few logisitical concerns Sean and Morgan
brought up over in the service-types-authority and keystoneauth repos.
Once we find agreement, I can basically have this implemented on the
consume side in OpenStack in a few days.

On the aliases front... I'm actually a little concerned about putting
that into keystoneauth1 at all unless it's easy to globally disable,
because it glosses over the transition in a way that people may make
changes that assume differences in the service catalog than actually are
true.

There was an equivalent change when keystoneauth1 put in the magic that
allows OS_AUTH_URL to not have a version in it (which only works with
keystoneauth1 based clients). That meant that people started being told
that the keystone endpoint didn't need a version marker in the url.
Except, that kind of config would actually not work with every other
client out there. I actually wanted to revert that special work around,
but was told that basically lots of code now depends on it, so it would
break the world. :(

Totally. This is why a large part of this plan involves both documentation and not _only_ putting it in keystoneauth, but everywhere else too.

The thing is - the world is already broken because we have special snowflake workarounds in various of our python libs (python-cinderclient has a volume/volumev2/volumev3 workaround btw) We're also embracing microversions ... except that consuming microversions is impossible as an API consumer right now because it's unpossible to to get the discovery document as an API consumer. Well, unless you use python-novaclient which does magic URL inference to find the unversioned doc so nobody notices that a normal user has no access to the otherwise quite excellent mechanism.

This is why the summary of the plan is "define what things should look like in an area that is currently undefined, work to ensure backwards compatible consumption support for all of the consumers, encourage deployment adoption"

So I feel like we probably could use a powow in Boston to figure out the
concerns here. Because, honestly we can get compatibility without
keystoneauth1 by going wide here, and just asking folks to add all the
new entries (and making some validation system for people's service
catalog so they can see any changes that might be suggested).

Sure. We could only document and then ask all of the operators of all of the clouds out there to add new entries to the catalog. But they all won't - which means that client consumers _still_ won't be able to express "I want to connect to block-storage" and know that it'll just be a thing they can do.

I agree about a pow wow in Boston. We don't have to go with my proposed plan - I'll happily work to implement alternate plans as well ... but I'm very against continuing to spin our wheels in this area and continue to leave the problem to our API consumers with no help or guidance.

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to