...
This field is optional and ignored for services deployed to a device. 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. <=== there is no way for this built-in constraint to become an OR condition, therefore this behavior might force the user to create additional deployment policies.
The OH cluster scoped agent already 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 three 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. Third, it introduces a similar semantic conflict if the deployer specifies "cluster_namespace" in the deployment policy.
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 the embedded namespace definition act as a built-in constraint which eliminates namespace scoped nodes with a different namespace. The deploycheck CLI MUST detect this case.
The third problem is detected by the deployment publish CLI and returns an error to the user.
A namespace specified in the deployment policy overrides any namespace defined in the operator definition.
...