[02:46] Hi. Looking for some guidance on the correct way to capitalize "cloud-init" in different use cases. [02:47] Obviously enough if you're talking about commands or package names or whatever they must reflect the command. What about generally speaking? [02:47] "What is cloud-init?" vs "What is Cloud-init?" [02:47] https://cloudinit.readthedocs.io/en/latest/ [02:48] Heading is "cloud-init Documentation" but the first line starts "Cloud-init" [02:49] I'm editing documentation and training and want to make sure I get it right. [02:49] thanks [14:31] 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] 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] 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] 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] 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] 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] 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] 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] beantaxi: I commented about integration testing directly on #745 so to have it a place a little less ephemeral [17:03] 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] https://cloudinit.readthedocs.io/en/latest/topics/faq.html#how-can-i-debug-my-user-data [17:21] 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] 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] yeah, it's helpful to understand that perspective [17:27] Docker provides app containers, so doesn't match the target environment that cloud-init runs in. [17:28] 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] I'm happy to take this week to try and get through it, and reconnect early next week? [17:29] 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] (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] 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] 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] 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] My primary obstacle being I don't know how to do that ... yet. [17:35] (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] 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] ("locally" on anything but Linux, I mean) [17:39] 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] 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] 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] However I can see that running lxd locally is one thing, and running cloud-init in that instance is another [17:43] Right, running it in a VM is as simple as running a VM and installing it. [17:43] But Docker can run "locally" on OS X: it will transparently take care of the VM stuff for you. [17:44] 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] 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] (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] 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] Haha ... no worries. That's pretty funny. [17:53] 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] 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] 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] falcojr: You know I will :) Thanks for all your help so far [18:03] beantaxi: Cool, armed with my new knowledge I've left you a couple of comments on #833. :) [18:14] Replied. Thanks for very much for the comments & thoughts! Good times