Solved

Passing a variable through to cloud-init script in Calm?


Userlevel 2
Badge +5
I know in Calm you can create variables in the service, and then use those variables throughout the config using @@{service.variable}@@. However, it doesn't seem like you can use those in cloud-init scripts. I'd like to be able to pass a variable that the user sets at the time of deployment (the IP address), which would then be used in the cloud-init script.

I've tried something like this, to no avail:

code:
#cloud-config
hostname: HAProxy1
fqdn: HAProxy1.domain.com
ssh_pwauth: yes
write_files:
- path: /etc/sysconfig/network-scripts/ifcfg-eth0
content: |
DEVICE=eth0
BOOTPROTO="none"
IPADDR="@@{HAProxy1.IP_Address}@@"
PREFIX="24"
GATEWAY="172.25.51.254"
DOMAIN="VIPCUSTOMERS.COM VTINFO.COM"
DEFROUTE="yes"
ONBOOT="yes"
DNS1="172.25.51.10"
DNS2="172.25.51.2"
IPV4_FAILURE_FATAL="yes"
IPV6INIT="no"
runcmd:
- [ifdown, eth0]
- [ifup, eth0]


Where HAProxy1.IP_Address is a user defined variable. Any thoughts on how I might achieve this?
icon

Best answer by Chandru 25 May 2018, 08:06

@JoeLemaire on PC versions below 5.7 @@{service.variable}@@ is not working inside guest customization scripts due to a bug. As an alternate you can define the variable in the Application profile and use it in your cloud init scripts. Instructions are below for configuring the variables in Application profile,

https://portal.nutanix.com/#/page/docs/details?targetId=Nutanix-Calm-Admin-Operations-Guide-v57:nuc-adding-configure-application-profile-t.html

You should have a default Application Profile already in the blueprint, you can configure the variable in the default Application profile.

When you define variables in the Application profile you need to just refer to the variable as @@{variable}@@ in the scripts. So, in your case if your variable is IP_Address then just refer to it in the Cloudinit script as @@{IP_Address}@@.

View original

7 replies

Userlevel 1
Badge +6
Hi,

it should work. I found this snippet from the Kubernetes blueprint which I used several times. Could you specify which versions you are using? PC, AOS, AHV/VMware etc.?

Best regards,
Thomas

#cloud-config
users:
- name: kube
ssh-authorized-keys:
- @@{INSTANCE_PUBLIC_KEY}@@
sudo: ['ALL=(ALL) NOPASSWD:ALL']
Userlevel 2
Badge +5
Thanks for replying @tfindelk . I'm using PC 5.5.2, AOS 5.5.0.6 (upgrading to 5.5.2 next week) and AHV 20170830.94.
Userlevel 1
Badge +6
Mhh.. The User defined Variable contains a "." dot. Maybe you could explain why this is? My defined variables are without a dot.
Userlevel 3
Badge +12
@JoeLemaire I have tested your blueprint on 5.7.0.1 PC and the variable works fine. On your 5.5.2 version are you seeing the vm getting deployed but failing to set ip address or the vm deployment fails with an error?
Userlevel 3
Badge +12
@JoeLemaire on PC versions below 5.7 @@{service.variable}@@ is not working inside guest customization scripts due to a bug. As an alternate you can define the variable in the Application profile and use it in your cloud init scripts. Instructions are below for configuring the variables in Application profile,

https://portal.nutanix.com/#/page/docs/details?targetId=Nutanix-Calm-Admin-Operations-Guide-v57:nuc-adding-configure-application-profile-t.html

You should have a default Application Profile already in the blueprint, you can configure the variable in the default Application profile.

When you define variables in the Application profile you need to just refer to the variable as @@{variable}@@ in the scripts. So, in your case if your variable is IP_Address then just refer to it in the Cloudinit script as @@{IP_Address}@@.
Userlevel 2
Badge +5
@Chandru thanks for the tip here. That actually ended up fixing my issue!

Out of curiosity, is there a benefit (outside of working around this bug) to defining the variable in the Application Profile vs the service itself? Is it better one way or the other? Just curious for the 'best practice'.

Also, thanks @tfindelk for your assistance in this too!
@JoeLemaire Depends on the use case etc, think of it as scoping for the variable on the objects in the blueprint. SO depending on where you want to use it etc, you might want to define it at a different level.

Reply