## 4 Results
### DAG Levels
#### 4.1.1 Component Level  
The lower level refers to the Component resources that implement the business logic. In Appendix A, Figure A2 presents how the generic CRD (see Figure 11) is particularized for the component resource. The spec subsection includes four required fields:  
* name: Name of the component resource as seen in Kubernetes. It must be unique in the system; therefore, ephemeral components are named as Application.name-Component.name. On the contrary, permanent components, as they take part in numerous applications, are given a name equal to Component.name. Permanent components will be unique in the system and, thus, no further identification is required.  
image: Name of the image to be pulled by Kubernetes. The container image includes the necessary code to run the component's functionality and is accordingly parameterized to interpret the rest of the component fields.
* flowConfig: This parameter holds the information related to the flow of the DAG relative to the component. It is subdivided into two parameters, namely previous and next: \(\bigcirc\) previous: An array of a duple of the name of the previous components in the flow and the topic (IFMHtopic, Intra Fog Message Hub topic) on which the component will be offering its service. \(\bigcirc\) next: An array of a duple of the name in the flow and the topic (IFMHtopic) of the next components on which the component will be publishing to reach the next components. The rest of the fields are considered optional. Therefore, they are not required when instantiating a component:
* customization: This field allows for the customization of a component with any additional information that might be relevant to its runtime environment, passed as Strings defined by the component developer. It is useful when the component developer sets additional requirements not part of the functioning of the platform but needed by the component code.
* permanent: The persistence of the component is reflected in this field. If a component is permanent, this field is set to True. The Component Controller will act differently depending on the persistence of the component.
* permanentCM: Related to the previous field, it indicates the name of the ConfigMap (Kubernetes object used as key-value storage) the permanent component will use as its configuration file. Ephemeral components are customized at the time of deployment using the previously explained parameters, as this type of component does not form part of different applications during their lifecycle. However, the configuration of permanent components is variable during runtime, and it must be updated when new applications request their services. Therefore, ConfigMaps are used to dynamically change the configuration of a permanent component without the need to redeploy it (i.e., to consider the permanent component as a node in different DAGs at the same time). Specifically, a ConfigMap is linked to a Volume (a directory containing data in the Kubernetes cluster for Pods to consume) so when the ConfigMap is updated, the information is ready for the container to access in the Volume. This process is controlled by Kubernetes and is independent of both the platform and the user. The status subsection of the Component CRD Is used to track the actual state of the component resources in the cluster. To do so, two fields are used:
* replicas: It represents the number of available replicas in a running state in the cluster.
* situation: It is a parameter that reflects the current status of the component (Deploying or Running). The initial situation is Deploying, but when all the desired replicas are running, the component controller updates it to Running.