On Wed, Apr 05, 2023 at 07:04:54PM -0300, Pedro Moura wrote: > Dear colleagues, > > I would like to share some updates and ask for suggestions regarding the > Fedora Planet. Hey Pedro. Thanks for updating everyone. :) > 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? I'm interested to hear from others if those subplanets are much used anymore. :) IMHO, we should probibly just try and make things as simple as possible to start with. I'd say we could even drop the subplanets unless people are really using them/expecting them anymore. But I guess lets see? Is the current url available to look at? Just to see what it looks like as a test? > 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 Yeah, the current planet script gets a ton of errors from places. It's pretty anoying. We definitely need to handle errors by passing on to the next feed when we get them or something. > 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. Yeah, in real clusters we can just have ansible get a service keytab for that, but there's no easy way to do that in communishift. > > Thank you in advance for your time, and looking forward to your suggestions. Thanks for bringing things up. I'm hoping for more input too... kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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