Excerpts from Steven Dake (stdake)'s message of 2016-09-13 23:33:04 +0000: > Hey folks, > > The quickstart guide was modified as a result of a lot of painful debugging > over the last cycle approximately a month ago. The only solution available > to us was to split the workflow into an operator workflow (working on stable > branches) and a developer workflow (working on master). We recognize > operators are developers and the docs indicate as much. Many times operators > want to work with master as they are evaluating Newton and planning to place > it into production. > > I’d invite folks using master with the pip install ./ method to have a > re-read of the quickstart documentation. The documentation was changed in > subtle ways (with warning and info boxes) but folks that have been using > Kolla prior to the quckstart change may be using kolla in the same way the > quickstart previously recommended. Folks tend to get jammed up on this issue > – we have helped 70-100 people work past this problem before we finally > sorted out a workable solution (via documentation). > > The real issue lies in how PBR operates and pip interacts with Kolla and is > explained in the quickstart. From consulting with Doug Hellman and others in > the release team, it appears the issue that impacts Kolla is not really > solveable within PBR itself. (I don’t mean to put words in Doug’s mouth, but > that is how I parsed our four+ hour discussion) on the topic. > > The documentation is located here: > http://docs.openstack.org/developer/kolla
It has been a while since that conversation, but IIRC the issue was with installing kolla from packages and then also trying to use the git version (or trying to use the git version instead) without updating the package metadata. For most projects this doesn't matter, but kolla uses its version number for some internal logic (I don't remember those details), which makes it more sensitive to having the wrong version than other projects might be. PBR has a 2 phase lookup for versions. It first uses setuptools to try to get the value from the metadata. If that fails, it then tries to get the value from a local git repository, using the tags. So, after the first kolla package is installed there is always metadata available, even if it's wrong. It's not clear that you need to tell people not to pip install from source, so much as that they need to uninstall one version before installing a new one, so that the metadata is correct. But if the instructions you have now are working, that's the true test. Doug __________________________________________________________________________ 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
