Page MenuHomePhabricator

Commit skeleton code for API Backend (FastAPI/Python3.7)
Closed, ResolvedPublic

Description

For the coding phase of GSoC, which starts on June 7th
We need to do a test commit to our repository bernard and following on, we will commit a skeleton code for the backend

Tasks

  • Test access to repo
  • Commit a skeleton code for API backend

Acceptance

  • Can access repo successfully
  • Skeleton code present in repo

I did some research and found out that the web framework FastAPI is a better option for creating APIs with Python and is more suited for the purpose.
(I've changed the title of the ticket accordingly)

Event Timeline

Change 698327 had a related patch set uploaded (by H.krishna123; author: H.krishna123):

[operations/software/bernard@master] [T284399] Perform first commit on operations/bernard repository, add .gitignore and README.md

https://gerrit.wikimedia.org/r/698327

I added you a comment asking you to amend the patch's commit message, more as a test than because an actual issue 0:-).

Thank you @jcrespo
I have made amendments to the commit message - let me know if that's okay
Do we need approval from jenkins-bot as well to merge? (I would have to setup tox config first)
How would one merge the changes? (I've got another patchset coming soon with the code skeleton)

h.krishna renamed this task from Commit skeleton code for API Backend (Flask/Python3.7) to Commit skeleton code for API Backend (FastAPI/Python3.7).Jun 15 2021, 12:41 AM
h.krishna updated the task description. (Show Details)

For jenkins-bot to run unit tests or other tasks, we need to add them to the Continuous Integration Wikimedia repo. I don't have write rights there, but anyone, including you, can submit a patch for review. This is for example, the config for last year's GSOC: https://phabricator.wikimedia.org/rCICF7a9b4f07332cd91daa4fc646e9fdf54ca90c8631

And this is how later we setup automatic doc publishing: https://phabricator.wikimedia.org/rCICFef290d413d80e6abe8e377359f79f1ad8908691a

But the important stuff is that we have unit tests (at the very least, able to run locally). Let's send a patch to make jenkins run automatically when you have at least one merged unit tests.

Okay, that sounds good. Once we have some unit tests in, I will start the work to setup tox for our projects. Thanks for the information

Looks like Gerritbot hasn't posted it here due to some reason but I've uploaded a different patchset for the backend skeleton code (I wonder if I am doing something wrong)
https://gerrit.wikimedia.org/r/c/operations/software/bernard/+/699915
Please have a look when you have the time, and let me know your thoughts
Alternatively we can go through it during the planned meeting this week

Looks like Gerritbot hasn't posted it here due to some reason

@h.krishna: See https://www.mediawiki.org/wiki/Gerrit/Commit_message_guidelines - there's an empty line between Bug: and Change-Id:

Change 699915 had a related patch set uploaded (by Aklapper; author: H.krishna123):

[operations/software/bernard@master] api_db: Add working skeleton code for api_db, add dockerfile

https://gerrit.wikimedia.org/r/699915

Ah very good spot, I will be a bit careful with that next time, thanks @Aklapper

This is the documentation for k8s wmf monitoring: https://wikitech.wikimedia.org/wiki/Streamlined_Service_Delivery_Design#Supporting_monitoring,_health_checks

I have to ask about the service-checker part, as cannot find documentation about it.

Change 699915 merged by Jcrespo:

[operations/software/bernard@master] api_db: Add working skeleton code for api_db, add dockerfile

https://gerrit.wikimedia.org/r/699915

Some production logging advice is at:
https://wikitech.wikimedia.org/wiki/Logstash/Interface

But give this is probably going to be a webservice behind apache, apache configuration will solve that, and you only have to care to loging to apache's error output, I think.

Thank you, will have a look and will design it accordingly.

Actions from me (putting it here so that I remember even if I close this ticket)

  • Will create a ticket for implementing the logger functionality in accordance with the JSON format mentioned in the above (for our own app logs)
  • Will have a look at the K8s log standards, see if there's something we need to add. We have a basic liveness/readiness endpoint for now, I think that should do for now but will have a look
  • Dockerfile, in future make it import from a private container registry rather than a public one (for security). For developer use, this is fine for now

I believe this ticket meets the following acceptance criteria as mentioned in task, therefore will close it soon. Thanks for your review :)

Acceptance

Can access repo successfully
Skeleton code present in repo

I believe this ticket meets the following acceptance criteria as mentioned in task, therefore will close it soon

We don't need to be super formal in terms of ticket aproving/closing. Tickets are mostly for your organization (also for us to communicate with you and know what you are working currently, etc.). Feel free to resolve them yourself as you see fit. In the odd case we disagree, we can always reopen :-).

Thank you for your work on this! :-)

Perfect, sounds great, no worries and thanks again for your guidance