=== msg is now known as Guest6571 === msg is now known as Guest4073 === msg is now known as Guest6663 === msg is now known as Guest68033 === msg is now known as Guest71432 === msg is now known as Guest31912 === msg is now known as Guest22659 === msg is now known as Guest17266 === msg is now known as Guest45695 [13:45] hello everybody [13:45] anybody here using cloud-init + microsoft azure + debian (credativ image) ? [13:47] It is never able to fetch its userdata [13:47] i think its not able to autodetect the platform [13:59] GreatSnoopy: what version of cloud-init are you using? [14:04] loud-init --version cloud-init 0.7.6 [14:05] what it does is gets to a point where it does [14:05] 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] and on and on [14:05] it looks like its not able to deduce it needs an azure datasource [14:05] i have waagent installed [14:07] interestingly, on a centos instance, it does not get stuck to "Calling ..." [14:08] also, waagent does get the userdata, but somehow cloudinit is not able to interact/fetch waagent data [14:10] 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] Do you have the option of using a more recent version? [14:11] larsks: should i try with a newer one ? [14:11] sure,ill try [14:11] weirdly on centos, I have an OLDER version [14:11] and it works :| [14:11] 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] 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] i see nothing relevant [14:12] i can even post that log maybe one of the devs can spot something i miss [14:13] 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] # pwd ; ls -1 /var/lib/cloud/instances iid-datasource-none [14:14] yes, my assumption is it does not know its on azure [14:14] tried making sure we have dmidecode and virt-what to help it [14:14] does not help [14:15] can the debug turned up for the platform detection itself ? [14:15] or for the datasource interaction ? [14:16] 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] Usually it's pretty verbose by default, I thought. [14:18] hm, found this [14:19] 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] i see no azure there [14:19] on the other hand on centos there is not a line like that at all [14:24] GreatSnoopy: does your configuration include an explicit list of data sources? E.g. in /etc/cloud/cloud.cfg (or cloud.cfg.d)? [14:24] Does the package include the Azure data source? [14:25] larsks: not as far as i know, its debian default [14:26] 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] Ill try to stick around or log back in later === rangerpbzzzz is now known as rangerpb === msg is now known as Guest45919 [14:48] GreatSnoopy, 2 thingsn to check is if the Azure datasource is listed in 'datasources' defined somewhere under /etc/cloud/ [14:48] if its not, cloud-init wont look for that (which is kind of what it looks like) [14:49] second, just make sure you *have* a DataSourceAzure.py [14:51] smoser: i added now, this datasource: Azure: set_hostname: False agent_command: __builtin__ [14:52] actually let me put something on a paste [14:52] moment [14:54] so this https://pastebin.mozilla.org/8979960 [14:54] does not work, even if i added the two lines with datasource azure [14:55] i also have /usr/lib/python2.7/dist-packages/cloudinit/sources/DataSourceAzure.py [14:55] now [14:55] on this debian there is also [14:56] 91_waagent.cfg and 92_azure.cfg [14:56] grep -r datasource /etc/cloud/ [14:57] /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] damn [14:58] https://pastebin.mozilla.org/8979963 [14:58] this is how it looks [14:59] damn [14:59] i thing it is defined in 90_dpkg and missing from there [15:04] 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] well cloud-init doesn't Depend on systemd-networkd [15:04] right ? [15:07] smoser: thanks for that hint, datasources was overriden somewhere i was not expected it to be [15:12] smoser: it's one of those [15:13] 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] maybe slangasek would have a solution [15:18] rharper, i'm gonna ask in ubuntu-devel [15:18] smoser: ok === msg is now known as Guest33828 === msg is now known as Guest71630 === msg is now known as Guest29178 === msg is now known as Guest55967 === rangerpb is now known as rangerpbzzzz