[01:48] <davecheney> oh this fslock class
[01:48] <davecheney> func (r *Reboot) checkForRebootState() error {
[01:48] <davecheney>         if r.machineLock.IsLocked() == false {
[01:48] <davecheney>                 return nil
[01:48] <davecheney>         }
[01:49] <davecheney> another fun part is the way the reboot worked lets you provide it with a lock ...
[01:49] <natefinch> yeah, the fslock code is only half the problem, the other half is how the rest of the code is abusing it
[02:21] <natefinch> is there a trick to bootstrapping maas in 2.0?
[02:21] <natefinch> $ ./juju bootstrap maas maas --upload-tools
[02:21] <natefinch> ERROR detecting credentials for "maas" cloud provider: credentials not found
[02:21] <natefinch> $ ./juju add-credential maas
[02:21] <natefinch> ERROR cloud maas not valid
[02:21] <rick_h_> natefinch: I think it's the whole $maas/$IP thing that got added in
[02:22] <natefinch> rick_h_: I don't even see maas in juju list-clouds... is there help for this somewhere?
[02:22] <rick_h_> natefinch: in the release notes
[02:24] <natefinch> rick_h_: people who commit new functionality without proper help in the CLI make hulk angry
[02:25] <anastasiamac_> natefinch: i think u ned to add cloud of type maas first, then bootstrap it \o/
[02:37] <natefinch> ug, this is a poor UX
[02:39] <natefinch> "MAAS works out of the box"   "Bootstrapping models using ... MAAS ... providers also Just Work"  ....lol no
[02:39] <natefinch> unless we have drastically different ideas of what "Just works" means.
[02:45] <natefinch> a little ways down "For MAAS and OpenStack clouds, it's necessary to edit a clouds.yaml file."... ahh, ok.  Maybe we should remove the "just works" BS from mentioning MAAS?
[02:47] <davecheney> great, the worker/uniter test _require_ that BreakLock _always_ breaks the lock
[02:52] <natefinch> :wq
[02:52] <natefinch> heh
[02:53] <davecheney> hmm, or maybe they don't pass at all
[02:56] <davecheney> nope, they just don't pass at all
[02:56] <natefinch> nice
[02:58] <natefinch> davecheney: I do have a new fslock library mostly written.  I got stuck with an error message on windows having to do with overlapped IO, which is required to do the timeout in a non-terrible way... but since the linux code is already doing the timeout in a semi-terrible way, I could easily do windows the same way and have it read to go pretty quickly (or I could spend some time figuring out the windows error)
[02:58] <natefinch> davecheney: I didn't look too carefully at what it would take to rip out all the garbage from juju's code that requires breaklock etc, however
[03:01] <mup> Bug #1584565 opened: Documentation regarding user management is out of date <juju-core:New> <https://launchpad.net/bugs/1584565>
[03:02] <natefinch> davecheney: there also appeared to be some BS About storing a message in the file and then reading the message to determine who had the lock, which I also assumed was just a Bad Idea, and therefore would probably not be hurt by just being ripped out.
[03:02] <davecheney> that is a monsterous idea
[03:02] <davecheney> it's not concurrency safe
[03:03] <davecheney> lock.ReadMessage() => "stale message"
[03:03] <natefinch> yawp
[03:03] <davecheney> if you make a decision based on that data, that's a mistake
[03:03] <natefinch> it's possible it was only something as innocuous as a log message, still bad, but not fatal
[03:03] <davecheney> maybe that's a way to approach it
[03:04] <davecheney> remove the Message() method
[03:04] <davecheney> that might give a more tractable hold on removing BreakLock
[03:05] <natefinch> davecheney: https://github.com/juju/juju/blob/master/worker/uniter/uniter.go#L394
[03:11] <davecheney> stop, you'll make me cry
[03:12] <natefinch> and actually... anywhere at all that calls lock or lock with timeout or lock with func.... https://github.com/juju/utils/blob/master/fslock/fslock.go#L279
[03:13] <natefinch> which at least is apparently just for logging
[03:42] <natefinch> gah, what I wouldn't give for a dedicated maas environment that I could test on.
[03:50] <davecheney> great, c.Logf, doesn't log anything
[03:52] <natefinch> don't you need either a failure or -checl.vv or something to get those to show up?
[03:53] <natefinch> this is why I just use fmt.printf, because that just works
[03:54] <natefinch> (for debugging, obv)
[03:56] <natefinch> bedtime for me
[03:59] <davecheney> thanks, that worked
[03:59] <davecheney> that's stupid
[03:59] <davecheney> i want log output
[03:59] <davecheney> i don't want to debug gocheck
[03:59] <davecheney> which is what -vv does
[04:26] <davecheney> http://reviews.vapour.ws/r/4881/
[07:08] <mup> Bug #1584616 opened: mtu configuration should not be moved to bridge interface <juju-core:New> <https://launchpad.net/bugs/1584616>
[07:35] <mup> Bug #1584616 changed: mtu configuration should not be moved to bridge interface <juju-core:New> <https://launchpad.net/bugs/1584616>
[08:05] <mup> Bug #1584626 opened: cmd/jujud/agent: MachineSuite.TestDyingModelCleanup is flaky and unreliable <intermittent-failure> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1584626>
[08:49] <dimitern> babbageclunk: morning :) can you have a second look on http://reviews.vapour.ws/r/4871/ please?
[08:50] <babbageclunk> dimitern: sure! Looking now.
[08:50] <dimitern> babbageclunk: ta!
[09:17] <voidspace> dimitern: http://reviews.vapour.ws/r/4874/
[09:48] <frobware> voidspace: did you want to chat. 1:1?
[09:48] <voidspace> frobware: I need coffee!
[09:49] <voidspace> frobware: anything you want to chat about?
[09:49] <frobware> voidspace: ok. top of the houor?
[09:49] <frobware> hour
[09:49] <voidspace> sure
[13:35] <dimitern> babbageclunk: the whole point of having "preferred" addresses is that once set, they cannot change (unless they get removed, then another "sticky" preferred will be picked)
[13:36] <dimitern> babbageclunk: PrivateAddress() and PublicAddress() prefer to return IPv4 addresses if available, falling back to IPv6 otherwise (if any), finally returning NoAddressError
[13:37] <babbageclunk> dimitern: It seems like those are at odds - if a machine gets an IPv6 address first, and then later gets an IPv4 address, won't its preferred address change?
[13:38] <dimitern> babbageclunk: AIUI your suggestion, it's about adding a PreferredPrivateAddress []address on machineDoc containing up to 2 addresses (1 for each type)
[13:38] <babbageclunk> dimitern: Yes, that's what I meant.
[13:39] <dimitern> babbageclunk: well, the preferred addresses will settle long before the machine agent actually starts (or state transitions to started from pending), so no workloads will be running
[13:39] <babbageclunk> dimitern: ok, fair enough.
[13:40] <dimitern> babbageclunk: that specific issue deals with racy DHCPv4 vs DHCPv6 in the lxd provider (either one can come first, but eventually we'd like to use IPv4 as preferred private/public)
[13:40] <dimitern> babbageclunk: however, your suggestions make a lot of sense now that I'm looking at the implementation..
[13:40] <babbageclunk> dimitern: Sure, but I still don't understand why you can't implement the fallback logic on top of the addresses being stored in []address
[13:41] <babbageclunk> dimitern: Ok
[13:41] <babbageclunk> dimitern: :)
[13:41] <dimitern> babbageclunk: so I'd try to use a slice of addresses or perhaps a map[type]address
[13:41] <dimitern> babbageclunk: it might even work better at the end :)
[13:42] <babbageclunk> dimitern: yeah, I could see wanting a map instead - I wasn't sure about that.
[13:43] <babbageclunk> dimitern: The reason I didn't suggest that was that it's probably worse space and time wise with only two entries.
[13:43] <babbageclunk> dimitern: But it also makes the code a bit simpler, so maybe still worth it.
[13:44] <dimitern> babbageclunk: I doubt it makes much difference - one is a nested doc the other is a nested array
[13:44] <dimitern> babbageclunk: yeah
[14:51] <mup> Bug #1584805 opened: Timeout in github.com/juju/juju/apiserver/service on windows <ci> <regression> <test-failure> <timeout> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1584805>
[14:51] <mup> Bug #1584815 opened: SSHSuite.TestSSHCommand fails on windows <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1584815>
[15:03] <hoenir> who broke the upstream?
[15:04] <hoenir> http://paste.ubuntu.com/16633838/
[15:13] <katco> dooferlad: hey, are you feeling better/back yet?
[15:14] <dooferlad> katco: not really
[15:14] <dooferlad> katco: just catching up on email between sleeps
[15:14]  * dooferlad had the flu
[15:14] <katco> dooferlad: ouch, i'm sorry to hear that :( i hope you feel better :(
[15:14]  * dooferlad has a body that still doesn't work
[15:14]  * katco understands
[15:21] <mup> Bug #1576313 changed: windows: uniter tests fail because logs get dumped to stderr <ci> <regression> <test-failure> <windows> <juju-ci-tools:Triaged> <juju-core:Fix Released by bteleaga> <https://launchpad.net/bugs/1576313>
[15:21] <mup> Bug #1584832 opened: payloads are not cleaned up when units are destroyed <juju-core:Triaged> <https://launchpad.net/bugs/1584832>
[15:52] <babbageclunk> dimitern, voidspace: sorry guys, I can't make the networking knowledge share this week - I have to get home to help with the baby.
[15:52] <voidspace> babbageclunk: ok
[15:58] <mup> Bug #1582798 changed: After bootstrapping, juju gui isn't automatically deployed <cpe-sa> <juju-core:Invalid> <https://launchpad.net/bugs/1582798>
[16:00] <dooferlad> dimitern, voidspace, babbageclunk, frobware: is the networking call on?
[16:04] <dimitern> dooferlad, voidspace, frobware: omw, sorry - 2m
[16:46] <voidspace> alexisb: ping
[16:47] <alexisb> voidspace, ping
[16:47] <alexisb> pong
[16:47] <perrito666> ah solo pingpong game
[16:54] <lazyPower> Thats when you know you're dealing with a pro
[16:56] <natefinch> lazyPower: http://i.imgur.com/A6VxL6d.gif
[16:57] <lazyPower> it always comes back ot this for me https://www.youtube.com/watch?v=qHe6vhexm6g
[16:58] <natefinch> lazyPower: holy crap, is that real?
[16:58] <lazyPower> very much so
[16:59] <natefinch> hmm... comments say it's an ad for a nokia phone
[17:00] <lazyPower> dont take this away from me natefinch
[17:00] <lazyPower> ;_;
[17:01] <natefinch> lol sorry
[17:36] <katco> natefinch: hey don't forget to flag that bug as incomplete if you can't repro
[18:04] <mup> Bug # opened: 1584896, 1584897, 1584899, 1584900, 1584901, 1584903, 1584905, 1584906
[18:06]  * fwereade could use a review of http://reviews.vapour.ws/r/4873/ if anyone has some time
[18:09] <perrito666> 4 pages?
[18:17] <rick_h_> katco: ping, did we end up with a download % indicator in the resources output?
[18:17] <katco> rick_h_: no i believe we deferred that. let me 2x check
[18:17] <rick_h_> katco: ty
[18:19] <perrito666> fwereade: I +1 but I want another set of eyes there
[18:24] <katco> rick_h_: yeah, we deferred. see your comment on the resource spec... last comment in the first thread in the doc
[18:24] <katco> rick_h_: (if that's not too confusing)
[18:26] <rick_h_> katco: rgr ty
[19:01] <natefinch> ericsnow: why only alphanumerics and dashes for payload class?  Why only ascii?
[19:01] <ericsnow> natefinch: starting as minimal as possible; we can broaden it later
[19:01] <perrito666> I feel discriminated, I want "El Pailoád"
[19:02] <fwereade> perrito666, thanks, appreciated
[19:03] <perrito666> fwereade: in principle, as you said, these seem like almost mechanical changes
[19:03] <fwereade> perrito666, you have no idea how hard it was to keep it mechanical, but I think I really did
[19:04] <fwereade> perrito666, the one change was to TestDyingModelCleanedUp and I think I called it out explicitly
[19:04] <perrito666> you did
[19:05] <fwereade> perrito666, ok, cool -- and you're happy with the sanity of the high-level changes? that's the really important thing ;)
[19:05] <perrito666> fwereade: I am, I also celebrate that we have one thing less called test*
[19:06] <fwereade> perrito666, cool, thanks :)
[19:16] <cherylj> natefinch: are you still looking into bug 1537585?
[19:16] <mup> Bug #1537585: machine agent failed to register IP addresses, borks agent <2.0-count> <blocker> <landscape> <network> <juju-core:Triaged by natefinch> <juju-core 1.25:Triaged by natefinch> <https://launchpad.net/bugs/1537585>
[19:17] <katco> cherylj: yes he is
[19:17] <cherylj> cool beans
[19:17] <cherylj> thanks, katco
[19:17] <katco> natefinch: you never responded to me... this ^^^ is why i asked you to mark the bug incomplete :)
[19:17] <katco> cherylj: np... fyi he's working with the landscape team because he can't repro
[19:17] <natefinch> katco: crud, sorry, missed that somehow
[19:18] <katco> natefinch: no worries, i knew cherylj would come poking around ;)
[19:18] <cherylj> heh
[19:18] <katco> natefinch: maybe add a comment to that affect too
[19:18]  * cherylj grabs her poking stick
[19:18] <cherylj> yeah, comments good
[19:18]  * katco puts on her nerd mask
[19:19] <natefinch> katco: that's no mask! ;)
[19:19] <katco> lol
[19:50] <natefinch> ericsnow: left a comment on the names.ValidatePayload review... I don't really see why we need to limit people to such a limited set of characters.  If there's a technical reason, then sure, but I would hope there's not, other than maybe some delimiter somewhere.
[19:51] <ericsnow> natefinch: why do we do it for all the other tags?
[19:51]  * perrito666 sees tags a people in the same sentence and smells something weird
[19:51] <natefinch> ericsnow: no idea
[19:52] <natefinch> ericsnow: misplaced paternalistic instinct?
[19:59] <natefinch> ericsnow: eurocentric standards of beauty? :)  Maybe ask fwereade.  Sounds like something someone Decided™ at some point.
[20:00] <perrito666> natefinch: is that limitation for tags?
[20:00] <natefinch> perrito666: yes
[20:01] <perrito666> tags hasve nothing to do with users, users talk in names
[20:02] <natefinch> perrito666: I hate our naming system :/
[20:02] <perrito666> a user will never ever see a tag
[20:02] <perrito666> if you check names for units there is a whole conversion of names to tags removing invalid chars
[20:05] <natefinch> perrito666: double checked the code, this is the
[20:05] <natefinch> perrito666: the  user-facing name, I think
[20:05] <ericsnow> natefinch: correct; it's the "ID"
[20:06] <perrito666> then there is no reason as long as you can encode whatever you have into a tag name
[20:06] <perrito666> (that might be the origin of the limitation btw)
[20:09] <ericsnow> natefinch: currently the only rationale I have for restricting the ID is that making it more restrictive later has a substantially higher cost that making it less restrictive later
[20:09] <natefinch> ericsnow: are the tags for payloads new?  I don't see payloadtag in master
[20:10] <ericsnow> natefinch: no, I believe you added them last year
[20:10] <perrito666> natefinch: I have them inmaster
[20:11] <natefinch> ericsnow: my reading skills just suck, evidently :)
[20:15] <perrito666> bbl, since I need to talk to some downunders if they show up today :)
[20:16] <natefinch> perrito666: anyone at the sprint will not be here today
[20:16] <natefinch> perrito666: even thought today is tomorrow for them
[20:16] <perrito666> you are so underestimating the workoholism of some people
[20:17] <natefinch> hmm, good point, Ian may be one
[20:17] <natefinch> on
[20:17] <natefinch> ericsnow: I don't know... the id-tag-payloadclass thing still confuses the hell out of me.
[20:18] <natefinch> ericsnow: as you said, it's easy to expand later
[20:18] <perrito666> beware of expanding names later
[20:18] <perrito666> you might end up having clashes after sanitization
[20:19] <natefinch> have I mentioned I hate our naming system?  We have a real "let's encode way too much information into an ID" problem
[20:29] <ericsnow> natefinch: how strongly do you feel about that "payloadClass" const?  (I'd rather leave it)
[20:30] <redir> there's only 2 things that are hard in computer science
[20:31] <redir> cache invalidation, naming things, and off by 1 errors
[20:44] <natefinch> ericsnow: meh... seems extraneous... but why not put ^ $ in the constant?
[20:47] <ericsnow> natefinch: habit I guess; often snippets like that are re-usable if you leave the ^ $ off
[20:48] <natefinch> ericsnow: heh, I try to avoid using regexes in the first place ;)  Sure, that's fine.
[20:48] <ericsnow> natefinch: k, thanks :)
[20:50] <thumper> fwereade: sorry I missed our call this morning
[20:59] <perrito666> Thumper hey dunno if you are working today, but if so, could you see my answers In the acl doc to make sure stuff hasn't changed since the creation of that spec?
[20:59] <thumper> perrito666: I am, but I have quite a list ...
[21:02] <perrito666> I can put up a good impression of shreck's cat look :p
[21:17] <fwereade> thumper, haha, sorry so did I
[21:17] <fwereade> thumper, didn't quite expect you back and recovered, but I guess it's tuesday for you
[21:29] <alexisb> thumper, ping
[21:47] <anastasiamac_> is there something wrong with laning bot? I've asked it to merge my stuff 17mins ago and it did not respond :D
[21:47] <anastasiamac_> landing*
[21:57] <davecheney> launchpad is having problems
[21:57] <davecheney> i just had a build fail because the launchpad.com/tomb package was 503
[22:00] <katco> davecheney: we should look to migrate to the new version which i believe is hosted on github
[22:19] <alexisb> thumper, I am on our 1x1 HO when you are ready to join
[23:14] <wallyworld> anastasiamac_: axw: perrito666: otp, running a bit late
[23:16] <anastasiamac_> wallyworld: perfect.. just spilled hot drink so love this xtra time to clean up.. ping when ready
[23:23] <mup> Bug #1584979 opened: better container networking <juju-core:New> <https://launchpad.net/bugs/1584979>
[23:38] <wallyworld> axw: anastasiamac_: in standup now
[23:48] <davecheney> katco: yup, v1 and v2 are verys imilar
[23:48] <davecheney> v2 has one extra method which we can ignore