[00:10] klibc might not be a good name though [00:10] perhaps just kernel [00:10] or cmdline ? [00:15] hrm, was klibc ever exposed other than the name of the parser ? [00:15] seems like stages.py uses it [00:15] looks like it's a real package [00:15] ya, its really cmdline.py [00:15] should just name it that, lol [00:15] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715497 [00:16] the main function it exposes is read_kernel_cmdline_config [00:16] but maybe that's just ancient cruft [00:16] yeah [00:16] I'd be happy with cmdline, but smoser would know more history [00:16] idk what klibc is doing there, but there are like '_klibc_to_config_entry' and such in it [00:16] which i didn't understand, and therefore just picked klibc, lol [00:16] *didn't understand the reference to [00:17] also, we need smoser to go head and import bzr branch into code.launchpad.net/curtin/+git [00:17] that's gonna support more than debian right ;) [00:18] git repo, yeah, just git hosted at lp === rangerpbzzzz is now known as rangerpb [15:01] I'm experimenting with systemd-nspawn, and trying to use the ubuntu cloud-iamges as systemd-nspawn containers. Wondering if there's any sane way to use cloud-init to configure them [15:01] SpComb, you want to seed /var/lib/cloud/seed/nocloud/ [15:01] with a user-data and meta-data [15:02] lxd does this (you should try lxd, it really is quite smooth) [15:10] smoser: thanks [15:20] smoser: if I put something in cloud_init like the doc/examples/cloud-config.txt: source: "ppa:smoser/ppa" [15:20] smoser: that should get translated into the right thing right? [15:21] smoser: e.g. what apt-add-repository would make from it, due to aa_repo_match matching and then calling it [15:21] right? [15:21] cpaelzer, yeah. that will match the ADD_APT_REPO_MATCH [15:21] and be passed to apt-add-repository [15:21] err... add-apt-repository [15:21] smoser: hmm - it didn't (I started creating all kind of apt_source tests) [15:22] ok, just wanted to make sure it "should" will ping you again as soon as I have more data, a real question or a fix [15:22] smoser: FYI - you mail was a good starting point and I look into it - which is why I started creating apt_sources tests [15:23] smoser: I don't want to hack on the "key without sources" without any verification that the old works as it did before [15:23] smoser: is there any vmtest (planned) or is the unit test framework all we have atm? [15:25] there is some vmtest that rharper started [15:25] let me find [15:25] but still in a separate MP somewhere? [15:25] https://code.launchpad.net/~raharper/+git/cloud-init-test/ [15:25] smoser: thanks, not sure if I will use it, but worth a look [15:28] cpaelzer, http://paste.ubuntu.com/16347019/ [15:28] that works for me wrt ppa source [15:28] smoser: oh it works now as well, I found that the matcher is by default not provided since I call add_source directly [15:29] smoser: fixed now [15:29] smoser: but that pastebin is a nice test example - I like that [15:30] cpaelzer, so if you're looking at vmtest, we do want to get something better in place. [15:31] generally speaking for test we have [15:31] (or should have) [15:31] a.) unit tests [15:31] b.) datasource tests [15:31] c.) system boot tests [15:32] 'b' is a pain, requiring mock-like datasources (or testing on the real thing). so those can delay for sure. [15:32] both b and c require an os image and an ability to patch in trunk cloud-init into it. [15:33] although we'd want it to allow for other hypervisors, i'd think for most things i'd like to use lxd [15:33] for 'c' [15:34] for anything that was not environment specific (such as apt config) [15:34] cpaelzer, sorry i missed your ping in server earlier [15:38] smoser: thank, thats a good overview to start with [15:38] smoser: and never mind about the lost ping, that delay was worth 4 working tests already :-) [15:39] smoser: whenever the day is over I'll link a bzr branch (no MP yet) just to check if I head in the right direction before doing that for more time [15:40] you saw my comments in mp ? [15:41] yeah, you did. [16:47] rharper looks like i'll need to add rhel6 support, so i think sysconfig stuff is still needed (vs just networkd) [16:47] rharper are u doing the networkd stuff currently? [16:47] harlowja: ok, so wondering if we want to do the networking backends via the type (eni, sysconfig, networkd, network-manager) ? [16:47] versus distro ? [16:47] or I suppose the distro should import the backend writers [16:48] since debian could support eni and networkd [16:48] i think distro class should decide that :-P [16:48] y [16:48] but we might move the backend writer out of the distro-class itself [16:49] ah [16:49] then ya, i guess u are right [16:49] maybe net/kind/eni.py and ... [16:49] seem to make sense? [16:50] yeah [16:55] cool [16:55] i'll update the branch i have to do that [16:58] kind ? [16:58] definitely i think the distro object should know what it is going to render based on checking the system or config. [17:01] right, in https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor/+merge/293957 i put in a _net_renderer in the distro [17:01] (at least the debian distro) [17:02] just think cloudinit/net/ would be better named in that folder [18:20] harlowja: sorry I missed part of your original question; re: networkd, I'm starting on supporting network_config to write out networkd files (.link, .network, .netdev); so we'll have that as well [18:20] kk [18:20] seems like godaddy (where i'm at) still needs rhel6/centos6 soo i guess i'll have to do sysconfig [18:20] but if u doing networkd, that should i think work for newer versions of rhel7/centos7 [18:21] yeah [19:04] smoser: it gets late, but I think I'll gonna continue on the tests and then go for the "key without source" [19:05] smoser: if you want to do an early check and mail me some feedback over my night feel free to look at https://code.launchpad.net/~paelzer/cloud-init/test-apt-source/ [19:06] k === rangerpb is now known as rangerpbzzzz [20:10] smoser: have you heard of people seeing errors from growpart when running with LANG != en_US.utf8? [20:12] larsks, it would seem plausible [20:12] but current trunk does LANG=C anytime it invokes sfdisk [20:12] trunk for cloud-utils? or for cloud-init? [20:12] trunk for cloud-utils [20:13] Oooo, can we get a release? :) [20:13] probably should, yeah. [20:13] but if i were going to do that i'd like to know that it fixes your sisue first [20:13] rather than releasing something and then finding out still broken [20:14] I think that would almost certainly fix the issue, because the issue is clearly sfdisk returning localized text that doesn't parse correctly in response to --show-pt-geometry. [20:14] But I will test. [20:14] well, current trunk d oesnt use show-pt-geometry anymore either :) [20:15] So many wins! [20:16] revno 267 basically added support for sfdisk > 2.26 [20:16] so i'm kind of surprised youd only fail with different locale [20:18] This is sfdisk 2.23.2 (rhel 7) [20:19] ah. ok. [20:19] rharper ok https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor/+merge/293957 should have the new adjustments for folders/module names [20:29] once we can get that in, then i can start on the sysconfig stuffs [20:38] harlowja, from cloudinit.net.renderers import eni [20:38] yup [20:38] lol [20:38] renderers seems strange i think [20:38] they render network config -> blobs [20:38] where does the code that reads eni go ? [20:39] ie, cloudinit.net.renderers.eni renders eni [20:39] but [20:39] cloudinit.net.readers.eni reads it ? [20:39] better name? [20:39] or [20:39] cloudinit. [20:39] lol [20:39] cloudinit.net.netcfgsystems.eni has readers and writers for eni [20:40] idont knwo [20:40] *cloudinit.net.kinds.eni ? [20:40] hm.. i'm not being clear i think [20:40] be clear man [20:40] lol [20:40] lets use 'widget' for 'eni' above [20:40] k [20:41] cloudinit.net.renderers..Renderer() [20:41] and [20:41] cloudinit.net.readers..Reader() [20:41] versus [20:41] cloudinit.net..Renderer() [20:41] and [20:41] cloudinit.net..Reader() [20:42] that make sense ? [20:42] seems to [20:42] do you put readers together or together [20:42] is what i'm asking [20:42] i'm gonna go with widgets [20:42] er.. readers/renderers together. [20:42] k [20:42] ya, let's go with together [20:46] tweaking in progress [20:47] smoser would u be opposed to moving cloudinit/net --> cloudinit/distros/net ? [20:47] at least its in a similar module then [20:48] hm. [20:48] similar module ? [20:48] i think i kind of want net/ standalone [20:49] as that is the thing that is shared with curtin [20:49] net stuff being about distros :-P [20:49] and distros/ being where distro stuff is, lol [20:49] thats my only motivation for that [20:49] yeah. [21:19] okie dokie, updated that merge with that [21:47] also another question, on the 0.7.x stuff, has anyone been ensuring the py2.6 stuff continues to work? [21:48] i'm thinking some of net stuff won't work on 2.6 (due to format() changes that afaik only work in 2.7)