-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does anything other than datagrepper use the datanommer models API directly #151
Comments
Yeah, the badges do connect to the datanommer db directly using the models. We'll need to update this piece of code too. |
So did a little digging into this, and it appears that FMN also uses datanommer.models, but these are the only two i could find that use the database models directly. Both these applications seem to only use the grep method in datanommer.models, which is a good thing, as the API for this method has not changed, so we shouldnt need to change code in badges or fmn. We likely will need to update these applications to use the newest version of datanommer.models which shouldnt be a big issue. Notes on where these two applications use datanommer.models are detailed below: Fedora BadgesIt appears that Fedora Badges is using the datanommer.models "grep" function in fedora-infra/fedbadges , which is the consumer that reads the message queue and awards the badges. AFAICT, datanommer.models is initted here: and the grep method called in these two spots:
FMNdatanommer.models is initted here: and the grep method used once here: |
OK, Working on getting badges working in staging to see if we can test this. |
Ok, so badges is running in staging -- kinda. The frontend is working -- but the backend fails awarding badges as it appears to stil interface with FAS2 (and there is no FAS2 for staging... so...) Anyway, long story short, we can still test out the new datanommer by changing the url on staging badges-backend (
and we get this error:
Which i guess is because we are running python2.7 on badges backend, and using python-datanommer-models 0.9.0 -- https://src.fedoraproject.org/rpms/python-datanommer-models (this is pulled in as a dep of python-fedbadges, which is the fedmsg backend consumer) |
However, this is where i stopped, as not sure what the best approach here is -- the two options i see are:
|
Another option would be to switch badges to use HTTP requests instead of using the models directly. |
Fedbadges (in the develop branch) was ported to python 3: fedora-infra/fedbadges@a3f2b03 However, I think no one really know how to do a release (especially since the CI was not working), and the plan was to just run it in a pod, with the HEAD version (since doing release for a custom software where we are the only user seems a bit overkill) I am not sure there is no need to port the whole stack, just fedbadges. |
@mscherer fedbadges / badges backend on fedora infra is currently in a VM (i.e. not in openshift) AFAICT should the badges team open a ticket to get a new VM set up for fedbadges like what was done in this ticket for FMN: https://pagure.io/fedora-infrastructure/issue/9746 from the datanommer side, once fedbadges is updated to python3, fedbages can use the newest version of datanommer.models, and that side of things should just work as it has in the past (the datanommer.models API fedbadges uses hasnt changed) |
okay, opened a infra ticket for this -- not really sure how to proceed though. |
The datanommer readme states that the majority of tools and applications interact with the datanommer db using datagrepper, with the exception of datagrepper itself, and fedbadges.
The questions here are:
The text was updated successfully, but these errors were encountered: