...
However, OH currently allows an edge cluster service definition to contain a kubernetes namespace definition (yaml) embedded within the operator definition. The namespace definition indicates the target namespace into which the service should be deployed. There are two problems with this feature. First, it is the wrong placement of function because the namespace in which a service runs is a deployment concern, not an implementation concern. Second, it creates a semantic conflict when the deployer tries to deploy to a namespace scoped node in a different namespace. The use of this feature is not recommended and MAY be deprecated in a future version of OH.
To address both concerns, the deployer needs a way to explicitly indicate the target namespace of a deployment that addresses both concerns.
A new field is added to the service section of a deployment policy, indicating the target namespace for the service's deployment. This namespace overrides a namespace definition in the operator definition of an edge cluster service.
...
If a deployment policy constraint expression chooses a namespace scoped node as a deployment target, this field acts as a built-in constraint that causes namespace scoped nodes in namespaces other than the one specified by this field to be eliminated as deployment targets. The deploycheck CLI MUST detect this case.
options:
or a namespace scoped node <=== seems like it violates the principle of least astonishment.
This field is optional and ignored for services deployed to a device. <=== there is no way for this Effectively, this field acts as a built-in constraint to become an OR condition, it is essentially an AND tacked onto all ANDed to the user specified constraints, therefore this might force the user to create additional deployment policies.
options:
constraint expression. The deploycheck CLI MUST detect this case.
In the absence The first problem is solved by the introduction of the "cluster_namespace" field in the deployment policy. This field allows deployers to have control of the target namespace, especially when the deployer is dealing primarily with cluster scoped nodes.The second problem can be solved by having , a namespace definition embedded in the operator definition acts as a built-in constraint that causes namespace scoped nodes in namespaces other than embedded namespace definition to be eliminated as deployment targets. Effectively, the embedded namespace definition act acts as a built-in constraint which eliminates namespace scoped nodes with a different namespaceANDed to the user specified constraint expression. The deploycheck CLI MUST detect this case.
The third problem is detected by the deployment publish CLI and returns an error to the user. <=== violates separation of concerns between service developer and deployer by not allowing the deployer to have control of a deployment concept, the deployer would have to ask the developer to change the operator definition in the service def before the service can be deployed.
The third problem is handled by treating the "cluster_namespace" as an override of the operator definition.
----------------------------------------------------------------------------------------------------------------------------------
A namespace specified in the deployment policy overrides any namespace defined in the operator definition.
The Agbot calculates the target namespace of a cluster based service target nodes as follows:
- If present, use the
"cluster_namespace"in addition to the deployment policy constraint expression to match potential target nodes. - If present, use the embedded namespace in the service definition.Use openhorizon-agent namespace (this is the default namespace where the cluster scoped agent is installed)definition in addition to the deployment policy constraint expression to match potential target nodes.
- Otherwise, use the deployment policy constraint expression to match potential target nodes.
Once the Agbot has calculated the target namespace it:
...