[13:45] <GreatSnoopy> hello everybody
[13:45] <GreatSnoopy> anybody here using cloud-init + microsoft azure + debian (credativ image) ?
[13:47] <GreatSnoopy> It is never able to fetch its userdata
[13:47] <GreatSnoopy> i think its not able to autodetect the platform
[13:59] <larsks> GreatSnoopy: what version of cloud-init are you using?
[14:04] <GreatSnoopy> loud-init --version cloud-init 0.7.6
[14:05] <GreatSnoopy> what it does is gets to a point where it does
[14:05] <GreatSnoopy> 2017-02-22 14:04:22,657 - url_helper.py[WARNING]: Calling 'http://168.63.129.16//latest/meta-data/instance-id' failed [0/120s]: bad status code [404]
[14:05] <GreatSnoopy> and on and on
[14:05] <GreatSnoopy> it looks like its not able to deduce it needs an azure datasource
[14:05] <GreatSnoopy> i have waagent installed
[14:07] <GreatSnoopy> interestingly, on a centos instance, it does not get stuck to "Calling ..."
[14:08] <GreatSnoopy> also, waagent does get the userdata, but somehow cloudinit is not able to interact/fetch waagent data
[14:10] <larsks> GreatSnoopy: I don't know how functional the azure data source was in 0.7.6.  There was a bunch of work done on it recently.
[14:11] <larsks> Do you have the option of using a more recent version?
[14:11] <GreatSnoopy> larsks: should i try with a newer one ?
[14:11] <GreatSnoopy> sure,ill try
[14:11] <GreatSnoopy> weirdly on centos, I have an OLDER version
[14:11] <GreatSnoopy> and it works :|
[14:11] <larsks> The other thing is to do is maybe inspect the logs from cloud-init on the debian system (maybe compare them to centos) and see if you can spot anything interesting.
[14:12] <GreatSnoopy> except url_helper.py[WARNING]: Calling 'http://168.63.129.16//latest/meta-data/instance-id'  and the fact that cloud init is not able to find an instance id for itself
[14:12] <GreatSnoopy> i see nothing relevant
[14:12] <GreatSnoopy> i can even post that log maybe one of the devs can spot something i miss
[14:13] <larsks> That's a red herring; that message means it's trying to access an EC2 data source...that is, it's not even trying to get metadata from azure.
[14:13] <GreatSnoopy> # pwd ; ls -1 /var/lib/cloud/instances iid-datasource-none
[14:14] <GreatSnoopy> yes, my assumption is it does not know its on azure
[14:14] <GreatSnoopy> tried making sure we have dmidecode and virt-what to help it
[14:14] <GreatSnoopy> does not help
[14:15] <GreatSnoopy> can the debug turned up for the platform detection itself ?
[14:15] <GreatSnoopy> or for the datasource interaction ?
[14:16] <GreatSnoopy> maybe it's something trivial for which reason he does not properly interact with its environment, but i see no hint on where this would be
[14:16] <larsks> Usually it's pretty verbose by default, I thought.
[14:18] <GreatSnoopy> hm, found this
[14:19] <GreatSnoopy> Looking for for data source in: ['NoCloud', 'AltCloud', 'CloudStack', 'ConfigDrive', 'Ec2', 'MAAS', 'OVF', 'GCE', 'None'], via packages ['', 'cloudinit.sources'] that matches dependencies ['FILESYSTEM']
[14:19] <GreatSnoopy> i see no azure there
[14:19] <GreatSnoopy> on the other hand on centos there is  not a line like that at all
[14:24] <larsks> GreatSnoopy: does your configuration include an explicit list of data sources?  E.g. in /etc/cloud/cloud.cfg (or cloud.cfg.d)?
[14:24] <larsks> Does the package include the Azure data source?
[14:25] <GreatSnoopy> larsks: not as far as i know, its debian default
[14:26] <larsks> There may be folks around later who are more familiar with the debian/ubuntu side of things.   I think they may be on california time...
[14:28] <GreatSnoopy> Ill try to stick around or log back in later
[14:48] <smoser> GreatSnoopy, 2 thingsn to check is if the Azure datasource is listed in 'datasources' defined somewhere under /etc/cloud/
[14:48] <smoser> if its not, cloud-init wont look for that (which is kind of what it looks like)
[14:49] <smoser> second, just make sure you *have* a DataSourceAzure.py
[14:51] <GreatSnoopy> smoser: i added now, this datasource:   Azure:     set_hostname: False     agent_command: __builtin__
[14:52] <GreatSnoopy> actually let me put something on a paste
[14:52] <GreatSnoopy> moment
[14:54] <GreatSnoopy> so this https://pastebin.mozilla.org/8979960
[14:54] <GreatSnoopy> does not work, even if i added the two lines with datasource azure
[14:55] <GreatSnoopy> i also have /usr/lib/python2.7/dist-packages/cloudinit/sources/DataSourceAzure.py
[14:55] <GreatSnoopy> now
[14:55] <GreatSnoopy> on this debian there is also
[14:56] <GreatSnoopy> 91_waagent.cfg and 92_azure.cfg
[14:56] <smoser> grep -r datasource /etc/cloud/
[14:57] <GreatSnoopy>   /etc/cloud/cloud.cfg.d/91_waagent.cfg:datasource: /etc/cloud/cloud.cfg.d/90_dpkg.cfg:datasource_list: [ NoCloud, AltCloud, CloudStack, ConfigDrive, Ec2, MAAS, OVF, GCE, None ] /etc/cloud/cloud.cfg:# Example datasource config /etc/cloud/cloud.cfg:# datasource: /etc/cloud/cloud.cfg:datasource:
[14:57] <GreatSnoopy> damn
[14:58] <GreatSnoopy> https://pastebin.mozilla.org/8979963
[14:58] <GreatSnoopy> this is how it looks
[14:59] <GreatSnoopy> damn
[14:59] <GreatSnoopy> i thing it is defined in 90_dpkg and missing from there
[15:04] <rharper> smoser: re cloud-init dpkg deps;  in the merge request, you said that cloud-init doesn't want to depend on those packages directly;  can you elaborate on the rationale/issues ?
[15:04] <smoser> well cloud-init doesn't Depend on systemd-networkd
[15:04] <smoser> right ?
[15:07] <GreatSnoopy> smoser: thanks for that hint, datasources was overriden somewhere i was not expected it to be
[15:12] <rharper> smoser: it's one of those <some networking service to be defined by distro>
[15:13] <rharper> but you're right in that we don't have a way to express the idea that *if* you're using networkd  as your $networking_service *then* you need systemd >= X and resolvconf >= y
[15:14] <smoser> maybe slangasek would have a solution
[15:18] <smoser> rharper, i'm gonna ask in ubuntu-devel
[15:18] <rharper> smoser: ok