[14:10] what does the ~ mean in cloud.cfg values? [14:12] my machine comes with a cloud.cfg with "ssh_genkeytypes: ~" [14:13] as well as "syslog_fix_perms: ~" and a couple of other instances [14:25] oh, it's a YAML construct [16:23] copumpkin, yeah. yaml has some nice things [16:23] yeah, somehow I've been writing yaml for ages and never came across the tilde :) [16:23] i didn't know that '~' is same as null [16:24] yeah, not sure who produced the cloud.cfg with it in there [16:24] it's the default cloud.cfg for centos AMIs on ec2 [16:24] [somewhat related] anchors are very useful in yaml [16:24] yeah, I've dealt with those [16:25] although I start preferring jsonnet or nix when it comes to that [16:27] http://paste.ubuntu.com/16686200/ [16:27] i dont know jsonnet or nix [16:28] think json/YAML withs slightly different syntax, explicit variable binding, and functions [16:28] makes it very pleasant to do repetitive things [16:28] http://jsonnet.org/ and http://nixos.org/nix [16:29] yeah, jsonnet looks nice. [16:30] nix is a package manager ? [16:30] how does that have to do with json or yaml ? [16:31] yeah, but it's also a language with very similar behavior to jsonnet (basically the same thing with a different syntax), which they use to specify all their packages in [16:31] basically a purely functional lazy language for defining config (no side effects, file writing, or any of that junk) [16:32] I actually prefer it to jsonnet, but it's a less obvious match than jsonnet because nobody really thinks of it as a standalone language [17:52] rharper not much response on that thread, thinking i'll just go ahead and make a versioned openstack 'converter' [18:34] harlowja: I think so; someone we have 3 reasonable ppl saying bug [18:34] so versioned converter makes sense [18:34] k [18:34] in your branch I think [18:34] sure [19:04] if I'm writing my own cloud-init module, is there a simple way to query the instance ID? [19:04] I could hit 169.254.169.254 directly, but that doesn't account for the various other ways cloud-init could get an instance ID [19:07] aha, cloud.get_instance_id() looks promising [19:15] or 'cat /var/lib/cloud/data/instance-id' [19:17] is there a reason to do that over get_instance_id()? [19:18] nah, if u are writing python code modules then probably prefer get_instance_id [19:19] cool, thanks [20:45] harlowja: on the network_data.json, should we propose a fix to those drivers (ovs and linuxbridge) and have them emit type: vif in their metadata hook ? [20:46] in nova u mean rharper ? [20:46] would seem to make sense to me [20:47] yeah or neutron; where ever those backends live [20:47] https://github.com/openstack/nova/blob/master/nova/virt/netutils.py#L172 is where the json gets made [20:47] yeah [20:47] seems like https://github.com/openstack/nova/blob/master/nova/virt/netutils.py#L250 just needs to be not just ethernet :-P [20:47] but vif.get('type') in ['ethernet', 'vlan', 'vos'] [20:48] or something like that? [20:48] the vif .type attribute is the deal [20:48] yeah, hard to say if the metadata should fix it up or if there's some other attribute that should be set (like guest visible vif_type) ? [20:48] agreed [20:48] the mapping in netutil is easy; not sure if we should push further up [20:48] in the model [20:49] agreed [20:49] k [20:49] can just propse a patch, see if it gets shot down :-P [20:49] * rharper adds something else to poke at [20:49] u or i can, ha [20:49] haha [22:51] rharper https://gist.github.com/harlowja/12e0a56ff0ee0182cc943f966bef8ec0 [22:51] should fix that issue