Garden tickets from coop-cloud/karrot#4 #522

New Issue

decentral1se · 2023-10-20T09:11:31Z

decentral1se commented

2023-10-20 09:11:31 +00:00

Don't have time now, let's not forget! Good usability stuff pointed out there.

Don't have time now, let's not forget! Good usability stuff pointed out there. https://git.coopcloud.tech/coop-cloud/karrot/issues/4

decentral1se added the

enhancement

help wanted

good first issue

labels 2023-10-20 09:11:31 +00:00

decentral1se commented

2023-10-20 12:45:19 +00:00

Moar:

a few random points/questions:

they will also explore moving their existing separate vps with wordpress over to co-op cloud, and maybe a custom php app they have (that uses karrot api)
mostly everything worked nicely
the hardest error was my mistake in not running abra recipe lint, and I accidently pushed a lightweight recipe tag, not an annotated one, so changed it, and force pushed it, and had to get them to abra recipe fetch karrot and force pull.... my mistake, would be useful to use something like pre-commit to enforce abra recipe lint on commit/push
as I think was in my comments in the issue the other day, would be nice if there was more reassurring status feedback, especially after initial deploy, as it looks like it's errored, but is just doing stuff, could just have longer timeout for starters? is that/could/shoudl it be configurable? (per recipie?)
on redeploys (and presumably upgrades), there is a bunch of different errors, saw 404s this time, maybe because healthchecks are not healthy, and it shows some default traefik thing? not sure... a nice page to show a friendly message that it's undergoing maintaince would be nice and more reassuring :)

Moar: > a few random points/questions: > > they will also explore moving their existing separate vps with wordpress over to co-op cloud, and maybe a custom php app they have (that uses karrot api) > mostly everything worked nicely > the hardest error was my mistake in not running abra recipe lint, and I accidently pushed a lightweight recipe tag, not an annotated one, so changed it, and force pushed it, and had to get them to abra recipe fetch karrot and force pull.... my mistake, would be useful to use something like pre-commit to enforce abra recipe lint on commit/push > as I think was in my comments in the issue the other day, would be nice if there was more reassurring status feedback, especially after initial deploy, as it looks like it's errored, but is just doing stuff, could just have longer timeout for starters? is that/could/shoudl it be configurable? (per recipie?) > on redeploys (and presumably upgrades), there is a bunch of different errors, saw 404s this time, maybe because healthchecks are not healthy, and it shows some default traefik thing? not sure... a nice page to show a friendly message that it's undergoing maintaince would be nice and more reassuring :)

decentral1se commented

2023-10-20 12:46:20 +00:00

re: confusion over domains (/cc @3wordchant)

i think it's back to the behaviour i expected: as long as foobar.com and somethingelse.com resolve to the same IP address, you can deploy an app with DOMAIN=somethingelse.com on a server called foobar.com without passing --no-domain-checks

re: confusion over domains (/cc @3wordchant) > i think it's back to the behaviour i expected: as long as foobar.com and somethingelse.com resolve to the same IP address, you can deploy an app with DOMAIN=somethingelse.com on a server called foobar.com without passing --no-domain-checks

nicksellen commented

2023-10-20 13:05:38 +00:00

One improvement which I'm not sure I mentioned clearly, but maybe did (sorry for scatter-gun feedback!) is about the secrets:

Ideal situation (I think) would be:

secrets can be marked as generated or user provided (I did mention that)
secrets can be marked as required or optional
when deploying abra prompts you appropriately, e.g.
- if a secret is missing, generated, and required -> go ahead and generate it
- if it's missing, user provided, and optional -> ask if the user wants to provide it (only on first deploy to not spam them on subsequent deploys)
- if it's missing, user provider, and required -> prompt them to input it and don't let them continue without
- missing, optional, and generated -> not sure... maybe ask individually on first run for each of them if they want it generated

One improvement which I'm not sure I mentioned clearly, but maybe did (sorry for scatter-gun feedback!) is about the secrets: Ideal situation (I think) would be: - secrets can be marked as generated or user provided (I did mention that) - secrets can be marked as required or optional - when deploying abra prompts you appropriately, e.g. - if a secret is missing, generated, and required -> go ahead and generate it - if it's missing, user provided, and optional -> ask if the user wants to provide it (only on first deploy to not spam them on subsequent deploys) - if it's missing, user provider, and required -> prompt them to input it and don't let them continue without - missing, optional, and generated -> not sure... maybe ask individually on first run for each of them if they want it generated

decentral1se removed the

good first issue

label 2024-11-26 11:03:10 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/organising#522