[02:47] <natefinch-afk> ericsnow: you around?
[03:37] <mup> Bug #1477355 changed: MachineSuite.TestDyingMachine fails on windows <blocker> <ci> <regression> <unit-tests> <windows> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1477355>
[04:05] <sinzui> axw: We need to let ci mark the fix released so that the master is unblcked with an bless
[04:07] <axw> sinzui: sorry, I just saw that the bug was resolved, so thought it shouldn't be blocking anymore. will leave it next time.
[04:08] <sinzui> axw: i am pretty sure the bug  is resolved since the remaining tests passed in our previous efforts. CI though wants a bless rather that some tests passing. The bless can happen before all tests have run if non-voting tests are the only ones left runnung
[04:09] <axw> sinzui: okey dokey
[04:10] <sinzui> I think the last two viting jobs are running, but they are long. master will be opened in about 45 minutes...get ready to merge
[04:13] <mup> Bug #1477355 opened: MachineSuite.TestDyingMachine fails on windows <blocker> <ci> <regression> <unit-tests> <windows> <juju-core:Fix Committed by axwalk> <https://launchpad.net/bugs/1477355>
[04:52] <mup> Bug #1477355 changed: MachineSuite.TestDyingMachine fails on windows <blocker> <ci> <regression> <unit-tests> <windows> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1477355>
[05:55] <axw> wallyworld: FYI: https://github.com/juju/juju/pull/2879. probably won't get it backported today, so no rush for a review. in case you're queried though, the fix is there
[06:00] <wallyworld> axw: reviewed, i meant to make the comment not an issue but a question, gotta go do school pickup, will catch you next week, have a good weekend
[06:01] <axw> wallyworld: cheers, have a good week
[06:01] <wallyworld> will try to :-)
[07:52] <mattyw> fwereade_, ping?
[08:30] <fwereade_> waigani, couple of comments on http://reviews.vapour.ws/r/2250/ -- happy to discuss if you're around
[09:01] <TheMue> fwereade_: hangout?
[10:08] <mup> Bug #1477920 opened: juju bootstrap failed with "discarding API open error" <juju-core:New> <https://launchpad.net/bugs/1477920>
[10:32] <fwereade_> perrito666: early-morning complaining
[10:32] <fwereade_> perrito666, Service.Status()
[10:33] <fwereade_> perrito666, returns a service status document if it exists, and otherwise aggregates unit status
[10:33] <fwereade_> perrito666, how is that meant to work?
[10:35] <fwereade_> perrito666, (what if nobody's set a service status for 6 hours?)
[10:38] <fwereade_> perrito666, actually, when you come on -- please look in detail at http://reviews.vapour.ws/r/2255/
[10:39] <fwereade_> perrito666, then we can talk in that context
[10:55] <perrito666> Morning
[10:55] <perrito666> Fwereade i am in my cell phone as soon as I get to a pc I'll answer and look at your patch
[10:56]  * mgz imagines horacio strunk down to teeny size to fit inside his phone
[10:57] <perrito666> Very short answer service shows its status, they can only be set by the leader, or an aggregated status from its units
[10:58] <perrito666> Wow autocorrect on this phone really sucks in English
[10:58] <perrito666> And my English too
[10:58] <mgz> hey, I accidentally made up a word when making fun of your english
[10:58] <mgz> so should really not talk
[11:00]  * perrito666 is in a bar getting breakfast after having his blood sampled
[11:00] <perrito666> I really wish the could find a less cumbersome way to get metrics from me
[11:01] <mgz> maybe you should provide an api
[11:24]  * perrito666 is back in a computer
[11:26] <fwereade_> perrito666, cool
[11:26] <fwereade_> perrito666, so I contend that we're doing it in the wrong place
[11:27] <fwereade_> perrito666, http://reviews.vapour.ws/r/2255/diff/1/?file=81513#file81513line1217
[11:28]  * perrito666 reas
[11:30] <perrito666> fwereade_: ok, throw some justification to that?
[11:30] <fwereade_> perrito666, um, in the comment?
[11:30] <fwereade_> perrito666, the given approach gives bad values on a wide range of not-very-unhappy paths
[11:30] <perrito666> duh, I ignored the comment
[11:31] <perrito666> if you broke something its certainly not there
[11:32] <fwereade_> perrito666, well, yes, there is also the clear fact that service status code does not exist because it's not tested, so we are merely discussing the features of a shared hallucination
[11:33] <fwereade_> perrito666, so, the set-service-status code used to insert if the doc wasn't there
[11:34] <fwereade_> perrito666, wallyworld told me that was to work around one of the not-understanding-mgo/txn things, and could be safely removed
[11:34] <fwereade_> perrito666, it turns out that, no, there is logic to do things when the service status doc is not there
[11:34] <fwereade_> perrito666, so it is significant
[11:35] <perrito666> yes, iirc when we talked its because there is no upsert?
[11:35] <fwereade_> perrito666, please reread the comment
[11:35] <fwereade_> perrito666, you should not want to upssert
[11:35] <fwereade_> perrito666, upserting is wrong
[11:35] <fwereade_> perrito666, and causes us to lie to the user all the time
[11:36] <fwereade_> perrito666, it's the leader's job to set the service status
[11:36] <fwereade_> perrito666, not the state server's job to backstop for it
[11:37] <perrito666> fwereade_: you are mixing layers, the leader job is to set status, it doesnt really care if service has a statusDoc already in place or not
[11:38] <fwereade_> perrito666, you said it yourself
[11:38] <fwereade_> perrito666, it is the leader's job to set the service status
[11:38] <fwereade_> perrito666, just as it is a unit's job to set its own status
[11:39] <fwereade_> perrito666, if the unit doesn't bother, the *uniter* supplies a default implementation
[11:39] <fwereade_> perrito666, otherwise you have two distributed components each reponsible for setting the same value, and no sane synchronisation between them
[11:40] <fwereade_> perrito666, which does not generally lead to happy outcomes
[11:41] <fwereade_> perrito666, and in this particular case will *obviously* deliver stale values in several scenarios
[11:41] <fwereade_> perrito666, and *probably* doesn't have any worse behaviour
[11:42] <fwereade_> perrito666, but *only* because the second thing with an opinion never writes it to the db, and only sometimes tells the user what its opinion is
[11:43] <fwereade_> perrito666, am I making sense?
[11:44] <perrito666> you are being a bit socratic, but yes, basically yes, you are not making a point from which to extract action though
[11:44] <fwereade_> perrito666, what I am primarily seeking is acknowledgement that trying to jam all our logic into state is a disaster
[11:45] <fwereade_> perrito666, in the hope that you and others will more carefully consider the impact of their layering decisions
[11:48] <fwereade_> perrito666, and I guess that's what I'm also hoping for from that review -- I made an effort to only fix the very worst problems in state, and do so only to the minimum standard I felt professionally comfortable with
[11:48] <fwereade_> and that's still, what, a 2800-line diff
[11:49] <fwereade_> perrito666, and if there is any doubt whatsoever as to why any of the changes were made, or disagreement over whether they should be, we should talk it out
[11:50] <fwereade_> perrito666, in particular I am now pissed off because it looks like there's no way to introduce sane behaviour without an upgrade step
[11:51] <fwereade_> perrito666, because service status is *sometimes* calculated differently from other types of status
[11:51] <fwereade_> perrito666, and therefore apparently we should write new apis and new model types and new serialization rules and new document-existence conventions and ARRRRGH
[11:53] <fwereade_> and NO FRICKING TESTS
[11:53]  * fwereade_ is done for now
[12:21] <fwereade_> perrito666, I am sorry to rant at you, it is not productive :(
[12:22] <perrito666> well you did attach a patch to your rant, it makes up a bit for it ;)
[12:26] <bogdanteleaga> is any gwacl expert around?
[12:26] <fwereade_> perrito666, and now I start thinking about it it's not just an upgrade step it's ofc the uniter change too...
[12:28] <perrito666> fwereade_: it is not  a light decission, I think that, if service status is going to grow, such grouth must be first reconciled with the existing health spec
[12:32] <fwereade_> perrito666, I do not think it is a hard decision -- it is clearly wrong, because it performs unhelpfully in poor conditions, and we have to write code that assumes and tolerates poor conditions
[12:34] <perrito666> not hard, I dont think I can express that particular problem in english, whatever we do with this status is going to stick with us, needs to accomodate the spec already decided (introduce changes that get accepted) and needs to take in account all our immediate future wishes for the health work
[12:56] <sinzui> wow 3 blesses for master in row.
[12:58] <anastasiamac> sinzui: we must b mid-cycle ;D
[12:58] <sinzui> indeed :)
[13:12] <mup> Bug #1472749 changed: github.com/juju/utils has contradictory licences <juju-core:Fix Released by sinzui> <juju-core 1.24:Fix Released by sinzui> <https://launchpad.net/bugs/1472749>
[13:16] <natefinch> ericsnow: you around?
[13:16] <natefinch> or wwitzel3 ?
[13:16] <wwitzel3> natefinch: yeah
[13:17] <natefinch> wwitzel3: are we supposed to be showing processes in yaml status by default or with a --processes flag?  I had thought I'd seen a --processes flag somewhere, but I don't see it in the spec now
[13:18] <wwitzel3> natefinch: by default now
[13:18] <natefinch> wwitzel3: ok, good, that's what I have done :)
[13:22] <perrito666> rick_h_: you beat me to the joke to mattyw
[13:22] <rick_h_> perrito666: lightning paws!
[13:24] <mattyw> perrito666, rick_h_ since when is twitter a medium that requires people not to duplicate messages?
[13:24] <mattyw> lol natefinch wins
[13:24] <rick_h_> mattyw: twitters approved form of dupes is the RT :P
[13:30] <perrito666> so mattyw wanna tell us about your new job?
[13:32] <mattyw> perrito666, can't think of anything funny to reply with :(
[13:37] <natefinch> dammit, another package with friggin' table driven tests... man those things make it so hard to figure out what is failing AND you can't then rerun just a single test.
[13:38] <perrito666> natefinch: yep, at least there should be a way to make the runner pick an element of the table and just try that
[13:38] <perrito666> it shouldnt beall that hard to implement, sicne you are there :p
[13:48] <natefinch> wow.... Sublime's open file dialog (maybe it's the linux one, I don't know if there is such a thing?)  sorts files by name very weirdly.  It seems to ignore underscores when sorting by name.  so status.go  status_formatters.go then statushistory.go
[13:48] <natefinch> boggle
[13:51] <natefinch> oh 3500 line file, fantastic
[13:51] <dooferlad> natefinch: you don't just hit ctrl+p and start typing bits of path and file name?
[13:51] <TheMue> hehe, pretty small and very good maintainable
[13:53] <natefinch> dooferlad: No, I'm not really a super user of sublime.   I should probably learn more of this stuff.   Didn't realize ctrl+p could do that
[13:55] <dooferlad> natefinch: I am not a super user of sublime either, but I try. With gosublime installed ctt
[13:55] <dooferlad> ctrl + . then ctrl + g is very useful
[13:55] <dooferlad> that or F12
[13:55] <perrito666> I hate being a over the average user of an editor, it makes me an idiot in any other editor
[13:55] <dooferlad> both try and get you to a definition.
[13:56] <TheMue> take vim
[13:56] <TheMue> or katco would say you should take emacs
[13:56] <TheMue> ;)
[13:56] <dooferlad> the JetBrains go to definition logic is the best I have found, but the go plugin is still in heavy development and it can cause the editor to lag.
[13:57] <perrito666> TheMue: well I tried to go from vi to emacs, I completely failed, and I dont think emacs had anything to do with it, I just became too vi dependent
[13:57] <katco> TheMue: i am but a messenger for the divine creator which is emacs
[13:57] <TheMue> perrito666: once being trained on a product it always is hard to switch seamlessly
[13:57]  * TheMue remembers good old times with SPF/2
[13:58] <perrito666> TheMue: the problem is I was unable to do fairly reasonable stuff
[13:58] <natefinch> dooferlad: yeah, I remapped ctrl+shift+g to go to definition.  I don't do two key shortcuts.
[13:58] <perrito666> natefinch: so hardcore
[13:58] <TheMue> perrito666: I'm no emacser too. using vim when hopping from server to server and bbedit today as my development environment
[13:58] <natefinch> perrito666: there should be no "then" in a shortcut, otherwisei t's not a shortcut
[13:58] <perrito666> you will all laugh at me, but I really miss turboC editor
[14:00] <TheMue> perrito666: which inherited from turbo pascal, yeah, which inherited from wordstar
[14:00] <natefinch> wtf? https://github.com/juju/juju/blob/master/cmd/juju/commands/status_test.go#L3712
[14:02] <katco> natefinch: standup
[14:18] <mup> Bug #1478024 opened: Looping config-changed hooks in fresh juju-core 1.24.3 Openstack deployment <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1478024>
[14:25] <natefinch> ericsnow: not going to get that review up this second... unfortunately there was a merge in there that is confusing git, so my PR looks like it has 100 of your commits in it
[14:25] <ericsnow> natefinch: np
[14:29] <katco> perrito666: the only thing i am adamant about with editors is this: if it's your job to edit text, find an editor and learn everything about it
[14:29] <katco> perrito666: and it would behoove you to find an editor you can use for the rest of your life
[14:30] <katco> perrito666: this is why i like emacs; it has grown with me and followed me across windows, linux, os x, and bsd
[14:34] <katco> natefinch: lmk when your changes are pushed to a branch i can merge
[14:35] <bogdanteleaga> perrito666: you should try spacemacs
[14:36] <natefinch> katco: everything is on my fix-status branch, but I think cherry-picking one of your changes may have confused git or something
[14:36] <natefinch-afk> gotta run
[14:48] <mup> Bug #1478027 opened: supportedSeriesWindowsSuite.TestSupportedSeries mismatch with "arch" <blocker> <ci> <regression> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1478027>
[15:08] <bogdanteleaga> http://reviews.vapour.ws/r/2259/ for the supportedseries bug
[15:08] <bogdanteleaga> anybody knows why ubuntu only returns ubuntu series when SupportedSeries is called?
[15:44] <mattyw> evilnickveitch, ping?
[15:44] <evilnickveitch> mattyw, hey
[15:54] <mup> Bug #1478051 opened: KVM provider should expose host CPU to guest <kvm> <local-provider> <juju-core:New> <https://launchpad.net/bugs/1478051>
[17:16] <katco> ericsnow: looks like i have what i need from the feature branch. merge away!
[17:16] <ericsnow> katco: thanks
[17:16] <katco> ericsnow: ty for waiting
[17:39] <natefinch> gah, sometimes I really hate git
[17:47] <natefinch> ericsnow: somehow I think when I merged some of katco's stuff into my branch, it brought in a bunch of featuretest stuff as well.  Are those going to get into the feature branch anytime soon?
[17:48] <ericsnow> natefinch: probably not today but Monday
[18:03] <perrito666> Bbl
[18:16] <natefinch> think i finally got the correct revisions cherry-picked into a new branch that I'll be able to propose
[18:19] <natefinch> ericsnow: is the launch command proc-launch now or something?
[18:19] <ericsnow> natefinch: process-launch
[18:20] <natefinch> ericsnow: ok, cool.  gotta update my charms
[18:20] <ericsnow> natefinch: k
[18:21] <mup> Bug #1477920 changed: juju bootstrap failed with "discarding API open error" <bootstrap> <cloud-installer> <maas-provider> <juju-core:New> <https://launchpad.net/bugs/1477920>
[18:47] <natefinch> ericsnow: http://reviews.vapour.ws/r/2261/
[18:47] <ericsnow> natefinch: yeah, I'll take a look soon
[18:48] <natefinch> ericsnow: thanks
[20:05] <natefinch> gah, I cannot for the life of me get goyaml to omit an empty map
[20:05] <natefinch> it works in a simple testcase, but in the status output... it's not.
[20:06] <natefinch> also - goyaml seems to always lowercase the field names, which means like half our struct tags are unnecessary
[20:26] <natefinch> wow, man.... don't ever typo a struct tag
[20:26] <perrito666> natefinch: there was a policy about where to put tags
[20:27] <natefinch> perrito666: can you find the typo?
[20:27] <natefinch> Components         map[string]interface{} `json:"components,omitempty", yaml:"components,omitempty"`
[20:27] <natefinch> the yaml wasn't doing the omit empty
[20:27] <perrito666> I give up
[20:28] <natefinch> perrito666: the comma between the json definition and yaml definition is incorrect
[20:28] <natefinch> should not exist
[20:28] <natefinch> correct version:
[20:28] <natefinch> Components         map[string]interface{} `json:"components,omitempty" yaml:"components,omitempty"`
[20:34] <natefinch> that one frigging comma was making a ton of tests fail.  Stupid comma.
[20:34] <perrito666> yeah, the comma
[20:38] <natefinch> I wish omitempty on a map would omit it if the len of the map was zero, not just if the map was nil
[20:40] <natefinch> I bet go vet catches the struct tag problem
[20:41] <natefinch> yep, it does
[22:38] <marcoceppi> katco: ping
[22:44] <marcoceppi> katco: for when you get back https://bugs.launchpad.net/juju-core/+bug/1478156
[22:44] <mup> Bug #1478156: summary format does not give enough details about machine provisioning errors <charmers> <juju-core:New> <https://launchpad.net/bugs/1478156>
[22:58] <mup> Bug #1478156 opened: summary format does not give enough details about machine provisioning errors <charmers> <juju-core:New> <https://launchpad.net/bugs/1478156>