The "kernel_params" option was moved from computed deployment facts

[Daniil Lapshin]

An undocumented/non-backward compatible change was introduced to split the content of node astute.yaml (via https://review.openstack.org/#/q/status:merged+project:openstack/fuel-web+branch:stable/mitaka+topic:bug/1596987 ).
This change extracts out the common attributes of the node as separate common.yaml file.
Among this common attributes kernel_params was also considered as common for the cluster.
However, kernel_params should be in node astute.yaml and not in the common.yaml of the cluster. This is because, not all the nodes in the cluster will have same configuration and hence the kernel_params are node specific and not common for cluster.
For example, kernel parameters related to SR-IOV or hugepages are node specific.
So, please consider moving the kernel_params back to node astute.yaml.

[Georgy Kibardin (gkibardin)]

From what I see in my test deployment kernel_params are still there, in astute.yaml. The common part which has been moved out contains kernel_params inherited from cluster, while astute.yaml contains node specific kernel params as set here:
https://github.com/openstack/fuel-web/blob/stable/mitaka/nailgun/nailgun/orchestrator/provisioning_serializers.py#L162

[Georgy Kibardin (gkibardin)]

Could you please provide diagnostic snapshot.

[Daniil Lapshin (dlapshin)]

Hi Georgy,

The problem is not with astute.yaml but with configuration that could be downloaded, altered and uploaded prior deployment.

[Vladimir Kuklin (vkuklin)]

Daniil, in this case, if you want to specify kernel_params specific for a particular node, just specify it in this node-specific hash.

[Georgy Kibardin (gkibardin)]

It looks like per node kernel_params are still there anyway:
[root@fuel ~]# fuel --env 1 provisioning --default
[root@fuel ~]# grep kernel_params provisioning_1/*
provisioning_1/node-2.yaml: kernel_params: console=tty0 net.ifnames=1 biosdevname=0 rootdelay=90 nomodeset
provisioning_1/node-3.yaml: kernel_params: console=tty0 net.ifnames=1 biosdevname=0 rootdelay=90 nomodeset
provisioning_1/node-4.yaml: kernel_params: console=tty0 net.ifnames=1 biosdevname=0 rootdelay=90 nomodeset
provisioning_1/node-5.yaml: kernel_params: console=tty0 net.ifnames=1 biosdevname=0 rootdelay=90 nomodeset

[Daniil Lapshin (dlapshin)]

The problem is related to deployment info not provisioning.
fuel --env 1 deployment --default

[Georgy Kibardin (gkibardin)]

I'm figuring the point where misunderstanding happens.

For now however, the params are still there:

[root@fuel ~]# fuel --env 1 deployment --default
Default deployment info was downloaded to /root/deployment_1
[root@fuel ~]# grep kernel_params deployment_1/*
deployment_1/100.yaml: kernel_params: console=tty0 net.ifnames=1 biosdevname=0 rootdelay=90 nomodeset
deployment_1/101.yaml: kernel_params: console=tty0 net.ifnames=1 biosdevname=0 rootdelay=90 nomodeset
deployment_1/102.yaml: kernel_params: console=tty0 net.ifnames=1 biosdevname=0 rootdelay=90 nomodeset
deployment_1/103.yaml: kernel_params: console=tty0 net.ifnames=1 biosdevname=0 rootdelay=90 nomodeset
deployment_1/104.yaml: kernel_params: console=tty0 net.ifnames=1 biosdevname=0 rootdelay=90 nomodeset
....
....

[Georgy Kibardin (gkibardin)]

Actually, deployment info for nodes contains also full provisioning info, however when provisioning info is uploaded back as a part of deployment info it is not taken into account. For kernel_params to take effect for particular node modified provisioning info must be uploaded, not deployment info.

[Georgy Kibardin (gkibardin)]

kernel_params get on the top of the node deployment info as a part of merging cluster attributes into each node during serialization so that common cluster info is available on each node. As soon as kernel_params appeared at a cluster level it automatically got into node deployment info despite being unnecessary there because it only makes sense for provisioning. Making changes to kernel_parameters in node deployment info never affected kernel command line on nodes.