[08:38] <aps> smoser: I just want to silent logs for apt tasks, like with the -q flag to normal apt-get commands
[08:39] <aps> I do want logs for other commands
[18:01] <harlowja> ok eyes on https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-sysconfig/+merge/297115 would be nice :)
[18:02] <harlowja> more data samples would be cool to
[18:03] <sather> I'm having trouble finding 'official' documentation on creating a module
[18:17] <smoser> harlowja, more examples of ?
[18:19] <smoser> Odd_Bloke, harlowja i have shame for both of you
[18:19] <smoser> sather, what kind of module you want ? config ?
[18:20] <smoser> harlowja, http://paste.ubuntu.com/17334762/ <-- that is you
[18:22] <smoser> Odd_Bloke, http://paste.ubuntu.com/17334843/ <-- that is you
[18:25] <sather> smoser: parsing user-data and writing it to a yaml file for another service to process later
[18:26] <smoser> sather, check /var/lib/cloud/instance/user-data.txt
[18:26] <smoser> and /var/lib/cloud/instance/user-data.txt.i
[19:03] <mgagne> harlowja: what's the best way to download a diff of this merge request?
[19:07] <smoser> mgagne, the 'Download diff' link at https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-sysconfig/+merge/297115 ?
[19:07] <smoser> maybe im' missing something
[19:07] <mgagne> smoser: yea, I'm not geared to rebuild a new package against bzr
[19:08] <mgagne> smoser: I can handle diff fine
[19:08] <mgagne> oh
[19:08] <mgagne> found the link
[19:08] <mgagne> https://i265227674.restricted.launchpadlibrarian.net/265227674/b1aed10a-3259-11e6-8a1a-002481e91f22.txt?token=KWhCrx10JmGLMNdFlQVPDw4PBP3Cfm91
[19:14] <mgagne> ok looks like I don't have the appropriate version to patch against. I used https://launchpad.net/~smoser/+archive/ubuntu/cloud-init-dev and it looks to be outdated compared to trunk.
[19:15] <smoser> yeah, mgagne i was just fixing that.
[19:23] <smoser> harlowja, if you run 'tox' do you get a file 'c' in top dir ?
[19:29] <smoser> tests/unittests/test_cli.py that seems to create it
[19:57] <harlowja_> smoser hmmm
[19:58] <harlowja_> let's see
[19:58] <smoser> harlowja_, i fixed.
[19:58] <harlowja_> k
[19:59] <harlowja_> btw, data samples == openstack network_json samples
[19:59] <harlowja_> i have tests in https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-sysconfig/+merge/297115 that take that file, and test to see it gets rendered as expected
[19:59] <harlowja_> should also be able to easily do the same for eni rendering
[20:04] <smoser> mgagne, the daily archive shoudl be up to date shortly
[20:05] <smoser> ah. harlow right.
[20:06] <rharper> smoser: did you share the cloudinit-data repo  ?
[20:06] <rharper> that's got I think most of the example OS config data we've seen
[20:07] <rharper> cloudinit-ds-test
[20:24] <harlowja_> smoser lol, W503 line break before binary operator
[20:24] <harlowja_> oops
[20:24] <harlowja_> i have sinned
[20:24] <harlowja_> forgive me father
[20:24] <harlowja_> *for http://paste.ubuntu.com/17334762/
[20:24] <smoser> harlowja_, its ok. you were lucky in that Odd_Bloke did worse :).
[20:24] <harlowja_> lol
[20:24] <smoser> harlowja_, but for your penance...
[20:25] <smoser> want to see if you can get rid of that 'c' file ?
[20:25] <harlowja_> i thought u said u did
[20:25] <harlowja_> ?
[20:25] <harlowja_> why u not fix it yet
[20:25] <harlowja_> lol
[20:26] <smoser> i fixed your pep error
[20:26] <harlowja_> hmmm, good point
[20:26] <harlowja_> ok i fix 'c'
[20:26] <smoser> thefile that creates the 'c' is tests/unittests/test_cli.py
[20:27] <harlowja_> which line fixes it?
[20:27] <harlowja_> lol
[20:28] <smoser> :)
[21:03] <harlowja_> smoser what would u think about making bin/cloud-init -->> cloud-init/cmd/main.py and then using the python tooling to build this cmdline entrypoint
[21:03] <smoser> i do not believe i am opposed to such a thing
[21:04] <harlowja_> k
[21:04] <harlowja_> the whole test_cli gets less weird if thats done imho
[21:04] <smoser> yeah. i'm not sure why Odd_Bloke didn't suggest doing that.
[21:04] <smoser> i think maybe jsut when he did he wanted to be less invasive
[21:05] <harlowja_> ya, cause right now it does
[21:05] <harlowja_> ' cli = imp.load_module(
[21:05] <harlowja_>             'cli', open(BIN_CLOUDINIT), '', ('', 'r', imp.PY_SOURCE))'
[21:05] <harlowja_> which is like woah
[21:05] <harlowja_> lol
[21:11] <harlowja_> because smoser  i did the following on that 'c' file
[21:11] <harlowja_> $ file c
[21:11] <harlowja_> c: python 2.7 byte-compiled
[21:11] <harlowja_> so i'm pretty sure its the imp module dynamically compiling that thing
[21:11] <harlowja_> and if then just bin/cloud-init is an actual importable thing, well this goes all away, ha
[21:16] <harlowja_> cause i'm pretty sure that c file is getting created way down in the import machinery
[21:20] <smemsh> hello,  how do i affect changes to actual root user account (password, chpasswd, ssh_authorized_keys), not the "distro default" ? there does not seem to be a way to specify the user except if creating new one (comment says "add each entry to ~/.ssh/authorized_keys for the configured user or the first user defined in the user definition directive")
[21:22] <smemsh> same if i add password/chpasswd stanza it changes my "distro default" user, not root
[21:48] <smemsh_> does user-data override cloud.cfg in the image filesystem or which takes precendence?
[21:49] <smemsh_> mgagne: thanks for your gist, i don't think that sets the default user though, i think that would have to be done with redefined system_info or default_user
[21:50] <mgagne> link I sent https://gist.github.com/mgagne/5a571499a337975b224e358b5286feb8
[21:50] <smemsh_> mgagne: but, if that does change only the root user, that would solve my issue because i don't care about the "distro user"
[21:50] <mgagne> smemsh_: this is the config we use in our images
[21:50] <mgagne> I can't find the ubuntu user in our image
[21:50] <smemsh_> mgagne: i didn't realize you could specify a user that already existed
[21:51] <mgagne> but if it's built-in the base image, there is little you can do I guess
[21:51] <mgagne> we build our own images from .iso so can't tell when config is applied against cloud images
[21:53] <smemsh_> mgagne: it looks like i can change the distro default user with system_info or default_user, but i don't know if my user-data will override the embedded cloud.cfg in the image or not, or if i would have to make my own images
[21:54] <smemsh_> mgagne: mgagne do you know if the filesystem-supplied cloud.cfg takes precedence over the same values provided from user-data? which "wins" if both places specify?
[21:54] <mgagne> let me try against a cloud image, I think I have one somewhere
[21:54] <mgagne> I don,t know =)
[21:55] <smemsh_> mgagne: i will try, i thought might know
[21:55] <mgagne> once stuff works, I often forget about the details =)
[21:56] <mgagne> works for me
[21:58] <harlowja_> smoser  https://code.launchpad.net/~harlowja/cloud-init/cloud-init-fix-up-cli/+merge/297409 have fun
[21:58] <harlowja_> try that, no 'c' file should appear...
[22:01] <smemsh_> half the stuff in my vendor's cloud.cfg are using underscores and half are dashes.  they must both work
[22:02] <smemsh_> but then i see e.g. https://bugs.launchpad.net/cloud-init/+bug/1531582 which leads me to believe they have to be underscores
[22:02] <harlowja_> pretty sure we have some crappy logic to handle both
[22:03] <smemsh_> harlowja_: probably it would break a billion peoples' configs if you ever decided on one
[22:03] <harlowja_> ya
[22:04] <smemsh_> unfortunately it causes confusion and inconsistency, maybe flag day for version 3 or something ;-)
[22:04] <harlowja_> :-P
[22:05] <smemsh_> harlowja_: if i have same key supplied by both user-data and the cloud.cfg in the image which will have precedence?
[22:05] <smemsh_> and lists will not merge right?
[22:05] <harlowja_> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/helpers.py#L259 the ordering
[22:05]  * harlowja_ i forget if lists merge by default, probably not
[22:06] <harlowja_> so to my understanding smemsh_ user-data overrides all
[22:06] <smemsh_> ahh ok good, that makes more sense then
[22:07] <harlowja_> actually i take that back
[22:07] <harlowja_> its input config files (from say the cli)
[22:07] <harlowja_> then config files from the env (didn't know we could do that)
[22:08] <harlowja_> then user data -> then vendor data then datasource specific stuff then base
[22:08] <smemsh_> L260 comment
[22:08] <harlowja_> ya
[22:08] <smemsh_> you mean _read_cfg() ? ok
[22:09] <smemsh_> so datasource configs are user-data right?
[22:09] <harlowja_> nah, user data is @ http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/helpers.py#L238
[22:10] <harlowja_> datasource configs i'm not sure who uses those
[22:10] <harlowja_> i guess for datasources that don't have the concept of user-data?
[22:11] <smemsh_> so user-data are "instance configs" in that comment?
[22:13] <smemsh_> it says highest -> lowest are: input config files -> env config files -> override instance configs -> datasource configs -> base configuration
[22:13] <harlowja_> ya, that looks about right
[22:14] <harlowja_> and the default merge strategy doesn't overwrite keys from later entries over the newer ones
[22:15] <harlowja_> so a key 'x' in instance config will stay 'x' even if base configuration has the same key
[22:15] <smemsh_> so _get_instance_configs() is the one that picks up user-data ? i had thought that was a "datasource", hrm
[22:15] <harlowja_> its more complicated than that
[22:15] <harlowja_> the datasource does provide the user-data, but the consumption and merging and usage is a different stage of the app
[22:16] <harlowja_> there's a consumption stage and then there are merging/using that config stages
[22:16] <harlowja_> that ranking is post-consumption
[22:16] <smemsh_> by doing ConfigMerger once consumed
[22:16] <harlowja_> ya
[22:16] <smemsh_> from all sources
[22:16] <harlowja_> right
[22:17] <smemsh_> well i'll never say it's not configurable ;-)
[22:17] <smemsh_> as long as i know my user-data will override the cloud.cfg the vendor put there i'm good
[22:17] <harlowja_> :-p
[22:18] <smemsh_> thanks for explanation...
[22:18] <harlowja_> np
[22:23] <smemsh_> btw, there is a syntax for yaml to split long unbroken lines without any spaces, i noticed your docs have long lines for stuff like authorized_keys but they could split them (not sure if this is useful to change)
[22:27] <harlowja_> smemsh_ ya, there is, feel free to submit some adjustments if u want :)
[22:28] <smemsh_> i would if it were on github...
[22:28] <smemsh_> i guess i could set up a launchpad thingy and figure out bzr...
[22:28]  * harlowja_ diverts question to smoser 
[22:28] <harlowja_> more people that yell at smoser about need-for-git the better :-P
[22:29] <harlowja_> where yell == encourage
[22:29] <harlowja_> lol
[22:29] <smemsh_> it's just too easy on github and part of normal workflow.  launchpad is some silo somewhere with different tools, not that it's bad or anything of course
[22:30] <smemsh_> i know canonical likes its umbrella projects on launchpad too if they fund it which is reasonable
[22:57] <ajorg> smemsh_: well, it will let you override cloud.cfg, but only using the default merge strategy.
[23:33] <smemsh_> great i'm all working now.  thanks for help all, have good night.
[23:45] <harlowja_> smoser if u merge https://code.launchpad.net/~harlowja/cloud-init/cloud-init-fix-up-cli/+merge/297409 then merge https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-sysconfig also :-P