On Mon, 30 May 2022 at 21:26, Neal Gompa <ngompa13(a)gmail.com> wrote:
On Mon, May 30, 2022 at 11:20 PM Miroslav Suchý
<msuchy(a)redhat.com> wrote:
>
> Dne 23. 05. 22 v 20:57 Kevin Fenzi napsal(a):
> > However, now a days we have a number of new apps that are deployed in
> > openshift and aren't using rpms, but pip or s2i or other things.
>
> Regarding pip applications - we have pyp2rpm and pyp2spec which can
convert to rpm easily. And we have
>
>
https://copr.fedorainfracloud.org/coprs/g/copr/PyPI/
>
> with about 70k packages.
>
The bigger problem is that those applications are *not* able to easily
be deployed outside of Fedora infrastructure. One consequence of
OpenShift based deployments is that it's become almost too easy to
assume nobody else would ever want to run that code. Noggin and Bodhi
both have had a number of code changes in the past couple of years
that have made it increasingly difficult to use outside of Fedora
deployments in their default code state. I've given up on Bodhi, but
I'm still trying to get Noggin into good shape.
I've been able to evaluate those issues by packaging them as RPMs,
because RPM packaging forces a total decoupling of development,
deployment, and configuration. None of that is true with our container
based deployments. They're not discoverable, and if you can find them,
they're not independently useful.
Because of this, it becomes hard for community growth around these
projects.
I think we should be clearer about if community growth is expected. 15 to
10 years ago, we tried very hard to grow community support into helping to
build things but found that the requirements of what was wanted in the
applications always took more time and energy than volunteers had. Over the
last 10 years, we have had less and less time to do this community growth
work.
Fedora Infrastructure's primary mission is to provide a working build
system and produce N thousand deliverables every day (be this individually
built RPMS, containers, spins, isos, raw images, etc etc). We are to do
this while also maintaining the core community features which allow for
mail, badges, and outsourced tools to work as best as possible. The amount
of resources to actually make it work where we could have people do the
marketing and community support needed to make generic apps or even build
an infrastructure community is about 2x what we have people for IF we only
had to keep the current applications going. However as soon as you hire
someone in this space, you find that 3-4 new projects which were waiting to
be resourced become high priority. And the timeframes to delivery are
shortened as it is no longer acceptable to have a tool in development for N
years before initial deployment like Bodhi and some others had. Instead you
usually go from prototype to full production in 1 to 1.5 release cycles (6
to 9 months).
In order to meet this, we usually have to bake all the 'business rules' of
the time into the application. The idea being that when the rules change,
the developer will just likely rewrite it from scratch to meet those.
[Since one of the lessons learned from when we did 'long form development'
was that a lot of code was rewritten every time a new framework which
helped solve something better was found.]
Finally, I think trying to decouple deployment, development, and
configuration is going against the tide. "Infrastructure as Code" sounds
great but it generally means that those 3 things are tied together deeply
in every application and tool written these days. Like the tide, this is a
cyclical pattern in the industry and it will roll out and leave a pile of
bad example flotsam that few will remember the next time the tide comes in.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren