[15:29] <amansi26> Hi, just a general query: If we use manage_etc_host: true in cloud.cfg . It will add hostname mapped with localhost like http://paste.openstack.org/show/799923/ in /etc/hosts. Which make sense if we do with private NIC deployment, it helps to ping the hostname from that very same system. But in case of public NIC deployment, if we map a fqdn with localhost, that's not correct . Right?  Ideally in case of Public NIC hostname should be mapped with
[15:29] <amansi26> IPv4/IPv6 IP assigned to the system
[15:30] <amansi26> Generally how are we handling this condition?
[15:52] <meena> who's idea was hirsute??
[17:05] <muhaha> guys? how can i get metadata public ip from azure datasource in cloud-init ?
[17:08] <amansi26> smoser: blackboxsw: Odd_Bloke: Can you help me with the above query?
[17:15] <muhaha> how to query variable from datasource ?
[17:16] <blackboxsw> amansi26: muhaha was just looking that up to see if it is exposed by the cached Azure datasource. Unfortunately it is not preserved.
[17:16] <blackboxsw> the only way to get that for azure is python3 -c "from cloudinit.sources.DataSourceAzure import IMDS_URL; print(IMDS_URL)"
[17:17] <blackboxsw> on AWS instances, cloud-init does preserve the metadata version queried  under the key "_metadata_api_version"
[17:17] <muhaha> blackboxsw: I just want to pass ip address to config file in write_files section
[17:18] <amansi26> blackboxsw: I think there is a bit confusion. muhaha and my query are different I guess
[17:19] <amansi26> My  query: If we use manage_etc_host: true in cloud.cfg . It will add hostname mapped with localhost like http://paste.openstack.org/show/799923/ in /etc/hosts. Which make sense if we do with private NIC deployment, it helps to ping the hostname from that very same system. But in case of public NIC deployment, if we map a fqdn with localhost, that's not correct . Right?  Ideally in case of Public NIC hostname should be mapped with IPv4/IPv6 IP
[17:19] <amansi26> assigned to the system. Generally how are we handling this condition?
[17:19] <blackboxsw> I'd like to see all datasources grow and present that information so you could run `cloud-init query ds._meta_data_api_version`
[17:20] <blackboxsw> muhaha, so to query the datasource specifically you could run  sudo python3 -c 'from cloudinit.stages import _pkl_load; ds = _pkl_load("/var/lib/cloud/instance/obj.pkl"); dir(ds)'
[17:21] <blackboxsw> or alternately (some metadata in formation is saved in /run/cloud-init/instance-data.json which can be queried with 'cloud-init query ds'
[17:21] <blackboxsw> amansi26: checking your question now
[17:22] <muhaha> what is difference between querying this data via curl like IP=$(curl -s -H Metadata:true --noproxy "*" "http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/privateIpAddress?api-version=2017-08-01&format=text") , and using  /run/cloud-init/instance-data.json file ?
[17:23] <muhaha> i am cloud-init newbie
[17:24] <blackboxsw> muhaha: instance-data.json  is seeded by what cloud-init consumes on the instance. specifcally if you look in /var/log/cloud-init.log you can see that on Azure cloud-init read from "Read from http://169.254.169.254/metadata/instance?api-version=2017-12-01"
[17:24] <blackboxsw> so your version you curled will be different as
[17:25] <blackboxsw> the version you specified was 2017-08-01
[17:25] <amansi26> blackboxsw: Just an additional data. /etc/hosts data for private nic deployed VM: http://paste.openstack.org/show/799931/
[17:26] <blackboxsw> muhaha: cloud-init only preserves what it had read, so you may have data missing if you rely on other metadata routes besides http://169.254.169.254/metadata/instance or different api versions than 2017-12-01
[17:27] <muhaha> blackboxsw: I see, can you please point me, how to replace $IP in https://pastebin.com/raw/tBC6R3Rb to be able to resolve this variable as actuall ip address of instance ?
[17:27] <blackboxsw> thx for the paste amansi26 looking
[17:31] <blackboxsw> ugh muhaha, Azure needs to better surface public ips under instance-data.json 'v1' key heading. if you feel like filing a bug requesting instance-metadata v1.public_ip athttps://bugs.launchpad.net/cloud-init/+filebug I'd happily +1 that feature request
[17:31] <blackboxsw> muhaha: as it is. here's what your user-data would need.
[17:34] <blackboxsw> 1. add this line before the #cloud-config   "## template: jinja" 2. replace $IP with {{ds.meta_data.imds.network.interface[0].ipv4.ipAddress[0].publicIpAddress}}
[17:35] <blackboxsw> muhaha: how to use jinja templates to render instance-data: https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html#using-instance-data
[17:36] <blackboxsw> to find out what types are instance-data vars are available: `cloud-init query --all`
[17:39] <muhaha> blackboxsw thanks ! I will try asap. One more question, as a newbie.. , if I want to change file content in write_files, how should I (re)provisioning it ?  This cloud-init will run on every boot and if I want to manually reprovisioning it, do I need to run some cloud-init --rerun command? thanks
[17:40] <blackboxsw> hrm amansi26, so are you saying public fqdn is being listed alongside 127.0.0.1 on the host system?
[17:42] <amansi26> yes, blackboxsw. public fqdn is mapping with 127.0.0.1
[17:43] <blackboxsw> muhaha: if you are testing out new cloud-config and want to re-run write-files, typically the cloud platform would change the instance-id it exposes to indicate to cloud-init that it should re-run any config modules that are run PER_INSTANCE, which is what cc_write_files is set to run as https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_write_files.py#L20
[17:44] <blackboxsw> muhaha: if you are manually developing, changing user-data on a system ;sudo cloud-init clean --logs --reboot' will rerun cloud-init on your system as if it were completely fresh
[17:46] <blackboxsw> amansi26: hrm wouldn't you want to hit the local IP address 127.0.0.1 to avoid the "external" roundtrip to the public IP?
[17:47] <blackboxsw> I guess that would block anything if iptables were setup uniquely for public fqdn ip address handling. hrm. I'm not sure honestly if that is *not* desired behavior
[17:52] <amansi26> blackboxsw: Thanks. I raised this query bcz it was not making any sense to me to map public ip hostname( which is already pingable ) with localhost . Anyone else has some comment on this?
[17:54] <amansi26> It is like pinging loopback
[17:55] <muhaha> blackboxsw: thanks ! its working !
[17:56] <blackboxsw> good to hear muhaha
[18:20] <blackboxsw> amansi26: yes definitely I think someone else more knowledgeable than me whether the fqdn should *not*  be listed linked  to 127.0.0.1. That said, this config setting has been in cloud-init since pre 2013. So I would've thought a concern like this would have come up before now.
=== ijohnson is now known as ijohnson|lunch
=== dionysus70 is now known as dionysus69
=== ijohnson|lunch is now known as ijohnson
[21:04] <split-brain> hi there, can i ask about this bug/feature, please? i'm trying to get cloud-init to handle secondary ip for my aws ec2 instance in vpc. i found that it should be working now, but after i've upraded to the last version, still there is no secondary ipv4 configured. running centos 8, cloud-init 20.3+603.gca266d38-1.el8.
[21:04] <split-brain> https://github.com/canonical/cloud-init/pull/114
=== vrubiolo1 is now known as vrubiolo
=== dionysus70 is now known as dionysus69