<p dir="ltr">As a note, there is potential that this will require older deployments that have historical names migrated to update project IDs to hex-strings. These are a minority of deployments at best, but this should be considered in the proposal so if this goes forward we can clearly communicate this change to deployers as an upgrade requirement. This arbitrary id string was mostly seen in LDAP assignment (not user data) backends which is now deprecated/soon to be removed.</p>
<div class="gmail_quote">On Jan 13, 2016 06:08, "Sean Dague" <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There is a snag at the moment in making project_id optional in API URLs<br>
because of how python routes modules works.<br>
<br>
When we call mapper.resource(...) it's creating a series of<br>
mapper.connect(...) calls to setup routes. This just adds items to a<br>
dictionary. When we later use the mapper to match a route it builds a<br>
master regex out of everything in that dictionary, which it applies to<br>
the inbound url. (Note: this is an extremely large regex in the case of<br>
Nova).<br>
<br>
Today our use of the mapper captures the {project_id} here -<br>
<a href="https://github.com/openstack/nova/blob/21f7dabd01e5b4d771de4b88114878d93ffa9b18/nova/api/openstack/__init__.py#L200" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/21f7dabd01e5b4d771de4b88114878d93ffa9b18/nova/api/openstack/__init__.py#L200</a><br>
<br>
<br>
The issue is that by default mapper captured variables are set to the<br>
regex ([^\/]+) (i.e. match anything that's not a slash).<br>
<br>
This makes for an ambiguous route when we consider the following url:<br>
<br>
   /v2.1/extensions/os-agents<br>
<br>
Because it could match extensions/{name} or it could match<br>
{project_id}/os-agents. There are about a dozen extensions which create<br>
a top level resource.<br>
<br>
Because this regex is built from a dictionary, hash seed matters, and it<br>
is not stable which will get precedence.<br>
<br>
<br>
** Proposal for restriction of project_id **<br>
<br>
There is a wrinkle here that, strictly speaking, project_id has no<br>
schema in OpenStack.<br>
<br>
If you are using upstream Keystone, your project_id is going to be a 32<br>
character hex uuid. Unless you hack keystone really hard it's not<br>
possible to get another answer.<br>
<br>
RAX doesn't use Keystone, their project_id is an int.<br>
<br>
I'd like to propose for Nova we restrict project_id in the URL to<br>
[0-9a-f]+, which is any valid hex string. Ints are a subset of this so<br>
RAX will be fine. This will be enough to prevent the collision in the<br>
case of extensions. I tried to float a question out to the operators<br>
list about this, but I actually think this is sufficiently obscure<br>
internals that most people aren't even aware that project_id isn't<br>
always a uuid.<br>
<br>
This collision only happens when both sets of routes (with and without<br>
project_id) are being run. That's what we're going to do for a while for<br>
client compatibility. Either route set on it's own is fine.<br>
<br>
This was caught by one stray functional test and took a while to figure<br>
out what was going on. But if we come up with a resolution here we can<br>
move forward on this work (which is part of what's needed in revising<br>
the service catalog).<br>
<br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>