feat(remote-config): add support for multiple components of the same type, and change from hard to soft delete

MAINTAINERS.md

@@ -16,11 +16,10 @@ Maintainers are assigned the following scopes in this repository:
 
 | Name | GitHub ID     | Scope      | LFID | Discord ID          | Email | Company Affiliation |
 |----- | ------------- | ---------- | ---- | ------------------- | ----- | ------------------- |
-|      | jeromy-cannon | Maintainer |      | jeromy_at_hashgraph |       | Hashgraph           |
+|      | jeromy-cannon | Maintainer |      | jeromy\_at\_hashgraph |       | Hashgraph           |
 |      | leninmehedy   | Maintainer |      |                     |       | Hashgraph           |
 |      | nathanklick   | Maintainer |      | nathan.hashgraph    |       | Hashgraph           |
 
-
 ## Emeritus Maintainers
 
 | Name | GitHub ID | Scope | LFID | Discord ID | Email | Company Affiliation |
@@ -31,75 +30,75 @@ Maintainers are assigned the following scopes in this repository:
 
 Maintainers are expected to perform the following duties for this repository. The duties are listed in more or less priority order:
 
-- Review, respond, and act on any security vulnerabilities reported against the repository.
-- Review, provide feedback on, and merge or reject GitHub Pull Requests from
+* Review, respond, and act on any security vulnerabilities reported against the repository.
+* Review, provide feedback on, and merge or reject GitHub Pull Requests from
   Contributors.
-- Review, triage, comment on, and close GitHub Issues
+* Review, triage, comment on, and close GitHub Issues
   submitted by Contributors.
-- When appropriate, lead/facilitate architectural discussions in the community.
-- When appropriate, lead/facilitate the creation of a product roadmap.
-- Create, clarify, and label issues to be worked on by Contributors.
-- Ensure that there is a well defined (and ideally automated) product test and
+* When appropriate, lead/facilitate architectural discussions in the community.
+* When appropriate, lead/facilitate the creation of a product roadmap.
+* Create, clarify, and label issues to be worked on by Contributors.
+* Ensure that there is a well defined (and ideally automated) product test and
   release pipeline, including the publication of release artifacts.
-- When appropriate, execute the product release process.
-- Maintain the repository CONTRIBUTING.md file and getting started documents to
+* When appropriate, execute the product release process.
+* Maintain the repository CONTRIBUTING.md file and getting started documents to
   give guidance and encouragement to those wanting to contribute to the product, and those wanting to become maintainers.
-- Contribute to the product via GitHub Pull Requests.
-- Monitor requests from the LF Decentralized Trust Technical Advisory Council about the
-contents and management of LFDT repositories, such as branch handling,
-required files in repositories and so on.
-- Contribute to the LFDT Project's Quarterly Report.
+* Contribute to the product via GitHub Pull Requests.
+* Monitor requests from the LF Decentralized Trust Technical Advisory Council about the
+  contents and management of LFDT repositories, such as branch handling,
+  required files in repositories and so on.
+* Contribute to the LFDT Project's Quarterly Report.
 
 ## Becoming a Maintainer
 
 This community welcomes contributions. Interested contributors are encouraged to
 progress to become maintainers. To become a maintainer the following steps
 occur, roughly in order.
 
-- The proposed maintainer establishes their reputation in the community,
+* The proposed maintainer establishes their reputation in the community,
   including authoring five (5) significant merged pull requests, and expresses
   an interest in becoming a maintainer for the repository.
-- A PR is created to update this file to add the proposed maintainer to the list of active maintainers.
-- The PR is authored by an existing maintainer or has a comment on the PR from an existing maintainer supporting the proposal.
-- The PR is authored by the proposed maintainer or has a comment on the PR from the proposed maintainer confirming their interest in being a maintainer.
-  - The PR or comment from the proposed maintainer must include their
+* A PR is created to update this file to add the proposed maintainer to the list of active maintainers.
+* The PR is authored by an existing maintainer or has a comment on the PR from an existing maintainer supporting the proposal.
+* The PR is authored by the proposed maintainer or has a comment on the PR from the proposed maintainer confirming their interest in being a maintainer.
+  * The PR or comment from the proposed maintainer must include their
     willingness to be a long-term (more than 6 month) maintainer.
-- Once the PR and necessary comments have been received, an approval timeframe begins.
-- The PR **MUST** be communicated on all appropriate communication channels, including relevant community calls, chat channels and mailing lists. Comments of support from the community are welcome.
-- The PR is merged and the proposed maintainer becomes a maintainer if either:
-  - Two weeks have passed since at least three (3) Maintainer PR approvals have been recorded, OR
-  - An absolute majority of maintainers have approved the PR.
-- If the PR does not get the requisite PR approvals, it may be closed.
-- Once the add maintainer PR has been merged, any necessary updates to the GitHub Teams are made.
+* Once the PR and necessary comments have been received, an approval timeframe begins.
+* The PR **MUST** be communicated on all appropriate communication channels, including relevant community calls, chat channels and mailing lists. Comments of support from the community are welcome.
+* The PR is merged and the proposed maintainer becomes a maintainer if either:
+  * Two weeks have passed since at least three (3) Maintainer PR approvals have been recorded, OR
+  * An absolute majority of maintainers have approved the PR.
+* If the PR does not get the requisite PR approvals, it may be closed.
+* Once the add maintainer PR has been merged, any necessary updates to the GitHub Teams are made.
 
 ## Removing Maintainers
 
 Being a maintainer is not a status symbol or a title to be carried
 indefinitely. It will occasionally be necessary and appropriate to move a
 maintainer to emeritus status. This can occur in the following situations:
 
-- Resignation of a maintainer.
-- Violation of the Code of Conduct warranting removal.
-- Inactivity.
-  - A general measure of inactivity will be no commits or code review comments
+* Resignation of a maintainer.
+* Violation of the Code of Conduct warranting removal.
+* Inactivity.
+  * A general measure of inactivity will be no commits or code review comments
     for one reporting quarter. This will not be strictly enforced if
     the maintainer expresses a reasonable intent to continue contributing.
-  - Reasonable exceptions to inactivity will be granted for known long term
+  * Reasonable exceptions to inactivity will be granted for known long term
     leave such as parental leave and medical leave.
-- Other circumstances at the discretion of the other Maintainers.
+* Other circumstances at the discretion of the other Maintainers.
 
 The process to move a maintainer from active to emeritus status is comparable to the process for adding a maintainer, outlined above. In the case of voluntary
 resignation, the Pull Request can be merged following a maintainer PR approval. If the removal is for any other reason, the following steps **SHOULD** be followed:
 
-- A PR is created to update this file to move the maintainer to the list of emeritus maintainers.
-- The PR is authored by, or has a comment supporting the proposal from, an existing maintainer or a member of the project's Technical Steering Commitee (TSC).
-- Once the PR and necessary comments have been received, the approval timeframe begins.
-- The PR **MAY** be communicated on appropriate communication channels, including relevant community calls, chat channels and mailing lists.
-- The PR is merged and the maintainer transitions to maintainer emeritus if:
-  - The PR is approved by the maintainer to be transitioned, OR
-  - Two weeks have passed since at least three (3) Maintainer PR approvals have been recorded, OR
-  - An absolute majority of maintainers have approved the PR.
-- If the PR does not get the requisite PR approvals, it may be closed.
+* A PR is created to update this file to move the maintainer to the list of emeritus maintainers.
+* The PR is authored by, or has a comment supporting the proposal from, an existing maintainer or a member of the project's Technical Steering Commitee (TSC).
+* Once the PR and necessary comments have been received, the approval timeframe begins.
+* The PR **MAY** be communicated on appropriate communication channels, including relevant community calls, chat channels and mailing lists.
+* The PR is merged and the maintainer transitions to maintainer emeritus if:
+  * The PR is approved by the maintainer to be transitioned, OR
+  * Two weeks have passed since at least three (3) Maintainer PR approvals have been recorded, OR
+  * An absolute majority of maintainers have approved the PR.
+* If the PR does not get the requisite PR approvals, it may be closed.
 
 Returning to active status from emeritus status uses the same steps as adding a
 new maintainer. Note that the emeritus maintainer already has the 5 required

docs/site/content/en/_index.md

@@ -2,7 +2,7 @@
 title: Solo docs
 ---
 
-{{< blocks/cover title="Welcome to Solo" image_anchor="top" height="full" >}} <a class="btn btn-lg btn-primary me-3 mb-4" href="docs/">
+{{< blocks/cover title="Welcome to Solo" image\_anchor="top" height="full" >}} <a class="btn btn-lg btn-primary me-3 mb-4" href="docs/">
 Learn More <i class="fas fa-arrow-alt-circle-right ms-2"></i> </a>
 {{< blocks/link-down color="info" >}}
 {{< /blocks/cover >}}

docs/site/content/en/about/index.md

@@ -4,7 +4,7 @@ linkTitle: About
 menu: {main: {weight: 10}}
 ---
 
-{{% blocks/cover title="About Solo" image_anchor="bottom" height="auto" %}}
+{{% blocks/cover title="About Solo" image\_anchor="bottom" height="auto" %}}
 
 ### A Hiero Ledger tool for deploying and managing Hiero Ledger networks.
 

eslint.config.mjs

@@ -137,7 +137,7 @@ export default [
         'warn',
         {
           allowExpressions: false,
-          allowTypedFunctionExpressions: false,
+          allowTypedFunctionExpressions: true,
           allowHigherOrderFunctions: false,
         },
       ],

src/business/errors/read-remote-config-before-load-error.ts

@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: Apache-2.0
+
+import {SoloError} from '../../core/errors/solo-error.js';
+
+export class ReadRemoteConfigBeforeLoadError extends SoloError {
+  public constructor(message: string, cause?: Error, meta?: object) {
+    super(message, cause, meta);
+  }
+}

src/business/errors/write-remote-config-before-load-error.ts

@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: Apache-2.0
+
+import {SoloError} from '../../core/errors/solo-error.js';
+
+export class WriteRemoteConfigBeforeLoadError extends SoloError {
+  public constructor(message: string, cause?: Error, meta?: object) {
+    super(message, cause, meta);
+  }
+}

src/business/runtime-state/api/remote-config-runtime-state-api.ts

@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: Apache-2.0
+
+import {
+  type ClusterReference,
+  type ClusterReferences,
+  type Context,
+  type DeploymentName,
+} from '../../../types/index.js';
+import {type NamespaceName} from '../../../types/namespace/namespace-name.js';
+import {type ConfigMap} from '../../../integration/kube/resources/config-map/config-map.js';
+import {type AnyObject, type ArgvStruct, type NodeAliases} from '../../../types/aliases.js';
+import {type LedgerPhase} from '../../../data/schema/model/remote/ledger-phase.js';
+import {type ConsensusNode} from '../../../core/model/consensus-node.js';
+import {type ComponentFactoryApi} from '../../../core/config/remote/api/component-factory-api.js';
+import {type RemoteConfig} from '../config/remote/remote-config.js';
+
+export interface RemoteConfigRuntimeStateApi {
+  currentCluster: ClusterReference;
+  configuration?: RemoteConfig;
+
+  getClusterRefs(): ClusterReferences;
+  getContexts(): Context[];
+  getConsensusNodes(): ConsensusNode[];
+  deleteComponents(): Promise<void>;
+
+  isLoaded(): boolean;
+  load(namespace?: NamespaceName, context?: Context): Promise<void>;
+  populateRemoteConfig(configMap: ConfigMap): Promise<void>;
+  write(): Promise<void>;
+  persist(): Promise<void>;
+
+  create(
+    argv: ArgvStruct,
+    ledgerPhase: LedgerPhase,
+    nodeAliases: NodeAliases,
+    namespace: NamespaceName,
+    deployment: DeploymentName,
+    clusterReference: ClusterReference,
+    context: Context,
+    dnsBaseDomain: string,
+    dnsConsensusNodePattern: string,
+  ): Promise<void>;
+
+  createFromExisting(
+    namespace: NamespaceName,
+    clusterReference: ClusterReference,
+    deployment: DeploymentName,
+    componentFactory: ComponentFactoryApi,
+    dnsBaseDomain: string,
+    dnsConsensusNodePattern: string,
+    existingClusterContext: Context,
+    argv: ArgvStruct,
+    nodeAliases: NodeAliases,
+  ): Promise<void>;
+
+  addCommandToHistory(command: string): void;
+  createConfigMap(namespace: NamespaceName, context: Context): Promise<ConfigMap>;
+  getConfigMap(namespace?: NamespaceName, context?: Context): Promise<ConfigMap>;
+  loadAndValidate(
+    argv: {_: string[]} & AnyObject,
+    validate?: boolean,
+    skipConsensusNodesValidation?: boolean,
+  ): Promise<void>;
+}

src/business/runtime-state/config/local/local-config-runtime-state.ts

@@ -51,7 +51,8 @@ export class LocalConfigRuntimeState {
   // Loads the source data and writes it back in case of migrations.
   public async load(): Promise<void> {
     if (!this.configFileExists()) {
-      return await this.persist();
+      await this.persist();
+      return;
     }
 
     try {