[00:16] <menn0> perrito666, thumper: what did I do?
[00:17] <menn0> perrito666: natefinch-afk: the other problem with goimports is that it doesn't know about the 3 import groupings we use in Juju (i.e. std lib, external, internal)
[00:17] <menn0> perrito666: natefinch-afk: it sometimes puts new imports in the wrong place
[00:17] <menn0> perrito666: natefinch-afk: but apart from that it's awesome
[00:22] <thumper> davecheney: o/
[00:22] <davecheney> thumper: hey there
[00:22] <davecheney> welcome back
[00:22] <thumper> cheers
[00:22] <davecheney> thumper: thought you came back tomorrow ?
[00:22] <thumper> true for yesterday :)
[00:23] <davecheney> understood
[00:23] <davecheney> i didn't remember when I was supposed to come back
[00:23] <davecheney> and turned up on monday
[00:23] <thumper> haha
[02:58] <natefinch> anyone online know about downloading our tools and how they relate to proxies?  re: https://bugs.launchpad.net/juju-core/+bug/1515289
[02:58] <mup> Bug #1515289: bootstrap node does not use the proxy to fetch tools from streams.c.c <bug-squad> <juju-core:Triaged> <https://launchpad.net/bugs/1515289>
[02:59] <natefinch> thumper, menn0, waigani, davecheney^ ?
[02:59]  * thumper shakes his head
[03:00] <menn0> natefinch: I suspect wallyworld or axw might be able to help
[03:02] <axw> natefinch: all I can say is that it's meant to use the proxy... I don't know why it's not
[03:03] <natefinch> axw: ok, pretty sure I know why it's not: https://github.com/juju/utils/blob/master/http.go#L79
[03:03] <natefinch> axw: this should be setting Proxy to http.ProxyFromEnvironment .... but wanted to make sure we weren't avoiding the proxy on purpose
[03:04] <axw> natefinch: yep, that'll do it :/
[03:04] <axw> natefinch: not that I'm aware of
[03:04] <axw> (avoiding proxy)
[03:07] <natefinch> axw: I notice that the http.Client's default transport (https://golang.org/pkg/net/http/#DefaultTransport) sets a tlshandshaketimeout ... and our version doesn't.  Seems worth setting the same as the default.
[03:07] <natefinch> axw: do you concur?
[03:08] <axw> natefinch: seems reasonable
[03:08] <thumper> axw: sometime when you have some time, I'd like to chat about storage collections w.r.t. model migration
[03:11] <axw> thumper: sure thing
[03:12] <thumper> menn0: it looks like my read only branch did get merged
[03:12] <axw> thumper: I can do whenever really. let me know when suits you
[03:12] <thumper> axw: kk, I may ping you when I need a break
[03:12] <thumper> probably tomorrow
[03:12] <axw> okey dokey
[03:15] <thumper> menn0: ah, not all of it
[03:17] <natefinch> axw: care to review? http://reviews.vapour.ws/r/3529/
[03:18] <axw> natefinch: sure
[03:19] <axw> natefinch: ah, looks like Go 1.2 has no TLSHandshakeTimeout field.
[03:19] <natefinch> whoopee
[03:20] <natefinch> timeouts are for suckers anyway
[03:23] <natefinch> tempted to make two files with build constraints so we get the tls handshake timeout on builds that use go 1.3+ ...
[03:31] <natefinch> axw: updated with go 1.2/1.3+ code.... I don't want to have to remember to go fix this later... now the worst that happens is we have unused go 1.2 code hanging around, which won't hurt anything if we forget about it for forever.
[03:32] <axw> natefinch: WFM. shipit
[03:43] <cherylj> can someone review dave's patch for the gccgo problems?  http://reviews.vapour.ws/r/3527/
[03:58] <davecheney> ping https://github.com/juju/juju/pull/4106
[03:59] <davecheney> this is an urgent bug fix
[03:59] <davecheney> reviews most welcome
[03:59] <axw> looking
[04:00] <cherylj> davecheney: once reviewed, can you also get it into 1.25?
[04:03] <axw> davecheney: LGTM
[04:08] <davecheney> cherylj: yes
[04:13] <cherylj> thumper: this is another patch you'll need to pull into controller-rename
[04:14] <thumper> ugh
[04:14] <thumper> k
[04:35] <cherylj> davecheney: looks like the merge failed because of go fmt issues?
[04:49] <davecheney> cherylj: fixed
[04:50] <cherylj> thanks davecheney !
[04:54] <natefinch> axw: one more review, to hook up the previous change to juju/juju (and bonus fix for metric sender that was already rolling its own transport incorrectly in other ways as well as forgetting the proxy): http://reviews.vapour.ws/r/3530/diff/#
[04:55] <axw> natefinch: LGTM
[04:56] <natefinch> axw: thanks!
[04:56] <natefinch> axw: heh, of course, master is blocked, so I guess it's moot.  Ahh well, it'll get unblocked at some point.
[04:57]  * thumper is done
[04:58] <thumper> I'll check in to see if davecheney's fix lands in master and bring it into controller-rename
[05:17] <davecheney> oops
[05:17] <davecheney> that didnt work
[05:18] <davecheney> i didnt rn the whole test suite s it tajes close to an hour for me
[05:30] <davecheney> oh great
[05:30] <davecheney> this is a go 1.2 vs go 1.5 differnce
[05:30] <davecheney> anyway, fix coming up
[06:02] <davecheney> cherylj: axw thumper-afk https://github.com/juju/juju/pull/4109
[06:02] <davecheney> ^ 1.25 backport
[06:02] <thumper-afk> shipit
[06:03] <axw> davecheney: +1, also, you don't need to get a review for trivial back/forward ports
[06:04] <davecheney> m'kay
[06:09] <davecheney> axw: https://github.com/juju/juju/pull/4109
[06:09] <davecheney> which part of JFDI does the bot not understand
[06:12] <axw> davecheney: huh, dunno what's up with that
[07:03] <mup> Bug #1534011 opened: ~/.juju/credentials.yaml permissions should be 600 <juju-core:New for wallyworld> <https://launchpad.net/bugs/1534011>
[10:03] <dooferlad> dimitern, voidspace, frobware: https://plus.google.com/hangouts/_/canonical.com/juju-core-team
[10:03] <voidspace> ah yes
[10:03] <voidspace> dooferlad: thanks
[10:03] <frobware> dooferlad, running late
[10:09] <anastasiamac> waigani: ping?
[10:47] <dooferlad> frobware: ISTR you mentioned lldb needing some patches to debug go. Did I imagine that?
[10:48] <frobware> dooferlad, only if you want to do it within Emacs.
[10:48] <dooferlad> frobware: cool!
[10:49] <frobware> dooferlad, I have a patch for gud.el but I was looking back through my chrome history and cannot find its provenance.
[10:50] <frobware> dooferlad, https://gist.github.com/ptrv/71b93594589f3a5f27d2
[10:50] <frobware> dooferlad, found it! ^^
[10:52] <dooferlad> frobware: I am sure dimitern will be interested. Myself, I am a sublime text guy.
[10:52] <frobware> dooferlad, I'm sorry. :-D
[10:52] <dimitern> frobware, hmm - is this the debugger code you were talking about?
[10:53] <frobware> dimitern, yep. but you will need to build lldb from trunk.
[11:03] <frobware> dimitern, seen this before? "WARNING interface "bond1" link 339 missing subnet"
[11:03] <voidspace> frobware: dimitern: when is our "demo"?
[11:03] <frobware> voidspace, was done on Monday/Tue, I believe.
[11:04] <frobware> voidspace, dooferlad, dimitern: shall we have a quick call based on jam's meeting yesterday?
[11:04] <frobware> voidspace, we can share news on the demo, et al.
[11:06] <voidspace> frobware: sounds good, gimme 5 to grab coffee first?
[11:06] <voidspace> frobware: dimitern: dooferlad: http://reviews.vapour.ws/r/3534/
[11:06] <dooferlad> frobware: +1
[11:07] <frobware> dimitern, dooferlad, voidspace: I dumped an entry into the calendar but let's use the standup HO
[11:10] <dimitern> frobware, yeah
[11:10] <dooferlad> frobware: the juju-saphire or saphire one. There are two :-)
[11:11] <dimitern> frobware, that's coming from the new NICs handling code
[11:11] <dimitern> voidspace, looking in a bit
[11:13] <frobware> dooferlad, juju-sapphire
[11:18] <frobware> dimitern, voidspace: ready to join?
[11:18] <voidspace> frobware: yes
[11:18] <voidspace> omw
[11:22] <mup> Bug #1534103 opened: "unknown operation kind run-action" (1.26alpha3) <juju-core:New> <https://launchpad.net/bugs/1534103>
[11:31] <mup> Bug #1534103 changed: "unknown operation kind run-action" (1.26alpha3) <juju-core:New> <https://launchpad.net/bugs/1534103>
[11:34] <mup> Bug #1534103 opened: "unknown operation kind run-action" (1.26alpha3) <juju-core:New> <https://launchpad.net/bugs/1534103>
[12:12] <perrito666> voidspace: just as an example, there is no such thing as house-wide climatization for residences and afaik for business is way more rudimentary than yours
[12:14] <frobware> dooferlad, https://bugs.launchpad.net/juju-core/+bug/1532167
[12:14] <mup_> Bug #1532167: maas bridge script handles VLAN NICs incorrectly <addressability> <maas-provider> <network> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1532167>
[12:25] <mgz> dooferlad: can you test lp:~gz/juju-ci-tools/common_container_networking
[12:25] <mgz> dooferlad: I tried not to break your existing expectations, but it'sa pretty big change
[13:11] <voidspace> perrito666: "house-wide climatization", you mean thermostat or air conditioning?
[13:11] <voidspace> perrito666: we don't do air conditioning here in the UK either...
[13:33] <perrito666> voidspace: climatization as climatization in any sense
[13:33] <perrito666> usually we have individual heaters for each room (those with a gas powered flame)
[13:33] <perrito666> and same with ACs
[13:33] <perrito666> I got a house wide in-floor heating but its a weird thing
[13:48] <frobware> dimitern, do you have a MAAS setup with VLANs, bonds & aliases that you could try change on: https://github.com/frobware/juju/tree/maas-space-bridge-party
[14:02] <dimitern> frobware, looking
[14:02] <dimitern> frobware, I don't have bonds but I'll add one now
[14:03] <frobware> dimitern, I'm looking for some confirmation that what I'm doing is not too simplistic.
[14:03] <cherylj> oh thank god SOMETHING got blessed
[14:03] <frobware> dimitern, "WARNING interface "bond1" link 339 missing subnet" - 339 is some internal id?
[14:04] <dimitern> yeah it's the link id
[14:05] <dimitern> the thing represented in the "links" of an item inside the interface_set map
[14:08] <voidspace> perrito666: ah ok, maybe you are safe then...
[14:13] <dooferlad> mgz: it seems fine, but I haven't run it. Thanks for cleaning it up.
[14:18] <mgz> dooferlad: not sure it's quite right atm, haven't got it to actually reuse an env yet
[14:18] <mgz> the other bits seem fine
[14:20] <mgz> (well, kvm doesn't work on aws, but that's expected)
[14:33] <frobware> dimitern, can't decide whether my change or moving to 1.9.0 has affected the way bond0 works...
[14:33] <frobware> dimitern, but I do have trouble with bond0 now...
[14:38] <dimitern> frobware, I'm testing maas-spaces + your changes on the hw maas
[14:39] <frobware> dimitern, I dropped my bond0 and all is well. Hmpf.
[14:49] <dimitern> frobware, hmm - perhaps it depends on the specific bond params
[14:50] <dimitern> frobware, I'm deploying a node now with the 2 NICs in a bond0, and on top of it 6 vlans with various modes - unconfigured, auto, static, dhcp
[14:50] <frobware> dimitern, do you still see the 120s wait if you have an alias?
[14:50] <dimitern> once it comes up I'll try the script on the rendered e/n/o
[14:51] <dimitern> frobware, I haven't seen an improvement there, but also haven't tried with 1.9.0 lately
[14:51] <frobware> dimitern, looks like it is still present
[14:52] <frobware> dimitern, if it works, and you have the bandwidth, can juju deploy to that node and also add a container --- and verify that container can do something with the internet
[14:53] <frobware> dimitern, but not apt-get update.  Too much caching going on there...
[14:54] <dimitern> sure, I'm first trying the "pure" deployment - no juju involved
[15:03] <katco> ericsnow: stand up
[15:09] <dooferlad> frobware: so, what was the reason for not using add-juju-bridge.py from maas-spaces? It looks like we need a bridge per VLAN anyway.
[15:10] <dooferlad> frobware: it it simply that the rest of our code doesn't handle 1 bridge per NIC?
[15:10] <frobware> dooferlad, untested
[15:10] <dooferlad> frobware: so, it may work, but we don't know.
[15:11] <frobware> dooferlad, seems a fair assessment
[15:11] <dooferlad> dimitern: ^^
[15:11] <dooferlad> dimitern: opinions?
[15:11] <frobware> dooferlad, the trouble I have is I think, in general, the script and how we get it to the node is way better on maas-spaces.
[15:25] <mup> Bug #1534201 opened: TestHelpAddImage fails <ci> <regression> <test-failure> <windows> <juju-core:New> <juju-core controller-rename:Triaged> <https://launchpad.net/bugs/1534201>
[15:31] <dimitern> frobware, so I couldn't even get to the node without juju in play
[15:31] <frobware> dimitern, oh :(
[15:31] <dimitern> dooferlad, so the plan is to use the new shiny and better script from maas-spaces on master
[15:31] <frobware> dimitern, it is?
[15:31] <dimitern> dooferlad, but not until we're sure it's working properly
[15:32] <frobware> dimitern, aha.
[15:32] <natefinch> katco: btw, looks like lxc-clone and lxc-clone-aufs would not do what you'd think in LXD.  They're for when you juju deploy to a lxc container on a machine, not for when the lxd provider creates new machines.
[15:32] <dooferlad> frobware, dimitern: that bug has been re-targeted to 2.0-alpha2
[15:32] <frobware> dimitern, dooferlad: so for 1.25 there may be a small fix that we can do there.
[15:32] <dimitern> frobware, I suspect I went with a bit too wild config of the bond, trying a simpler approach now
[15:32] <dooferlad> ignore me, that is just one target
[15:32] <frobware> dimitern, do you time for a quick HO?
[15:33] <frobware> dimitern, all related to spaces/bond0 and state of tip on maas-spaces.
[15:33] <katco> natefinch: ah interesting
[15:33] <dooferlad> dimitern, frobware: but doesn't the siny new script do it right?
[15:33] <frobware> dooferlad, I was concerned at the magnitude of the change.
[15:33] <dooferlad> or don't we need a bridge per vlan?
[15:34] <dimitern> we do
[15:34] <dimitern> if we need containers on those vlans
[15:35] <dimitern> frobware, well, considering my devices tests have stalled yet again due to gomaasapi limitations, sure - let's HO
[15:35] <frobware> great
[15:36] <frobware> I'm a bit broke too
[16:31] <cherylj> frobware: did you see my question in bug 1532354?
[16:31] <mup> Bug #1532354: Juju 1.26-Alpha4 reports incorrect public-address with MaaS 1.9 <juju-core:New> <https://launchpad.net/bugs/1532354>
[16:32] <mup> Bug #1534011 changed: ~/.juju/credentials.yaml permissions should be 600 <juju-core:Invalid by wallyworld> <https://launchpad.net/bugs/1534011>
[16:32] <mup> Bug #1534214 opened: Juju KVM container doesn't respect constraints <juju-core:Triaged> <https://launchpad.net/bugs/1534214>
[16:36] <ericsnow> katco: you want to keep pairing?
[16:36] <katco> ericsnow: definitely... give me a few mins
[16:36] <ericsnow> katco: np, just ping me
[16:36] <katco> ericsnow: will do
[16:37] <ericsnow> katco: I'll be in moonstone
[17:02] <mup> Bug #1488166 changed: Service with just one unit left which doesn't think it's the leader <landscape> <leadership> <juju-core:Triaged by fwereade> <https://launchpad.net/bugs/1488166>
[17:08] <frobware> cherylj, have added a comment to the bug.
[17:08] <cherylj> thanks, frobware!
[17:16] <cherylj> frobware: I'm updating the release notes for 2.0 and wanted to put in a comment about the default gateway.  Does this work?  "Users on MAAS 1.8 should set the default gateway for network used by juju to avoid problems with container networking".
[17:16] <cherylj> for THE network used by juju...
[17:17] <cherylj> I'm not sure what terminology we need to use for that
[17:29] <frobware> cherylj, I think I would also add a comment about where you can see/validate this in the MAAS UI. "You can verify whether a default gateway has been set on an interface by looking at the network details in the "Networks" tab" - or words to that affect.
[17:31] <cherylj> frobware: good suggestion, thanks!
[17:32] <mup> Bug #1532354 changed: Juju 1.26-Alpha4 reports incorrect public-address with MaaS 1.9 <juju-core:Invalid> <https://launchpad.net/bugs/1532354>
[17:32] <mup> Bug #1534238 opened: juju debug-log fails with 1.26alpha3 and lxd <juju-core:New> <https://launchpad.net/bugs/1534238>
[17:37] <cherylj> sinzui: you mentioned I could get a windows VM to test the unit test changes.  Could I get one to test the changes for the controller-rename branch?
[17:37] <cherylj> given my recent history with windows tests...
[17:37] <sinzui> cherylj: I'll pass you the  connection into in a moment
[17:37] <cherylj> awesome :)
[18:42] <perrito666> hey anyone is familiar with debuglogfilesuite?
[18:47] <natefinch> ...abstractfactorybean?
[18:50] <cherylj> bogdanteleaga: ping?
[18:50] <perrito666> well I am not sure what exactly it is testing or in any case why it breaks when log to mongo breaks :p
[19:06] <cherylj> has anyone done unit tests in a windows system?
[19:07] <natefinch> cherylj: not recently, but in theory, yes
[19:07] <cherylj> natefinch: I keep getting this error:  provider\azure\environ.go:18:2: no buildable Go source files in C:\Users\Administrator\ci\gogo\src\github.com\Azure\azure-sdk-for-go\arm\resources
[19:08] <cherylj> and I did a go get for the sdk
[19:17] <bogdanteleaga> cherylj: hmm, that does look weird
[19:18] <bogdanteleaga> I didn't run unit tests for a while, but I do build windows binaries quite often and I never got that
[19:18] <bogdanteleaga> try deleting $GOPATH/pkg ?
[19:18] <cherylj> bogdanteleaga: good idea, I'll try that
[19:19] <cherylj> nope, same issue :(
[19:28] <bogdanteleaga> do you have files in there?
[19:35] <natefinch> cherylj: that's because there's no buildable go source files in https://github.com/Azure/azure-sdk-for-go/tree/master/arm/resources
[19:35]  * natefinch is very helpful ;)
[19:35] <cherylj> thanks, captian obvious
[19:35] <cherylj> heh
[19:35] <perrito666> cherylj: check if the files arent linux only
[19:36] <natefinch> perrito666: there's no files at all in that folder
[19:36] <natefinch> click the link I posted
[19:36] <perrito666> meh why would it try to build that particular thing?
[19:36] <natefinch> cherylj: did you run godeps?
[19:37] <cherylj> natefinch: let me set up godeps on this vm
[19:37] <hatch> is it possible for the detla sent to the GUI via the api to differ from the juju status output? The delta is returning 'pending' but status shows 'error'
[19:37] <perrito666> yes
[19:37] <natefinch> cherylj: that's probably the problem. They probably removed what was there in HEAD of master
[19:37] <perrito666> hatch: that yes was for you
[19:38] <hatch> perrito666: so is this a bug in juju or...what are we looking at? I've never seen this before
[19:39] <cherylj> hatch: sorry if I missed it in the scroll back...  what is it that's showing as "pending" / "error"?
[19:40] <hatch> cherylj: so here is the delta https://gist.github.com/kadams54/1c64a146b416a0639802#file-gistfile2-txt-L307 and here is the status https://gist.github.com/kadams54/1c64a146b416a0639802#file-juju-status-txt
[19:41] <hatch> so the GUI is displaying the unit as in Pending as per the delta, but it's actually in error...
[19:41] <perrito666> hatch: in that case I would believe status
[19:41] <perrito666> and yes, that IS a bug
[19:42] <hatch> I've never seen this before, another (kadams54) just ran into it in his env
[19:42] <hatch> this of course breaks the GUI because it can't properly interact with that unit
[19:43] <hatch> of course I'll gladly file a bug report...what information do you need from the environment for a report for this to be helpful?
[19:43] <perrito666> hatch: I presume that it hapens in certain cases only
[19:44] <hatch> yeah - I've never seen this before, didn't think it was even possible :)
[19:44] <perrito666> the two gists should be enough, plus version of all involved juju pieces
[19:44] <perrito666> well iirc the code doing the delta and the status is slightly different
[19:44] <cherylj> I bet there's some aggregation of status reported in 'juju status'
[19:44] <perrito666> yup, there is some massaging of the data before printing the status
[19:45] <hatch> alright no problem - so there is probably some work we can do on the GUI side to make the reporting a little more resilient in this case, but I'll file a bug on juju though in the mean time
[19:45] <hatch> thanks!
[19:46] <perrito666> glad to not be helpful
[19:46] <cherylj> heh
[19:46] <hatch> lol! you were more helpful than you think :)
[19:47] <perrito666> dont lie to me, you expected a "click here and all be fixed" kind of answer :p
[19:47] <hatch> haha nah, I was looking for "this isn't possible, look elsewhere for the issue"
[19:47] <hatch> but since it IS possible
[19:48] <hatch> I can wash my hands of it lol
[19:48] <hatch> (of course besides making the gui more resilient)
[19:48] <cherylj> Can I get a review?  http://reviews.vapour.ws/r/3539/
[19:48] <cherylj> I reverted a PR, then added back the feature flag definition
[19:56] <natefinch> cherylj: ship it
[20:00] <cherylj> natefinch: actually, I might have a real fix, now that I can reproduce the failure on this windows machine
[20:02] <natefinch> cherylj: cool
[20:11] <perrito666> whyyy, why dead code paths whyyy
[20:11] <mup> Bug #1534289 opened: tag aws security groups to prevent accidental deletion <juju-core:New> <https://launchpad.net/bugs/1534289>
[20:12] <perrito666> yeah, thanks mup, you always find a way to cheer me up
[20:14] <mup> Bug #1534289 changed: tag aws security groups to prevent accidental deletion <juju-core:New> <https://launchpad.net/bugs/1534289>
[20:17] <mup> Bug #1534289 opened: tag aws security groups to prevent accidental deletion <juju-core:New> <https://launchpad.net/bugs/1534289>
[20:20] <katco> ericsnow: your patch lgtm. ready to pair up again?
[20:23] <ericsnow> katco: sure
[20:24] <katco> ericsnow: in moonstone
[20:34] <cherylj> hey bogdanteleaga I'm now running into an issue that you had resolved elsewhere:  2016-01-14 20:30:41 WARNING utils.featureflag flags_windows.go:34 Failed to open juju registry key HKLM:\\SOFTWARE\\juju-core; feature flags not enabled
[20:34] <cherylj> bogdanteleaga: it's not entirely clear to me what I need to do to fix it
[20:36] <cherylj> bogdanteleaga: oh, maybe I need to use setUpFeatureFlags?
[20:44] <mup> Bug #1534296 opened: api delta and juju status differ <juju-core:New> <https://launchpad.net/bugs/1534296>
[20:48] <cherylj> thumper: I think this PR of yours is causing problems for me now:  https://github.com/juju/juju/pull/3271
[20:49]  * thumper looks
[20:50] <thumper> cherylj: tests should never poke the registry
[20:50] <thumper> there is no reason that tests should do that
[20:50] <thumper> what exactly is the problem?
[20:51] <cherylj> thumper: http://reports.vapour.ws/releases/3508/job/run-unit-tests-win2012-amd64/attempt/1800#highlight
[20:51] <cherylj> caused by Ian's change:  https://github.com/juju/juju/pull/4093
[20:53] <thumper> cherylj: yeah, that is just bad...
[20:53] <thumper> the testing of the flag setting should be independent of the main
[20:54] <thumper> however everything is just shoved together in a single file
[20:55] <thumper> cherylj: my suggestion at this stage is to file a bug, and skip the test on windows as long as the windows feature flag setup is done right
[20:55] <thumper> the longer job is testing it properly
[20:56] <thumper> we don't do this type of testing in other places
[20:56] <thumper> because it impacts an external resource - the windows registry
[20:56] <cherylj> thumper: what I've tried to do is separate out the init() into a main_nix.go and main_windows.go  and set the flags appropriately there
[20:56] <cherylj> each has a main() that just calls Main()
[20:56] <thumper> changing the windows registry during tests can cause independent juju commands to fail
[20:56] <cherylj> is that correct?
[20:57] <thumper> that'll work
[20:57] <cherylj> ok, thanks
[21:02] <bogdanteleaga> iirc, the tests created some random key in the registry that is not used by juju
[21:03] <bogdanteleaga> oh, I was thinking about different tests
[21:05] <cherylj> bogdanteleaga: how do I set feature flags on windows (and can I do it from cygwin cli?)
[21:07] <bogdanteleaga> are you trying to do it for running juju or for tests?
[21:07] <cherylj> for running a command
[21:07] <bogdanteleaga> I think tests will just recognize environment variables
[21:07] <cherylj> for manually running a juju command
[21:07] <bogdanteleaga> that's $env:variable = something
[21:07] <cherylj> thanks!
[21:07] <bogdanteleaga> might be without space
[21:08] <bogdanteleaga> in powershell at least
[21:08] <bogdanteleaga> I think cygwin just does it the bash way
[21:08] <cherylj> ah, then I'll give that a try
[21:08] <bogdanteleaga> if not you might have to create the key in registry
[21:12] <bogdanteleaga> that is, have JUJU_DEV_FEATURE_FLAGS in HKLM:\SOFTWARE\juju-core with csv of flags
[21:14] <cherylj> okay, I give up for now.  I'm still getting that error when I run the tests, even when I skip the ones that set the feature flag
[21:15] <cherylj> I'm reverting Ian's patch and he can deal with it later, or I'll do it later
[21:15] <cherylj> mgz: has there been another os deployer run with the ceilometer failure we need to look at?
[21:22] <cherylj> sinzui: the revert is merging now.  I confirmed the tests pass on windows again
[21:25] <sinzui> cherylj: okay. I see perrito666's branch will finish soon
[21:36] <bogdanteleaga> cherylj: I looked a bit at it now
[21:36] <bogdanteleaga> it should have nothing to do with registry
[21:36] <bogdanteleaga> only jujud loads variables from the registry
[21:37] <bogdanteleaga> tbh, I'm not sure what the problem is, the only strange thing is that juju home is added with key=value to the env and the feature flags are only added with value
[21:37] <bogdanteleaga> (inside badrun in the file with errors)
[21:47] <jw4> perrito666: Thanks, loving my new beverage: https://www.dropbox.com/s/l1edd4huooft8lu/2016-01-14%2011.55.55.jpg?dl=0
[21:51] <thumper> davecheney: ping
[22:08] <davecheney> thumper: ack
[22:15] <thumper> davecheney: I have worked around my problem, but still don't entirely understand it
[22:15] <thumper> I was trying to write a custom YAML marshaller for time.Time
[22:15] <davecheney> mmm
[22:15] <thumper> that was smarter around IsZero
[22:15] <thumper> but the unmarshal function never got called and yaml just errored out
[22:16] <thumper> not sure why
[22:16] <thumper> but now I'm just using time.Time
[22:16] <davecheney> T vs *T
[22:16] <davecheney> ?
[22:16] <thumper> I copied from version.Number
[22:16] <davecheney> why not teah yamk to handke times directly
[22:16] <thumper> because gopkg yaml
[22:17] <thumper> also was using omitempty
[22:17] <davecheney> yeah, borlerline impossible to land that change
[22:17] <thumper> but that didn't work with time.Time either
[22:17] <thumper> so now using *time.Time in the yaml struct
[22:17] <thumper> and converting at the boundaries
[22:17] <thumper> using time.Time.IsZero()
[22:17] <davecheney> oh well
[22:18] <thumper> yeah, just futzing around
[22:22] <perrito666> Jw4 glad you like, and that you could get one
[22:23] <jw4> :)
[22:30] <mup> Bug #1531932 changed: Unit agents unable to connect with MAAS 1.8 due to lack of default gateway in MAAS <juju-core:Won't Fix by dooferlad> <juju-core 1.25:Incomplete> <https://launchpad.net/bugs/1531932>
[22:30] <mup> Bug #1534353 opened: Wrong command displayed when trying to destroy a controller with destroy-environment <juju-core:Triaged> <https://launchpad.net/bugs/1534353>
[22:30] <cherylj> hey natefinch, the idea with bug 1511659 / http://reviews.vapour.ws/r/3536/ was to see if you could take it over - try and recreate / verify the fix and get it merged
[22:30] <mup> Bug #1511659: Destroyed leader, new leader not elected. <bug-squad> <leadership> <sts> <juju-core:Triaged by fwereade> <juju-core 1.25:Triaged by fwereade> <https://launchpad.net/bugs/1511659>
[22:30] <cherylj> natefinch: do you have the bandwidth to do that?
[22:42] <mup> Bug #1534353 changed: Wrong command displayed when trying to destroy a controller with destroy-environment <juju-core:Triaged> <https://launchpad.net/bugs/1534353>
[22:42] <mup> Bug #1531932 opened: Unit agents unable to connect with MAAS 1.8 due to lack of default gateway in MAAS <juju-core:Won't Fix by dooferlad> <juju-core 1.25:Incomplete> <https://launchpad.net/bugs/1531932>
[22:43] <katco> cherylj: yes he does; that was what i communicated to him
[22:44]  * thumper crawls back under his rock with the laptop
[22:44] <cherylj> thanks, katco!
[22:45] <mup> Bug #1531932 changed: Unit agents unable to connect with MAAS 1.8 due to lack of default gateway in MAAS <juju-core:Won't Fix by dooferlad> <juju-core 1.25:Incomplete> <https://launchpad.net/bugs/1531932>
[22:45] <mup> Bug #1534353 opened: Wrong command displayed when trying to destroy a controller with destroy-environment <juju-core:Triaged> <https://launchpad.net/bugs/1534353>
[23:14] <cherylj> sinzui: It looks like it failed the openstack check because juju deployer couldn't run status
[23:14] <cherylj> 2016-01-14 16:27:12 Error getting status, is it bootstrapped?
[23:14] <cherylj> 2016-01-14 16:27:12 Command (juju status --format=yaml -e maas-1_8-OS-deployer) Output:
[23:14] <cherylj>  <blank lines>
[23:15] <perrito666> axw: anastasiamac not making it to the standup, will mail later
[23:15] <cherylj> I wonder if it is trying to use a different juju than what's been built for the test?
[23:15] <axw> perrito666: okey dokey
[23:15] <anastasiamac> perrito666: ok \o/
[23:17] <sinzui> cherylj: ohh...could the script be assuming a jenv? I expect a call to Juju to work because JUJU_HOME is exported to a unique path
[23:17] <cherylj> sinzui: that's exactly what I was thinking
[23:18] <cherylj> sinzui: juju-ci-openstack-check.sh:export OS_AUTH_URL=${OS_AUTH_PROTOCOL:-http}://`juju-deployer -e $1 -f keystone`:5000/v2.0
[23:18] <cherylj> and we can see by the output that the juju-deployer call fails
[23:19] <sinzui> cherylj: The current job we are watching has its JUJU_HOME set to ~/cloud-city/jes-homes/maas-1_9-OS-deployer
[23:20] <cherylj> sinzui: I bet it's using an older juju and looking for a jenv
[23:20] <cherylj> in that juju home
[23:20] <cherylj> sinzui: I gotta run to dinner with the family.  bbl
[23:21] <sinzui> cherylj: The path is also exported...well should be if the script is run using the jujupy lib
[23:23] <sinzui> cherylj: good news the health check bypasses to env var we setup. Once I start dinner, I will change the script toensure JUJU_HOME and PATH are honoured.
[23:35] <katco> ericsnow: oauth kicked me out, brt