...
Currently, the edge cluster agent is installed with cluster permissions which must be granted by the Kubernetes cluster admin. This means that a DevOps team wishing to make use of Open Horizon is required to engage the Ops team responsible for providing Kubernetes services. In order to enable DevOps to be more self sufficient, this barrier needs to be removed. In effect, a DevOps team needs to be able to install an edge cluster agent installed with permission to a specific namespace becomes responsible for managing application so that the agent can manage service deployments in that namespace, and only in that namespace. An As a result, a namespace scoped edge cluster agent installed like this is no longer able to install deploy services into any namespace (as it does currently). As a result, OH will be responsible for preventing namespace specific edge agents from attempting to deploy services into a namespace other than the agent's namespace..
Once However, once this barrier is removed, another set of seemingly disjoint use cases surfacesis also solved. When multiple DevOps teams are utilizing an edge cluster in this way, they are effectively using it in a pseudo multi-tenant fashion. That is, each DevOps team would expect to be able to manage their own agents and services deployed by those agents without interference from agents in other namespaces within the same cluster. To the extent that Kubernetes administration enables multi-tenancy within a cluster, a namespace scoped agent supports those goals. . Thus, a provider of kubernetes services could enable each of their customers to independently exploit OH in their own namespace.
The use cases for a single cluster scoped agent with cluster wide permissions are still valid and are not altered by this design. Further, it is desirable that OH can support a single edge cluster containing both a cluster scoped agent and one or more namespace scoped agents.
...
Agent Install:
The agent install script is updated to include a namespace flag indicating the target namespace of the agent:
...
The user invoking the install script MUST have permission to the MyProjectNamespace, otherwise the install will fail. The absence of the --namespace flag indicates a desire to install an the agent with cluster wide permissions, which will be installed into the openhorizon-agent namespace.
Node Properties:
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 policy constraint expression.
...
...Talk about the openhorizon.service.kubernetesNamespace built-in property.....
Deployment:
When an edge cluster service is deployed, by default, it is deployed into the same namespace as the agent.
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 onto nodes in a specific namespace or set of namespaces.
When deploying an edge cluster service to cluster scoped nodes, the service deployer needs a way to indicate the target namespace. A new field is added to the service section of a deployment policy, indicating the target namespace for the service's deployment.
"service": { ...
"cluster_namespace": <string>
}This field is optional and ignored for services deployed to a device .or a namespace scoped node <=== seems like it violates the principal 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 OH cluster scoped agent already allows an edge cluster service definition to contain a kubernetes A cluster based service MAY contain a namespace definition (yaml) , which embedded within the operator definition. The namespace definition indicates the target namespace in 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 yaml file is packaged with the operator definition in the cluster deployment section of the service definition. This is already supported in the agentfirst 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 primarily dealing with cluster scoped nodes.
A namespace specified in the deployment policy overrides any namespace defined in the operator definition.
...
DevOps user - a conflation of roles found in the practice of DevOps; e.g. service developer, or service deployer.
Usage scenarios:
As a DevOps user, I want to install the OH agent into one or more namespaces that I have permission to use for my project.
As a DevOps user, I want to select the namespace into which a service is deployed, for both cluster scoped and namespace scoped agents.As a DevOps user, I want OH to ensure that other DevOps teams (in the same OH organization/tenant) are unable to deploy applications into my namespaces.
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.
...