Enhancement of Container Update Function¶
https://blueprints.launchpad.net/tacker/+spec/enhancement-container-update
Problem description¶
In the current implementation, when users invoke update operation of ConfigMaps and Secrets, all Pods are restarted even if they don’t use those updated ConfigMaps and Secrets. This modification aims to remove this limitation.
Proposed change¶
This specification proposes the following changes:
Add process to Container Update operation [1] to restart only the Pods that use updated ConfigMap or Secret.
ConfigMap and Secret can be used in a Pod either by setting the environment variable or mounting to volume. Therefore, the keys for searching the usage of ConfigMap and Secret are as follows:
In the case of Pods,
spec.containers.env.valueFrom.configMapKeyRef.namespec.containers.env.valueFrom.secretKeyRef.namevolumes.configMap.namevolumes.secret.name
In the case of Deployments, ReplicaSets and DaemonSets,
spec.template.spec.containers.env.valueFrom.configMapKeyRef.namespec.template.spec.containers.env.valueFrom.secretKeyRef.namespec.template.volumes.configMap.namespec.template.volumes.secret.name
Note
If the image parameter of a manifest file changes, the Pod is replaced and the image is updated. In this case, the Pod is replaced regardless of whether the Pod has ConfigMap or Secret to update.
Design of operation¶
The diagram is basically the same as container update [1] , except that only pods that use the updated ConfigMap and Secret or whose image has changed are selected for replacement.
Below is a diagram of the VNF Modify Information operation:
+---------------+ +--------+
| Updated | | VNFD |
| manifest file | | |
+-------------+-+ +-+------+
| |
| |
+-v-----v--+ +------------------+
| CSAR | | Modify Request |
| | | with new vnfd_id |
+----+-----+ +-+----------------+
| | 1. Modify VNF Information request
| |
+-----+----------+----------------------------------------+
| | | VNFM |
| +--v----------v----------------+ |
| | Tacker-server | |
| +--+---------------------------+ |
| | 2. Modify VNF Information request |
| | |
+--------------------------+ | +--v------------------------------------------------+ |
| TackerDB | | | | |
| |4. Update vnfdId | | +----------------------+ | |
| <---------------------+--+----+ VnfLcmDriver | | |
| | | | | | | |
| |6. Update resourceId | | | | | |
| <---------------------+--+----+ | | |
| | | | | | | |
| <--+ | | | | | |
+--------------------------+ | | | +-+------------------+-+ | |
| 5-4. Select the | | |3. modify_start |5. modify_end | |
+--------------------------+ | Pod to | | | | | |
| | | replace | | +-v------------------v-+ | |
| +--------------------+ | +------------------+--+----+ MgmtDriver | | |
| | Kubernetes | | 5-1. Get the | | | |5-2. Select the | |
| | ConfigMap/Secret | | ConfigMap and | | | | ConfigMap and | |
| | | | Secret | | | | Secret to replace | |
| | <--+---------------------+--+----+ +---------------+ | |
| | | | | | | | | | |
| | | | 5-3. Replace config | | | | | | |
| | <--+---------------------+--+----+ <---------------+ | |
| +--------------------+ | | | | |5-6. Select the Pod | |
| | | | | | whose image has | |
| +--------------------+ | 5-5. Get the Pod | | | | changed | |
| | <--+---------------------+--+----+ +---------------+ | |
| | | | | | | | | | |
| | Kubernetes Pod | | 5-7. Replace Pod | | | | | | |
| | <--+---------------------+--+----+ <---------------+ | |
| | | | | | +----------------------+ | |
| | | | | | | |
| | | | | | Tacker-conductor | |
| +--------------------+ | | +---------------------------------------------------+ |
| | | |
| Kubernetes cluster | +---------------------------------------------------------+
+--------------------------+
+--------------------------+
| Hardware Resources |
+--------------------------+
Request parameters for operation¶
User gives following modify parameter to
“PATCH /vnflcm/v1/vnf_instances/{vnfInstanceId}” as
VnfInfoModificationRequest data type in:
Note
The request parameters have not changed from the existing Container Update.
Attribute name |
Cardinality |
Parameter description |
|---|---|---|
vnfInstanceName |
0..1 |
String. “vnfInstanceName” attribute in “VnfInstance”. |
vnfInstanceDescription |
0..1 |
String. “vnfInstanceDescription” attribute in “VnfInstance”. |
vnfdId |
0..1 |
Identifier. “vnfdId” attribute in “VnfInstance”. |
vnfConfigurableProperties |
0..1 |
KeyValuePairs. “vnfConfigurableProperties” attribute in “VnfInstance”. |
metadata |
0..1 |
KeyValuePairs. “metadata” attribute in “VnfInstance”. |
extensions |
0..1 |
KeyValuePairs. “extensions” attribute in “VnfInstance”. |
vimConnectionInfo |
0..N |
map (VimConnectionInfo). “vimConnectionInfo” attribute array in “VnfInstance”. |
vimConnectionInfoDeleteIds |
0..N |
Identifier. To be deleted from the “vimConnectionInfo” attribute array in “VnfInstance”, |
Following is a sample of request body:
{
"vnfdId": "093c38b5-a731-4593-a578-d12e42596b3e"
}
Using ConfigMap and Secret with Kubernetes¶
ConfigMap and Secret can be used in a Pod either by setting the environment variable or mounting to volume. The following are examples of the Kubernetes object file when using ConfigMap and Secret.
Note
The usage of ConfigMap and Secret has not changed from the existing Container Update.
Sample file to define the Kubernetes ConfigMap and Secret:
---
apiVersion: v1
kind: ConfigMap
metadata:
name: cm-data
data:
cmKey1.txt: |
configmap data
foo
bar
---
apiVersion: v1
kind: Secret
metadata:
name: secret-data
stringData:
password: 1mbb1G968fb1CUg
secKey1.txt: |
secret data
baz
Sample file of Kubernetes object when using ConfigMap and Secret as environment variables:
apiVersion: v1
kind: Pod
metadata:
name: env-test
spec:
containers:
- image: alpine
name: alpine
env:
- name: CMENV
valueFrom:
configMapKeyRef:
name: cm-data
key: cmkey1.txt
- name: SECENV
valueFrom:
secretKeyRef:
name: secret-data
key: password
envFrom:
- prefix: CM_
configMapRef:
name: cm-data
- prefix: SEC_
secretRef:
name: secret-data
terminationGracePeriodSeconds: 0
Sample file of Kubernetes object when using ConfigMap and Secret by mounting to volume:
apiVersion: v1
kind: Pod
metadata:
name: modify-VNF-volume-test
spec:
containers:
- image: alpine
name: alpine
volumeMounts:
- name: cm-volume
mountPath: /config
- name: sec-volume
mountPath: /etc/secrets
volumes:
- name: cm-volume
configMap:
name: cm-data
defaultMode: 0666
items:
- key: cmKey1.txt
path: cm/config.txt
- name: secret-volume
secret:
secretName: secret-data
defaultMode: 0600
items:
- key: secKey1.txt
path: creds/secret.txt
terminationGracePeriodSeconds: 0
Sequence for operation¶
The Client sends a PATCH request to the “Individual VNF instance” resource.
Tacker-conductor sends modify VNF request to VnfLcmDriver.
VnfLcmDriver calls modify_start of MgmtDriver.
VnfLcmDriver updates VnfInstance.vnfdId in the TackerDB to the ID of the new VNFD.
VnfLcmDriver calls modify_end of MgmtDriver. modify_end uses the replace API to replace ConfigMap, Secret, and Pod.
5-1. MgmtDriver sends request to get information of ConfigMap and Secret to the VIM (Kubernetes).
5-2. MgmtDriver selects ConfigMap and Secret if the information retrieved in 5-1 differs from the new information.
Note
ConfigMap and Secret is selected for replacement if there is a difference in parameters between the retrieved and new ones.
5-3. MgmtDriver sends request to replace config of ConfigMap and Secret selected in 5-2 to the VIM (Kubernetes).
5-4. MgmtDriver sends request to select Pod that uses the old ConfigMap or Secret to TackerDB.
Note
The ideal way to retrieve information about pods that have the ConfigMap and Secret name selected in 5-2, is using field-selector mechanism implemented in Kubernetes. However, current implementation of Kubernetes does not support field-selectors for the parameters described in Proposed change section.
5-5. MgmtDriver sends request to get information of Pod to the VIM (Kubernetes).
5-6. MgmtDriver selects Pod whose image has changed.
5-7. MgmtDriver sends request to replace Pod selected in 5-4 and 5-6 to the VIM (Kubernetes).
Note
If the image parameter in the manifest file for the Pod, Deployment, ReplicaSet and DaemonSet has changed, the image will be replaced when the Pod is replaced. If parameters other than image is changed in the Pod or Deployment manifest file, the change is not applied.
VnfLcmDriver updates VnfInstance.instantiatedVnfInfo.vnfcResourceInfo.computeResource.resourceId in the TackerDB to the ID of the replaced Pod.
Alternatives¶
None
Data model impact¶
None
REST API impact¶
None
Security impact¶
None
Notifications impact¶
None
Other end user impact¶
None
Performance Impact¶
None
Other deployer impact¶
None
Developer impact¶
None
Implementation¶
Assignee(s)¶
- Primary assignee:
Masaki Ueno<masaki.ueno.up@hco.ntt.co.jp>
- Other contributors:
Yusuke Niimi<niimi.yusuke@fujitsu.com>
Yoshiyuki Katada<katada.yoshiyuk@fujitsu.com>
Ayumu Ueha<ueha.ayumu@fujitsu.com>
Work Items¶
Add process to Container Update operation to restart only the Pods that use updated ConfigMap and Secret.
Dependencies¶
None
Testing¶
Unit and functional tests will be added to cover cases required in the spec.
Documentation Impact¶
Complete user guide will be added to explain modifying VNF information from the perspective of VNF LCM APIs.
