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