Dear colleagues,
I would like to share some updates and ask for suggestions regarding the Fedora Planet.
As some of you may already know, Fedora Planet was deployed on CommuniShift with the blogs hard-coded. Additionally, we are working on some significant changes that affect the process of adding new blogs to the Fedora Planet.
Instead of users having to SSH and create a .planet file to add their blogs, the idea would be simply add their blogs to Fedora Accounts. The fields in Fedora Accounts should be available in FasJSON, and we are using this API to create the files for each planet so Pluto can build them.
I wrote a Python script, just for now, that creates planet build files using the "website" field in FasJSON and brute-force directories to find RSS feeds (not the best solution, but I'll get there), this script classifies in which planet a particular blog will be added based on which group the user is in (i.e. if the user is in design fedora account group, then will be added to design planet). However, this could bring some issues to the users like showing an article not related to the corresponding planet. Additionally, a user also may have tags in their blog that correspond to a particular planet, such as security, design, fedora, etc. Because of those issues, I talked to Kevin about adding an RSS field in Fedora Accounts (noggin) that would allow the user to add links to the planets they want and also get rid of that brute-force solution. I created an issue about it here: https://github.com/fedora-infra/noggin/issues/1155
Is it the best approach? Are those planets still being used? Also, is it okay to let users freely add some link that will appear in Fedora planet? Maybe creating a group for people that wish to add their blog on Fedora Planet would help to improve the security about the last one?
The container build also needs some improvement, as Pluto breaks due to the misconfiguration of some feeds, such as "error: This is not well-formed XML Missing end tag for 'meta' (got 'head')" and "error: undefined method `rss_version' for nil:NilClass". Maybe adding a condition in that Python script checking those feeds would solve it. Additionally, due to queries to FasJSON, Kerberos login is required. Probably, there will be a service account to automate this process for prod, but for now during container build in CommuniShift, I don't know how to automate this part.
Thank you in advance for your time, and looking forward to your suggestions.
Best regards,
Pedro Moura
On Sat, Jan 21, 2023 at 12:09:34AM -0000, Gerard Ryan wrote:
> Hi Kevin,
Hello.
> I have been helping Pedro a little with this (and will try to continue to do so, if I can).
Great!
> > I finally got around to trying this... and I couldn't quite get it
> > working.
> >
> > It built ok, but then I ran it and got the default httpd web page on
> > port 80. Is the content under something ?
> >
> > Likely it's me not being very container savvy... but perhaps you could
> > go through the steps again on how to build/run it and where the content
> > will be?
>
> Hmm, I know I made some Dockerfile changes, but the following works for me, and brings me straight to a working instance of the planet site:
>
> podman build -t fedora-infra/planet:dev . && \
> podman run --rm -it -p 8080:80 fedora-infra/planet:dev && \
> xdg-open http://localhost:8080
Huh. Now this works here too... I am not sure what I did wrong. ;(
> Are you sure that you're looking at port 8080 in your browser, or might you be looking at port 80, and somehow have httpd running separately from the container? Otherwise, it sounds like something has gone wrong during your "podman build" step. If you hit that problem again, could you upload the image that you built to quay.io or somewhere like that, and the build logs to somewhere that I could see them too?
Yeah, I was definitely looking at 8080... not sure. ;(
> > But yeah, given that you have it pulling things, we should definitely
> > look at bringing it up in staging so everyone can help out and check it.
>
> +1, it would be great to get it coughing and wheezing in staging to get eyes on it. There are a few things that I think still need to be done to make it great. For example, I don't think the build-planets.sh should be run as part of the image build. Assuming this will run in an OpenShift/k8s cluster, I think we'd be better off looking at something like a pod with 2 containers with a shared persistent volume: one container would run httpd, serving the planet from that disk (read-only), and the other would periodically run the script to scan the feeds and update the contents on disk.
Yes, I think that model is right...
> Where would the best place to create such tasks/proposals be...issues in that GitHub project? It's been quite a while since I've been involved in anything around Fedora, so I'm not really sure how/where things are done nowadays!
So, I talked with Pedro last week and we thought setting up a
communishift instance for this would be a good first step. You all can
then get it all working as you like in openshift there and then
exporting the config to staging should be easy. :0)
I setup Pedro as manager of the communishift-planet group, so he should
be able to add you and then you should have access to the project.
Thats to you (and Pedro!) for working on this.
kevin
_______________________________________________
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, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
