Commit 197198fa authored by Plup's avatar Plup

docs: changed the issue template for new instances

parent 03fe360c
# New instance to deploy
Configuration of deployed instances can be inspect [here](https://git.startinblox.com/infra/platform/blob/master/inventory/prd/apps.yml)
Keep in mind that an instance is actually 2 servers with different hostnames:
## App parameters
* one called `API` to serve the data
* and one called `client` which allows us to download the application itself
* app address: `<example>.startinblox.com`
* title:
* logo:
* favicon:
## Define your hostnames
## Requested services
For example with an `<example>` application name:
* [x] server address: `api.<example>.startinblox.com`
* [ ] email
* [ ] matomo
* [ ] xmpp with domain: `<example>.startinblox.com`
* for `API`: `<example>.startinblox.com`
* for `client`: `api.<example>.startinblox.com`
## Requested bloxes
The Startin'blox managed domains are `startinblox.com` (the default) and `hubl.world` (reserved for FNK).
* [x] international
* [ ] registering
* [ ] account
* [ ] notification
* [ ] admin
* [ ] about
* [ ] communities
* [ ] dashboard
* [ ] profileDirectory
* [ ] jobBoard
* [ ] projects
* [ ] invoice
* [ ] contact
* [ ] circles
* [ ] conversation
* [ ] uploader
* [ ] skill
* [ ] chat
* [ ] analytics
## Specific requirements for bloxes
### Special requirements for external domains
## Environments
Instances using external domains (domains not managed by Startin'blox) require a technical configuration from the client.
* [ ] development
* [ ] staging
* [ ] production
For example, if your client wants something like `example.org` and `api.example.org`:
## Federation
1. First you need to ask devops to provide you 2 internal adresses like:
* `example.startinblox.com`
* `api.example.startinblox.com`
2. In return you'll have the DNS configuration the client needs to implement himself. Something like:
```
example.org. IN CNAME example.startinblox.com.
api.example.org. IN CNAME api.example.startinblox.com.
```
One of:
Once the client did the work, we can deploy using the proper domains.
* [ ] hublworld
* [ ] hublunderworld
* [ ] standalone (not federated)
`/!\`: A domain used for a Startin'blox application can't be used for something else. So in this example, `example.org` wouldn't be available for a website or a blog. It's common to use `app.example.org` for the `client` hostname in case the root domain is reserved for another usage. But you can come up with whatever suits you.
If it requires a new custom federation:
## App parameters
* name: `just a disambigous name for our usage`
* title: `the displayed title for the client`
* logo: `the client logo`
* favicon: `same as logo ?`
* federation name:
* other instances to move in:
To plup: to convert logo use `curl -L https://cdn.shortpixel.ai/spai/w_260+q_lossy+ret_img+to_webp/<url of the image> -o logos/webp/<app>_logo.webp`
## Requested bloxes
* [x] jobBoard
* [x] projects
* [x] invoice
* [x] circles
To plup: it seems `jobboard` and `projects` can't be disabled in many cases, use `route: false` if not wanted.
## Environments
* [x] staging
* [x] production
New applications should always come with both.
## Federation
## Update startegy for standalone or custom federation
This should be a list of other instances to federate with:
* [ ] My app should be updated along with `hublworld` and `hublunderworld` (`/!\` only possible if they have the exact same bloxes configuration)
* [ ] I want to control the deployment process (should also come with a staging instance)
* ...
* ...
## Comments
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment