button works deployed

integrating this with tests like #323 needs a conscious approach on if/how to distinguish metadata from user input at the module interface.
currently, metadata has still been either hard-coded, or read in from files.

the place to deploy to would be required to test this tho, raising the question of whether to:

use TF object type inputs to group user input and a newly distinguished meta explicit input group. this would keep it clear on which part would be relevant for front-ends, all the more relevant since #285, but seems less elegant for cluttering the TF interface, as top level inputs get convenient interfaces such as -var and TF_VAR_*.
de-hardcoding metadata using alternate channels such as files and environment variables, as we may not need to otherwise expose make these in the first place:
- npins deps should not need to be pluggable, and originally were calculated within TF - since having been decoupled only as a performance improvement
- IPs eventually should not need setting, and are only still hard-coded until #113
- domains are similar as IPs there (#110)
- maybe misc stuff, see #314
for the moment exposing metadata needed for testing over the same interface as user input - temporarily inelegant for the purpose of visual demos, tho otherwise maybe offering a simpler approach (until #313) for testing purposes for facilitating grouping of metadata with service, while simultaneously perhaps being a bit more explicit about our technical debt.

for the purpose of testing this story (short of lumping all the further automation on), i feel option 3 may be the lesser evil for the moment.

integrating this with tests like #323 needs a conscious approach on if/how to distinguish metadata from user input at the module interface. currently, metadata has still been either hard-coded, or read in from files. the place to deploy to would be required to test this tho, raising the question of whether to: 1. use TF object type inputs to group user input and a newly distinguished meta explicit input group. this would keep it clear on which part would be relevant for front-ends, all the more relevant since #285, but seems less elegant for cluttering the TF interface, as top level inputs [get convenient interfaces](https://developer.hashicorp.com/terraform/language/values/variables) such as `-var` and `TF_VAR_*`. 1. de-hardcoding metadata using alternate channels such as files and environment variables, as we may not need to otherwise expose make these in the first place: - npins deps should not need to be pluggable, and originally were calculated within TF - since having been decoupled only as a performance improvement - IPs *eventually* should not need setting, and are only still hard-coded until #113 - domains are similar as IPs there (#110) - maybe misc stuff, see #314 1. for the moment exposing metadata needed for testing over the same interface as user input - temporarily inelegant for the purpose of visual demos, tho otherwise maybe offering a simpler approach (until #313) for testing purposes for facilitating grouping of metadata with service, while simultaneously perhaps being a bit more explicit about our technical debt. for the purpose of testing this story (short of lumping all the further automation on), i feel option 3 may be the lesser evil for the moment.

fricklerhandwerk commented

2025-05-02 08:49:16 +02:00

Owner

What exactly is the metadata here? Other than that, 👍for making tech debt explicit.

kiara commented

2025-05-05 18:23:56 +02:00

Author

Owner

@fricklerhandwerk the meta-data includes:

calculated in TF
- code hash
calculated before TF
- pins
hard-coded stuff (now updated at #314)

edit: to be clear, what i intended to propose making explicit for now is less 'all of that' more 'what we actually need for testing already', for now

@fricklerhandwerk the meta-data includes: - calculated in TF - code hash - calculated before TF - pins - hard-coded stuff (now updated at #314) edit: to be clear, what i intended to propose making explicit for now is less 'all of that' more 'what we actually need for testing already', for now

kiara force-pushed tofu from 4065675b99

/ check-pre-commit (pull_request) Successful in 9s

Details

/ check-peertube (pull_request) Successful in 16s

Details

/ check-panel (pull_request) Successful in 1m23s

Details

/ check-deployment-basic (pull_request) Successful in 12m11s

Details

/ check-launch (pull_request) Successful in 55s

Details

to 1019ac15b0

/ check-pre-commit (pull_request) Failing after 11s

Details

/ check-peertube (pull_request) Successful in 17s

Details

/ check-panel (pull_request) Successful in 1m21s

Details

/ check-deployment-basic (pull_request) Successful in 12m10s

Details

/ check-launch (pull_request) Successful in 55s

Details

2025-05-05 20:23:01 +02:00

Compare

fricklerhandwerk commented

2025-06-16 10:27:48 +02:00

Owner

Shall we close this, as it seems to be mostly exploratory code? The TF migration is in the other PR, so what's left here as substance?

kiara commented

2025-06-16 11:47:39 +02:00

Author

Owner

@fricklerhandwerk wrote in Fediversity/Fediversity#307 (comment):

Shall we close this, as it seems to be mostly exploratory code? The TF migration is in the other PR, so what's left here as substance?

the intended division of labor wasn't exploratory vs real, rather focus on user applications vs infra - tho tbf a code move on the latter's part has currently affected code here as well, making it more of a superset of this branch (tho it might be missing recent bits).
if we are to merge things piece-meal (as you expressed before), then i'm not sure going for just that one would match that intent.

i would propose instead ensuring this one matches the move over there, such as to reduce diffs while keeping PRs not too much bigger than needed.

@fricklerhandwerk wrote in https://git.fediversity.eu/Fediversity/Fediversity/pulls/307#issuecomment-7819: > Shall we close this, as it seems to be mostly exploratory code? The TF migration is in the other PR, so what's left here as substance? the intended division of labor wasn't exploratory vs real, rather focus on user applications vs infra - tho tbf a code move on the latter's part has currently affected code here as well, making it more of a superset of this branch (tho it might be missing recent bits). if we are to merge things piece-meal (as you expressed before), then i'm not sure going for just that one would match that intent. i would propose instead ensuring this one matches the move over there, such as to reduce diffs while keeping PRs not too much bigger than needed.

kiara commented

2025-06-16 11:53:12 +02:00

Author

Owner

in retrospect, i may not be certain what other PR you're referring to. i assumed the infra one, but you may have intended the tofu-test branch, which is kinda intended as a successor for this branch, tho i'd put off opening a PR over forgejo PRs being annoying about rebases.
if that one was your intent, i could open one for that to replace this one.

in retrospect, i may not be certain what other PR you're referring to. i assumed the infra one, but you may have intended the [`tofu-test`](https://git.fediversity.eu/Fediversity/Fediversity/compare/main...kiara/Fediversity:tofu-test) branch, which is kinda intended as a successor for this branch, tho i'd put off opening a PR over forgejo PRs being annoying about rebases. if that one was your intent, i could open one for that to replace this one.

fricklerhandwerk commented

2025-06-16 16:06:11 +02:00

Owner

I meant Fediversity/Fediversity#319, which seems to be somewhat similar in scope and nature.

I meant https://git.fediversity.eu/Fediversity/Fediversity/pulls/319, which seems to be somewhat similar in scope and nature.

kiara commented

2025-06-16 16:22:44 +02:00

Author

Owner

ok in that case see Fediversity/Fediversity#307 (comment)

ok in that case see https://git.fediversity.eu/Fediversity/Fediversity/pulls/307#issuecomment-7825

kiara changed title from ~~buttons works deployed~~ to button works deployed