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