| === Wulf4 is now known as Wulf | ||
| 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:37 |
| 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:47 |
| hendry | magicalChicken: thank you, though is it in the documentation? | 03:48 |
| hendry | was curious to figure out what was the default too | 03:48 |
| 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:49 |
| 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:55 |
| * hendry wonders what the difference is between repo_upgrade: all and package_upgrade: true | 03:59 | |
| hendry | https://twitter.com/kaihendry/status/750178637026996224 | 04:16 |
| === Wulf4 is now known as Wulf | ||
| === rangerpbzzzz is now known as rangerpb | ||
| === rangerpb is now known as rangerpbzzzz | ||
| === rangerpbzzzz is now known as rangerpb | ||
| mgagne | smoser: so I tested cloud-init with baremetal and found that Nova does not use vlan_mac_address but ethernet_mac_address | 18:09 |
| rharper | mgagne: do you have your network_data.json and the network config it rendered ? | 18:52 |
| mgagne | rharper: it failed to render with a KeyError | 19:00 |
| 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:04 |
| 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:05 |
| mgagne | and provider implementing the spec are using ethernet_mac_address, not vlan_mac_address. | 19:06 |
| 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:07 |
| 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:08 |
| mgagne | jroll: ^ do you know if rax provides mac address for VLAN interfaces in config drive? if so, in which field? | 19:11 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| mgagne | oh, I know why | 19:29 |
| 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:30 |
| rharper | interesting | 19:31 |
| 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:36 |
| rharper | that looks about right =( | 19:38 |
| harlowja | mgagne start contributing to the upstream cloud-init one ;) | 20:13 |
| harlowja | shouldn't be a need for a custom version anymore | 20:13 |
| 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:14 |
| harlowja | ya, that render helper thing is useful for seeing exactly wtf is gonna be output given a network_data.json | 20:15 |
| harlowja | and yes mgagne u should let me know if that thing has rendering issues | 20:29 |
| === rangerpb is now known as rangerpbzzzz | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!