Summary

Deploy a simple django application on Openshift Online using the free tier.

Background

Openshift Online is a container management service, based on Openshift and Kubernetes. The service offer a free tier for testing purpose, and would be the same environment where we would deploy the badgr system during the internship.

Details

Complete the following steps:

• Open a trial account on the service
• Download the openshift-client binary based on openshift.com instruction
• Deploy a basic django application (just a hello world).
• Take a screenshoft of the output of oc get pods when the application is running and post it on this issue

Outcome

• Working hello world application
• Successful understanding how to do basic tasks on Openshift

Note: This issue will remain open until the end of the Outreachy 2020 application phase. This ticket does not require an assignee to work on this task – it can be repeated by anyone.

Summary

Run a local instance of badgr, and check the different features we were looking to add to see which are already implemented in the new system.

Background

Badgr is the application we want to use to replace the current system. This is a django application and can be run locally. It do requires a few others component, so a Linux VM would be needed.

We did write last year a set of features and general improvements we wanted on the bugs tracker of the current system.

Some of the issues are related to the deployment, some around the general process, some could be fixed by code, some are not.

Details

Complete the following steps

• Get a Linux system (a VM would be perfect for that, ideally Fedora)
• Run a local instance of badgr from git, nothing fancy needed since that's just for tests.
• Look the issues from the bug tracker
• Tell which are obsolete once the new system is deployed, by commenting with a screenshot if needed to show that's a feature that already exist. No need to do all of them, a few 2/3 will be enough.

Outcome

• Working local badgr instance
• Better understanding of what we want with badgr and the architecture

Note: This issue will remain open until the end of the Outreachy 2020 application phase. This ticket does not require an assignee to work on this task – it can be repeated by anyone.

Summary

Install fedora-messaging and publish a test message

Background

fedora-messaging is like a live feed of the Fedora Project. Different kinds of contribution activities are registered in the fedora-messaging bus. This allows an application to publish a message that triggers an application somewhere else in Fedora, like awarding a new Fedora Badge.

fedora-badges receives and publishes messages to the Fedora Infrastructure fedora-messaging bus. Understanding how fedora-messaging works is useful to understand for future development work.

Details

Complete the following steps:

• Install fedora-messaging on your device
• Set up fedora-messaging in new test project
• Write script to publish a test message

Use the fedora-messaging documentation for guidance. You can post a screenshot of running your test script here in the ticket when you're done! 💻 📷

Outcome

• Working fedora-messaging installation
• Successful understanding how to publish a message to fedora-messaging bus

Note: This issue will remain open until the end of the Outreachy 2020 application phase. This ticket does not require an assignee to work on this task – it can be repeated by anyone.

Right now, the sysadmin of tahrir do get mailed on a regular basis with error about: OperationalError: (TransactionRollbackError) deadlock detected

Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/fedbadges/consumers.py", line 232, in consume
    self.award_badge(recipient, badge_rule, link)
  File "/usr/lib/python2.7/site-packages/fedbadges/consumers.py", line 166, in award_badge
    self.l.tahrir.add_assertion(badge_rule.badge_id, email, None, link)
  File "/usr/lib/python2.7/site-packages/tahrir_api/utils.py", line 10, in _wrapper
    result = func(self, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/tahrir_api/dbapi.py", line 924, in add_assertion
    self._adjust_ranks(person, old_rank)
  File "/usr/lib/python2.7/site-packages/tahrir_api/dbapi.py", line 952, in _adjust_ranks
    self.session.flush()
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py", line 1919, in flush
    self._flush(objects)
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py", line 2037, in _flush
    transaction.rollback(_capture_exception=True)
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/util/langhelpers.py", line 60, in __exit__
    compat.reraise(exc_type, exc_value, exc_tb)
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py", line 2001, in _flush
    flush_context.execute()
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/orm/unitofwork.py", line 372, in execute
    rec.execute(self)
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/orm/unitofwork.py", line 526, in execute
    uow
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/orm/persistence.py", line 60, in save_obj
    mapper, table, update)
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/orm/persistence.py", line 518, in _emit_update_statements
    execute(statement, params)
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 729, in execute
    return meth(self, multiparams, params)
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/sql/elements.py", line 322, in _execute_on_connection
    return connection._execute_clauseelement(self, multiparams, params)
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 826, in _execute_clauseelement
    compiled_sql, distilled_params
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 958, in _execute_context
    context)
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1159, in _handle_dbapi_exception
    exc_info
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/util/compat.py", line 199, in raise_from_cause
    reraise(type(exception), exception, tb=exc_tb)
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 951, in _execute_context
    context)
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/default.py", line 436, in do_execute
    cursor.execute(statement, parameters)
OperationalError: (TransactionRollbackError) deadlock detected
DETAIL:  Process 6924 waits for ExclusiveLock on tuple (1201,83) of relation 2860724 of database 16454; blocked by process 17757.
Process 17757 waits for ShareLock on transaction 2885771372; blocked by process 6924.
HINT:  See server log for query details.
 'UPDATE persons SET rank=%(rank)s WHERE persons.id = %(persons_id)s' {'persons_id': 86, 'rank': 23}

My analysis of the issue lead me to believe this is caused by concurrent access. While tahrir have safeguard for that, we have several cronjob that do run at random time that also award badges, and who would lock the same table, but outside of the fedbadge in process transaction manager (the transaction object as seen here: https://github.com/fedora-infra/fedbadges/blob/develop/fedbadges/consumers.py#L154 ).

Since the rank is currently stored in the DB per user, it need to be updated each time someone get a badge, and updated for everybody (if I go from rank 20 to 10, people between 20 and 10 might need to be changed). This likely create too much contention due to performance issue.

So for the new system, I would propose that we spin the leaderboard part in a separate process (like a specific REST based micro services) instead of writing the info in the database.

The new process would just compute the leaderboard as needed, and cache it, and serve the information over a REST API in json. Since the rank computation would be done by a separate process asynchronously, this would let the transaction be blocking for a shorter time.

This would bring a few benefts

• Since awarding a badge wouldn't write anything but 1 line, this wouldn't trash pg cache/index, which mean less recomputation later.

• Better parallellism, since now, awarding a badge would lock the table less often, since that's just adding 1 row (instead of locking X rows to update the rank)

• that part of the code is ressources expensive, according to comments (https://github.com/fedora-infra/tahrir-api/blob/develop/tahrir_api/dbapi.py#L993-L1011). Having it in a separate process mean that it will be easier to profile and tune, or, if needed, rewrite it in a faster language than python if that's a bottleneck.

• the rendering of the leaderboard could be pushed to browsers, who would just fetch it in json directly. This could mean less CPU usage on our side and less netwrok usage, even if that's likely negligeable. But since badgr-ui is using angular, I suspect in browser rendering would go well with that.

On the other hand:

• that mean we start to do microservices, and that's maybe overkill. If we deploy badgr on openshift/kubernetes, that would lessen the pain of managing that, but maybe this is over engineering for more traditional users.
• maybe badgr already solved that problem. I did check quickly for leaderboard/ranking and found nothing, but I just did a quick grep of the code, so I would need to check more details.
• current notification do tell which rank you are when you get a badge. That mean the message need to be sent once the leaderboard have been recomputed. Doing this asynchronously mean that the new leaderboard service would need to send the information somehow.