--- tags: UI --- # UI Sequence Diagrams ## As an Operator of the Platform Cluster Is the UI something that implicitly present navigation through the infra struct * As a user I want to see what vm's I have declared in the clusters * As a user I want to see what vm's exists in the clusters and their state --- ## As a Consumer of a Subcluster ### Login flow * Select region from list of regions that I have access to or ownership of Navigation rooted at the "top" elements for those regions that I have visibility to I don't want to really see the underlying region, anything SIP or Vino, but since my endpoint would be a subcluster, there needs to be management facilitation tied to the underlying cluster's exposed interfaces for this purpose. *What about pointing airshipctl to a non airship deployed/managed cluster? What happens?* ### Manage a Cluster Details of the cluster * capacity/usage info List of Nodes List of Applications The following things would be more about the "public" interface for SIP/Vino, using some set of exposed APIs for the consumer of a subcluster: Manage access to the cluster Keys/Certs? Commission/Decommission a cluster? *Can I add/remove virtual nodes later? I don't expect to have much control of this as a consumer.* ### Manage a Node Details of node * capacity/usage info Actions I can take against a node: * Things I'd do using kubectl: * cordon * label management * Things I'd expect to have special support in airshipctl UI * remove/rejoin from cluster * restart node *Since my interaction with the node would be that of a subcluster administrator, I'd expect to be able to do such things as node labeling, cordoning nodes, and all the things I could normally do to a node using kubectl. I probably need to have exposed API (or equivalent) controls to ask the infrastructure cluster to completely rebuild nodes/cluster* ### Manage Applications *This would only be if I've chosen to use airship to manage my cluster* * list of helm charts What's running (& has it been modified) Apply Changes What's delcared Deploy *At this point, I'm thinking that Octant's view is what I'd want to use for exploration of the cluster* ### What about if I'm a subcluster admin, and I choose to use airshipctl to manage my cluster's installed applications? In the case where the infrastructure cluster is administered by someone different than the subcluster, there's a possibility that the subcluster admin chooses to manage the subcluster using airshipctl. In this case, as the subcluster admin, I'd expect that there be two portions of the airshipctl UI: ![](https://i.imgur.com/GTkLJ0V.png) * Manage my cluster through the subcluster management API (or equivalent), for the things noted above - reboots, rebuilds * It would be ideal if this portion of the ui pointed to an exposed API in the Infrastructure cluster * Manage deployment, document management, etc... much like the infrastructure admin would, but without the subcluster (i.e. subcluster subclusters) management. * for this reason, I think it's important that the airshipctl ui is "smart" about the existance of sip/vino and subcluster specific features, only showing them if the current cluster has these things installed. * This portion of the UI would need to point to the cluster itself, and to the source control for the subcluster's workload/configuration. --- ### Example Sequence Diagram see: https://plantuml.com/sequence-diagram ```plantuml @startuml entity "something" as something entity "another" as another participant "Thing A" as thinga participant "Thing B" as thingb title MySequenceFlow something -> thinga: begin the transaction thinga -> thingb: do some processing another --> thingb: interruption thingb --> thinga: answer thinga -> something note left: Something to say @enduml ```