Skip to content

Commit

Permalink
Apply suggestions from code review
Browse files Browse the repository at this point in the history
Co-authored-by: Simon Gerber <simon.gerber@vshn.ch>
  • Loading branch information
HappyTetrahedron and simu committed Jan 9, 2025
1 parent ead2e78 commit 1f92d7b
Showing 1 changed file with 7 additions and 13 deletions.
Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
= SDD 0033 - Commodore Component Instance Versioning

:sdd_author: Aline Abler
:sdd_owner: Aline Abler
:sdd_reviewers: SIG
:sdd_owner: Aldebaran
:sdd_reviewers: Simon Gerber
:sdd_date: 2025-01-08
:sdd_status: draft
include::partial$meta-info-table.adoc[]
Expand All @@ -24,17 +24,13 @@ Commodore does not currently support specifying different component versions for

* Define how different versions for each component instance can be specified and generated.

=== Non-Goals



== Design Proposal

Commodore will leverage the existing configuration options in `.parameters.components` to retrieve version information for specific instances.
Instance versions can be specified in `.parameters.components.<instance-name>` and override the value specified in `.parameters.components.<component-name>`.
Even if all instances provide their own version, a version for the base component (`.parameters.components.<component-name>`) must still be specified.

Component authors must explicitly declare that their component supports multi-versioning.
Component authors must explicitly declare that their component supports multi-versioning by setting component parameter `_metadata.multi_versioning=true`.
In a valid catalog, all used versions of the same component must advertise this support.

Components with multi-versioning support must ensure they create no file conflicts when downloading dependencies.
Expand All @@ -51,24 +47,22 @@ Similarly, if the component includes a Jsonnet library that is made available to
We can clone the repository of the base component and create a separate worktree for each instance to check out the correct version.

If the instance version specifies a different URL from the base component, more work is needed: in this case, we clone the changed repository for the instance and create a worktree from that.

This means that if two instances both override the URL to the same value, this repository is cloned twice, which can impact performance.
However, since this only affects instances which override the repository URL, the impact is tolerable.
We can leverage the existing MultiDependency architecture to avoid cloning the same repository multiple times.

=== Risks and Drawbacks

* Since the Jsonnet dependencies and libraries are all provided from a single component version, there is a risk for some combinations of versions not compiling properly due to version compatibility issues.
** Even if a component's dependencies are sufficiently backwards-compatible at the moment, it's possible for future changes to break compatibility.
This might force a component author to remove multi-version support in higher component versions, causing a catalog to stop compiling if either component instance is updated.
* Overriding the repository URL in a component instance always causes a new repository to be cloned - even if the same URL is used in multiple instances.

== Alternatives

=== Automatically detecting multi-version support

It could be possible to automatically determine whether a component supports multi-versioning, by way of checking whether the `${_base_directory}` parameter is used in the component's compile configuration.
We could try to automatically determine whether a component supports multi-versioning, by way of checking whether the `${_base_directory}` parameter is used in the component's compile configuration and for Jsonnet expressions that refer to downloaded data.
However, automatically declaring components to be "safe for multi-versioning" carries some risk - even if a component is configured accordingly, it is not guaranteed that its provided Jsonnet libraries and/or its Jsonnet dependencies work if used across versions.
Therefore, we deem it safer to let component authors decide if multi-versioning is safe to use for their component.
Additionally, so far we've defined explicit flags for components to indicate that they support optional features, such as multiple instances.
For all of those reasons, we've decided that component authors must explicitly declare whether multi-versioning is safe to use for their component.

=== Supporting different versions of Jsonnet dependencies per instance

Expand Down

0 comments on commit 1f92d7b

Please sign in to comment.