=== wCPO5 is now known as wCPO
=== hjensas|afk is now known as hjensas
[13:37] <beantaxi> Hi all. One thing I have yet to find in the docs and code is how to propertly 'install' a cloud config / userdata file. I know how to create the file with cloud-init devel make-mime, and I know how to set userdata with the AWS and lxd CLIs.
[13:38] <beantaxi> But what I don't know is what to do with a userdata file on an arbitrary VM with cloud-init installed. I happen to be using OVHCloud but I believe any VM should work the same. Thanks!
[13:55] <beantaxi> Incidentally, I believe the correct location to be /var/lib/cloud/instance/cloud-config.txt, but that's just an inference from inspecting /var/lib/cloud.
[14:27] <Odd_Bloke> beantaxi: There isn't really a way to specify cloud config from within a booted VM: cloud-init runs during boot (and does many of its operations only on first boot) so by the time you're able to access the machine, cloud-init has already run (or, at least, you'd be racing with it).
[14:28] <smoser> beantaxi: i do think ovhcloud has user-data support in cloud-init. i might be wrong.
[14:28] <smoser> and Odd_Bloke is correct, but after first boot if you wanted to put such user-data down anad reboot, you can accomplish that in one of 2 ways
[14:29] <smoser>  a.) /var/lib/cloud/seed/nocloud/{user-data,meta-data}
[14:31] <smoser>  b.) /etc/cloud/cloud.cfg.d/your-file.cfg  . NoCloud can take user-data or meta-data in its datasource config. trying to find an example of that.
[14:33] <beantaxi> Odd_Bloke: Thank you, and understood, cloud-init will have already run by this point.
[14:33] <smoser> ah. cloud-init/doc/examples/cloud-config-datasources.txt
[14:33] <smoser> that has the syntax for it.
[14:34] <smoser> fwiw, 'a' is what lxc does (so you can see examples in a container)
[14:34] <smoser> but lxc puts those in place before system boot.
[14:38] <beantaxi> smoser: Thanks for the docs link, though I'm sorry to say I'm at a loss for what to make of it
[14:46] <smoser> https://paste.ubuntu.com/p/6PnX4WshWT/
[14:46] <smoser> beantaxi: better ?
[14:46] <smoser> man.. ubuntu pastebin is slow
[14:46] <smoser> or is it just me.
[14:48] <Odd_Bloke> Writing a nocloud seed _could_ be problematic if OVH is expecting cloud-init to honour its networking configuration (and our fallback config doesn't work).
[14:48] <Odd_Bloke> (I think OVH is OpenStack?)
[14:49] <smoser> i think it is openstack, yes. at least at one point in the past they had some openstack options.
[14:52] <beantaxi> cloud-id says 'OpenStack'
[14:54] <beantaxi> smoser: Thank you, that is better and pastebin was slow for me too :) I am not seeing an existing /etc/cloud/cloud.cfg.d/nocloud.cfg; should I? Does any file there get moved on startup?
[14:55] <beantaxi> Incidentally I just checked the lxd source and I can see where it's trying option a). So it sounds like in theory it is actually entirely up to the host system to read and process initial user data, although in practice there are those 2 conventions?
[14:56] <beantaxi> Odd_Bloke: That sounds like an important warning, and enough outside of my expertise to wonder if I'm trying to do something that I oughtn't be doing. Which I suppose is why I started looking for a cloud-init command to handle userdata installation in the first place.
[14:59] <smoser> "host system" ?
[14:59] <smoser> beantaxi: you need to write that file. it doesn't matter the name. just that it end in .cfg.
[15:00] <beantaxi> smoser: Meaning the lxd container, or the OVH VM, or what have you
[15:00] <smoser> its kind of a wierd thing, but nocloud just will read its "metadata" from a confnig file.
[15:00] <smoser> right. cloud-init reads the user-data and meta-data from a number of  places and then acts on it.
[15:01] <smoser> the "platform" (ovh or lxd) provides that information in platform specific ways
[15:01] <smoser> and when we made lxd start providing user-data/meta-data, we just used an already existing mechanism in cloud-init (nocloud)
[15:03] <beantaxi> Would this be a good time for me to confess I think I'm confused by NoCloud? Ie if OVH is OpenStack, and lxd is lxd, then I would have expected NoCloud to not factor in, so apparently I'm wrong about NoCloud
[15:10] <beantaxi> Perhaps the idea is that the method you suggest would effectively make my OVH instance NoCloud rather than OpenStack. Also, from looking at these NoCloud docs, I wonder if I can skip the instance-id specification by specifying a metadata_url, and if I can avoid the network config problem OddBlock seemed to allude to by setting apply_network_config: true
[15:11] <beantaxi> (whoops - OddBloke not OddBlock. Sorry OddBloke!)
[15:12] <beantaxi> Sorry, I was looking at the OpenStack docs, not the NoCloud docs, on my comments above.
[15:22] <Odd_Bloke> beantaxi: So generally we would expect users to specify user-data to OVH; OVH should make it available via the OpenStack metadata service (or config drive) and cloud-init will process it.  Is the issue that OVH don't allow you to do this, or is there something more complex that you're trying to do?
[15:23] <Odd_Bloke> If the latter, then a step back to explain what you're trying to achieve might make it easier for us to help. :)
[15:43] <beantaxi> Fair enough :) I was looking to write a script, that I'm literally calling bluepill.sh, that I can upload to a server w OpenCloud, reboot, and when the VM 'wakes up' it's been configured
[15:43] <beantaxi> As a first step I've been looking for where I would upload a userdata file to allow for configuration. But it's looking like there is no generally effective way of doing that across data sources
[15:44] <beantaxi> or platforms
[15:45] <fishfry> I need help understanding setting up network interfaces with cloud init. KVM based VM  it looks like I should use netplan syntax to define the interface.  is that correct?
[15:46] <fishfry> how do I control the Ethernet device names or discover them so I have the right names on the configuration?
[16:54] <Odd_Bloke> beantaxi: Yeah, unfortunately our assumption is that user-data comes from the cloud (via the appropriate data source).  So you could use NoCloud, as we've discussed, but then you'll lose the cloud-specific features of the data source that you're switching away from.  Whether that's acceptable will vary across platforms (and perhaps even deployments of platforms in the case of OpenStack): the Azure
[16:54] <Odd_Bloke> datasource does some quite specific things to get Azure instances up properly, for example.
[16:57] <Odd_Bloke> It's also tricky because many cloud-init config modules aren't idempotent (because cloud-init handles only calling them when appropriate), so re-running cloud-init yourself can have unexpected consequences (e.g. cc_ssh is responsible for both installing authorized keys and cycling host keys: you can't provide configuration which will only cycle host keys the first time cc_ssh runs but install authorized
[16:57] <Odd_Bloke> keys on every run).
[16:57] <Odd_Bloke> Something like `cloud-init single --config my_config.yaml <module name>` might be interesting for this case.
[17:53] <beantaxi> Odd_Bloke: Thank you so much for the detail. It sounds like what I want to do is not possible, for two reasons: 1. there is not a common way of specifying/installing initial userdata, but rather a number of vendor-specific ways, and 2. many modules are not designed to be run more than once anyway.
[17:55] <beantaxi> From my first-ever cloud-init chat, with rharper back in August, the following 2 commands were suggested
[17:56] <beantaxi> `cloud-init --debug --file my-cloud-config.cfg single --name cc_write_files --frequency=always`, which I guess is the closest thing to cloud config installation ... and
[17:56] <Odd_Bloke> Oooh, OK, I missed --file because it's not in `single --help`, it's in the `cloud-init --help`.
[17:57] <Odd_Bloke> That's what I was thinking the addition of `--config` would do, it makes sense we already have it!
[17:57] <beantaxi> `cloud-init --debug single --name cc_scripts_user --frequency=always` to run the scripts
[17:57] <beantaxi> I'm unclear on what --frequency=always does ... perhaps it means 'ignore any semaphores etc that say this has already run - run it anyway!'
[17:58] <Odd_Bloke> beantaxi: So if you have a specific subset of config modules that you want to run which don't do anything destructive (from your usecase's POV at least), I think that's possible with single and --file; if you want a generic "apply this cloud-config to a running instance" then I think you'll have more problems.
[17:59] <Odd_Bloke> Yep, that's what --frequency=always does.
[18:00] <Odd_Bloke> cc_write_files would be fine, as would cc_scripts_user (from a cloud-init perspective: obviously the scripts themselves could do something undesirable but if they do that's on you ;).
[18:09] <beantaxi> Odd_Bloke: Thank you very much (again). It sounds like I actually might be ok ... because as it turns out, I'm really just looking for a way to run initialization scripts, which is the only part of cloud-init I halfway understand at present.
[18:10] <beantaxi> So it sounds like my ambitions of 'run cloud-init as if for the first time!' are nowhere near necessary for my use case, because initialization scripts are just a subset of what cloud-init can do, and it's sort of the easy part.
[18:12] <beantaxi> My cloud-init fu is not Strong enough to think in terms of individual modules, though I might be starting to gain that understanding. It sounds like all I need are two modules, write-files and cc_script_user. And running them will not hide the fact that my VM 'has a past', and whether or not that's ok simply varies with the use case.
=== ijohnson is now known as ijohnson|lunch
[19:51] <blackboxsw> Odd_Bloke: thanks for the review on the integration tests Azure PR. I'm not sure what you'd prefer we do, discussion on the PR here  https://github.com/canonical/cloud-init/pull/798#discussion_r578702675
[20:24] <Odd_Bloke> beantaxi: Yep, that sounds about right to me; apologies for the brief confusing detour because _my_ cloud-init fu didn't include `--file`. :)
[20:33] <Odd_Bloke> blackboxsw: Thanks!  I've replied.
=== ijohnson|lunch is now known as ijohnson
[22:51] <Odd_Bloke> Oh dear, the apt tests are broken on xenial LXD VMs because they configure squid.internal as a proxy which means when we try to install openssh-server (because we aren't using Ubuntu cloud images), we hit errors.