Open Stack

On 2021-12-10 10:43:10 +0100 (+0100), Jean-Philippe Evrard wrote:
> On Thu, Dec 9, 2021, at 19:03, Jeremy Stanley wrote:
[...]
> >   * Skyline performs its release versioning by committing the
> >     version strings to files in its repositories rather than
> >     assigning them at build time from Git tag metadata. This leads
> >     to ambiguity as to what exact state of the repository represents
> >     that version, as well as opening up the possibility of
> >     forgetting to merge the version update before tagging (a very
> >     common problem which drove OpenStack to rely on its current
> >     model). Wholly different tools are also needed in order to
> >     track versions for these projects as a result. Should the rest
> >     of OpenStack's projects follow suit there? Has something changed
> >     to make the idea of using Git to signal releases a bad one?
> 
> You're raising again a valid point, for which the skyline team
> will have to find a solution.
> 
> For me, it boils down to defining that projects should follow a
> "project release interface", which explains the expected behaviour
> in regards of releasing for projects. We don't have such. I am not
> claiming we should, I am merely asking us to think about what we
> are doing.
> 
> Projects could indeed move to use pbr/setuptools. However, I am
> not sure many developers understand why. Should we simply explain
> what is expected in terms of building the version from git? People
> might even come with interesting solutions. Promoting creativity
> will create tech debt, but might also reduce it over time. What if
> we don't need pbr anymore? Will we even notice?

Isn't that exactly what I did? You'll notice here and in my review I
didn't say "use PBR," I outlined the properties desired instead.
It's the case that using PBR is likely the easiest way to do that
since we already have a lot of examples, but like you I don't think
that the implementation is important as long as we can find a
suitable solution to the problems we face.

That said, using a consistent implementation across as many projects
as possible increases our familiarity and ability to address new
issues with the fewest set of solutions.

> >   * Skyline uses makefiles to script its build and test workflows
> >     rather than tox, adding a tox wrapper around the make targets
> >     in order to nominally comply with the OpenStack PTI. As a
> >     result, it's unable to rely on most of tox's features for
> >     environment isolation, package management, path overrides, et
> >     cetera. OpenStack projects have solved a lot of cross-project
> >     development workflow challenges through applying consistent
> >     changes across the tox.ini files of repositories, should those
> >     solutions be abandoned and recreated for make instead?
> 
> I didn't say so. I am only partially agreeing with you there, for
> once :)
> 
> For me, tox is a test runner that provides many nice features
> thanks to its code (and integration with setuptools) I would
> prefer if python projects using tox for testing interface indeed.
> Should that be the standard? I don't know. Does it make sense to
> rely on tox features for isolations/package management/other? I
> don't know. You might be aware that it's possible to integrate tox
> with poetry. Does it provide all we _need_? I don't know: We
> aren't explicit in the requirements of what we need, we just talk
> about tools.
> 
> If I were to rephrase: Is it easier to fit the existing mold or
> clarify what we need, why, and how we can deal with the tech debt?
> Probably the former. Should we do it? I don't know. The TC should
> however evaluate this seriously.

Let's be clear, I have nothing against make. In fact, I somewhat
prefer it, since it's useful for projects written in all sorts of
different programming languages beyond Python. At one point we even
came very close to recommending OpenStack switch from tox to make
during one of the more unfortunate backward-incompatible tox
releases some years ago. Clark had a proof of concept recreating the
fundamentals of tox itself in Makefiles, and it wasn't half bad.

But having one project use make while the rest use tox isn't really
great for anyone, it turns the make-based project into a
second-class citizen within the whole. Its maintainers have to do a
lot more work to support the same workflows with a different tool,
and the community as a whole incurs some additional burden in
working around that difference (additional CI jobs, separate
functionality, different developer documentation). If we think make
is a superior solution we should use it across all of OpenStack and
not just in a few random projects.

> >   * Skyline does not put its external Python package dependencies in
> >     central lists nor use tools which would allow it to rely on
> >     OpenStack's global constraints implementation, making it very
> >     hard for them to guarantee that their software can run with the
> >     same versions of shared dependencies as the rest of OpenStack.
> >     Is this unnecessary? Have we given up on the idea that two
> >     pieces of OpenStack software can be coinstalled into one
> >     environment, or that Linux distributions won't be stuck having
> >     to package many different versions of the same software because
> >     OpenStack projects don't agree on which versions work for them
> >     any longer?
> 
> Now, we are hitting the nail, IMO :)
> 
> This is a bit of the issue's core, isn't it? I think that's what
> we need to document. While I (personally) don't believe it's
> important nowadays (cf. containers), I am sure distros will
> disagree with me. It's important to know who we are pleasing, as
> we can't please everyone ;) Let's be clear about the audience.
[...]

Just my opinion, but I think buying into container hype to the point
where we make OpenStack only deployable through containerization
would be a massive step backwards.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20211210/0a387008/attachment-0001.sig>