[03:37] <hendry> hi guys, looking for a way to turn off ssh password authentication
[03:37] <hendry> saw mention of ssh_pwauth, but I can't find it in the docs
[03:37] <hendry> do you guys seriously still use bzr? https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
[03:47] <magicalChicken> hendry: just setting 'ssh_pwauth: false' in config should disable it. its handled in cc_set_passwords.py around line 100 if you want to see the details
[03:48] <hendry> magicalChicken: thank you, though is it in the documentation?
[03:48] <hendry> was curious to figure out what was the default too
[03:49] <magicalChicken> i searched the docs and I don't think its there
[03:49] <magicalChicken> I think the default is to just preserve whatever the distro default is
[03:49] <magicalChicken> which I think for ubuntu is true
[03:55] <hendry> magicalChicken: shouldn't that be raised as a bug perhaps? that's its not documented?
[03:55] <magicalChicken> yeah, probably, there's some other documentation that needs to be updated too
[03:59]  * hendry wonders what the difference is between repo_upgrade: all and package_upgrade: true
[04:16] <hendry> https://twitter.com/kaihendry/status/750178637026996224
[18:09] <mgagne> smoser: so I tested cloud-init with baremetal and found that Nova does not use vlan_mac_address but ethernet_mac_address
[18:52] <rharper> mgagne: do you have your network_data.json and the network config it rendered ?
[19:00] <mgagne> rharper: it failed to render with a KeyError
[19:04] <rharper> mgagne: ok, so there's a vlan device but no vlan_mac_address key in the json
[19:04] <rharper> or that's my guess without seeing the network_data.json
[19:04] <mgagne> yea, it is ethernet_mac_address
[19:04] <rharper> well that's odd
[19:04] <mgagne> not vlan_mac_address
[19:04] <rharper> to have ethernet_mac_address under vlan device ?
[19:04] <mgagne> I don't think that's the point
[19:05] <mgagne> https://github.com/jayofdoom/cloud-init-fedora-pkg/blob/master/cloud-init-0.7.5-onmetal-configdrive.patch#L103-L104
[19:05] <mgagne> https://github.com/openstack/nova/blob/master/nova/virt/netutils.py#L261
[19:05] <mgagne> there is no special case for vlan
[19:06] <mgagne> and provider implementing the spec are using ethernet_mac_address, not vlan_mac_address.
[19:07] <mgagne> in fact, I found that glean supports both
[19:07] <mgagne> https://github.com/openstack-infra/glean/blob/master/glean/cmd.py#L514-L515
[19:07] <mgagne> or I misinterpreted it
[19:08] <mgagne> what do you think?
[19:08] <rharper> I'm checking some doc;  I had at least one example where the data included a vlan_mac_address
[19:11] <mgagne> jroll: ^ do you know if rax provides mac address for VLAN interfaces in config drive? if so, in which field?
[19:18] <rharper> mgagne: AFAICT, vlans can have a uniq mac, if they want;    if the type: vlan didn't include vlan_mac_address or ethernet_mac_address, then the vlan interface would get the mac from the vlan_link interface it runs on top of;  in your case, I think we should at least check for either vlan_mac_address or ethernet_mac_address in the type:vlan dictionary;
[19:19] <mgagne> rharper: right so this could fallback gracefully to the "raw" interface mac address? I'm not sure of the impact of such change tbh
[19:20] <rharper> mgagne: well, it would omit including a hwaddress under the vlan interface
[19:20] <mgagne> I'm more or less concerned about what should be the name of this field as I saw implementation differing from spec
[19:20] <rharper> well
[19:20] <rharper> it could be called 'mac_address'
[19:20] <rharper> and it's properly scoped under a type: ethernet  or type: vlan
[19:20] <mgagne> it's already ethernet_mac_address in code
[19:21] <rharper> in our model, in either case, if when rendering a type: x, it shows up as an interface property
[19:21] <rharper> the spec didn't cover vlans IIRC, no ? just mentioned them in passing
[19:21] <rharper> in the examples show, they were type: ethernet devices and then included the 'ethernet_mac_address' field
[19:22] <mgagne> rharper: yea, they mentioned it in the example which happened to be a "strong" reference when writing the implementation
[19:22] <rharper> right
[19:22] <mgagne> but as you saw, they followed part of it
[19:22] <mgagne> they renamed neutron_network_id for network_id and didn't update the spec
[19:23] <mgagne> and now we also have out of tree implementation floating around (including mine)
[19:23] <rharper> right, and others
[19:23] <rharper> rackspace/ironic  (which is where I got the vlan_mac_address) for their type: vlan
[19:23] <mgagne> which I happened to write to fit the rax's cloud-init fork implementaiton
[19:24] <mgagne> rharper: there is no mention of vlan_mac_address in their implementation in cloud-init. Do you happen to have access to a config drive generated at rax?
[19:24] <rharper> I'm not certain what we should do w.r.t the spec lacking specification other than be widely accepting in *mac_address
[19:24] <mgagne> will check bifrost
[19:24] <rharper> mgagne: I have the network_data.json , is that good enought ?
[19:24] <mgagne> I'm sure it contains all that's needed
[19:25] <mgagne> I'm happy to change my implementation if the consensus happens to be vlan_mac_address
[19:25] <mgagne> well... https://github.com/openstack/bifrost/blob/fa5f65adeff340f8415be46754cb327a3912852d/playbooks/library/network_metadata.py#L83
[19:25] <rharper> honestly, it'd be nice to drop the prefix, since the field is under a type: XXX dictionary
[19:25] <mgagne> looks like I was wrong =()
[19:26] <mgagne> true
[19:26] <rharper> I have ethernet, bond and vlan dictionaries
[19:26] <rharper> each which *could* have a mac_address value, and it's scoped per-interface anyhow;
[19:26] <mgagne> but it's a public "api" and changing implementation is close to impossible to make for "don't break end user interface"
[19:26] <mgagne> ok, will update my implementation I guess
[19:26] <rharper> http://paste.ubuntu.com/18575659/
[19:27] <rharper> that's the rax one we got with ipv6 , bonding, and vlans
[19:27] <mgagne> cool, looks like it's vlan_mac_address
[19:27] <mgagne> but
[19:27] <mgagne> I'm sure it used to be ethernet_mac_address =)
[19:28] <rharper> yeah, and I'd +1 updating spec to just be 'mac_address' under type: X
[19:28] <mgagne> because otherwise this would make no sense: https://github.com/jayofdoom/cloud-init-fedora-pkg/blob/master/cloud-init-0.7.5-onmetal-configdrive.patch#L277
[19:28] <rharper> mgagne: yeah, that wouldn't work with the mismatch
[19:28] <mgagne> so I guess I will include both for now until I fix all my images :-/
[19:29] <mgagne> oh, I know why
[19:30] <mgagne> it used to be in vendor_data.json
[19:30] <mgagne> and now it's in network_data.json which happens to respect the new approved spec
[19:31] <rharper> interesting
[19:36] <mgagne> so to conclude: cloud-init implementation is right. old implementation by rax is wrong when used against upstream Nova implementation (but not against their own vendor implementation)
[19:36] <mgagne> and I'm stuck in the middle :D
[19:38] <rharper> that looks about right =(
[20:13] <harlowja> mgagne start contributing to the upstream cloud-init one ;)
[20:13] <harlowja> shouldn't be a need for a custom version anymore
[20:14] <harlowja> and with https://code.launchpad.net/~harlowja/cloud-init/cloud-init-render-tool u can test the rendering(s) before using it
[20:14] <mgagne> waiting for git repo (muhaha)
[20:14] <harlowja> ah, smoser ^^^^^
[20:14] <harlowja> ding a ling
[20:14] <harlowja> lol
[20:14] <rharper> nice
[20:15] <harlowja> ya, that render helper thing is useful for seeing exactly wtf is gonna be output given a network_data.json
[20:29] <harlowja> and yes mgagne u should let me know if that thing has rendering issues