...
A new built-in node property called openhorizon.kubernetesNamespace is introduced, the value reflects the namespace in which the agent is installed. This property is read-only, it is always set by the OH runtime and is not settable by any user role. This property MAY be used in a deployment or policy constraint expression.
Service Definition:
When publishing a service definition, the operator definition is introspected for namespace definitions. If one is found, the CLI user will receive a warning.
...Talk about the openhorizon.service.kubernetesNamespace built-in property.....if we find a need for itThere are no updates to the service definition schema.
Deployment:
When an edge cluster service is deployed, by default, it is deployed into the same namespace as the agent/node.
When deploying an edge cluster service, the service deployer MAY write a constraint expression referencing the built-in openhorizon.kubernetesNamespace property in order to limit the placement of the edge service to nodes in a specific namespace or set of namespaces. This is the recommended way to target edge cluster services to nodes in a specific namespace (or namespaces).
However, OH currently allows When deploying 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.
To address both concerns, the to cluster scoped nodes, the service 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.
"service": { ...
"cluster_namespace": <string>
}options:
This field is optional and ignored for services deployed to a device 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. 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 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 built-in constraint to become an OR condition, it is essentially an AND tacked onto all the user specified constraints, therefore this 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 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.
options:
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.
...