Hey folks. I thought I would open a discussion about fedoraplanet and
possibly some plans for it.
fedoraplanet.org runs on people02.fedoraproject.org (aka fedorapeople).
To add a blog/rss feed you have to login there and edit your .planet
file, then scripting pulls all those .planet files and tries to fetch
all the feeds and then serves them up at http://fedoraplanet.org.
It uses a app called 'venus' to do this. venus is written in very old
python2 and very very dead upstream.
We run into the following problems with it:
* Sometimes it gets stuck and just stops processing until it's killed.
* It's serving on a http site, which causes people to ask us to make it
https, but that would just change the errors because many feeds it pulls
are still http since they were added back before letsencrypt existed.
* We have a handy 'website' field in our new account system, but aren't
using it at all.
* The .planet parsing is poor, any number of things can cause it to
We have two open tickets on it:
- https://pagure.io/fedora-infrastructure/issue/10383 (upgrade to pluto,
a ruby based, but maintained thing)
( planet not served via ssl) Which I am just going to close now.
So, I can think of a number of options and would love everyone who has
thoughts on it to chime in:
1. Do nothing. Venus "works" and .planet files are cool and retro.
2. Switch to pluto and use account system 'website' fields of
contributors. We could likely shove it in openshift and serve it
directly from there to avoid fedorapeople entirely.
(This would likely break anyone who has multiple feeds in there)
3. Switch to something better/bigger. I would think (although I don't
know) that there might be something that would not only aggregate rss
feeds for contributors, but perhaps mastodon/twitter/whatever also.
4. Planets are old and tired, just drop the entire thing. People can
maintain their own rss lists.
5. Planets are old and tired, just drop the entire thing.
But also, get our social media people to maintain contributor /
interesting lists. ie, the fedoraproject twitter account could maintain
a list of 'fedora contributors' and 'fedora packagers' or whatever.
6. Switch to pluto as in 2, but also setup some curators. Have a
'firehose' of all feeds, but the main fedora planet would be just
curated things that are known to be related to fedora and not off topic
6. Get someones (not it!) to take in all the
twitter/facebook/mastodon/blog posts/rss feeds and post some kind of
curated round up every week or something.
7. Your brilliant idea here!
So, thoughts? this is not at all urgent, but we should end up doing
something with it sometime. :)
I'd like to ask if there is anybody familiar with the state of flask-oidc?
It's been long-time broken with the latest itsdangerous, which was recently
bumped in Rawhide, which broke all the applications using flask-oidc from
Fedora repositories ( https://bugzilla.redhat.com/show_bug.cgi?id=2150955 ).
There is an upstream PR against flask-oidc changing itsdangerous to pyJWT:
https://github.com/puiterwijk/flask-oidc/pull/144 (which, according to my
previous testing, makes the trouble go away). Can somebody take a look at
it, and merge/release a new fixed version? I can handle pyJWT packaging in
Fedora if this is the way forward.
On a similar note, is the flask-oidc library the way to connect to FAS
login for python applications? I had an impression that apps should migrate
to this from plain openid (and I am planning to handle the transition of
remaining Fedora QA apps). It seems abandoned upstream, so should the devs
of python/flask apps use some other lib/way?
Thanks a lot upfront!
Best regards / S pozdravem,
Senior Quality Engineer
I'm working on implementing my fas-groups-to-discourse-groups bridge. My
goal is to have this work from the message bus.
I can see that `org.fedoraproject.prod.fas.group.member.sponsor` triggers
when someone is added to a group in the FAS UI. There is also
`org.fedoraproject.prod.fas.group.member.approve` in the docs, but I'm not
sure what triggers that (maybe nothing in the current workflow -- a holdvoer
from the older account system?).
There is also `org.fedoraproject.prod.fas.group.member.remove`, but that
does't seem to actually show up in datagrepper when I remove an account from
a group. (Nor are there any user-related messages.)
I must be missing something obvious, here....
Fedora Project Leader
I want to sync group membership to Discourse. See one idea for this here:
However, this would be approximately one billion times easier if I didn't
need to worry about the hard part of automating something with fasjson,
which is keeping a kerberos ticket fresh from a keytab. (I'd love to run my
whole thing as a function-as-a-service function.)
I get why we require authentication, but since this info is open to anyone
who authenticates, it's only one part of our protection. And it occured to
me that one needs a FAS account to create something in Communishift anyway.
Unless I am missing something (and I might be)... that really offers
basically the same protection. So..... would it be possible to just
allow-list connections coming from the Communishift nodes?
Fedora Project Leader
As you may have read in the announcement on the devel mailing list, I've
started a change proposal about bumping Pyramid to version 2.0 for F38.
I cross-announce here because Pyramid and its dependencies are mostly
maintained by infra-sig and I don't want to bypass main-admins, but I
think it's time to move forward (and I have some projects about using
pyramid-openapi3 to provide REST APIs in Bodhi which will need Pyramid 2).
I intend to upgrade Pyramid and rebuild dependent packages also updating
spec files to latest packaging guidelines and possibly upgrade packages
to the latest versions. The list of packages is:
* python-pyramid - Maintained by kevin / infra-sig
* bodhi-server - Maintained by humaton
* python-cornice - Maintained by hguemar / python-packagers-sig
* python-pyramid-fas-openid - Maintained by abompard / infra-sig
* python-pyramid-mako - Maintained by kevin / infra-sig
* python-pyramid-tm - Maintained by kevin / infra-sig
* python-pyramid_sawing - Maintained by abompard
The dependent packages rebuild is not really needed, but it will ensure
that the tests will not fail with Pyramid 2.0. In fact,
python-pyramid-mako is the only one which needs an upgrade to be
compatible with Pyramid 2.0.
I have set up a COPR repository to test the upgrade:
Let me know if there's any objection to the proposal.
I hope you are doing well. I write this to let you know that I have been
working on the MDAPI project under Pierre-Yves Chibon's guidance for some
time now for
1. Refactoring the code
2. Implementing code quality standards
3. Adding more comprehensive tests
4. Implementing a CLI wrapper
And other major changes
The codebase functionality remains the same in this rewrite for users, but
I have made attempts to ensure that it becomes relatively easier for the
community members to be able to contribute to the project with the addition
of documentation, enhancements in code readability and other miscellaneous
changes that help improve the contributor quality of life. Once the changes
were completed, I moved the repository from my personal GitHub namespace
(now archived) over to Fedora Infra's GitHub namespace and deployed
it on the Fedora's staging environment, with David Kirwan's assistance.
Please take it for a spin and test it out so that we can fix as many issues
as we can before we deploy it on the production environment.
Happy holidays! :)
Akashdeep Dhar (he/him),
Objective Representative, Fedora Council
Red Hat Community Platform Engineering