[openstack-dev] [nova] path forward on making project_id optional in API URLs

Sean Dague sean at dague.net
Wed Jan 13 17:09:58 UTC 2016

On 01/13/2016 10:31 AM, Chris Dent wrote:
> On Wed, 13 Jan 2016, Sean Dague wrote:
>> Because this regex is built from a dictionary, hash seed matters, and it
>> is not stable which will get precedence.
> Ow[1].
>> I'd like to propose for Nova we restrict project_id in the URL to
>> [0-9a-f]+, which is any valid hex string. Ints are a subset of this so
>> RAX will be fine. This will be enough to prevent the collision in the
>> case of extensions. I tried to float a question out to the operators
>> list about this, but I actually think this is sufficiently obscure
>> internals that most people aren't even aware that project_id isn't
>> always a uuid.
> There was some discussion, if I recall correctly, about making the
> restriction configurable, with the default [0-9a-f]+ (would
> [0-9a-f-]+ be slight more flexible?) so that people who are doing
> extra weird things (as pointed out by Morgan) have an option. That
> seems like a good idea.

Adding a configuration option encourages people to use it. If we believe
that someone needs either an ancient cloud moving forward, or a pretty
hacked up code stack, do we believe that "for your stuff to work" a
config is really needed.

It would be helpful if we knew of any actual environments that wouldn't
work here. No hits yet on operators list. And I feel like we're pretty
unlikely to ever get one there.

This will only trip people up if they have programs which don't use the
service catalog to get their API end point and the cloud operator uses
something other then ints or hex for their project_ids. Because after
this change the cloud operator can update their service catalog to drop
the project_id interpolation, and everything is fine for service catalog
consuming programs.

So my hope is making it clear in the release notes will be enough for
people to know this will be a concern for upgrade. Most clouds don't hit
an issue like this until they consider upgrade, 6 - 12 months after our
release. We'd still be in a position at that point to field the bug from
a cloud that this is an issue for and change the behavior (and backport
said fix). Which would let us address any actual bugs in the field
instead of theoretical concerns.


Sean Dague

More information about the OpenStack-dev mailing list