#8291 Fedora messaging - Translation platform topics review
Opened 3 years ago by jibecfed. Modified 15 days ago

Our future translation platform will send to fedora messaging.

The Weblate dev, Michal Čihař, did this: https://github.com/WeblateOrg/fedora_messaging/

He says: "Also it would be great if somebody would review the payload and topics if those make
sense, because I have no clue how those things are going to be used."

As I never used the Fedora messaging and as I'm not a dev, I don't feel like I can assume this task. Who can give it a look?

I think the question is: what do you want to use these notifications for?
Answering this question should help you figure out if the messages have the content you need.

I don't think infra has anything scheduled at this time around weblate, so I don't think we have an opinion at what the content of the notifications should be.

One thing you may want to discuss with upstream is adding message schema to their plugin: https://fedora-messaging.readthedocs.io/en/stable/messages.html#schema

(If it is already there, sorry for missing it :()

Thank you for your answer, my question was purely on technical aspect, such as the schema or naming rules. I think it's OK to close this if no other advice or issue identified.

On request of @bex here is a ping for @mattdm and @bcotton

In short: the weblate dev did the work to push the changes you can see here: https://translate.stg.fedoraproject.org/changes/ in our messaging infrastructure. The purpose of this is to be able to track Localization team activity using the tools we use the measure our community activity. The biggest volume is related to the number of translations, which also is the most interesting data.

In addition for infra team, the weblate dev says:

I don't think I can push directly to your infra, I probably need some
SSL cert and configuration to do that. The documentation [1] covers
consuming the events, but doesn't speak about what is needed for
publishing to your infra.

[1]: https://fedora-messaging.readthedocs.io/en/stable/fedora-broker.html

That is correct, we'll have to provide them with an SSL cert so they can published on the bus.

@jibecfed Can the folks at weblate provide the following in their repo's README:

  • Several example messages
  • A guide to the values that will appear in the action field and a list if it is reasonable to be exhaustive.

Can you:

  • Verify the following have specific meaning in weblate and are well understood:
    • url
    • project
    • component
  • Verify both of these represent FAS IDs?
    • author
    • user

I think this will allow us to understand the review request.

thanks Bex.

I confirm url, project and component are standard items from Weblate. I explicitly asked to have these.

With current configuration, user will always be a user existing in FAS. I'll check with Weblate folks if we it's indeed the FAS ID and not something else.
Author may be unknown if we accept non logged user to suggest an improvement.

It is possible in Weblate to allow other connection methods than FAS. I'm unsure we'll enable these someday, but if we decide to do so, user value may vary.

Metadata Update from @kevin:
- Issue priority set to: Waiting on Assignee (was: Needs Review)

3 years ago

example were added, please give your feedback: https://github.com/WeblateOrg/fedora_messaging/

In the example the dev added, three are technical, three are functional, but I assume there will be many more.

Here is my opinion on how we may use it.

  • Repository merge event, new source string event and Resource update event are technical indicator, useful for debugging in our early adoption and every once in a while afterwards.
    • May be useful to track upstream issues with po files: when we suddenly have a lot of translation to do for an already translated project, it means something went wrong, it's what happening now with REHL, French team went from 1000 words to 60 000 words to translate, but I can't investigate...
  • Project removal event: functional indicator, useful for public stats (I assume project creation is also in the list of events)
  • New contributor event: functional indicator, useful for welcoming newcomers and to monitor community health
  • New translation event: functional indicator, useful to monitor community health and provides badges to contributors

@pingou I think we won't have any other feedback, could you please tell me what is the procedure to allow Weblate team to publish events in our infrastructure?

best wishes for 2020!
@pingou, @abompard may you help here to allow the publication of messages?

Best wishes, @jibecfed !
I think the messages look fine, I spotted one small possible improvement in the code: instead of catching PublishReturned in tasks.py:77, you should catch PublishException, as it will cover more cases.

Is weblate deployed within the Fedora infra? I don't find any reference to it in our ansible repo.

Weblate is hosted by the Weblate company.
URL is: https://translate.stg.fedoraproject.org/
production URL will be https://translate.fedoraproject.org/
I'll open a ticket soon to ask for redirection

@jibecfed is anything more that needs to be done in this ticket ? or can we close it ?

Yes, same question again: how to publish the messages?

Yes, same question again: how to publish the messages?

@abompard it is possible to publish messages using the public amqp endpoint ? We need to provide a specific cetificate for that ?

We need to provide a specific cetificate for that ?

Yes we do and we then run into: https://pagure.io/fedora-infrastructure/issue/8167

any news on this subject? when will it be possible for an outside tool to publish on our infrastructure? It's been seven months now, and I would like to have badges for localization community.

Seems 8167 is being fixed slowly with the move to the new DC.

kind remember, do we have progress on this request?

Metadata Update from @smooge:
- Issue tagged with: dev, medium-gain, medium-trouble

2 years ago

Metadata Update from @smooge:
- Issue untagged with: dev
- Issue tagged with: ops

2 years ago

It looks like there has been some progress on #8167 in the last week or so.

also added this issue as blocking this issue, to keep them linked.

So, this is still blocked on the #8167 thing which is blocked on ansible upgrade which is hopefully happening this year.

@jibecfed But, to make sure: do you still want/need this? Or did you work around it some other way?

This is still blocked, hopefully it's still wanted. :)

[backlog refinement] This is still blocked by #8167. We want to start working on ansible upgrade soon after it will be available in RHEL8.

hello, yes this is still a wanted feature, this should allow badges for fed=
ora contributors (and other yet unknown usages)

[backlog refinement]

This may be unblocked now due to an upgraded version of the rabbitmq collection on batcave01 but some investigation will be necessary.

Metadata Update from @kevin:
- Issue tagged with: blocked

a year ago

There seems to be some kind of solution from @abompard in https://pagure.io/fedora-infrastructure/issue/8167 Does this help to unblock this ticket?

[backlog refinement]

This may be unblocked now due to an upgraded version of the rabbitmq collection on batcave01 but some investigation will be necessary.

How can the L10N team help with the investigation?

There seems to be some kind of solution from @abompard in https://pagure.io/fedora-infrastructure/issue/8167 Does this help to unblock this ticket?

I'm afraid we, the L10N team, don't know if it does help. Who could know that? Or how we could know/learned that?

Could also someone shed some light on if and how this issue is or may be affected (in terms of possible implementation) by the present work on FMN?

@abompard Are you able to answer @peartown question?

@abompard Are you able to answer @peartown question?

Hey @peartown! The new FMN allows publishers (apps) to define what how they want the notifications to look like. To take advantage of it, you need to create a schema in a separate Python package (I recommend using a separate git repo for it). Then you can define the summary property and the string representation of the message, and they will be used in the notifications. Other properties control when the notifications are emitted, it's all in the docs.
Once that's done, just add this new package as a dependency of your fedora-messaging plugin and instanciate your schema classes instead of the generic Message class.

Feel free to ping me in #fedora-apps if you have questions!

Login to comment on this ticket.

Boards 1
ops Status: Backlog