Implement database tests for subject table #88
Conversation
rhmdnd
force-pushed
the
add-subject-integration-tests
branch
2 times, most recently
from
050bdb4 to
e8964b4
Compare
rhmdnd
changed the title
rhmdnd
force-pushed
the
add-subject-integration-tests
branch
2 times, most recently
from
98806f5 to
822be2a
Compare
There was a problem hiding this comment.
let's give this some thought... subjects are the entity that's being evaluated, right? If so... how will we divide OpenShift clusters, which have different attributes per machine pool? Will they have different subjects for each pool? Then, how will we add a relationship? e.g. worker nodes and control plane nodes belong to the same cluster.
| @@ -1,5 +1,5 @@ | |||
| CREATE TABLE IF NOT EXISTS subjects ( | |||
There was a problem hiding this comment.
Let's add documentation about what a Subject can be. I recall you mentioned that a subject may be the entity that's being audited for compliance. e.g. a server, a cluster, and so on. Let's mention this in documentation.
There was a problem hiding this comment.
FWIW - I do have an issue open to discuss the overall schema if we want to iron some of that out there (and take propose the outcome as documentation).
| @@ -1,5 +1,5 @@ | |||
| CREATE TABLE IF NOT EXISTS subjects ( | |||
| id serial PRIMARY KEY, | |||
| id uuid PRIMARY KEY, | |||
| name VARCHAR(255), | |||
| type VARCHAR(50) | |||
| ); | |||
There was a problem hiding this comment.
What about adding metadata to better help locate a subject? While we use very consistent naming for our servers (just from the name we'll know a lot about what server and where it is) some other places treat their servers more like cattle and have very vague names, which can get confusing. I'd suggest adding a json blob column that may store metadata for subjects.
There was a problem hiding this comment.
Yeah - that's a fair point. I also think metadata could be generalized and used across multiple tables. For example, I could see created_at, last_modified, and version as being valid metadata attributes for results and subjects. OSCAL uses a similar approach [0].
What are your thoughts on defining a schema for metadata, and reusing it across multiple entities (e.g., resources and subjects initially)? My concern with using a JSONB type for a column is that it promotes easy storage, but it can be more difficult to migrate those things out later. Long term, performance could be a concern using JSON over other types.
[0] #33
Make sure we test the current schema for the subject table. This commit adds some basic tests that we can use as a template for testing additional tables and schemas moving forward. Fixes #81
rhmdnd
force-pushed
the
add-subject-integration-tests
branch
from
822be2a to
85da02e
Compare
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rhmdnd, Vincent056 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Following up that this will likely need more work and test coverage depending on the outcomes of #84 At the very least - this should serve as an example for other contributors to build more testing on as we develop more schemas. |
Fixes #81