On Mon, 30 May 2022 at 21:26, Neal Gompa <ngompa13@xxxxxxxxx> wrote:
On Mon, May 30, 2022 at 11:20 PM Miroslav Suchý <msuchy@xxxxxxxxxx> 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_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
