Website : linking with frontend & backend #12
Labels
No labels
backend
billing
bug
duplicate
enhancement
frontend
gitpad
help wanted
invalid
operations
priority-1
priority-2
priority-3
question
shared hosting
User Research
wontfix
No milestone
No project
No assignees
2 participants
Total time spent: 5 hours
Due date
dachary
3 hours
realaravinth
2 hours
No due date set.
Dependencies
No dependencies set.
Reference: Hostea/july-mvp#12
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Here is the basic logic for the backend to communicate with the frontend. We discussed using webhooks as a way to trigger actions in the backend but we did not discuss what these webhooks should do. The section below, "Updating the Gitea instances", explains what they need to do, ultimately.
If the frontend triggers a webhook, it needs to send information via JSON, the script watching the webhook then receives the JSON, parses it, writes YAML files that are meaningful to Ansible and then calls Ansible to interpret these YAML files and create/update/destory the Gitea instances.
Alternatively, the frontend could write the YAML files directly and call Ansible which would save steps and there would be no need to define an intermediary JSON format that has no purpose.
If that makes sense to you, the next step will be for me to document which YAML files must contain what so the frontend can create them to reflect the state of the Gitea instances controled by a given user.
Updating the Gitea instances
The creation, update and deletion of a Gitea instance is done by running ansible with a set of variables. The frontend needs to create files that contain these variables. For instance changing
gitea.yml
from:to
Will upgrade the gitea instance to version 1.16.4 the next time Ansible runs. The frontend should not run Ansible directly though but use the enough command line instead: it wraps Ansible with sensible defaults.
Getting information about the Gitea instances
All Gitea instances are monitored individually by Icinga. In addition, the icinga probes archive values in an influxdb database which linked with grafana. To get information about an instance, the frontend can:
It can then populate a dashboard displayed to the user when it is logged in, with all informations regarding the past and present resources it rented.
By "frontend" I'm assuming you are talking about the payments software and the "backend" is the lifecycle software.
I understand that the lifecycle can be handled entirely by the payments server, but I would prefer to keep the payments server as lean and as generic as possible. Also, I prefer to JSON for all communications involving the payments server. Adding YAML would mean maintenance overhead.
I was under the impression that payments would run at payments.example.com and the lifecycle backend at dash.example.com. This way, the user will interact with the payments software only for payments. If the functionality can't be implemented within the lifecycle backend, then I propose that we create a separate dashboard program.
Billing : linking with website & devops backendto Website : linking with website & devops backendWebsite : linking with website & devops backendto Website : linking with frontend & backendRegarding how the frontend sends instructions to the backend, here is how we will move forward:
(i) I'll document the files the frontend needs to produce and their semantic,
(ii) you make it so the frontend creates those files to reflect what the user wants
(iii) I'll make it so those files are acted upon.
In other words I'll make it so you don't need to understand the underlying Ansible logic but that it is really equivalent to sending a payload to a webhook that says: "create this VM with this amount of ram and run gitea + ci on it". Only it's not a webhook, it's a plain file
For the record we clarified the website / devops / billing relationship: website + billing are part of the "frontend" and the "website" label was renamed "frontend". The "devops" label was renamed "backend" and is about everything needed to run the infrastructure, based on enough.community.
@realaravinth thanks for your patience, this was rather confusing and I feel we now have clarity on how the pieces fit together.
https://icinga.hostea.org is up and has icinga + grafana + influx DB
To create a new instance named
foobar-host
, the following file must be added to~/.enough/hostea.org/inventory/host_vars/foobar-host/gitea.yml
file, with the values of the variable set according to the user preferences.The size of the VM hosting the gitea instance is set in the
~/.enough/hostea.org/inventory/host_vars/foobar-host/provision.yml
file:To delete an instance the
~/.enough/hostea.org/inventory/host_vars/foobar-host
directory must be removed and thefoobar-host
name added to the list of deleted hosts in the~/.enough/hostea.org/inventory/deleted.yml
file:This is necessary so that monitoring knows to delete all resources associated with
foobar-host
on the next update.