[11:53] <boolman> hey guys, How do I create an account with the password in plain text? I tried this http://pastebin.com/HkVAZT24 but it doesnt work
[11:53] <boolman> i also tried in quotes, eg 'installer'
[11:58] <boolman> ohh I needed to set lock_passwd: False
[15:04] <smoser> boolman, yeah.
[17:38] <larsks> smoser: any thoughts on when we might see 0.7.7?
[17:39] <larsks> Oh, huh, ubuntu ships a package based on a pre-release checkout it looks like.
[17:40] <smoser> larsks, i acknowledge we need one.
[17:40] <smoser> i'd 'like to get a list of bugs that we should target, and just start killing them.
[17:40] <smoser> so long...
[17:40] <smoser> since last release.
[17:40] <larsks> Yeah.  I'm carrying a bunch of backports in the RHEL package and would love to stop doing that :)
[17:41] <larsks> I am happy to help squash bugs if you have a list of release blockers..
[17:42] <smoser> larsks, are you subscribed to https://launchpad.net/~cloud-init
[17:42] <larsks> I am now :)
[17:43] <smoser> ok.
[17:43] <smoser> bah. harlowja not here.
[17:43] <smoser> :-(
[17:44] <smoser> holey moley. speak of the devil
[17:44] <smoser> harlowja, i said your name literally not 45 seconds before you joined
[17:44] <harlowja> lol
[17:44] <harlowja> i have risen
[17:44] <harlowja> from a conference in arizon
[17:44] <harlowja> *arizona
[17:44] <harlowja> lol
[17:44] <larsks> harlowja is in your irc servers, watching your messages...
[17:44] <smoser> larsks, is asking fora release.
[17:45] <harlowja> ah
[17:45] <harlowja> has it reached 2 years yet?
[17:45] <smoser> i think harlowja is outside my window!
[17:45] <harlowja> we can only release every 2 years
[17:45] <harlowja> lol
[17:45] <harlowja> do we want to have that CI working before  a release
[17:45] <harlowja> make sure things are tidy before that?
[17:46] <harlowja> (might be nice to have that same CI activate the building-packages code, ensuring it works)
[17:46] <harlowja> then sure?
[17:46] <smoser> this is true...
[17:46] <smoser> well i'd like to get a release to have something.
[17:46] <smoser> and then we can add more releases.
[17:46] <harlowja> sure
[17:46] <smoser> hopefully less than 2 years from now.
[17:47] <harlowja> lol
[17:47] <harlowja> sooo the other stuff i was liking to do was to have a cloud.cfg that was for fedora
[17:47] <harlowja> fedora/redhat
[17:47] <smoser> the rsyslog thing is obnoxious for sure.
[17:47] <harlowja> ya, that to
[17:48] <larsks> harlowja: you mean, a fedora compatible cloud.cfg in the distribution?
[17:48] <smoser> so i'd like to do a round of bug triage, and we can target some to a 0.7.8 release.
[17:48] <harlowja> in the tree larsks
[17:48] <smoser> and then we can go through and move them out if we want
[17:48] <harlowja> at least for people to look at, vs having to find the source rpm, know how to extract it ...
[17:48] <smoser> er... i guess 0.7.6
[17:48] <smoser> er... i guess 0.7.7
[17:48] <harlowja> i mean we have a brpm tool in tree, but if it uses the default cloud.cfg, that probably not gonna work out the best
[17:48] <smoser> i'm so used to seeing 0.7.7~ that i have started to assume that that was the releas.e
[17:48] <larsks> Okay. Any objection to just grabbing what's currentinly in the fedora packages and committing it?
[17:49] <harlowja> larsks not from me
[17:49] <harlowja> there is a syslog patch in the fedora package as well
[17:49] <harlowja> which goes back to how its weird and i'd almost like file logging to be the default in cloud-init
[17:49] <harlowja> (providing a logging config that is basic by default, and known to work)
[17:50] <larsks> The only fedora rsyslog related patch appears to be a one-liner changing the match critera in the rsyslog config?
[17:51] <harlowja> ya, so i've tried that one, it doesn't seem to work, lol
[17:51] <harlowja> at least when i was using it
[17:51] <larsks> Having said that, I think the logging is a little mucked up right now anyway.  I would rather we were just spitting everything to stdout/stderr and let the system take care of logging it.
[17:51] <harlowja> larsks ya, or just dump it to a file (by default)
[17:52] <harlowja> which we can do with a 1 line change
[17:53] <harlowja> i'd rather not have mucked up logging, but simple stuff that should just work, lol
[17:53] <smoser> alright. so very informal. lets say we do a release of 0.7.7 2 weeks from today.
[17:53] <harlowja> 2 years from today
[17:53] <harlowja> lol
[17:53] <harlowja> wfm
[17:54] <smoser> :-)~
[17:54] <harlowja> can we arrange to do it on smoser bday
[17:54] <harlowja> when is your bday
[17:54] <harlowja> lol
[17:57] <larsks> Looking at cloud.cfg...it would be nice if the distribution-specific parts were in something like cloud.cfg.d/distro.cfg or something, so that we could have a common set of modules enabled by default across distribution.  Does that make sense at all?  Right now the cloud_*_modules sections differ substantially between stock/freebsd/fedora...
[17:57] <larsks> Maybe that gets too complicated.  I dunno.
[17:58] <smoser> well, for more complexity there, i'd rather hav the modules declare supported distros and improve how the list is done and such.
[17:59] <harlowja> smoser right, we have basic support for that already
[18:00] <harlowja> it more though just results in a 'warning' if the module supports an operating system and its being ran on a different one
[18:00] <harlowja> so perhaps just further stuff there
[18:00] <harlowja> then we can just 'list all modules'
[18:00] <harlowja> and let the runtime figure out what should/shouldn't work
[18:01] <harlowja> 3https://code.launchpad.net/~harlowja/cloud-init/cloud-init-file-logging/+merge/300798 is the logging change
[18:01] <harlowja> if we desire it
[18:01] <harlowja> * https://code.launchpad.net/~harlowja/cloud-init/cloud-init-file-logging/+merge/300798
[18:03] <harlowja> i don't think most people know that http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/stages.py#L808 exists :-P
[18:03] <smoser> ok. harlowja larsks i just added a team name cloud-init-bugcontrol
[18:03] <larsks> I am fine with the idea of just logging to a file by default.  Can we get file logging directly without spawning a new process like that?
[18:03] <smoser> and makde it the "bug supervisor" for http://launchpad.net/cloud-init bugs
[18:03] <harlowja> larsks spawn new process?
[18:04] <larsks> harlowja: output: {all: '| tee -a /var/log/cloud-init-output.log'}
[18:04] <smoser> you should be able to move state of bugs now i think
[18:04] <harlowja> that's all in smoser realm for that one :-P
[18:04] <smoser> larsks, log to a file without a process ?
[18:04] <smoser> you just want to avoid the tee?
[18:04] <larsks> smoser: log to a file just use the python logging api, rather than having to pipe output to something.
[18:05] <harlowja> that one i think is for 'print'
[18:05] <larsks> That just strikes me as weird.  But whatever works...
[18:05] <smoser> right.
[18:05] <smoser> output: handles any subprocesses
[18:05] <larsks> Oh right, makes sense.
[18:05] <harlowja> right, also subprocesses
[18:05] <larsks> Neeeeeever mind.
[18:05] <smoser> cloud-init makes its standard out (and inherited) go to places described in output:
[18:05] <harlowja> we can alter that to adjust stdout and stderr
[18:05] <harlowja> that could avoid the tee
[18:06] <smoser> the python logging is configured in 05_logging.cfg
[18:06] <harlowja> larsks  i mean if u really want, we could likely drop the tee
[18:06] <larsks> harlowja: Eh, never mind.
[18:06] <harlowja> :-P
[18:06] <larsks> I'd rather get a release :)
[18:07] <harlowja> :-P
[18:07] <harlowja> 200 years
[18:07] <harlowja> lol
[18:10] <harlowja> smoser does https://gist.github.com/harlowja/e2333dd3ed219b53ef44671185177c3e actually skip anything?
[18:11] <harlowja> even though things get accumulated in forced and skipped there, those lists only seem to get used for logging?
[18:11] <harlowja> (or maybe i'm confused, ha)
[18:14] <smoser> harlowja, you would appear to be correct :)
[18:14] <harlowja> :-P
[18:15] <smoser> larsks, can you try something for me ?
[18:15] <smoser> so to get a realease... i added you and harllwo to bug control team
[18:16] <larsks> Okay.
[18:16] <smoser> and you should be able to now target things you think valid to 0.7.8 milestone
[18:16] <smoser> for example... https://bugs.launchpad.net/cloud-init/+bug/1603830 seems reasonable
[18:16] <smoser> can you just try to confirm that (mark it confirmed, it sure seems legit) and then target it to milestone ?
[18:16] <larsks> Sure.  Let me try...
[18:16] <smoser> i can spedn some time going through bugs and targetting them to 0.7.8
[18:17] <smoser> and woudl appreciate it if you and harlowja did the same.
[18:17] <harlowja> yes sir boss
[18:17] <smoser> rharper, is also in that group
[18:17] <smoser> and powersj
[18:17] <larsks> That seemed to work.
[18:17] <rharper> smoser: ok
[18:17] <smoser> alright then.. we have the start of a bug list
[18:18] <smoser>  https://launchpad.net/cloud-init/+milestone/0.7.7
[18:18] <rharper> 0.7.7 or 0.7.8 ?
[18:18] <harlowja> cloud-init 0.7.7 "been-to-long"
[18:18] <harlowja> lol
[18:18] <smoser> rharper is in the same camp as me and has just seen 0.7.7 for so long that he thought that was released :)
[18:18] <harlowja> lol
[18:18] <rharper> heh
[18:18] <smoser> the ubuntu versions are 0.7.7~bzrREVNO
[18:19] <smoser> where '~' in apt speak means less than
[18:19] <smoser> dpkg speak i guess
[18:20] <harlowja> whats ubuntu
[18:23] <smoser> its one of those free linux things
[18:23] <smoser> kind of like centos
[18:23] <harlowja> ah
[18:23] <harlowja> except newer?
[18:23] <harlowja> lol
[18:26] <harlowja> https://code.launchpad.net/~harlowja/cloud-init/cloud-init-really-skip-baddies if u want it :-P
[18:26] <harlowja> that will actually skip modules, lol
[18:27] <smoser> is worked_distros close to sane ?
[18:28] <harlowja> in the various modules?
[18:29] <harlowja> i think the redhat/yum ones probably need updating
[18:29] <smoser> does larsks have a list that he runs ?
[18:29] <harlowja> so no, imho, not all the modules very well use that
[18:29] <harlowja> some do, some don't, ha
[18:29] <harlowja> ones like cc_rhn_subscription should
[18:29] <smoser> if its in their default list, i'd mark it as working
[18:29] <harlowja> or cc_yum
[18:29] <smoser> yeah.
[18:30] <harlowja> cc_lxd also should probably have debian...
[18:30] <harlowja> so there probably should be an audit...
[18:30] <smoser> agreed.
[18:30] <larsks> smoser: A list of modules?  Honestly, I'm not sure that anyone has paid much attention to the cloud_*_modules sections of the config.  Hence my earlier comments about moving to some sort of single list or something...
[18:31] <larsks> That is, there is a config we are using, and it includes some things intentionally, like cc_rhn_subscription, but other stuff just because it was already there.
[18:31] <harlowja> larsks so just some background
[18:32] <harlowja> each module can optionally have a attribute 'distros' or 'osfamily'
[18:32] <harlowja> the cloudinit runtime (the thing that executes those modules) will look for these attributes and potentially skip if not on a supporting distro
[18:32] <harlowja> by default if a module doesn't list that attribute, its assumed to 'just work'
[18:33] <harlowja> some modules do list it (but without https://code.launchpad.net/~harlowja/cloud-init/cloud-init-really-skip-baddies things aren't actually skipped anyway)
[18:33] <harlowja> so we can have a single list, but we have to list those attributes correctly
[18:33] <harlowja> and then the runtime itself will handle skipping on unsupported distros
[18:34] <harlowja> just we have to consistently mark 'distros = ['ubuntu', 'debian']' in modules
[18:35] <harlowja> so that could == single list if we use it correctly
[18:35] <harlowja> bbiab
[18:36] <larsks> Fair enough.  Fwiw, I would love to see an is_available() method or something that could perform arbitrary runtime checks (e.g., cc_puppet could check if puppet were available, etc), rather than checking against distro names (like, what if someone were running an rpm based distribution with apt?)
[18:36] <larsks> missed him by this much...
[18:39] <larsks> harlowja: Repeating myself re:the distros var, because you quit at just the wrong moment: Fwiw, I would love to see an is_available() method or something that could perform arbitrary runtime checks (e.g., cc_puppet could check if puppet were available, etc), rather than checking against distro names (like, what if someone were running an rpm based distribution with apt?)
[18:39] <harlowja> lol
[18:39] <larsks> But obviously not right now :)
[18:39] <harlowja> larsks why not right now?
[18:39] <harlowja> its not that hard
[18:39] <mgagne> looks like 'name' is optional in links http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/helpers/openstack.py#L547 but later is mandatory: http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/net/network_state.py#L284
[18:39] <larsks> Well, if we're trying for a 0.7.7 release, something that introduces an entirely new mechanism for like that seems like a bad choice in the short term.
[18:39] <harlowja> larsks well we can at least build in the mechanism right now
[18:40] <larsks> Any chance we can work on github, or do I need to learn bzr + lp to submit changes for review?
[18:40] <harlowja> i'll make something quick
[18:40] <harlowja> smoser ^^^^^
[18:40] <harlowja> smoser is mr.moveittogit
[18:40] <smoser> harlowja, yeah, lets do it.
[18:40] <harlowja> smoser like by EOD
[18:40] <harlowja> ?
[18:40] <harlowja> lol
[18:41]  * larsks yays
[18:41] <harlowja> to git
[18:41] <harlowja> ?
[18:41] <mgagne> harlowja: tested bonding + vlans with latest cloud-init and it fails.
[18:41] <smoser> mgagne, :-(
[18:41] <harlowja> mgagne any log u got, any output of input and what it generated?
[18:41] <mgagne> for the reasons I mentioned above
[18:42] <harlowja> hehe, let me find the logger for this
[18:42] <mgagne> let me setup network, currently on IPMI
[18:42] <harlowja> mgagne can u try https://code.launchpad.net/~harlowja/cloud-init/cloud-init-render-tool
[18:42] <harlowja> it should write out files given a config in
[18:42] <mgagne> explain like I'm 5 ?
[18:42] <harlowja> given network_config.json ---> poof >>> turd
[18:42] <smoser> :)
[18:43] <harlowja> pooppy
[18:43] <harlowja> lol
[18:43] <harlowja> or is that el3?
[18:43] <harlowja> lol
[18:43] <smoser> mgagne, did that regress ?
[18:48] <smoser> harlowja, for git... we have to just rid 'bzr' from everywehre
[18:48] <smoser> that is cloud-init's http://paste.ubuntu.com/20342955/
[18:49] <smoser> and then my debian packaging in ubuntu makes use of bzr export and bzr merge upstream
[18:49] <smoser> but that is not a blocker for cloud-inti
[18:50] <smoser> for version sutff. i think we were saying pbr. have to look. i think you had something on that.
[18:51] <harlowja> prob
[18:53] <mgagne> smoser: never managed to test bond + vlan, only tested "flat" networks (without bond)
[18:53] <mgagne> smoser: testing cloud-init is really a part time job here =)
[18:54] <smoser> mgagne, right. thats fine. i was just wanting to make sure it wasant regression
[18:54] <mgagne> I don't think so
[18:54] <harlowja> larsks https://code.launchpad.net/~harlowja/cloud-init/cloud-init-dynamic-distro-check/+merge/300805 (the basics of that dynamic distro check)
[18:54] <smoser> as i was pretty sure you'd verified it working for you.
[18:54] <smoser> yeah.
[18:54] <mgagne> there is nothing to regress at that point
[19:03] <mgagne> ok, I'm having issue with networking, can't easily fetch logs without SSH. will take more time to debug as it could also be related to our auto networking config.
[19:04] <powersj> smoser, I have an initial job running the python tests now every 12 hours. I'll start looking into the vmtests and how they are run for curtin to see what we can do for cloud-init.
[19:04] <smoser> powersj, yeah, that will be a fair amount of work.
[19:05] <smoser> we shoudl talk some / brainstorm on how to get something reasonable into place.
[19:05] <powersj> ok
[19:05] <smoser> we can do a whole lot of test (including non-ubuntu distros) on lxd
[19:06] <mgagne> ok, that's the best I can do in the short term: http://imgur.com/a/wVuTr
[19:06] <powersj> that's how I've been experimenting is setting up lxd env.
[19:06] <powersj> not sure how to do different archs other than i386 yet though
[19:07] <smoser> well, we have resources for power at least
[19:09] <smoser> harlow dead
[19:09] <smoser> harlowja
[19:10] <smoser> (summoning worked before)
[19:10] <smoser> this is new to me:
[19:10] <smoser>  http://paste.ubuntu.com/20345473/
[19:10] <smoser> guess which of those lines pep8 doesn't like
[19:10] <smoser> complaining
[19:10] <smoser>  E225 missing whitespace around operator
[19:11] <smoser> must of come as fallout of https://github.com/PyCQA/pycodestyle/issues/166
[19:35] <larsks> smoser: I am looking at the bzr->git stuff in the scripts right now.
[19:36] <smoser> larsks, nice.
[19:36] <smoser> larsks, i think the plan was to use pbr sensible_version and the like
[19:39] <larsks> smoser:  does anyone actually use brpm?
[19:40] <smoser> harlow does
[19:40] <smoser> at least used to frequently.
[19:40] <larsks> Arg, he's dropped off again.
[19:41]  * larsks is going to buy harlowja an irc proxy for his birthday.
[19:41] <smoser> and i'd like to have something like that.. thats what i'd use for some c-i
[19:41] <smoser> i use bddeb in development for testing a package.
[19:42] <larsks> Okee dokee.
[20:06] <smoser> mgagne, if you can manage to get the openstack network_json of the failed system that'd be helpful
[20:07] <mgagne> smoser: will try =)
[22:47] <mgagne> smoser: finally made it: http://paste.openstack.org/show/539268/
[22:52] <simar> is this channel logged? any publicly available logs?
[22:57] <simar> also how does cloud init keep a track of which modules to run on boot? let's say I write a module that changes the hostname of the machine, would it actively check /etc/hosts on boot each time to know if it's required to run that module or not?
[22:58] <mgagne> IIRC there are flags created in /var/lib/cloud/instances/<uuid>/sem for once_per_instance configuration
[22:58] <mgagne> otherwise some always run at boot
[23:02] <simar> gotcha. thanks mgagne that seems to be right
[23:03] <simar> Also if I write a custom module that lives in /etc/cloud/cloud.cfg.d/ how would I call that up from cloud.cfg?
[23:04] <simar> so if its xx_modulename.cfg, i'd have to call it as modulename from within cloud.cfg under cloud_final_modules?