ensure application resilience #598
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
Depends on
#289 key features improving user experience supported
fediversity/fediversity
#619 kubernetes set up
fediversity/fediversity
#620 generate kubernetes container from modular service
fediversity/fediversity
#621 applications' NixOS modules use modular services
fediversity/fediversity
#622 NixOS modules wrap modular services
fediversity/fediversity
#623 applications use modular services
fediversity/fediversity
#624 application definitions use service-level containers
fediversity/fediversity
#625 contracts coordinated across pods
fediversity/fediversity
Reference: fediversity/fediversity#598
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?
As an operator,
I want for my applications to be resilient,
so that I may feel confident I can rely on them.
implementation notes
application resilience is inherent to kubernetes (thread), which uses service-level pods so that things may be restarted at the appropriate level.
a path to using that might looks as follows: