metadata/name in setup.cfg inconsistent with release name

[Brian Rosmaita]

This is a really weird one. It showed up when setting up a periodic "tips" job in glance, where the glance unit/functional tests would be run against the glance_store master [*]. The ansible task tox_install_sibling_packages looks at the [metadata]/name in the setup.cfg for each of the repos zuul is asked to clone to figure out what packages it needs to uninstall and replace with a new version generated from the cloned repo. For the cloned glance_store repo, it gets 'glance_store' from setup.cfg, but the pip freeze output has 'glance-store' (because that's how requirements.txt and upper-constraints.txt refer to it).

From what I can tell, there are 3 options here:

(0) leave glance_store unchanged and modify zuul-jobs/roles/tox/library/tox_install_sibling_packages.py so that it can handle glance_store
pros:
- won't have to modify glance_store at all
- won't break anything consuming glance_store
- makes that task more pip-compatible (pip handles -/_ substitutions seamlessly, more or less)
cons:
- have to talk infra group into accepting the fix

(1) change pypi-name in releases/deliverables/.../glance-store.yaml to 'glance_store'
cons:
- have to change requirements.txt, u-c.txt, l-c.txt to use the underscore
- have to do the above for all consuming projects
pros:
- when you ask for glance-store, pypi currently redirects you to glance_store
- tox-install-siblings ansible task will work unchanged

(2) change [metadata]/name in setup.cfg FROM glance_store TO glance-store
pros:
- no changes necessary to requirements, etc.
- wheel and package are glance_store (as they are now), so don't anticipate breaking any consumers (though don't know for sure)
- tox-install-siblings ansible task will work unchanged
cons:
- not sure what will happen on pypi (currently, pypi.org/project/glance-store redirects to pypi.org/project/glance_store; presumably, that will stop happening with the next release, whose name will actually be glance-store)

[*] https://review.openstack.org/#/c/569225/

[Brian Rosmaita (brian-rosmaita)]

Here's a patch that tries option 0: https://review.openstack.org/#/c/571005/

[Brian Rosmaita (brian-rosmaita)]

"Fixed" this issue by adjusting zuul-jobs: http://git.openstack.org/cgit/openstack-infra/zuul-jobs/commit/?id=b457191d14fd6e550a7ed4375be570da2771b840 , on the theory that since pip doesn't have a problem with this issue, zuul shouldn't either.

We still have the inconsistency, but won't fix it because (a) it doesn't seem to be causing any problems, and (b) fixing it might cause some consumers to fail.

[Brian Rosmaita (brian-rosmaita)]

Won't fix this in glance, instead modified zuul-jobs so that it is no longer an issue.