Fuel for OpenStack

Bug #1463182
Comment #6

Comment 6 for bug 1463182

Revision history for this message

Vladimir Kozhukalov (kozhukalov) wrote on 2015-09-15:

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.

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.

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.