| ananke | smoser: thanks! that's exactly what I was considering. what are those key words with & in front of them? I've never seen that nomenclature | 00:26 |
|---|---|---|
| ananke | eg: write_launch_info | 00:26 |
| ananke | ahh, it's some kind of labels | 00:26 |
| ananke | ohh, this is nifty | 00:28 |
| ananke | smoser: what's the significance of 'sm_misc'? I can't find any reference to that in cloud-init's docs | 00:30 |
| ananke | nevermind, that was too obvious :) | 01:34 |
| smoser | ananke: they're called 'anchors' | 01:59 |
| smoser | sm_misc means nothing, just a namesapce. | 01:59 |
| smoser | it is hard to search for | 01:59 |
| ananke | smoser: thanks for the hints. I've been able to use similar approach and get it working. I do have one question: why are those labels/anchors sometimes referred as '*something' and sometimes as 'something'? | 13:46 |
| ananke | I'll try to read more about anchors & aliases, perhaps I'm missing something obvious | 13:48 |
| smoser | ananke: always need the & to refer to it. | 13:59 |
| smoser | err... sorry. the * to refer to it, the & to name it. | 13:59 |
| smoser | fwiw, 'sm_misc' is just 'smoser misc' | 14:01 |
| ananke | smoser: yeah, my 'too obvious' comment was related to figuring out what sm_misc stood for :) took me too long to figure that out. | 15:47 |
| ananke | smoser: as to the alias reference, I was just confused by some of the nomenclature where I saw the same things appear twice. eg: - [sh, -xc, *write_exe, write_apt_go_fast, apt-go-fast, *apt_go_fast] | 15:48 |
| ananke | I have a hard time figuring out how this maps out exactly, what is 'apt-go-fast' doing there as a list item | 15:49 |
| Odd_Bloke | ananke: That's a `sh` thing. *write_exe is the command_string, write_apt_go_fast is the command_name, and then everything else (apt-go-fast, *apt_go_fast) are arguments to command_string. | 15:51 |
| Odd_Bloke | ananke: (Those names come from the dash man page, I didn't just know them off the top of my head :p https://linux.die.net/man/1/dash) | 15:52 |
| Odd_Bloke | The command name throws me almost every time. | 15:52 |
| ananke | ahh, thanks. the naming convention was throwing me off, and made me question what I thought was a YAML reference and what wasn't | 15:54 |
| ananke | on an unrelated note, is there a way to access the name of the cloud provider from within the user-data config? I'd like to have some conditional logic for when a given recipe is executed against 'nocloud' platform | 15:58 |
| ananke | I'm already writing the recipe as a jinja template | 15:59 |
| smoser | yeah, sh command thing is a pain. | 15:59 |
| smoser | with sh -c 'shell commands blob here' | 16:00 |
| smoser | the *next* argument will be the "command name". | 16:00 |
| smoser | if you don't give it one, '$*' and '$1' and the like aren't going to work as expected (they'll be off by one) | 16:00 |
| smoser | so i try to give it one that would make some sense in a 'ps' | 16:01 |
| smoser | other times you'll see people use '--' or '-' ... but those seem no more descriptive to me | 16:01 |
| smoser | maybe 'this-is-argument-zero-just-ignore-it' | 16:01 |
| ananke | ahh, that's good to know. thank you | 16:06 |
| robjo | lunch | 17:15 |
| robjo | back | 17:55 |
| meena | hello, i'm alive; i'll be writing some patches / fix some of my prs | 19:27 |
| blackboxsw | saving the world one PR at a time :) | 19:28 |
| meena | cloning freebsd and freebsd-ports | 19:55 |
| meena | at the same time. | 19:56 |
| meena | my computer is unimpressed | 19:56 |
| meena | so, import distro patches: https://github.com/canonical/cloud-init/pull/161 | 20:12 |
| meena | rebase https://github.com/canonical/cloud-init/pull/53 and throw out the integration test. @skipUnlessFreebsd stays, however. in case it might be needed later. | 20:13 |
| meena | soooooooooooooo… has anyone had any time to give my thoughts over at https://hackmd.io/3-YBj1t9TAeKhmfLBQUjXQ?view | 20:18 |
| meena | the silence is deafening 😜 | 20:38 |
| rharper | meena: I left some comments on your hackmd doc, and reviewed your PR | 20:44 |
| meena | uninstalled DejaVu and now my emoji are displayed now | 20:46 |
| meena | rharper: i'm not sure i understand this: https://github.com/canonical/cloud-init/pull/53#pullrequestreview-340801051 | 20:52 |
| meena | ah | 20:52 |
| ProfFalken | Hey all, I'm running Cloud-init 18.5 from EPEL on a custom CentOS 7 box in DigitalOcean, and I don't appear to have access to the network interface information. | 20:53 |
| ProfFalken | I'd expect it to be at ds.meta_data.interfaces or similar, but that key doesn't even exist | 20:53 |
| ProfFalken | (but it does exist for an Ubuntu server) | 20:53 |
| ProfFalken | Any ideas what might be causing this? | 20:53 |
| Odd_Bloke | ProfFalken: Are they both using the same datasource? (`cloud-init status --long` will tell you the DS in use.) | 20:56 |
| blackboxsw | ProfFalken: and `cloud-init query --all` will show all the instance metadata obtained. `cloud-init query --format '{{ds.meta_data.keys()}}'` will show all keys present by datasource's scraped metadata. | 20:58 |
| robjo | rharper: More fun with networking https://github.com/canonical/cloud-init/pull/162 | 21:01 |
| blackboxsw | ProfFalken: from https://github.com/canonical/cloud-init/blob/master/cloudinit/sources/DataSourceDigitalOcean.py#L68L74 it looks to me like it attempts to pull that metadata content if present regardless of distribution type. | 21:02 |
| Odd_Bloke | blackboxsw: If they aren't using the same data source, that doesn't matter. :) | 21:02 |
| blackboxsw | right. good pt | 21:03 |
| robjo | This should get us to "clean" ifcfg-*" files, i.e. only options understood on the given distro RHEL or SUSE get written to the files, it solves the BOOTPROTO handling bug, and gets the SUSE ifcfg-* files closer to what they should look like for bonding, vlan and bridge configs | 21:03 |
| blackboxsw | Odd_Bloke: also, if it didn't exist, and they were actually using the DO datasource, network_config would have died horribly: raise Exception("Unable to get meta-data from server....") | 21:04 |
| rharper | robjo: thanks | 21:04 |
| robjo | After we get this through I'll come back with a proposal for route writing and then DNS handling after that | 21:04 |
| ProfFalken | Odd_Bloke / blackboxsw: sorry, got dumped out there for a minute, anyway, it looks like it's because I'm running my own custom images, not ones provided by DO, because a DO CentOS box is running the DO datasource | 21:04 |
| ProfFalken | I'm talking to them now, if they manage to fix it then I'll let you know, but I'm going to assume it's a DO issue, not a Cloud-init one. Thanks for the pointers :) | 21:05 |
| meena | rharper: fixed | 21:05 |
| rharper | meena: excellent | 21:06 |
| blackboxsw | yeah ProfFalken, I think Odd_Bloke was coming to that conclusion per his suggestion about status --long. Your custom images should probably derive from latest DO CentOS images, or you could alternately try adding a /etc/cloud/cloud.cfg.d/99-mandate-digitalocean-datasource.cfg file which would provide "datasource_list: [DigitalOcean]" | 21:07 |
| blackboxsw | that was cloud-init would default to DigitalOcean on your custom images (if you were rolling your own for digital ocean specifically) | 21:07 |
| blackboxsw | I *think( | 21:07 |
| ProfFalken | blackboxsw: oh, that's a neat trick, I'll have a look at that, thanks. And yes, we are rolling our own for DO (and will be for other cloud providers as well) - we need a specific disk layout amongst other things, so this could be awesome if it works, I'll try it now... | 21:08 |
| blackboxsw | ProfFalken: generally cloud-init should be able to detect the right datasource, so you shouldn't have to 'pin' a specific one for each image you create. So something else may be going on there (check your /var/log/cloud-init.log and /run/cloud/ds-identify.log to see why detection of DigitalOcean datasource didn't work for cloudinit) | 21:12 |
| ProfFalken | I'm being told it's something to do with the way DO have their networking configured, I'm trying to get more details now... | 21:14 |
| blackboxsw | +1. may end up being a cloud-init bug/feature then | 21:15 |
| ProfFalken | interestingly, curl http://169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address returns the expected data | 21:16 |
| ProfFalken | so it's when I'm trying to use the YAML for Cloud-Config, or querying via the CLI that it's not being seen | 21:17 |
| Odd_Bloke | ProfFalken: The cloud-config and `query` command use cloud-init's cached state. | 21:22 |
| Odd_Bloke | So that suggests to me that it isn't using the DO datasource, so cloud-init never goes to fetch the DO-specific configuration (which is then, of course, not present in cloud-init's cache). | 21:22 |
| ProfFalken | apparently the "solution" is to use a bash-script rather than the YAML, which makes the config more complicated, but if it works... :( | 21:23 |
| ProfFalken | ah, ok | 21:23 |
| rharper | I don;t believe we expose the datasource network_config in the instance data; further; in insttance metadata that we persist, the datasource must have a 'network_json' value | 21:23 |
| Odd_Bloke | rharper: The assertion is that it works on Ubuntu but not on CentOS. And it's under the meta_data key, so I think that's whatever the datasource wants to put in there? | 21:24 |
| rharper | well, Ubuntu vs Centos almost always works out to cloud-init version differences | 21:24 |
| Odd_Bloke | (i.e. I believe that's DO network configuration, not v1 or v2 YAML) | 21:24 |
| ProfFalken | Odd_Bloke: FWIW, DO appear to be in agreement with you | 21:26 |
| rharper | Odd_Bloke: I guess what I was getting at (which may not be ProfFalken issue) is we currently don't consitently persist network metadata from platforms in a consistent place; which would be a nice feature improvement to the instance-metadata.json | 21:26 |
| Odd_Bloke | rharper: Agreed. | 21:26 |
| ProfFalken | I'm trying a switch over to using bash instead of using cloud-config, I'll see how it goes | 21:26 |
| Odd_Bloke | ProfFalken: If it's working on Ubuntu but not on CentOS, I don't believe you should have to switch, but if you'd prefer to stick with DO's advice then I'm happy to defer. | 21:27 |
| Odd_Bloke | (AFAICT, the DO datasource hasn't changed since 18.5, which was the version you're using on CentOS, I believe?) | 21:27 |
| rharper | Odd_Bloke: https://github.com/canonical/cloud-init/pull/53 ; I'm happy with this branch, it has a "Request changes" from you; could you take a peek and see if you're happy as well ? | 21:29 |
| Odd_Bloke | Sure thing. | 21:29 |
| ProfFalken | Odd_Bloke: I'll give it a go and see what happens, but there does seem to be something "not quite right" on the DO side of things here | 21:30 |
| * rharper grumbles about "vendor-data" | 21:31 | |
| Odd_Bloke | meena: Sorry, one last request on #53. | 21:41 |
| meena | Odd_Bloke: fair enough | 21:42 |
| meena | Odd_Bloke: done | 21:44 |
| Odd_Bloke | Thank you! | 21:51 |
| meena | i've also re-reviewed goneri's netbsd branch, maybe someone with more python / cloudinit experience might wanna rein in my review | 21:57 |
| ProfFalken | Odd_Bloke / blackboxsw: The bash-script approach has got me up and running again, thanks again for all your help, I'll take it up with DO and see if they can get it sorted on their end! :) | 21:58 |
| meena | always good approach… | 22:01 |
| * meena has spent about a year or more to get FreeBSD running on Hetzner | 22:02 | |
| meena | somebody pls merge all my patches | 22:06 |
| meena | This pull request can be automatically merged by project collaborators | 22:07 |
| meena | anyway, bed time. | 22:10 |
| === tds9 is now known as tds | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!