Way to handle state in NixOps4 #169
Labels
No labels
0 points
0.5 points
1 point
13 points
2 points
21 points
3 points
34 points
5 points
55 points
8 points
api service
blocked
component: fediversity panel
component: nixops4
documentation
estimation high: >3d
estimation low: <2h
estimation mid: <8h
infinite points
productisation
project-management
question
role: application developer
role: application operator
role: hosting provider
role: maintainer
security
technical debt
testing
type unclear
type: bug
type: deliverable
type: key result
type: objective
type: task
type: user story
user experience
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Blocks
#170 Way to handle task dependencies in NixOps4
fediversity/fediversity
#296 orchestrator features
fediversity/fediversity
Reference
fediversity/fediversity#169
Loading…
Add table
Add a link
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?
At present, our repo has a lot of hard-coded info that in practice should not be static global state, but rather state specific to a given deployment. A current examples of this is SSH keys.
Ideally, we would instead be able to handle such state through NixOps4, so that deployments would no longer depend on our source code, but SSH keys for example could rather be generated on the fly for subsequent updates to a deployment.
estimated at ~2w
superseded by #307