...
In the absence of the "cluster_namespace" field, 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 acts as a built-in constraint ANDed to the user specified constraint expression. The deploycheck CLI MUST detect this case.
There could be a semantic conflict if the deployer specifies a "cluster_namespace" and uses openhorizon.kubernetesNamespace in a constraint expression. It is likely that such a policy will result in no deployments, which would be the technically correct behavior but it might also be surprising to the user. This is why the hzn deploycheck command exists, to help the user understand semantic mismatches in deployment policy. The deploycheck command MUST detect whether or not there is a real semantic conflict in this case.
Deployment Examples:
Here are some examples that illustrate deployment outcomes resulting from the behavior described above. The examples show that the design is compatible with existing OH behavior and also enables control of the target namespace for the deployer.
...
And finally, some additional examples for namespace scoped nodes.
Once the Agbot has calculated the target namespace it:
- A node in namespace ABC. The deployment policy has
"cluster_namespace":"ABC". The edge service is deployed to the node. - A node in namespace ABC. The deployment policy has no
"cluster_namespace". The edge service is deployed to the node. - A node in namespace ABC. The deployment policy has no
"cluster_namespace". The deployment policy has a constraint expression openhorizon.kubernetesNamespace=XYZ. The edge service is NOT deployed to the node. - A node in namespace ABC. The deployment policy has
"cluster_namespace":"ABC". The deployment policy has a constraint expression openhorizon.kubernetesNamespace=XYZ. The edge service is NOT deployed to the node. The user received a warning when publishing the policy that the policy might result in no service deployments - Uses this namespace as a built-in constraint when searching for deployment targets (nodes) that are not in the openhorizon-agent namespace.
- Ignores this namespace for nodes in the openhorizon-agent namespace (these nodes are assumed to have cluster scope permissions and are therefore valid targets for services in any namespace. That is, there is no built-in constraint on deployments for nodes in the openhorizon-agent namespace.
- Includes this namespace as built-in service property (openhorizon.service.kubernetesNamespace), so that the node owner can create constraint expressions referring to the target namespace of a service.
Note: The node owner is always free to configure a deployment constraint expression that limits the namespace
...
As a service deployer, I want to know if my deployment policy will deploy to a namespace or cluster scoped node.
As a node owner, I want OH ensure that DevOps teams using my edge cluster are isolated from each other, based on the namespace(s) I have given to each team.
...
There are no new commands or verbs introduced by this design, but the behavior of some existing CLI commands is changed to accommodate this feature.
hzn exchange deployment addPolicy -f <policy_definition>
If the policy specifies "cluster_namespace" and the property openhorizon.kubernetesNamespace is present in the constraint expression, a warning is provided telling the user that this deployment policy may result in no service deployment. The user will be directed to use the hzn deploycheck command to verify whether or not a deployment will result.
hzn deploycheck
There are several situations outlined in the design above where deployment may or may not occur as expected, depending on the depth of knowledge of the user. The hzn deploycheck command is enhanced to identify:
- a semantic conflict if the deployer specifies a
"cluster_namespace"and uses openhorizon.kubernetesNamespace in a constraint expression - deployment target selection (or not) in the absence of the
"cluster_namespace"field, and a namespace definition embedded in the operator definition - deployment target selection (or not) in the presence of the
"cluster_namespace"field, and a namespace definition embedded in the operator definition
hzn exchange service publish
If the service definition contains an embedded namespace definition, provide a warning to the use that they are not following best practices. Use the hzn deploycheck command before this service to ensure that the policy will select nodes as expected.
...
When a namespace scoped agent is installed, it is given kubernetes privileges within its specific namespace but not beyond that scope.
...
The Exchange API is updated to support the new cluster_namespace field in a deployment policy resource.
The Exchange is unaware of node, service or deployment properties within its schema definitions.
...
- Authoring edge cluster services: Add a note that packaging a namespace definition inside an operator definition is not considered a best practice. Service developers should allow deployers to choose the target namespace in the deployment policy.
- Deploying edge cluster services: Document the new cluster_namespace field in the deployment policy. Describe how it's used and how it plays into the algorithm used by the Agbot to determine where edge cluster services are placed.
- Policy: Document the new built-in property openhorizon.kubernetesNamespace for edge node policies.
- Installing edge cluster agent: Document the new --namespace flag in the agent-install script.
...