[wip] Sketching out API, DB models for affinity and anti-affinity #7076
Conversation
|
|
||
| #[derive(Clone, Debug, Deserialize, Serialize, JsonSchema)] | ||
| pub enum AffinityGroupMember { | ||
| Instance(Uuid), |
There was a problem hiding this comment.
I know this is an "enum of one", but RFD 522 discusses having anti-affinity groups which contain "either instances or affinity groups". I figured I'd just define these as "members" to be flexible for future work
There was a problem hiding this comment.
Hopefully a quick drive-by review wasn't too premature, but this stuff is relevant to my interests, so I wanted to take a peek. Overall, everything looks very straightforward and reasonable --- I commented on a few small things, but it's quite possible you were planning to get to all of them and just hadn't gotten around to it yet.
nexus/db-model/src/affinity.rs
Outdated
| #[derive(Queryable, Insertable, Clone, Debug, Selectable)] | ||
| #[diesel(table_name = affinity_group_instance_membership)] | ||
| pub struct AffinityGroupInstanceMembership { | ||
| pub group_id: DbTypedUuid<AffinityGroupKind>, | ||
| pub instance_id: DbTypedUuid<InstanceKind>, | ||
| } | ||
|
|
||
| #[derive(Queryable, Insertable, Clone, Debug, Selectable)] | ||
| #[diesel(table_name = anti_affinity_group_instance_membership)] | ||
| pub struct AntiAffinityGroupInstanceMembership { | ||
| pub group_id: DbTypedUuid<AntiAffinityGroupKind>, | ||
| pub instance_id: DbTypedUuid<InstanceKind>, | ||
| } |
There was a problem hiding this comment.
I note that these lack created/deleted timestamps, implying that:
- we intend to hard-delete rather than soft-delete them, and,
- we don't presently record when instances were added to affinity/anti-affinity groups, so we can't present that in UIs in the future.
I'm not sure if either of these matter to us, but I figured I'd comment on it.
There was a problem hiding this comment.
When I wrote this I was kinda planning on just using hard deletion for membership. I could definitely add the "time_modified" and "time_deleted" columns, and use soft-deletion here too, but as usual, we'll need to be more cautious with our indexing.
("Why hard delete" -> this was kinda arbitrary, my decision here isn't super strong, but I'm more familiar with us using soft deletion for user-facing objects that have full CRUD APIs, and hard-deletion for more internal-facing stuff, to avoid the cost of garbage collecting later, which we haven't really done at all)
There was a problem hiding this comment.
That's totally fair!
The reason I brought up deletion was because if we start out with a schema that uses hard-deletion, and decide to switch to soft-deletion later in order to do something like display affinity group histories in the UI, we can't get back records from before that change, since...they've been deleted. On the other hand, if we started with soft-deletion, we could switch to hard-deletion and blow away any soft-deleted records if we decide to not use them in that way.
On the other hand, maybe the problem of displaying historical affinity group changes is better solved by other things, like audit logging! I dunno.
Extremely WIP, this is an exploratory implementation of RFD 522
See: #1705