[13:55] <larsks> harlowja or smoser: can someone confirm the minimum python version required by cloud-init?  It looks like the answer is "2.6" but want to be sure.
[14:00] <smoser> larsks, harlowja says that 2.6 is busted in trunk.
[14:00] <smoser> and he intendes to fix that. it shouldnt be much.
[14:01] <smoser> i would like to support 2.6 but less than that i have no plan.
[14:02] <larsks> Awesome, thanks.
[14:03] <larsks> Someone is asking about cloud-init for RHEL 5 (python 2.4), and I wanted to be able say no with authority :)
[14:06] <smoser> larsks, i think realistically speaking that requires some epel stuff to get python2.6
[14:06] <smoser> its just *so* old
[14:06] <larsks> Yeah, absolutely.
[14:12] <Odd_Bloke> Ship a cloud-init package that bricks their machine; problem solved.
[14:12] <Odd_Bloke> ^_^
[15:04] <gamename> Hi guys. I'm trying to something simple.  I have a script which gets copied to the instance scripts as "part-001".  However, i need to test it by re-running init and that requires me to remove the "instance" dir where that file is now living. So, how does one test?
[15:08] <gamename> Come to think of it, where does a script live before it gets copied to the instance?  That is, where does the script "foo.sh" which becomes "part-001" live before being copied to the instance subdir in /var/lib?
[15:09] <Odd_Bloke> gamename: What cloud/data source are you using?
[15:10] <gamename> Odd_Bloke I'm using terraform to copy the user-data.
[15:10] <gamename> Initially copy it, that is.
[17:47] <harlowja> larsks smoser https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor has the 2.6 fixes
[17:47] <harlowja> someone just needs to merge that :-P
[18:54] <rharper> harlowja: hi;  so network_state isn't "designed" as I'm sure you can tell.  The constraints at the time were something roughly similar to the openstack network_metadata; but distinctly *not* network_metadata from openstack for uninteresting, yet important (internally at least) reasons.  I'm more than happy to look at modifying the internal structure to be something more useful for net-config <-> network-state <-> render
[18:54] <rharper> ed-format conversions.  In my initial stab at netword output, I've already needed to do some changes when parsing to map device types to the various "network", "netdev", "links" concepts that networkd has that eni doesn't
[19:43] <harlowja> rharper what were the 'yet important (internally at least) reasons.' ?
[19:45] <harlowja> rharper did smoser talk to u about a tiny-lib for that network conversions stuffs
[19:48] <smoser> fudge
[19:48] <smoser> rharper, i need to talk to you :)
[19:48] <nacc> heh
[19:55] <rharper> harlowja: that it not _be_ the openstack format
[19:55] <rharper> *sigh*
[19:55] <rharper> smoser: here now if you want to do g+
[19:56] <smoser> k. give me a bit.
[19:56] <rharper> sure
[19:57] <harlowja> if u need me on g+ just let me know :-P
[19:57] <harlowja> rharper any more details ;)
[19:57] <harlowja> spilllll the beans, lol
[19:58] <rharper> harlowja: that said, I want to spend some time thinking about the attributes we'd like in that internal state, with an eye toward the various output formats we need to support;  something that's currently hard to do is things like networkd's  .network with a match rule which applies to any interface that matches;  that doesn't map cleanly to an inteface-name indexed state
[19:59] <harlowja> ya, thus why i sorta think a tiny-lib could focus on that
[19:59] <rharper> harlowja: hehe; I'm sure you can imaging the usual sort of reasons and one or more of those applies
[19:59] <harlowja> lol
[20:00] <rharper> I've not looked at all of the other config formats we support or network configs we 'write out,  sysconfig seems simple enough but I've not looked at it exhaustively;  cloud-init targets many other OS types, so it would be useful to capture their sorts of requirements and syntax;
[20:01] <harlowja> ya, any freebsd folks around :-P
[20:01] <rharper> I don't think we'd need to implement those backends (I'd prefer an interested party to contribute those)
[20:01] <rharper> heeh
[20:01] <harlowja> yup
[20:02] <harlowja> i've volunteered for the sysconfig one (not hard, just gotta figure out the mapping)
[20:02] <rharper> but I'd want to make sure our internal structure supported things;  IMO, the key items "devices/links", "networks/subnets",  and "matching/templating" covers I think most of what we'd need
[20:02] <harlowja> likely involves knowing more about the sysconfig mapping than i currently know
[20:02] <rharper> usually; I've become all-to-familiar with eni and it's helpers (bridge-utils/ifenslave/vconfig)
[20:03] <harlowja> :-p
[20:42] <harlowja> smoser rharper so what was the decision :-P
[22:10] <copumpkin> what's the role of /var/lib/cloud/seed/nocloud/{user,meta,vendor}-data ?
[22:21] <copumpkin> oh, I see
[23:09] <harlowja> smoser https://code.launchpad.net/~harlowja/cloud-init/cloud-init-fix-test-times/+merge/294854 should have the fixed test times
[23:09] <harlowja> retries and timeouts triggering it.