## 4 Results
### User-Defined N HAMS Levels  
As mentioned above, the levels that compose the HAMS are implemented by a CRD, a controller, a ServiceAccount, a ClusterRole and a ClusterRoleBinding. The decision of the number of levels that form the HAMS must be made prior to the extension of Kubernetes and, thus, prior to the deployment of the platform. The number of levels (N) must be indicated, and the names of the spec section of each CRD must be specified. This information is used by the Application Structure Generator provided by the operator to generate the YAML files relative to each level. Figure A4 shows how the generic CRD (see Figure 11) is customized for the first level of the HAMS, that is, the level above the DAG levels.  
The spec subsection of these resources is based on three parameters: one for their name, another one for its list of applications and a third one to decide whether to deploy the resource at the same time it is instantiated in the cluster. The status subsection of the resources consists of an array to store the state of the applications by their name and situation, as well as the ready field. This latter represents whether the applications related to the resource have transitioned to the running state and, thus, the resource's ready field can be updated from Deploying to Running. The rest of the CRDs related to the additional HAMS level are generated using the same nesting logic shown in Figure A5.  
The spec subsection of these CRDs is a nested list of arrays of the lower resources. Thus, the CRD generation begins at level 2 and continues to the Nth level. Furthermore, their name must be specified as well as whether to deploy it. The status subsection, as for the previous case, reflects the name and situation of the lower resources as well as the state of the actual level resources in the ready field (Deploying or Running).  
The controllers for each of the levels utilize the same controller image, accordingly parameterized with the names of their upper, current and lower resources. For the uppermost level, the upper level is indicated as System, and thus, the controller interprets that it must not search for upper resources. The logic of these controllers is the same as the logic represented in Figure 12. The sequence diagram in Figure 14 illustrates the high-level interactions between the controllers for the HAMS levels, the Application and Component Controllers and the Kubernetes control plane elements.  
The initial state is equal to the one shown in Figure 13, although extended with the files necessary for the HAMS levels. All of the application structure level controllers activate watchers that are watching events in the system related to their managed resources. The sequence starts with a user that declares the Level N Resource Definition.yaml file. The HAMS level N Controller watcher detects the creation of the Level N Resource and issues the creation of the Level N-1 Resources that compose the Level N Resource. Then, for every controller related to the levels is \(i\in[2,\mathrm{N}-1]\), the watchers detect the creation of their respective resources and issue the creation of their lower-level resources. When the HAMSLevel 1 Resources are created, the HAMS Level 1 controller watcher detects the event and issues the creation of application resources, starting the sequence described in Figure 13.