<Please fill out the above fields, and the Overview, Design and User Experience sections below for an initial review of the proposed feature.>
Scope and Signoff:(to be filled out by Chair)
Overview
<Briefly describe the problem being solved, not how the problem is solved, just focus on the problem. Think about why the feature is needed, and what is the relevant context to understand the problem.>
...
The package field contains the JSON object from the package manifest of the most recently successful agent install. See the "Agent package" section.
Agent package:
BP: I think it is important for this and agent-install.sh to work from the same files, because they are doing essentially the same thing.
...
hzn [agentpackage | ap] [new | list | publish]
...describe more details...
Edge Clusters
Agents running in an edge cluster are running within a container. The container's guest OS and package manager will be used to upgrade the agent binaries. The agent will upgrade itself within the container, without terminating the container.
??? Question: Still deciding on this. The alternative is to have the agent installed via an operator (which we dont have today) and allow the operator to do the upgrade. Perhaps this is a better way? The agent process would have to communicate with the operator (through a CRD) in order to trigger an upgrade. ???
??? Question: Is there a case where we would need to update the container in some way that is different from updating the agent binary of the agent config ???
Agent in Linux Container
The existing upgrade script depends on pulling image from dockerhub OH ...design for this is tbd...
Additional management policy
...
Thinking forward a bit, NMP could be extended with the following schema to support additional scenarios:
<Describe which user roles are related to the problem AND the solution, e.g. admin, deployer, node owner, etc. If you need to define a new role in your design, make that very clear. Remember this is about what a user is thinking when interacting with the system before and after this design change. This section is not about a UI, it's more abstract than that. This section should explain all the aspects of the proposed feature that will surface to users.>
Command Line Interface
As a hub admin, I want to install updated agent packages into the management hub so that nodes in any org can receive agent updates.
As an org admin, I want to declare that some or all nodes in my org will automatically upgrade the agent when a new version becomes available in the management hub.
As an org admin, I want to declare that some or all nodes in my org will never automatically upgrade the agent.
As an org admin, I want to declare that some or all nodes in my org should start upgrading at a given time.
As an org admin, I want to declare that some or all nodes in my org should upgrade to a specific version.
As an org admin, I want to know the agent version of any given node or group of nodes in my org.
As a hub admin, I want to change the self signed SSL certificate used for TLS between agents and the hub.
As a hub admin, I want to declare the default agent upgrade behavior for all nodes in the org, when creating a new org.
As an org admin, I want to change the default agent upgrade behavior for all nodes in the org, after the org has been created.
As a node owner, I want to override the org's agent upgrade behavior, I want to control when to upgrade the agent on my node.
As an org admin, I want to get a list of nodes that my NMP applies to.
Some additional, but related use cases to ponder. These are NOT covered in detail by this design document:
As an org admin, I want some or all of the nodes in my org to upgrade dependent services.
As a cluster admin, I want to change one of the URLs that agents use to communicate with the hub.
As a node owner, I want to declare which nodes are part of an HA group.
Command Line Interface
<Describe any changes to the hzn CLI, including before and after command examples for clarity. Include which users will use thechanged CLI. This section should flow very naturally from the User Experience section.>
hzn exchange [ nm | nodemanagement ] [ list | new | publish | remove ]
NOTE: verb to ask if all nods have implemenetd a given NMP policy.
For the hzn exchange nm publish command, when the user is trying to publish a NMP with empty constraints and/or patterns == "*", they are required to confirm that they understand the potentially disruptive nature of the policy.<Describe any changes to the hzn CLI, including before and after command examples for clarity. Include which users will use thechanged CLI. This section should flow very naturally from the User Experience section.>
External Components
<Describe any new or changed interactions with components that are not the agent or the management hub.>
None.
Affected Components
<List all of theinternalcomponents (agent, MMS, Exchange, etc) which need to be updated to support the proposed feature. Include a link to the github epic for this feature (and the epic should contain the github issues for each component).>
Agent
Exchange (new resource and updates of that resource surfaced through /changes API)
Security
<Describe any related security aspects of the solution. Think about security of components interacting with each other, users interacting with the system, components interacting with external systems, permissions of users or components>