[17:39] <blackboxsw> hrm just reviewing our active queue today. https://code.launchpad.net/~johnguthrie/cloud-init/+git/cloud-init/+merge/331905 it feels like a nice thought (chef variable substitution. I feel like we could provide a variable substiturion mechanism for cloud-config modules based on the instance-data.json though instead which could be a bit more generic.
[17:40] <blkadder> Pretty please?
[17:43] <blkadder> Right now I am writing a wrapper script to do substitutions in my yaml files and writing another script to do substitutions in config files on the box as I am trying to see how far I can get without using chef/puppet/et al.
[17:44] <blkadder> variable substitution within cloud-init would be great...
[17:45] <blackboxsw> hehe :) yep. I need to get https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/330115 landed so we can build the substitution framework on that standardized instance-data.json
[17:46] <blackboxsw> I might take a quick stab at it today to see how tough this substitution framework would be.
[17:47] <blkadder> I am sure a generic framework will be much more challenging than the very specific little tidbits I am doing. :-)
[17:53] <blackboxsw> definitely, I'm trying to weigh how painful and whether it's better in the short term to grow our cc_* modules individual templating language vs. just swallowing the cost of generic templating
[17:54] <blackboxsw> (I'm an unrealistic optimist and hope the generic templating isn't too bad)
[17:57] <blkadder> Heh
[18:48] <blackboxsw> thx robjo on the branch. couple comments for discussionhttps://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/333575
[18:49] <robjo> OK, will take a look in about 10 minutes, thanks
[19:14] <robjo> blackboxsw: fixed the comment and the substitution, for the other stuff, just let me know the desired direction, symlink or template name substitution
[20:51] <robjo> I think there is a latent bug in cc_ntp, on line 127 rename_ntp_conf() is called, but if the timesync client is timesyncd the configuration file that may or may not be provided by the distro is never renamed as the file to be renamed alwasy falls back to NTP_CONF
[20:51] <robjo> the call should really be rename_ntp_conf(confpath) IMHO
[20:52] <robjo> smoser: blackboxsw ^^^^ thoughts?
[20:59] <blackboxsw> checking
[21:01] <blackboxsw> robjo: +1 on rename_ntp_conf(confpath) given that we could be dealing with a different service than actually NTP. and renaming NTP_CONF ->  NTP_CONF_FILE  too
[21:02] <robjo> OK, starting with chrony support so this will be intermingled ;)
[22:00] <jhogarth> rharper, ping ... heys ... it's James working on that net-tools deprecation :)
[22:01] <rharper> jhogarth: hey
[22:01] <jhogarth> I've made it a personal mission to "cleanse" Fedora of the dependancy ... not trivial though ...
[22:02] <rharper> hehe
[22:02] <jhogarth> just grabbed a NetBSD ISO so I can validate that ifconfig and route/netstat output and options against the net-tools version
[22:03] <rharper> is sysconfig net-tools free?
[22:03] <rharper> jhogarth: I think there are bsd images on azure as well, in case you just want to kick off one of those instead of the installer
[22:03] <jhogarth> yes ... as of about F19 I think or a little before that ... EL7 is net-tools free for the network service so it must be around F15-F19 they finished up on that
[22:04] <jhogarth> that means using azure ... I'm allergic to MS stuff :P
[22:04] <jhogarth> in all seriousness though it's probably useful to have a BSD VM template on my laptop for cloneing and testing
[22:04] <rharper> cool
[22:05] <rharper> currently the sysconfig renderer checks for "ifup" and "ifdown" as well as the /etc/sysconfig/network-scripts/network-functions
[22:05] <rharper> in F19/EL7 are there still ifup/ifdown tools provided outside of net-tools ?
[22:05] <rharper> see cloudinit/net/sysconfig.py:def available()
[22:07] <jhogarth> yes ifup and ifdown are owned by the initscripts package rather than the net-tools one and they either use nmcli if NM is running (and the interface isn't marked with NM_CONTROLLED=NO) or call the relevant network service funstions which use iproute2
[22:08] <jhogarth> so far as I can tell the only things that cloud-init relies on net-tools for on Red Hat based systems is the info printouts
[22:09] <jhogarth> so once netinfo.py is ported to have ip as a preference and ifconfig/netstat as a fallback then we *should* be good to drop the net-tools dependency in the rpm spec
[22:09] <blackboxsw> cloudinit/sources/DataSourceAzure.py has some ifconfig uses
[22:10] <blackboxsw> sorry, just eaves dropping
[22:10] <rharper> jhogarth: yeah; that's what I recall as well
[22:10] <blackboxsw> however that's spelled ;/
[22:10] <rharper> blackboxsw: good find
[22:10] <jhogarth> it's actually been quite amusing on this journey at times since at least a few packages already had iproute2 codepaths upstream but the maintainers just didn't realise they could drop the dependancy :)
[22:10] <rharper> I suspect there are other ifconfig (I think in the bsd space as well)
[22:10] <blackboxsw> don't thank me, thank fgrep -r :)
[22:10] <rharper> so a grepping of the source for dropped binaries is worth it
[22:10] <blackboxsw> rharper: true cloudinit/distros/freebsd.py
[22:11] <rharper> mmm, legacy
[22:11] <jhogarth>  grep -E '\b(ifconfig|netstat|arp|route)\b' -R * <-- you're friend ;)
[22:11] <blackboxsw> heh
[22:11] <jhogarth> well we dont' need to worry about porting the bsd stuff as that will never have ip ;)
[22:12] <rharper> right, it would be non-bsd paths use of net-tools
[22:12] <jhogarth> and looking at the code that azure adat source stuff is bsd only :)
[22:12] <rharper> indeed
[22:13] <blackboxsw> yeah though the stock  BOUNC_COMMAND.. isn't bsd-specific is it?
[22:13] <blackboxsw> line 30
[22:13] <jhogarth> there's some test stuff calling route etc ... but that's your debian/canonical packaging and testing :
[22:13] <jhogarth> :p
[22:14] <jhogarth> blackboxsw, that's calling ifup/ifdown which is safe though
[22:14] <blackboxsw> ahh too true.
[22:15] <rharper> hrm, I wonder how the Azure stuff on artful/bionic are getting on then;
[22:15] <rharper> we've no ifup/ifdown in netplan only images
[22:15] <blackboxsw> I'll spin one up now that we have images
[22:15] <jhogarth> luck? heh
[22:16] <rharper> well, there is some mystical things that happen under the agent which may or maynot need the bounce
[22:16] <jhogarth> this is why CI setups are good at both unit and integration/functional levels :p
[22:16] <rharper> =)
[22:31] <jhogarth> so .... NetBSD ifconfig output is different from even the current net-tools ifconfig linux snapshot heh ... glad I checked ;)
[22:32] <jhogarth> because everyone easily can read the netmask when it looks like: inet 192.168.124.96 netmask 0xffffff00 broadcast 192.168.124.255  :/ and hwaddr actually has a tok of address .... NetBSD output on cloud-init most have been nothing like the linux output :/
[22:33] <jhogarth> still ... now I have sample output to add to the test cases :)
[22:33] <jhogarth> do you guys just support NetBSD or should I confirm if FreeBSD has the same output?
[22:40] <jhogarth> and of course BSD has to have completely different routing output with netstat -rn ... and now I doubel check the code paths and it's FreeBSD you support, not NetBSD ... although I could have sworn NetBSD was referenced in a bug ...
[22:43] <blackboxsw> rharper: http://paste.ubuntu.com/25963614
[22:43] <blackboxsw> bionic works on azure
[22:43] <jhogarth> oh well ... enough of my verbiage ... it's bed time in the UK ... thanks for the feedback and discussion ... I'll keep on hacking this over the next week to hopefully get every case tested and something nice to merge with a bunch of bugs solved too :)
[22:43] <blackboxsw> because of the magic :)
[22:44] <blackboxsw> erm ,,,, heh n/,m
[22:44] <blackboxsw> traceback on hostname bounce
[22:44] <blackboxsw> due to failed ifdown/ifup
[22:44] <blackboxsw> I'll file a bug
[22:45] <jhogarth> i'll be about in the channel whilst working on the patch this week or so :) laters
[22:45] <blackboxsw> smoser: already had it https://bugs.launchpad.net/cloud-init/+bug/1722668