Add an app identifier if there is no domain when listing apps #636

New Issue

ammaratef45 · 2024-08-14T15:49:35Z

ammaratef45 commented

2024-08-14 15:49:35 +00:00

Some recipes like backup-bot-two don't have a domain because they won't be accessible by the internet.

We need abra to be able to list what domain to use when managing this app though. When running abra app ls the app shows without a domain

% abra app ls
+----------------+----------------------------------+
|     RECIPE     |              DOMAIN              |
+----------------+----------------------------------+
| backup-bot-two |                                  |

If I don't remember what domain I used to create the app I will have to figure it out by running ls .abra/server/<server> and finding the folder name.

It would be nice to have abra ls show that instead of having to run ls.

% abra app ls

+----------------+--------------------------------+-------------+
|     RECIPE           |          Identitfier                            | is_domain?   |
+----------------+--------------------------------+-------------+
| backup-bot-two |  backup-bot-two.example.com  | No                 |

(sorry for the poor table formating)

Some recipes like `backup-bot-two` don't have a domain because they won't be accessible by the internet. We need abra to be able to list what domain to use when managing this app though. When running `abra app ls` the app shows without a domain ``` % abra app ls +----------------+----------------------------------+ | RECIPE | DOMAIN | +----------------+----------------------------------+ | backup-bot-two | | ``` If I don't remember what domain I used to create the app I will have to figure it out by running `ls .abra/server/<server>` and finding the folder name. It would be nice to have `abra ls` show that instead of having to run ls. ``` % abra app ls +----------------+--------------------------------+-------------+ | RECIPE | Identitfier | is_domain? | +----------------+--------------------------------+-------------+ | backup-bot-two | backup-bot-two.example.com | No | ``` (sorry for the poor table formating)

👀 1

ammaratef45 added the

enhancement

label 2024-08-14 15:49:35 +00:00

ammaratef45 referenced this issue from coop-cloud/backup-bot-two

2024-08-14 15:53:10 +00:00

Update .env.sample #55

decentral1se added

bug

abra

and removed

enhancement

labels 2024-08-14 21:17:19 +00:00

moritz commented

2024-08-15 10:07:10 +00:00

I would propose to use the appname (.env file name) as identifier instead of the domain. Or maybe only as fallback if the domain is not available. In the current implementation the appnames equals the domain per default, but it's still possible to rename the .env file to change the appname.

❤️ 2

ammaratef45 commented

2024-08-15 21:16:56 +00:00

I would propose to use the appname (.env file name) as identifier instead of the domain.

I like this idea

> I would propose to use the appname (.env file name) as identifier instead of the domain. I like this idea

decentral1se referenced this issue from coop-cloud/backup-bot-two

2024-11-08 21:12:18 +00:00

Abra app ls output is confusing #68

fauno commented

2024-11-09 13:43:59 +00:00

I would propose to use the appname (.env file name) as identifier instead of the domain.

This but also consider them "internal" apps? Like in the third column of the proposed table, but as a secondary table could work too, so they're very distinctly separated.

> I would propose to use the appname (.env file name) as identifier instead of the domain. This but also consider them "internal" apps? Like in the third column of the proposed table, but as a secondary table could work too, so they're very distinctly separated.

❤️ 1

decentral1se referenced this issue from coop-cloud/backup-bot-two

2024-11-10 22:32:55 +00:00

Abra app ls output is confusing #68

decentral1se commented

2024-12-26 19:02:57 +00:00

@moritz @ammaratef45 @fauno Slightly off-topic but also not. I was thinking of even deprecating the <domain> in the CLI usage docs and using instead <app>? WDYT? Related coop-cloud/abra#452

@moritz @ammaratef45 @fauno Slightly off-topic but also not. I was thinking of even deprecating the `<domain>` in the CLI usage docs and using instead `<app>`? WDYT? Related https://git.coopcloud.tech/coop-cloud/abra/pulls/452

👍 1

ammaratef45 commented

2024-12-29 05:47:32 +00:00

I like the idea of replacing domain with app

👍 3

3wordchant commented

2024-12-29 23:18:53 +00:00

... Slightly off-topic but also not. I was thinking of even deprecating the <domain> in the CLI usage docs and using instead <app>? WDYT? Related coop-cloud/abra#452

I think you convinced me out of this. Gotta try to be less presuasive 😁

What I remember / what I now think: "app name" is an extra concept, and it's not worth introducing it for the sake of the 1% (unscientific) of recipes which don't have a domain.

My suggestion for the issue at hand is to say "every recipe has to have a domain even if in some cases it's just an identifier".

> ... Slightly off-topic but also not. I was thinking of even deprecating the `<domain>` in the CLI usage docs and using instead `<app>`? WDYT? Related coop-cloud/abra#452 I think you convinced me out of this. Gotta try to be less presuasive 😁 What I remember / what I now think: "app name" is an extra concept, and it's not worth introducing it for the sake of the 1% (unscientific) of recipes which don't have a domain. My suggestion for the issue at hand is to say "every recipe has to have a domain even if in some cases it's just an identifier".

decentral1se commented

2024-12-30 00:27:09 +00:00

Oh yes, I remember that 😂 That seems like a reasonable take. I was also experimenting with just putting "N/A" in the cell for domain when not present 🤷 Unless I hear otherwise, I'll add this one to the pile to fix up.

~~decentral1se referenced this issue 2024-12-30 00:27:34 +00:00~~

`abra` v0.10.x-beta release planning #583

ammaratef45 commented

2024-12-30 05:28:37 +00:00

app name is not that of an extra concept, a bunch of recipe use that word either instead of domain or exchangeable with domain in their documentation and comments

─    ~/.abra/recipes ······················································································································ 2|0|0 ✔  at 21:26:52  ─╮
╰─ grep -i app_name **/* 2>/dev/null | cut -d ":" -f 1 | cut -d "/" -f 1 | sort | uniq -c                                                                                 ─╯
  26 authentik
   5 backup-bot-two
   1 bonfire
   1 firefly-iii
   1 funkwhale
   2 gitea
   5 hometown
   1 kimai
   1 levelfly
   8 mastodon
   2 matrix-synapse
   1 miniflux
   6 nextcloud
   3 pixelfed
   2 xwiki
   3 zammad

app name is not that of an extra concept, a bunch of recipe use that word either instead of domain or exchangeable with domain in their documentation and comments ``` ─    ~/.abra/recipes ······················································································································ 2|0|0 ✔  at 21:26:52  ─╮ ╰─ grep -i app_name **/* 2>/dev/null | cut -d ":" -f 1 | cut -d "/" -f 1 | sort | uniq -c ─╯ 26 authentik 5 backup-bot-two 1 bonfire 1 firefly-iii 1 funkwhale 2 gitea 5 hometown 1 kimai 1 levelfly 8 mastodon 2 matrix-synapse 1 miniflux 6 nextcloud 3 pixelfed 2 xwiki 3 zammad ```

👀 1

fauno commented

2024-12-30 14:46:49 +00:00

I agree using app name may be less confusing if you mean:

Changing the column header from "DOMAIN" to "APP"
Using app name instead of domain as the column cells

But I'd still like to have a clear separation of which apps are publicly accesible (pass a domain check, have an URL I can open on a browser) and which are not. AFAIK only backup-bot-two is an internal app? I'd be happy if it shows a status page when I open https://backup-bot-two.server.org :B

I agree using app name may be less confusing if you mean: * Changing the column header from "DOMAIN" to "APP" * Using app name instead of domain as the column cells But I'd still like to have a clear separation of which apps are publicly accesible (pass a domain check, have an URL I can open on a browser) and which are not. AFAIK only backup-bot-two is an internal app? I'd be happy if it shows a status page when I open https://backup-bot-two.server.org :B

3wordchant commented

2025-01-01 00:28:58 +00:00

@ammaratef45 fair point, there's probably some dangling inconsistency from when this conversation was had before. I think we should change all the references to app_name to domain.

As far as I know the only recipes which do not have a domain (that is, fully-qualified domain name) are:

backup-bot-two
swarm-cronjob (is anyone else except me / Autonomic using this?)
renovate-bot (is anyone using this?)
Traefik, if dashboard is disabled and/or HEADLESS=1

What I mean by "extra concept" is that currently abra just asks for "domain" during app new.

If we asked for "app name" as well (like we used to), that's two decisions everyone now has to make for about naming, for all apps they deploy.

And it seems to me that's question would mostly be a confusing waste of users' time, given that the other ~155 recipes don't need it.

It seems much more reasonable – if possibly a little silly – to say that all apps need a domain, even if it's an identifier, so backup.example.com doesn't resolve to anything.

Alternatively, as a more-correct, more-work second option I would suggest saying every Co-op Cloud app has to have a domain because it has to have at least one webpage. Then we add a basic "it works" HTML page to the above 4 recipes.

@ammaratef45 fair point, there's probably some dangling inconsistency from when this conversation was had before. I think we should change all the references to `app_name` to `domain`. --- As far as I know the only recipes which do not have a domain (that is, fully-qualified domain name) are: - backup-bot-two - swarm-cronjob (is anyone else except me / Autonomic using this?) - renovate-bot (is anyone using this?) - Traefik, if dashboard is disabled and/or `HEADLESS=1` What I mean by "extra concept" is that currently `abra` just asks for "domain" during `app new`. If we asked for "app name" as well (like we used to), that's two decisions everyone now has to make for about naming, for all apps they deploy. And it seems to me that's question would mostly be a confusing waste of users' time, given that the other ~155 recipes don't need it. It seems much more reasonable – if possibly a little silly – to say that all apps need a domain, even if it's an identifier, so `backup.example.com` doesn't resolve to anything. --- Alternatively, as a more-correct, more-work second option I would suggest saying every Co-op Cloud app has to have a domain because it has to have at least one webpage. Then we add a basic "it works" HTML page to the above 4 recipes.

decentral1se referenced this issue from a commit

2025-01-03 07:24:41 +00:00

refactor!: maintain "domain"

moritz commented

2025-01-06 11:29:25 +00:00

Alternatively, as a more-correct, more-work second option I would suggest saying every Co-op Cloud app has to have a domain because it has to have at least one webpage. Then we add a basic "it works" HTML page to the above 4 recipes.

From a security perspective I don't like the idea that the backup bot is reachable from the outside. It should not expose anything to the internet. But maybe this can be solve directly inside of traefik? So traefik will expose a "it works" status HTML page for apps that are running but not exposing any ports?

> Alternatively, as a more-correct, more-work second option I would suggest saying every Co-op Cloud app has to have a domain because it has to have at least one webpage. Then we add a basic "it works" HTML page to the above 4 recipes. From a security perspective I don't like the idea that the backup bot is reachable from the outside. It should not expose anything to the internet. But maybe this can be solve directly inside of traefik? So traefik will expose a "it works" status HTML page for apps that are running but not exposing any ports?

👍 1

Sign in to join this conversation.

5 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/organising#636