[02:40] blackboxsw: rharper some interesting numbers collected from my runs for artful zesty and xenial [02:40] http://paste.ubuntu.com/25922247/ [02:40] and with that i go to bed. [16:56] rharper: how do i "dump" the journal [16:56] keeping the original format or whatever [16:56] so that i can then later feed it to journalctl commands [17:06] oh, you copy it from /run/log/journal [17:07] then you use journalctl --directory=/path/to/copy/of/journal [17:07] smoser: ^ [18:41] rharper: http://paste.ubuntu.com/25926898/ [18:44] smoser: oi; that's unfortunate; would be nicer to have journalctl apply and offset [18:45] well, yeah, but. if you have the offset and have the journall og, yhou can do whatever you want. [18:45] we could also read the journal format and update it. [18:45] well, that's what the offset would be fore [18:46] journalctl --offset foo and it just applies that value to the timestamp; but what you have is useful [18:47] right. but such a feature is kind of not expecte. [18:48] no; it's a namespace bug [18:48] and yes , not expected [18:54] Hi, are there any restrictions on the characters in the content section of a file that is written as plain text? [18:54] I am getting an error about unable to load yaml blob... [19:03] blkadder: not that I know of; generally for write files, I try to use the content: | to inline text with minimal formatting [19:04] Hrmm... [19:04] What about blank lines in the file? [19:04] It's busting on something... [19:06] as long as it's indented I think it's fine [19:07] Mind taking a peek? [19:07] pastebin away [19:07] https://pastebin.com/YYrGGd3t [19:08] I've just been using base64 which works fine, but one of the other folks here did this... [19:09] http://paste.ubuntu.com/25927045/ [19:09] that's my inline with newlines and how I check it [19:10] Hmm, wondering if it doesn't like some character or other. [19:10] the ? [19:10] it seems it doesn't like [19:11] ahh [19:11] your path is not indented I think [19:11] there you go [19:11] Ohh... [19:11] Thanks! [19:11] http://paste.ubuntu.com/25927066/ [19:12] * blkadder mumbles something about white space and scope [19:12] Madness. :-) [19:14] blkadder: easiest thing to do is to check that things are at least loadable as yaml [19:14] I included my yprint which loads and dumps yaml [19:14] we are working towards having a cloud-init tool to validate config [19:15] ah. i didnt see that rharper [19:15] yeah [19:15] basically: [19:16] Cool, thanks. [19:17] Would love a linter. :-) [19:17] blkadder: cloud-init devel schame --config-file will at least validate yaml for you (and some cloud-init keys currently) [19:18] blkadder: cloud-init devel schema --config-file will at least validate yaml for you (and some cloud-init keys currently) [19:18] it in progress currently, (as a 'devel' subcommand) we're building it up as smoser suggested. [19:27] Awesome, thanks. [19:27] That is going in the toolbox. === dustymabe is now known as langdont === langdont is now known as dustymabe [21:21] blackboxsw: could you https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/333350 [21:21] smoser: rharper how best to yeap [21:21] oops [21:21] yeap [21:21] yeap ? [21:21] best way to yeap is just to do it. let your personality ring out. [21:21] lol [21:21] each person has their own 'yeap' [21:21] *yawn* [21:21] I need more yeap [21:22] * smoser thinks "theres a million ways to yeap" [21:22] https://www.youtube.com/watch?v=dDZyJTDZi0w [21:24] ha! [21:25] ok approved smoser want me to merge? [21:25] smoser: quick question, the CI_DOMAIN value is not resolvable; is that expected ? later in the code there is a cloudinit2. [21:25] the subdomain is resolvable [21:25] so I suppose I'm missing something [21:26] hm. [21:26] we use CI_DOMAIN in python code [21:26] oh i see. yeahk, i didnt change the set_hostname_fqdn to use CI_DOMAIN [21:27] i could have... [21:27] - ex_fqdn = "cloudinit2.i9n.brickies.net" [21:27] 26 + ex_fqdn = "cloudinit2.i9n.cloud-init.io" [21:27] 27 [21:27] but since we'd need some further magic to make the set_hostname_fqdn.yaml [21:27] then its kind of 50/50 i think [21:27] well, if we changed the domain in the future we might miss [21:27] no ? [21:27] ie, there is usefulness in those strings being simple identical strings there. [21:27] so ex_fqdn = "subdomain." + CI_DOMAIN ? [21:28] or setting CI_DOMAIN to just the full string that's resolvable ? [21:28] but you have to change tests/cloud_tests/testcases/modules/set_hostname_fqdn.yaml anyway [21:28] again, I'm prolly missing something [21:28] just the diff by itself looks odd to me [21:28] well, line 39 there... [21:28] thats yaml [21:28] well, the yaml could use a template if we waned [21:28] so we can't as easily change that. [21:28] right. yes we could do something like that. but we dont do anything like that. [21:29] not in cloud-init [21:29] we do in vmtest for curtin [21:29] for similar reasons [21:29] we could include a # should match CI_DOMAIN from nocloudkvm.py in the yaml for a marker/hint [21:29] well. i dont knwo. i dont think there is a lot of value in it. its a string. tests cases are full of string duplication. if you think it shoudl say 'cloudinit2.' + CI_DOMAIN [21:30] then i can make it say that [21:30] so yaml aside, why doesn't CI_DOMAIN just equal the fqdn we want ? [21:30] but i'm not really interested in tmemplating yaml just for that. [21:30] I don't have a strong opinion other than it looked strange to me [21:30] that's fair on the template [21:31] blackboxsw: you think its worht the change there? [21:31] rharper is suggesting line 26 in the web diff would show: [21:32] ex_fqdn = "cloudinit2." + CI_DOMAIN [21:32] (probably an import to get it too) [21:32] it's a good point, either that + CI_DOMAIN or a comment cross-referencing the why [21:33] k. i'll push that [21:33] yes, don't want just magic, as then we have to fgrep [21:33] the "later we" who forget this [21:35] but you ahve to grep anyway [21:35] because of the yaml [21:35] true story [21:36] and i thought the inability to change the yaml and the proximity of the two meant it was more straight forward to have the same string [21:36] but aywahy. [21:37] hold up a sec. :/ hmm. I'm onboard w/ the import in python for CI_DOMAIN. [21:37] in yaml just want that string comparison [21:37] those files are side-by-side and easy to Xreference [21:37] no need to do much work for the yaml as I want just plain expected strings etc. [21:39] I kindof liken it to our unit test assertEquals('some-string', result_of_somefunc) it's nice to see the full expected string unaltered by having to decode what CI_DOMAIN means [21:40] smoser: rharper ^. I don't really mind one way or another. Just wanted a stance [21:40] I liken 'it' (the yaml file as the plain string assertions) [21:41] I suggested a comment in the yaml to point back to the variable source [21:42] IMO; I'd see CI_DOMAIN='cloudinit2.i9n.cloud-init.io'; then the test py code import CI_DOMAIN; and the yaml use the string value of the variable and add # CI_DOMAIN from nocloud_kvm.py [21:42] so, one variable, one string; all .py code uses the same variable; and the yaml points to the variable via comment string [21:42] ok +1 /me should go back to reading comprehension school [21:51] ok. udpated. [21:51] rharper: [21:52] k [21:52] good enough