[02:46] <davido> Hi. Looking for some guidance  on the correct way to capitalize "cloud-init" in different use cases.
[02:47] <davido> Obviously enough if you're talking about commands or package names or whatever they must reflect the command. What about generally speaking?
[02:47] <davido> "What is cloud-init?" vs "What is Cloud-init?"
[02:47] <davido> https://cloudinit.readthedocs.io/en/latest/
[02:48] <davido> Heading is "cloud-init Documentation" but the first line starts "Cloud-init"
[02:49] <davido> I'm editing documentation and training and want to make sure I get it right.
[02:49] <davido> thanks
[14:31] <Odd_Bloke> davido: From https://cloudinit.readthedocs.io/en/latest/topics/docs.html#common-words, "always lower case with a hyphen, unless starting a sentence in which case only the ‘C’ is capitalized" :)
[15:39] <beantaxi> Good morning all! Thought I'd check in on PR #745, which I think is ready from my end, and #833, which is new and I'm not sure what my next step is; I don't see reviewers assigned and if I forget if I'm expected to add reviewers or if it's better to just wait. Thanks!
[16:09] <falcojr> beantaxi: I took a look at 745 this morning and I think it looks good. I think it could use an integration test too, but there will be a few gotchas for this particular functionality, so I can add that myself (so don't expect it to merge right away)
[16:14] <falcojr> for 833, it's better to just wait unless you have a particular reason for wanting a particular reviewer (like an earlier discussion here on IRC or a follow-up to another PR). One of the committers will usually pick up new open reviews when we have the time
[16:17] <beantaxi> falcojr: That sounds good on both fronts. On 833, there is some obvious room for improvement, but I figured if I've written some Docker testing stuff to help myself, then so have other peeople, and theirs might be better, in which case their stuff might obviate mine. So I submitted the PR to submit the idea, as much as anything, though I'm happy to pursue my submission if that's how it goes.
[16:19] <beantaxi> For #745, I agree, & I feel a little skittish about the lack of integration test, but tbh I don't know how to write one for #745. I'm happy to do so, if somoene (eg you) is willing to answer some questions.
[16:29] <beantaxi> I suppose a nice convincing test would launch a venv, install latest cloudinit including the PR, run a few cloudinit devel make-mime commands, confirm that userdata looks right, then run cloud-config (I think?) on a test/mock cloudinit-enabled VM with the new userdata, and confirm the freq-specific scripts get copied to the right folder(s).
[16:29] <beantaxi> But this would require quite a bit of scaffolding, which I assume has already been written ... either that, or it hasn't, and none of that is considered necessary.
[16:58] <falcojr> beantaxi: I commented about integration testing directly on #745 so to have it a place a little less ephemeral
[17:03] <falcojr> also re: 833, not sure we'd be against dockerfiles per se, but LXD and multipass are generally easier ways of testing changes. We use LXD quite extensively
[17:03] <falcojr> https://cloudinit.readthedocs.io/en/latest/topics/faq.html#how-can-i-debug-my-user-data
[17:21] <beantaxi> falcojr: I love LXD, advocate for LXD professionally as often as I can,  and I credit @rharper for steering me to LXD in my first ever #cloud-init convo back in August
[17:23] <beantaxi> But my thinking was that folks who develop on OSX (and Windows I guess) would have to do a fair amount of work to test via LXD on their workstation.
[17:26] <falcojr> yeah, it's helpful to understand that perspective
[17:27] <Odd_Bloke> Docker provides app containers, so doesn't match the target environment that cloud-init runs in.
[17:28] <beantaxi> Thanks very much for your comment on #745 and for help in getting an integration test started. Thank you also for acknowledging that what you're suggesting is a decent chunk of work. I agree :) but it's all stuff I'd like to learn anyway.
[17:29] <beantaxi> I'm happy to take this week to try and get through it, and reconnect early next week?
[17:29] <Odd_Bloke> So Docker's isolation could be helpful for some development cases, but it doesn't provide an appropriate environment for integration testing of cloud-init.
[17:30] <Odd_Bloke> (The most obvious disconnect is that cloud-init expects to be invoked 4 times during boot by the init system, and most Docker containers don't have an init system.)
[17:31] <beantaxi> Odd_Bloke: Agreed. Docker has been very useful to me in running flake8/pylint/pytest before committing, and saved commits and Travis wait times. Beyond that it would be less useful.
[17:32] <beantaxi> And even anti-useful. That said, I have a browser-tab open, where some folks at hypriot seem to be using something called NextCloud to use cloud-init in Docker containers to make their lives all kinds of easier ... at least that's what I think is going on, or something similar
[17:32] <beantaxi> But yeah. To be honest my secret goal would be for the Docker testing stuff to be useful in and of itself but also to be a gateway drug to testing via lxd locally, even on OSX (and I guess Windows).
[17:33] <beantaxi> My primary obstacle being I don't know how to do that ... yet.
[17:35] <beantaxi> (Ironically, in an unrelated email thread, I'm trying and failing to get a client to stop doing things like running multiple web apps in a single docker container and trying to control them with an init system)
[17:38] <Odd_Bloke> You can't easily use LXD "locally"; it requires a Linux kernel and, unlike Docker (which has the same requirement), doesn't produce packages for Windows/OS X which include a virt stack to spin up a Linux VM behind the scenes.
[17:38] <Odd_Bloke> ("locally" on anything but Linux, I mean)
[17:39] <Odd_Bloke> So if we wanted to write some instructions to help folks get going with cloud-init development on those platforms, I think we'd want to skip the "local" step and recommend using a VM anyway.
[17:39] <Odd_Bloke> At which point LXD and Docker are equivalently available (well, LXD is preinstalled in Ubuntu images, but you know what I mean :p).
[17:42] <beantaxi> Odd_Bloke: There's a message board thread I came across earlier, where Simos was answering a "How do I run lxd on OSX?" question with "install Ubuntu as a VM on OSX, then install lxd client on the VM", with the implication it's just that simple.
[17:43] <beantaxi> However I can see that running lxd locally is one thing, and running cloud-init in that instance is another
[17:43] <Odd_Bloke> Right, running it in a VM is as simple as running a VM and installing it.
[17:43] <Odd_Bloke> But Docker can run "locally" on OS X: it will transparently take care of the VM stuff for you.
[17:44] <beantaxi> Right, it uses xhyve or whatever and just does the right thing. Which is why I went ahead with Docker ... I'm probably closer to equally-handy with Docker and lxd than almost anyone -- execept for anyone on #cloud-init -- and I myself found it easier to just use Docker for simple pre-push testing.
[17:47] <Odd_Bloke> Yeah, my point was just that while this makes Docker more attractive for an initial development experience, there's no natural stepping stone from running Docker on OS X to running LXD on OS X: one is a .dmg install, the other requires setting up a VM.
[17:48] <Odd_Bloke> (And so (if we were to guide people) we're probably better off guiding people through the VM setup process, so they have a full cloud-init dev environment, rather than through Docker setup and then later through VM/LXD setup.)
[17:52] <Odd_Bloke> beantaxi: Oh, my apologies, I missed the fact you'd pushed up #833, so none of my above thoughts took that into account at all.
[17:52] <beantaxi> Haha ... no worries. That's pretty funny.
[17:53] <beantaxi> And I like your points. I was coming from a POV of "If you have Docker installed, and you probably do, then here are some one-liners that will let you use Docker to test your cloud-init changes without having to do a doing a bunch of stuff"
[17:54] <beantaxi> I agree that, where the goal is "If you're up for rolling your sleeves up and really getting yourself set up to dev+test for real, here's how", then a path of a Docker Desktop .dmg install followed by a (eg) virtualbox install and then lxc install ... that would sort of be a silly path
[18:02] <falcojr> beantaxi: "I'm happy to take this week to try and get through it, and reconnect early next week?" Sounds good to me! Feel free to ping me with any questions
[18:03] <beantaxi> falcojr: You know I will :) Thanks for all your help so far
[18:03] <Odd_Bloke> beantaxi: Cool, armed with my new knowledge I've left you a couple of comments on #833. :)
[18:14] <beantaxi> Replied. Thanks for very much for the comments & thoughts! Good times