- SSH to primary
- Run the following command to open up vi and the virtual nova configuration file which is in YAML format. After the change is performed in the nova CR make sure to run the same steps in nova-compute:
viocli update nova
- Add a new section header called DEFAULT and add the specific allocation ratio under it.
Note: Formatting matters so here is what the file will look like with this addition
conf:
nova:
DEFAULT:
cpu_allocation_ratio: 10
ram_allocation_ratio: 1.5
disk_allocation_ratio: 1.5
neutron:
metadata_proxy_shared_secret: .Secret:managedencryptedpasswords:data.metadata_proxy_shared_secret
vmware:
passthrough: true
tenant_vdc: true
- Save the file.
Note: Saving the file will trigger LCM to update the nova services. You can observe by tailing the tiller log (kubectl -n kube-system logs -f -lapp=helm) and running pods to watch the destruction of the old pods and creation of the updated pods. The changes should be applied in less than a few minutes.
- Run the following to check deployment is in running status.
viocli get deployment
root@oms [ ~ ]# viocli get deployment
PUBLIC VIP PRIVATE VIP HIGH AVAILABILITY
...
OpenStack Deployment State: RUNNING
- Once the changes have been applied we can view them by exec-ing into the nova-api-osapi* pod and checking /etc/nova/nova.conf.
pods | grep -i nova-api
root@oms [ ~ ]# pods | grep -i nova-api
openstack nova-api-metadata-684b7fb449-nz577 1/1 Running 7 95d
openstack nova-api-osapi-cb5bcb5b7-knbcl 2/2 Running 6 95d
root@oms [ ~ ]# osctl exec -it nova-api-osapi-cb5bcb5b7-knbcl /bin/bash
Defaulting container name to nova-osapi.
Use 'kubectl describe pod/nova-api-osapi-cb5bcb5b7-knbcl -n openstack' to see all of the containers in this pod.
[root@nova-api-osapi-cb5bcb5b7-knbcl /]#
[root@nova-api-osapi-cb5bcb5b7-knbcl /]# grep -i allocation_ratio /etc/nova/nova.conf
cpu_allocation_ratio = 10
ram_allocation_ratio = 1.5
[root@nova-api-osapi-cb5bcb5b7-knbcl /]#
Note: If the changes aren’t applied, check the status of the osdeployment pod. If it is in init state for more than 15 or so seconds it may need to be destroyed manually (ie osdel po osdeployment-osdeployment1).