| smoser1 | do i just hit 'squash and merge' ? on https://github.com/canonical/cloud-init/pull/589 | 00:57 |
|---|---|---|
| === smoser1 is now known as smoser | ||
| smoser | or does a bot do it | 00:57 |
| === hjensas is now known as hjensas|afk | ||
| Odd_Bloke | smoser: We don't have a bot (yet), so please go ahead! | 13:01 |
| Odd_Bloke | falcojr: OK, cool, we might conflict but it shouldn't be too hard to fix if we do; and that option name is *chef's kiss*. | 13:10 |
| Odd_Bloke | otubo: smoser: I'm not going to wade into that IBM discussion, but note that https://cloudinit.readthedocs.io/en/latest/topics/code_review.html#prerequisites-for-landing-pull-requests lays out our unit testing requirement. | 13:13 |
| Odd_Bloke | In case you want some ammunition. ;) | 13:13 |
| otubo | Odd_Bloke: appologies, english is not my first language. But "lay out" as in "eliminates the requirement for unit tests" or as in "confirms the need of unit tests"? I got confused because of "In case you want some ammunition." :-D | 13:23 |
| otubo | Also, any chance to take a look at https://github.com/canonical/cloud-init/pull/586 ? | 13:23 |
| Odd_Bloke | falcojr: https://travis-ci.org/github/OddBloke/cloud-init/jobs/731932198 \o/ | 13:26 |
| Odd_Bloke | Just plugging it into our current configuration appears to have worked. | 13:26 |
| Odd_Bloke | otubo: Apologies! "lays out" as in "describes", and the requirement it describes is that new Python code should have unit tests (and so it "confirms the need of unit tests"). | 13:28 |
| otubo | Odd_Bloke: Ah nice, thanks :-) | 13:31 |
| Odd_Bloke | otubo: So I'm looking at that PR, and I think there's an issue in the pre-existing code: specifically, I think https://github.com/canonical/cloud-init/blob/master/cloudinit/ssh_util.py#L265 will always raise an IndexError (run `python3 -c "x = []; x[0] = 'foo'"` to see what I mean). Have you tested this change in an environment where it would be triggered? | 13:37 |
| meena | python isn't php?? | 13:57 |
| catphish | basically the same think though right :) | 13:58 |
| meena | i mean, this also works on Ruby, but Ruby is """inspired""" by perl (and Smalltalk) | 13:59 |
| meena | so, i knew these things, but i only ever considered them separately, and now, thinking about these two things at the same time, and how they make this one language makes my head spin | 14:01 |
| otubo | Odd_Bloke: sorry was on a meeting. But yes, the patch was tested (I generally test it on the env before a PR) and it works. But I understand what you're saying. I think .append('foo') would fix it. | 14:16 |
| smoser | Odd_Bloke: so what type of merge do i do ? | 14:19 |
| smoser | the button for me says "Squash and merge". But I think that is just the value from the last time i did it. | 14:19 |
| smoser | (rather than a project-set value) | 14:19 |
| smoser | which am i supposed to do | 14:20 |
| powersj | we only allow squash and merging | 14:23 |
| powersj | if you click on the little arrow the other two options should be greyed out | 14:23 |
| catphish | tds: i'm working on the thing i threatened :) https://paste.ubuntu.com/p/VFJ3Kz8475/ | 15:37 |
| catphish | it's actually going quite well | 15:37 |
| catphish | so it sends a multicast request to its first interface, the hypervisor responds to say hello, then it can pull config by TCP with no prior network config needed | 15:40 |
| smoser | powersj: thanks. | 16:34 |
| AnhVoMSFT | @blackboxsw @rharper https://github.com/canonical/cloud-init/pull/591 this is the PR to fix https://bugs.launchpad.net/cloud-init/+bug/1874544 using the approach we discussed during the summit | 17:39 |
| ubot5 | Ubuntu bug 1874544 in cloud-init "issue with double mac addresses on azure/ib0 devices" [High,Triaged] | 17:39 |
| alschaapman | Does any part of cloud-init's first time boot process *not* get put into the initramfs | 18:02 |
| alschaapman | It seems like everything that's supposed to be needed for that happens before the root filesystem is mounted | 18:02 |
| teward | does anyone have a ton of experience with pxe boot and preprovisioning a systme with a cloud-init, and can give some guidance on telling the LVM system to use the entire available disk for the LVM LV rather than only half the PV that it gets? (I think the lvm defaults for cloud-init/curtin are fubar, but not sure how to tell it to use full disk, when using the plain jane 'lvm' storage option without custom configuration of the storage) | 19:20 |
| teward | i'd rather not have to provide a full disk layout in cloud-init if possible | 19:20 |
| powersj | smoser, rharper ^ is that possible? | 19:28 |
| smoser | teward: i think yuou're talking about curtin, right ? | 19:29 |
| teward | smoser: it's called underneath cloud-init I assume, yes. I know in KVM-powered (LXD) VMs, growpart can be used to grow the partitions to full for the system, but what I'm after is building the LVM so that the default LV actually getws 100% of the PV that is autocreated not 50% | 19:30 |
| teward | (which is what my tests are seeing) | 19:30 |
| teward | smoser: the *problem* is in the curtin docs I can't find *anything* that would allow me to define 100% consumption of the PV by the LV *unless* I structure the entire disk layout from scratch, which I'm trying to not do :P | 19:31 |
| smoser | well... i'm not sure what you actually have. | 19:32 |
| rharper | this is the autoinstall yaml | 19:32 |
| rharper | for subiquity | 19:32 |
| smoser | i've nto used lxd kvm guests (i guess i could try) | 19:32 |
| rharper | pretty sure | 19:32 |
| smoser | surely lxd doesn't do a install | 19:32 |
| rharper | oh, maybe not | 19:32 |
| * rharper catches up | 19:32 | |
| rharper | how/where is the rootfs getting backed by lvm ? | 19:33 |
| teward | smoser: no, it doesn't, but i'm trying to do full VM autoinstalls via PXE | 19:34 |
| teward | smoser: so i'm familiar with cloud-init having growparts available, but not sure how to achieve similar with a pure LVM in a pxe boot | 19:34 |
| teward | hence my needing a bit of an assist with the autoinstall yaml :| | 19:35 |
| smoser | oh. i'm not familiar at all with subiquity autoinstall yaml. | 19:35 |
| rharper | right, autoinstall yaml; so curtin storage yaml supports using 100%FREE on an LV with no size key; | 19:35 |
| rharper | w.r.t to a PV, you can feed any curtin storage disk (or partition, or other block device) into the lvm_volgroup; and it's added as member of the volgroup; | 19:36 |
| teward | rharper: i think i'm looking for example syntax | 19:40 |
| teward | rather than a theoretical explanation | 19:40 |
| teward | because ERR:NoExamplesAvailable | 19:40 |
| teward | so i'm a little headscratching atm | 19:40 |
| rharper | if you're defining type: lvm_partition; you specify the lvm_volgroup id in which you want to create it; and then *omit* the 'size' key; and curtin will pass '100%' when invoking lvcreate | 19:42 |
| teward | rharper: what if the storage isn't defined *except* for the default of `storage: layout: name: lvm` like the example in the autoinstall page as a 'structure'/'example'? https://ubuntu.com/server/docs/install/autoinstall | 19:43 |
| teward | (and yes I removed the linebreaks, but assume actual yaml) | 19:43 |
| teward | rharper: trying to grasp this from scratch, without having to go through a complete storage definition through everything - from disk to pv to vg to lv | 19:44 |
| teward | see if there's any workarounds OTHER than defining the full disk structure the way you're suggesting | 19:44 |
| rharper | teward: not that I know of; there's an open bug complaining about using 100% LV; https://bugs.launchpad.net/subiquity/+bug/1785321 ; | 19:47 |
| ubot5 | Ubuntu bug 1785321 in subiquity "LVM Entire Disk option does not use entire disk" [Medium,Fix released] | 19:47 |
| rharper | teward: so maybe there's a follow-up bug (that says fixed) to allow the same feature in the autoinstall yaml | 19:48 |
| teward | rharper: then the next question is, can you proivde a Proof of Concept example for how the storage layout would have to be, including on-root boot partition, physical partition that'll be the PV, VG on the PV (100% of the PV), LV on the VG (100% of the VG)? Because again, headscratching here | 19:48 |
| teward | due to my unsuredness with this venture | 19:49 |
| rharper | teward: not for autoinstall, but for curtin, this is very close to what you want, https://git.launchpad.net/curtin/tree/examples/tests/lvmroot.yaml ; the only change for "LV consuming 100% of the free VG space" is to remove line 32; | 19:52 |
| teward | rharper: assuming this is passed in via cloud-init data, does cloud-init pass the storage configuration with curtin options? Or is this going to require more than simply a base autoinstall yaml? | 19:53 |
| teward | (again, new to this, I prefer manually deploying things :P) | 19:53 |
| rharper | so, for autoinstall, subiquity boots, reads cloud-init data, and writes the autoinstall.yaml to a well-known location, then subiquity runs, see the autoinstall yaml and runs it (which calls curtin to install the OS given the config) | 19:54 |
| teward | ok, so then the storage layout you provided would be passed in the autoinstall.yaml's storage section accordingly, which passes the config to curtin? Assuming I'm understanding it proper | 19:55 |
| teward | (sorry again for asking too many questions xD) | 19:55 |
| rharper | yes, subiquity reads the storage config first, and then adjusts it for disk name matching, https://ubuntu.com/server/docs/install/autoinstall-reference | 19:57 |
| rharper | so instead of using the storage: layout: ... (high level stuff), you'll use what's called "action-based config"; | 19:57 |
| teward | that makes sense | 20:00 |
| teward | rharper: thanks for the clarification, hopefully I can wrap my head around this | 20:00 |
| teward | more questions may follow "soon"ish :p | 20:00 |
| rharper | =) | 20:01 |
| Odd_Bloke | falcojr: I'm ready to land https://github.com/canonical/cloud-init/pull/581, do you want to author a commit message for it? | 20:06 |
| falcojr | if only I had had a PR template for that ;) | 20:08 |
| Odd_Bloke | Sounds like a good idea, someone should write one of those. | 20:08 |
| rharper | teward: we could continue #curtin ; I suspect the discussion will be more focused on curtin than cloud-init/config | 20:14 |
| teward | rharper: yep, but that's a task for later. | 20:14 |
| teward | currently wrapping my head around some landscape on-prem crap | 20:14 |
| rharper | lol | 20:17 |
| teward | no seriously. Landscape on-prem not accepting the license >.< | 20:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!