With this architecture, we have an extensible application module for which we can easily define new features and add them to application scores.

All this is driven by the ApplicationInterpret, who understands features and make sure they are "installed".

The drawback of this design is that we now have three different places to launch scores within Harmony : Maestro, Topology and Interpret. This is an architectural smell and I am not sure how to deal with it at the moment.

However, all these places where execution is performed make sense semantically : an ApplicationInterpret must understand ApplicationFeatures and can very well be responsible of them. Same goes for a Topology which provides features itself by composition (ex. K8sAnywhereTopology implements TenantManager) so it is natural for this very implementation to know how to install itself.

@@ -0,0 +71,4 @@
+pub trait ApplicationFeature<T: Topology>: std::fmt::Debug + Send + Sync {
+    async fn ensure_installed(&self, topology: &T) -> Result<(), String>;
+    async fn is_installed(&self) -> Result<bool, String>;
+    async fn uninstall(&self) -> Result<(), String>;

@@ -0,0 +69,4 @@
+/// ContinuousIntegration, ContinuousDelivery
+#[async_trait]
+pub trait ApplicationFeature<T: Topology>: std::fmt::Debug + Send + Sync {
+    async fn ensure_installed(&self, topology: &T) -> Result<(), String>;