feat: harmony now defaults to using local k3d cluster. Also created OCICompliant: Application trait to make building images cleaner
#76
No reviewers
Labels
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: NationTech/harmony#76
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "feat/oci"
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?
OCICompliant: Applicationtrait to make building images cleaner@ -14,0 +19,4 @@features: vec![Box::new(ContinuousDelivery {application: Arc::new(application.clone()),})],application,First impressions: this seems a bit redundant (and heavy) to have to pass the application around like this + having to "duplicate" the name between the score and the app. The clone seems a bit awkward as well.
Just a thought, don't have any better suggestions for now (I saw the previous PR that introduced it and the reasoning).
@ -23,0 +22,4 @@/// Creates a bare maestro without initialization.////// This should rarely be used. Most of the time Maestro::initialize should be used instead.pub fn new_without_initialization(inventory: Inventory, topology: T) -> Self {usually we see
::emptyto initialize something as naked as possible, would that make more sense here?makes more sense than
::newfor sure.new_without_initializationI agree is a bit uncanny. But technically the Maestro is not anymore "empty" when created via new than initialize, the only difference is a side-effect happening in initialize where the topology is initialized.I'm very much open to better ideas, but I don't feel like
emptyis much better... Maestro is not a collection, it's more of an "engine". Maybe something along the idea of "idle" or "stale" but both those options feel less obvious to me than new_without_initialization. But that may be because I know the internals.1d90c3308dtobd337d1cb9Looooooootttts of stuff in the last commit that is just stuffed there. Will need some refactoring but basic functionality works right now.
bd337d1cb9to5a89495c61@ -42,0 +65,4 @@// 1. Create the Helm chart files on disk.let chart_dir = self.create_helm_chart_files(image_url)For OCI, we get the (local) image name from the trait directly (
self.image_name()&self.local_image_name()). Why is it different here?Also, could (should?) it be generated automatically from the application name instead? It doesn't seem like we actually need it from outside.
This is actually the container image url. The chart uses it to reference the image correctly.
But yes, this is a common pain with image urls, helm chart names, application names, etc. Perhaps we could easily create an ApplicationIdentifier or ApplicationLocator concept that is used instead of a String that provides a robust way to get container image location, helm chart location, app name, etc, etc.