Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add graph prototype #6

Merged
merged 1 commit into from
Feb 2, 2024
Merged

add graph prototype #6

merged 1 commit into from
Feb 2, 2024

Conversation

vsoch
Copy link
Member

@vsoch vsoch commented Feb 2, 2024

We are updating the compatibility schema prototypes to be entirely graphs, meaning that every node must be represented in the graph, and there are several benefits to this:

  • parsing (for scheduling or image selection) means we can generate one graph (and don't need to combine graphs)
  • we don't need to handle cases of "single node" graphs (metadata attributes that are nodes but don't have edges)
  • we don't need to keep around an extra jsonschema to validate a custom format, it's just JGF!

For the last bullet, I considered V1 and V2 of JGF. While there are tools that are using V1, I reviewed the differences and think V2 is better in that we can lookup specific nodes in O(1) time (without needing to iterate over a list) and this seems to be the preference for the json graph maintainers, so we should go that route and (eventually) update underlying tools that might use this to support that. In addition, I am adding an example for a compatibility spec, or what would be an artifact that represents an application or container image, and uses one or more compatibility schemas. This spec still has a custom format that we provide a schema.json to validate against.

Thanks for the discussion today @milroy I think this is a good direction to take, and I'll be following up with changes to our lammps experiment / compspec-go implementation and the OCI working group proposal D to reflect the changes here. No need (for now) for a formal review - this is all a quickly moving prototype, and we will do more formal vetting of the details if/when this idea has feet upstream.

I'm excited! Looking forward to working on this in Go soon 🥳

we are updating the compatibility schema prototypes to be
entirely graphs, meaning that every node must be represented
in the graph. This also makes our lives simpler because we
do not need a separate json schema for some custom format -
we can just use JGF! While there are tools that are using V1,
I reviewed the differences and think V2 is better in that
we can lookup specific nodes in N1 time (without needing
to iterate over a list) and this seems to be the preference
for the json graph maintainers, so we should go that route
and (eventually) update underlying tools that might use
this to support that. In addition, I am adding an example
for a compatibility spec, or what would be an artifact
that represents an application or container image, and
uses one or more compatibility schemas.

Signed-off-by: vsoch <vsoch@users.noreply.github.com>
@vsoch vsoch force-pushed the add-graph-prototype branch from 69f34bb to 2906f7a Compare February 2, 2024 01:47
@vsoch vsoch merged commit ce3241f into main Feb 2, 2024
1 check passed
@vsoch vsoch deleted the add-graph-prototype branch February 2, 2024 01:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant