Fuel version is hardcoded in multiple places in fuel-web and fuel-astute

[Dmitry Borodaenko]

Bumping Fuel version involves tens of lines of changes in multiple repositories:

https://review.openstack.org/189322
https://review.openstack.org/189359
https://review.openstack.org/189384
https://review.openstack.org/189458
https://review.openstack.org/189518

fuel-web and fuel-astute are particularly bad, with 16 and 11 places where version is hardcoded, respectively.

[Mike Scherbakov (mihgen)]

Let's think through and ideally identify the place where we would put the version, and re-use it everywhere else referring to it as a variable instead of hardcode.

[Łukasz Oleś (loles)]

Why do you want to change mcagents version in astute? In my understanding version should be only changed when agent code is changed. Like for example in net_probe in 6.1.

[Ihor Kalnytskyi (ikalnytskyi)]

Honestly, I don't agree. We should not change repos once we want to bump Fuel versions. There's nothing in common between repos to be used and fuel version, and it could be done separately.

[deactivateduser (deactivateduser-deactivatedaccount)]

We could implement version fetching using 'pbr' library as it's done in other OpenStack projects.

[Vladimir Sharshov (vsharshov)]

Because it is a tech-debt and we have workaround, move it to 8.0

[Vladimir Kozhukalov (kozhukalov)]

My $2 on this

1)There is a good working approach to track compatibility of the components. This approach is RPM/DEB repository. Packages can have dependencies, there are meta-packages that are intended to track groups of packages. That is totally up to a package maintainer to align application dependencies. Package version is NOT application version. Please don't mix them. I strongly disagree that spec should be 100% aligned with application itself. They are different substances and ideally specs should be placed to separate git repos.

It is not always true that application developer and package maintainer are different people, but still these roles are certainly different.

2) However it is convenient to track/bump components versions together if those components are parts of a single huge project like Openstack. But in Openstack components are services or libraries that are usually changing during release cycle. There are no stable/dead components in Openstack. They all bumped together at the same time because they usually interact with each other via their APIs and they are likely not compatible when taken with different versions.

3) Small auxiliary Openstack libraries like, for example, Stevedore do not follow Openstack release cycle (Juno/Liberty/etc.) and thus aren't bumped. They are usually backward compatible and published on PyPi. If a part of library interface needs to be deprecated, an announcement is usually published and component teams align this change on independently.

4) The same is about Fuel. Fuel is a group of applications. Applications interact with each other via their APIs and these applications are likely not compatible with each other when taken with different versions. These big applications like Nailgun, Astute, Nailgun client, UI should be bumped together at the same time.

5) Small Fuel components like net-checker, shotgun, agent are usually quite stable and backward compatible. They can not be brought out of Fuel release cycle.

6) Please don't introduce yet another version.yaml file which was supposed to be a single convenient place where everything is aligned but instead it turned out to become a fifth wheel.

[Vladimir Kozhukalov (kozhukalov)]

Small type that changes everything :-)
s/They can not be brought out of Fuel release cycle/They CAN be brought out of Fuel release cycle/

[Vladimir Kozhukalov (kozhukalov)]

s/type/typo/

[Vladimir Kozhukalov (kozhukalov)]

Due to #6, changing the status to Invalid.

[Dmitry Borodaenko (angdraug)]

Vladimir's point against single cross-component version is valid. I'm fine with having a single (single!) place per component where version is defined. I'm not ok with 11 places like in astute and 16 in fuel-web. I also don't agree with an argument that if a separate component is bundled inside fuel-web repo it's ok for it to have its own version: extract it out of fuel-web first, and then when you can tag it independently in git you can track its version independently in the code.

[Vladimir Kozhukalov (kozhukalov)]

Dmitry, thanks for clarification, but I still think this bug is Invalid due to the following:

- We are continuing to separate fuel-web repository. Network checker, shotgun, fuel_upgrade_packages, fuelmenu, UI will be moved out of fuel-web and it will automatically reduce the number of places in fuel-web where we need to bump versions.
- Some of small projects like fuelmenu or shotgun can easily be brought out of Fuel release cycle (still need to discuss this), but it will also reduce the number of bumped places.
- I have strong opinion that RPM/DEB specs should be separated from the source code. Like I said we should stop mixing package version and application version. Maintaining specs is completely different process and we have dedicated infrastructure for this.

This particular issue will be partly assimilated by our current activities in simplifying build/delivery process.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/225143

[Vladimir Kozhukalov (kozhukalov)]

See comments above.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Bulat Gaifullin (<email address hidden>) on branch: master
Review: https://review.openstack.org/225143
Reason: it is not actual anymore.