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