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
