[03:18] <jog> axw, axw_, your commit to the structured-metadata branch didn't run through CI because it needs a version update, since 1.26-alpha3 was released to devel late last week.
[03:21] <axw> jog, ok, thanks
[04:03]  * thumper is done for another day
[04:03] <thumper> laters folks
[08:32] <frobware> jam, ping
[08:34] <jam> frobware: pong
[08:34] <jam> I heard you were up late trying to work on this stuff, thanks for helping me pick it up
[08:34] <frobware> jam, If I ask MAAS for the DNS info it comes back empty
[08:35] <frobware> jam, np - though I need to go out in about 10 mins
[08:35] <jam> frobware: dns_servers for the subnet comes back with nothing? I wonder how maas is filling it out from DHCP.
[08:35] <jam> I have the feeling there are some secret bits to configuration that neither MaaS nor we were realizing.
[08:36] <frobware> jam, I took a path to least resistance. We already parse the hosts /etc/resolv.conf so I took that route here too.
[08:36] <frobware> jam, if I `maas 9 nodes list |grep dns` I get no entries
[08:36] <frobware> jam, well, I get  "dns_servers": []
[08:37] <frobware> jam, when I say "already" that's what we do when address-allocation is enabled
[08:38] <jam> frobware: k, I think the trick there is that maas has a space for people to set up dns servers for subnets that you define, but they don't actually put their own information into the one that they manage
[08:38] <frobware> jam, I was almost confused by "space" there. :)
[08:39] <jam> frobware: can we think of anything other than nameservers that DHCP would be setting up that we would be missing?
[08:39] <jam> heh
[08:39] <jam> Like routes ?
[08:39] <frobware> jam, if you look at the containers /e/n/i it seems to do that itself
[08:40] <jam> frobware: gateway IP seems to be in the DHCP message
[08:40] <jam> but I'm guessing we know we need to set that up already?
[08:41] <frobware> jam, hmm. so this is specified in the LXC config
[08:42] <frobware> jam, and looking at my container I have a default route
[08:42] <jam> so DHCP has a fair number of options, Router, Time Server, Name Server, Domain Name Server, Log Server, Cookie Server, LPR Server, Impress Server, Resource Location Server
[08:43] <jam> Host Name, Boot File Size, Merit Dump File, Domain Name, Swap Server, Root Path, Extensions Path
[08:43] <jam> I'm guessing we don't need to use all of those, but that would be the sort of thing that we need to be clear on what we are and aren't using as we switch away from DHCP
[08:44] <frobware> jam, ac
[08:44] <frobware> jam, ack
[08:44] <jam> as long as its "ack" and not "ack!"  :)
[08:44] <jam> (eek! (?) )
[08:44] <frobware> jam, try ag. or pt.
[08:45] <jam> heh. I'm happy with ack, just bringing levity.
[08:45] <frobware> jam, and ag is nicely integrated with Emacs. But pt is written in go...
[08:45] <jam> wouldn't it just be "p" in go ?
[08:45] <jam> can't waste characters like that
[08:46] <frobware> jam, depends on font size
[08:47] <frobware> jam, is there anything else I can convey now? I'll check back in later but I suspect you'll be long gone.
[08:48] <jam> frobware: no I think we're good. I'll take custody of your patch and add some tests, and do some due diligence that we aren't missing anything else.
[08:48] <jam> frobware: thanks for helping on this during your holiday. enjoy your day
[08:48] <frobware> jam, great and thank you!
[08:51] <frobware> jam, so there was 1 unit tests failure. FAIL: client_validation_test.go:56: ClientValidationSuite.TestClaimLeaseName
[08:51] <frobware> jam, I didn't see that for the single run I did locally
[08:53]  * frobware needs to run - already late. Adios!
[09:38] <jam> weird, that test passes here
[09:38] <jam> seems like it is a random failure, but I'll investigate
[11:43] <jam> jog_: when you're around give me a ping
[13:48] <mup> Bug #1528572 opened: lxcBrokerSuite.TestStopInstance fails if a loopback is currently mounted <testing> <juju-core:Triaged> <https://launchpad.net/bugs/1528572>
[15:05] <ericsnow> natefinch: can you see or hear me on the hangout?
[16:18] <natefinch> ericsnow: trying to figure out the right place to convert Timestamp to used.  I guess the question is - do we expect Used to be printed out in the yaml output, or not?
[16:19] <ericsnow> natefinch: convert it in the formatter
[16:20] <ericsnow> natefinch: Used should be a field on the new "formatted" struct
[16:20] <natefinch> ericsnow: ok, yeah, that's basically what I was wondering - should it be in the struct or is it purely a "view" of the data in tabular format.
[16:21] <natefinch> ericsnow: I'm fine with it being in the struct
[16:21] <ericsnow> natefinch: k
[16:22] <natefinch> ericsnow: lol, just noticed resource.Type ... where there's only one valid value :/  (not your fault of course)   .... do we know what other values besides "file" might be used?
[16:23] <ericsnow> natefinch: there was talk of other things like repos
[16:23] <natefinch> ericsnow: that's interesting
[16:23] <ericsnow> natefinch: haven't worried about it because the semantics aren't clear and I don't have time :)
[16:23] <natefinch> ericsnow: right.
[16:55] <jog> jam, pong
[17:04] <perrito666> jam: hey can we schedule a time after the shutdown to go over security groups in aws so I make sure I dont screw anything?
[17:09] <perrito666> oh, cmoom, blocked? that is so unfair
[18:52] <natefinch> ericsnow: I note that the FormattedCharmResource has a bunch of fields not actually used in the tabular format... do you think we should drop them until they're asked for?
[18:52] <ericsnow> natefinch: we expose them through the JSON and YAML formatters
[18:53] <natefinch> ericsnow: yes, but there's not even anything in the spec about there being json and yaml formatters, let alone what fields are expected to be there
[18:54] <ericsnow> natefinch: so are you arguing that we should drop them?  If so, why?
[18:54] <rick_h_> natefinch: ericsnow any list commands should take fornstters so they're consistent
[18:55] <natefinch> rick_h_: ok
[18:55] <natefinch> ericsnow: just don't want to presume what should be displayed
[18:55] <ericsnow> natefinch: understood
[18:55] <natefinch> ericsnow: less to maintain
[18:57] <natefinch> rick_h_: there's a limited amount of information shown in the two list resources commands, as written in the spec.  Presumably this is to keep the tabular format small.  But what should we put in the yaml/json?  In theory, there's a lot more we can put in there, but my initial assumption would be to just put in the same data as in tabular
[18:57] <ericsnow> natefinch: we should put everything in there, which is what we've done
[18:59] <natefinch> ericsnow: "everything" is a rather fungible concept, though
[18:59] <natefinch> I guess that's why we do demos :)
[18:59] <ericsnow> natefinch: :)
[19:00]  * perrito666 imagines juju status returning even the source code for juju itself
[19:01] <rick_h_> natefinch: ericsnow i'm notnsure what thenlist of all metadats is but i'd think a basic dump of known details that matched up with a show command
[19:01] <rick_h_> natefinch: ericsnow but to be bqckward compatible best tonstart with less and add sipport than tonrekove later as anbackward incompatiblenchange
[19:02] <natefinch> yeah, I was just thinking that... once we start writing things out, we have to support those fields for forever
[19:02] <natefinch> though obviously that's not written in stone until we merge to master ;)
[19:02] <ericsnow> natefinch: let's table any changes there to after this iteration is complete (make a card)
[19:02] <rick_h_> natefinch: so i'm open tona list and starting feedback from stakeholders on 'need it' vs 'nope'
[19:03] <natefinch> ericsnow: sounds good
[20:32]  * natefinch just invented a new word - charmtabular.
[20:32] <natefinch> thumper: hope you're having a charmtabular day so far.
[20:35] <thumper> pretty quiet so far
[20:35] <thumper> get to just focus on hacking for a change
[20:35] <natefinch> nice
[20:36] <natefinch> I can tell I'm working with ericsnow's code, because everything gets a lot easier now that I have 5 windows open ;)
[20:36]  * ericsnow opens another tab to read natefinch's message
[20:37] <natefinch> haha
[20:38] <natefinch> honestly, it's not so hard with two big monitors, it's doijng it all on one 15" monitor that's the real problem (for me)
[21:12] <natefinch> ericsnow: this is a bad habit to get into: https://github.com/juju/charm/blob/v6-unstable/resource/fingerprint.go#L23
[21:12] <natefinch> ericsnow: far better to make() the target slice the correct size and just use copy to copy it over
[21:12] <ericsnow> natefinch: I started doing it when I saw it done in the stdlib :)
[21:13] <natefinch> ericsnow: hmm... maybe append is smarter than I'm thinking
[21:44] <natefinch> ericsnow: far better to make() the target slice the correct size and just use copy to copy it over
[21:45] <natefinch> oops
[21:46] <natefinch> ericsnow: I was just doing some benchmarking... I guess apend actually is smarter than I realized.  both are very very similar in memory usage and speed.
[21:47] <natefinch> I figured append would be wasteful of space, but it looks like it's just rounding up a little on capacity
[22:01] <mup> Bug #1528703 opened: juju unable to deploy juju-gui to lxc containers on servers with multiple networks <juju-core:New> <https://launchpad.net/bugs/1528703>
[22:04] <mup> Bug #1528703 changed: juju unable to deploy juju-gui to lxc containers on servers with multiple networks <juju-core:New> <https://launchpad.net/bugs/1528703>
[22:07] <mup> Bug #1528703 opened: juju unable to deploy juju-gui to lxc containers on servers with multiple networks <juju-core:New> <https://launchpad.net/bugs/1528703>