Incorrect content ID mapping results

[smashwilson]

The /_api/whereis/:content_id route includes incorrect results when one mapped content ID base is a prefix of another (modulo a trailing slash). For example:

$ curl -s https://staging.developer.rackspace.com/_api/whereis/https%3A%2F%2Fgithub.com%2Fbuild-ee383d31a9%2Frackerlabs%2Fdocs-dedicated-vcloud%2Fvcloud-handbook-v1.5/ | jq
{
  "mappings": [
    {
      "domain": "developer.rackspace.com",
      "baseContentID": "https://github.com/build-ee383d31a9/rackerlabs/docs-dedicated-vcloud/",
      "basePath": "/build-ee383d31a9/docs/private-cloud/dedicated-vcloud/",
      "path": "/build-ee383d31a9/docs/private-cloud/dedicated-vcloud/vcloud-handbook-v1.5/"
    },
    {
      "domain": "developer.rackspace.com",
      "baseContentID": "https://github.com/build-ee383d31a9/rackerlabs/docs-dedicated-vcloud/vcloud-handbook/",
      "basePath": "/build-ee383d31a9/docs/managed-vmware-services/vcloud/v1/",
      "path": "/build-ee383d31a9/docs/managed-vmware-services/vcloud/v1/-v1.5/"
    },
    {
      "domain": "developer.rackspace.com",
      "baseContentID": "https://github.com/build-ee383d31a9/rackerlabs/docs-dedicated-vcloud/vcloud-handbook-v1.5/",
      "basePath": "/build-ee383d31a9/docs/managed-vmware-services/vcloud/v1.5/",
      "path": "/build-ee383d31a9/docs/managed-vmware-services/vcloud/v1.5/"
    }
  ]
}

The middle result is inconsistent with the way that content mapping behaves for rendering:

$ headers https://staging.developer.rackspace.com/build-ee383d31a9/docs/managed-vmware-services/vcloud/v1/-v1.5/
HTTP/1.1 404 Not Found

$ headers https://staging.developer.rackspace.com/build-ee383d31a9/docs/private-cloud/dedicated-vcloud/vcloud-handbook-v1.5/
HTTP/1.1 200 OK

$ headers https://staging.developer.rackspace.com/build-ee383d31a9/docs/managed-vmware-services/vcloud/v1.5/
HTTP/1.1 200 OK

This is causing problems with the staging builds for rackerlabs/docs-dedicated-vcloud#51.

[meker12]

Providing additional information about the dedicated vcloud issues:

So the content at these URLs looks fine:

• https://developer.rackspace.com/docs/managed-vmware-services/vcenter/
• https://developer.rackspace.com/docs/managed-vmware-services/vcloud/v1/

This one still having trouble: shows the vcenter and vCloud v1 entries in addition to the v1.5.

https://developer.rackspace.com/docs/managed-vmware-services/vcloud/v1.5/

Also, PR build is failing now with a Strider error: https://build.developer.rackspace.com/rackerlabs/docs-dedicated-vcloud/

Thought:

The developer.rackspace.com.json route configuration has this specification:

"^/docs/managed-vmware-services": "user-guide.html",

Would it make any differences if the routes were configured explicitly?

"^/docs/managed-vmware-services/vcenter": "user-guide.html", 
"^/docs/managed-vmware-services/vcloud/v1": "user-guide.html",
"^/docs/managed-vmware-services"/vcloud/v1.5: "user-guide.html",

or does the order of the routes in the config.json matter? That is, would it make a difference if the config.json order put the more specific match first?:

"/docs/managed-vmware-services/vcenter/": "https://github.com/rackerlabs/docs-dedicated-vcloud/vcenter-handbook/",          
"/docs/managed-vmware-services/vcloud/v1.5/": "https://github.com/rackerlabs/docs-dedicated-vcloud/vcloud-handbook-v1.5/",
"/docs/managed-vmware-services/vcloud/v1/": "https://github.com/rackerlabs/docs-dedicated-vcloud/vcloud-handbook/",

[smashwilson]

Looking at the metadata envelope for vcloud-handbook, which is rendering the correct TOC, I see:

{
  "envelope": {
    "addenda": {
      "repository_toc": "https://github.com/rackerlabs/docs-dedicated-vcloud/vcloud-handbook/_toc"
    },
    // ...
}

Looking at the envelope for vcloud-handbook-1.5, however, I see:

{
  "envelope": {
    "addenda": {
      "repository_toc": "https://github.com/rackerlabs/docs-dedicated-vcloud/_toc"
    },
    // ..
}

From the contentIDBase in that repository, I would expect repository_toc to be https://github.com/rackerlabs/docs-dedicated-vcloud/vcloud-handbook-v1.5/_toc. This looks like a Sphinx preparer bug to me - we're missing a path segment from the TOC envelope content ID in the envelope addenda.

Would it make any differences if the routes were configured explicitly?

No. That would only be necessary if one of them needed to use a different template, but user-guide.html is the correct template for all three.

If the problem was an incorrect template mapping, you'd see no table of contents at all, not an incorrect table of contents.

or does the order of the routes in the config.json matter? That is, would it make a difference if the config.json order put the more specific match first?

No, JSON objects are unordered. Content mappings work by matching the longest prefix.

As far as I can tell, all of the control repository mappings are correct, but the TOC envelopes for vcloud-handbook-1.5 is being submitted incorrectly for some reason. I'll see if I can figure out why.

[smashwilson]

Strange. When I run the Sphinx preparer on vcloud-handbook-1.5 locally:

$ docker run --rm -it \
  -v $(pwd):/content \
  -e CONTENT_ROOT=/content/doc/vcloud-handbook-v1.5/ \
  quay.io/deconst/preparer-sphinx

The envelopes have the correct "addenda" entry for the TOC:

$ jq .addenda doc/vcloud-handbook-v1.5/_build/deconst-envelopes/https%3A%2F%2Fgithub.com%2Frackerlabs%2Fdocs-dedicated-vcloud%2Fvcloud-handbook-1.5.json
{
  "repository_toc": "https://github.com/rackerlabs/docs-dedicated-vcloud/vcloud-handbook-1.5/_toc"
}

[smashwilson]

Ohh, I see what's going on.

The contentIDBase for vcloud-handbook-v1.5 in the content repository is:

https://github.com/rackerlabs/docs-dedicated-vcloud/vcloud-handbook-1.5/

But the contentIDBase mapped in nexus-control is:

https://github.com/rackerlabs/docs-dedicated-vcloud/vcloud-handbook-v1.5/

Nexus is rendering the last content that was submitted with the old content ID, which references the old TOC envelope that includes all three subdirectories.

And I see that you've already noticed this and have a fix ready in rackerlabs/docs-dedicated-vcloud#54. I've tested locally and that will use the correct TOC.

[smashwilson]

Yup, that looks better:

All good?

[smashwilson]

Looks like this is good now. :+1: