On ma, 22 heinä 2019, Jeremy Cline wrote:
On Sun, Jul 21, 2019 at 05:37:10PM -0400, Neal Gompa wrote:
On Wed, Jul 17, 2019 at 4:31 PM Jeremy Cline <jer...@jcline.org> wrote:
>
> On Wed, Jul 17, 2019 at 08:33:02AM -0400, Neal Gompa wrote:
> > On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon <pin...@pingoured.fr>
wrote:
> > >
> > > Good Morning,
> > >
> > > We posted this [1] blog today and want to open a mailing thread to garner
> > > feedback, field questions and get some thoughts from the Community on
> > > the approach that we in Community Platform Engineering (CPE) are taking.
> > >
> > > [1]
https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/
> > >
> >
> > Two things that concern me at this time:
>
> <snip>
>
> >
> > > Ipsilon — Ipsilon is our identity provider. It supports multiple
> > > authentication protocol (OpenID 2.0, OpenID Connect, SAML 2.0, …)
> > > and multiple backends (FAS, LDAP/FreeIPA, htpasswd, system accounts…).
> > > While it was originally shipped as a tech preview in RHEL it no longer is
and
> > > the team working on this application has also been refocused on other
projects.
> > > We would like to move all our applications to use OpenID Connect or SAML
2.0
> > > (instead of OpenID 2.0 with (custom) extensions) and replace FAS with an
> > > IPA-based solution, which in turn allows us to replace ipsilon by a more
> > > maintained solution, likely Red Hat Single Sign On. The dependencies
> > > are making this a long term effort. We will need to announce to the
community
> > > that this means we will shut down the public OpenID 2.0 endpoints,
> > > which means that any community services that use this protocol need
> > > to be moved to OpenID Connect as well.
> >
> > There are two issues to unpack here:
> >
> > 1. We use a weird custom backend and custom protocol extensions.
> >
> > This should definitely be replaced if it makes sense. It’s more urgent
> > now that RHEL 6 is going EOL next year, and FAS 2 is still a Python
> > 2.6 application. FAS 3 *would* have fixed it, but interest by the FAS
> > developers died a while ago…
> >
> > Naturally, the replacement is equally in a poor state, but may have
> > some legs someday: https://github.com/fedora-infra/noggin
> >
> > 2. Ipsilon development was only considered important as part of being
> > tech preview in RHEL and now it’s not.
> >
> > There are some major problems here. First of all, Ipsilon development
> > has been gated by a single person. That person also seems to have
> > trouble making time to review pull requests. There has been interest
> > from the broader community about using and contributing to Ipsilon,
> > since unlike Keycloak, it is written in an accessible language
> > (Python).
> >
> > Getting Ipsilon to Python 3 would be enough for me to get started on
> > bootstrapping some of the other interested parties onto Ipsilon, and
> > hopefully give us a more sustainable community long-term.
>
> I guess my question to all this is... Why? What's the goal? If Keycloak
> does everything Ipsilon does and more, what's the point of keeping a
> dead project alive instead of contributing to the active, lively one?
>
> If there really, truly is interest from the broader community, why not
> do a friendly fork, get all the work you want in, and see what the
> original maintainer thinks?
>
Keycloak is not generally Fedora contributor friendly. Aside from it
being written in Java (which is problematic with the Java stack in
Fedora slowly imploding...), Keycloak is a lot less flexible and a lot
more tied to aspects of RHEL/Fedora that make it annoying to use in
other environments.
This sounds more like an issue with Fedora's Java stack. I don't love
Java anymore than anyone else (I think), but I really don't understand
why a language plays such a huge role.
It is mostly due to supportability of the packages in Fedora. Java
products tend to be split into smaller packages and an overhead for
maintaining them grows a lot. In 2019 Fedora Java packages got dropped
by one of maintainers and that created a havoc as many packages depend
on few important ones that were suddenly not supported anymore and were
going to be orphaned.
Keycloak is actually quite more flexible in terms what it provides and
how it could be integrated than Ipsilon but it is oriented to be
integrated within applications so that both user experience and visual
experience are integrated end-to-end. In most cases that means use of
the same ecosystem (Java-based) which doesn't play well with
semi-isolated non-Java Fedora project applications we are talking about
here.
At least with Ipsilon, the Python codebase makes it easy for a broad
base of contributors to hack on the code. It's also much easier to set
up than Keycloak and easier to plug into more environments.
I imagine Keycloak wouldn't be against making their project easier to
set up and plug into other environments, but maybe I'm wrong.
It is relatively easy to set up by itself. However, here we are coming
to a traditional dichotomy on what is easy for RPM-based environment and
what is easy for Java-based deployments. These two environments aren't
necessarily at conflict but traditions in both camps are widely
different.
The biggest issue with Ipsilon as a project is the lack of awareness
of its existence. That has allowed the fact that the maintainer hasn't
recently been able to focus on it in a while to be unnoticed. Now that
is changing, and this is a problem, as I outline later...
> For Fedora, though, if FreeIPA can replace FAS, or GitLab can replace
> Pagure, or a generic notification service exists somewhere to replace
> FMN, or whatever, why spend time on such things we could be spending
> developing the few unique tools we need to continue building the Fedora
> distribution? Stopping along the way to build an identity and access
> management platform isn't going to make the distribution better.
>
FreeIPA is a perfectly fine solution, since it's broadly available and
easy to deploy. The non-Java parts (everything but Dogtag) is quite
easy to understand and hack on. Reproducing the tooling and
environment is easy as well. I have no problems with it other than
FAS-specific functions still need implementing on top of FreeIPA
(which in theory, Noggin will do). It's more complicated than I'd like
in some ways, but at least setup is replicable, making it easy to do
development and contribute.
As for GitLab vs Pagure, my reasoning is more or less than same as
mine with Keycloak vs Ipsilon. And there *are* users other than us for
both Pagure and Ipsilon.
Ruby is just Python without () and a lot of question marks in function
names. Making a code review tool + issue tracker + story board + CI
pipeline is an insanely difficult, complicated task. Far harder than
learning Ruby properly.
I don't mean this as an attack on any of the maintainers or contributors
to Pagure, just feedback. It is not pleasant to use. Not for code
review, not for issue tracking, not for CI. Other platforms (several of
them open source) are far, far better in every area and at this time I
wouldn't ever choose to put a project on Pagure.
The opportunity cost of spending developer time trying to get Pagure
functional is enormous. The cost of system administrator time is huge.
Perhaps most importantly, it sucks up huge amounts of user time when
it's broken/down/slow/non-functional.
In my opinion Fedora is spinning its wheels here, and the vehicle isn't
even pointed in the right direction. Gnome is on GitLab. Debian and the
graphics stack is moving to GitLab AFAIK. We could be working towards
making their development environment better along with our own by
contributing to GitLab, or we can continue to work on a similar project
with a tiny fraction of the resources and cost users vast amounts of
time.
It all depends on what are you using it for. I'm not satisfied with
GitLab performance we see with Samba Team merge requests workflow.
GitLab UI is very slow there, for example, literally hanging up very
recent Firefox if you need to look at results of executed pipelines.
The difference between Ipsilon and Pagure, in my view, is the primary
maintainer. Pierre-Yves Chibon has been very accessible and a pleasure
to work with as part of contributing to Pagure. I have virtually no
experience interacting with Patrick Uiterwijk because he's barely
around.
I agree that Patrick is wildly over-worked. He's around everywhere, but
the problem is there's so much stuff there's just not enough of him to
go around and he deserves to be able to go on PTO or spend his evenings
relaxing rather that putting out fires all over Fedora.
We all feel the same. If Patrick is not enough, the answer should really
be not just in reducing the set of apps to maintain. It should also be
looked at another angle -- may be we need to have more Patricks. (This
is said by the guy who is also overworked on FreeIPA side).
We have a number of projects that we're basically said only the
"security guy" can work on (i.e. Patrick). That's more of a problem
than anything else the CPE team does. The bus factor of *one* security
person is ridiculous, and the fact we're stretching him across both
CentOS and Fedora now means he doesn't pay enough attention to either
project. If we're going to have this (frankly insane) requirement that
we need to block all this on a security person, we need more than one.
Full stop.
More resources would be great, yes. When I was on the infrastructure
team I felt we needed orders of magnitude more developers and system
admins for what we were doing. The thing is, though, Fedora's not going
to get that many more resources. I don't expect Red Hat to open more
positions for Fedora, and I know that the community is a very limited
resource.
That's why Fedora needs to stop re-inventing every single thing it
needs. We don't have the resources and pretending we do is damaging the
contributor experience.
My experience with those other tools, like GitLab, is that as soon as
you are going to solve the problems Fedora infra is facing, with those
tools, you are going to find issues everywhere and will have to
contribute to fixes to projects that might not be willing to accept
them. For various reasons, but would you have a plan how to handle that?
And you know what? Projects like FAS, Ipsilon, and Pagure *do* make
Fedora better in my eyes. With the exception of modularity, we haven't
built solutions that are so obscenely complicated that no one can
reasonably set up to replicate our environment. All the other
solutions out there are immensely more complicated, focusing on things
we don't care about, and generally being a pain for normal people to
get access to, deploy, modify, and contribute to.
I don't understand why this is something that is so easily forgotten...
I haven't forgotten that solutions out there are complicated, but it's
possible to simplify and improve existing projects without starting from
scratch.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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/devel@lists.fedoraproject.org
