[00:25] <wallyworld_> thumper: pingy
[00:31] <thumper> wallyworld_: hey
[00:31] <wallyworld_> thumper: i'd like to be able to land the joyent provider code as i think william wants it in my tomorrow
[00:31] <wallyworld_> i have it working
[00:32] <wallyworld_> http://165.225.148.189/wp-admin/install.php
[00:32] <wallyworld_> but it's a huuuuuuge branch
[00:32] <wallyworld_> since it has been developed all in one go
[00:32]  * thumper nods
[00:32] <wallyworld_> and i've taken what was there and modified it so it works
[00:32] <thumper> how much outside provider/joyent is there?
[00:32] <wallyworld_> none
[00:32] <thumper> ok, lets do it
[00:32] <wallyworld_> i have another branch i'm doing
[00:33] <wallyworld_> which does outside work
[00:33] <wallyworld_> fixes some other stuff
[00:33] <thumper> ok
[00:33] <thumper> can we land it but not enable for the first cut?
[00:33] <thumper> that way we can still release 1.18 off trunk
[00:33] <thumper> but the code is a least there
[00:33] <wallyworld_> thumper: yes, i want to land https://codereview.appspot.com/82050043/
[00:33] <wallyworld_> and i will have the other work done today
[00:33]  * thumper looks
[00:33] <wallyworld_> which will allow the provider to work as per the link i pasted above
[00:34] <thumper> do you want a real review
[00:34] <thumper> or a cursory look?
[00:34] <wallyworld_> the latter :-)
[00:34] <thumper> heh
[00:34] <wallyworld_> i know there's stuff to do
[00:34] <thumper> ok
[00:34] <wallyworld_> but we can iterate
[00:34] <thumper> agreed
[00:34] <wallyworld_> i have clean uop a lot
[00:34] <wallyworld_> but i ran out of steam
[00:35]  * thumper looks
[00:35] <wallyworld_> a lot of the work is not mine
[00:36] <wallyworld_> i branched off daniel's work and did stuff to get it going
[00:36] <davecheney> wallyworld_: thumper i say if it commits cleanly an the bot gives it the green light
[00:36] <davecheney> commit it
[00:37] <wallyworld_> davecheney: and it works :-) http://165.225.148.189/wp-admin/install.php
[00:37] <davecheney> wallyworld_: LGTM
[00:37] <davecheney> lets get it landed
[00:37] <wallyworld_> davecheney: also, i added a comment to the RT cause outgoing ssh did not work for me
[00:37] <davecheney> wallyworld_: balls
[00:37] <wallyworld_> i tried from rockne-03 with no luck
[00:37] <davecheney> wallyworld_: we might have to put the breaks on that
[00:37] <davecheney> arosales: said I should work on local and manual providers
[00:38] <davecheney> and I guess maas
[00:38] <davecheney> because those are what we would use to demo ppc
[00:38] <wallyworld_> ok, i think ppc will work fine, just want to verify
[00:38] <davecheney> wallyworld_: same
[00:38] <davecheney> i want to verify as well
[00:38] <davecheney> but i've been told a few times now not to proritise it
[00:38] <wallyworld_> so i'm not doing any dev work as such, just testing
[00:38] <davecheney> so I sohuld be smart and start listening
[00:40] <wallyworld_> thats what my wife says
[00:40] <wallyworld_> but less politely
[00:49] <davecheney> wallyworld_: your wife sounds smart
[00:50] <wallyworld_> she is, but not so smart she didn't marry me
[00:50] <thumper> davecheney: are there bugs filed for the failing power tests?
[00:50] <davecheney> thumper: i am raising them as I work on them
[00:50] <thumper> ok, how many failures do we have?
[00:50] <davecheney> thumper: i don't have an exact cound
[00:51] <davecheney> less than we had last week
[00:51] <davecheney> please hold
[00:51] <davecheney> doing a test run at the moment
[01:19] <axw> wallyworld_: in case you haven't seen this already: #1299802
[01:20] <_mup_> Bug #1299802: upgrade-juju 1.16.6 -> 1.18 (tip) fails <juju-core:New> <https://launchpad.net/bugs/1299802>
[01:20] <wallyworld_> oh :-( hadn't seen that
[01:20] <axw> looks like an upgrade steps thing, maybe
[01:21] <wallyworld_> could be, i'd have to trawl through the log
[01:21] <wallyworld_> i think if something fails, the desired version remains as it was
[01:22] <axw> ah ok
[01:30] <davechen1y> _thumper_: http://paste.ubuntu.com/7182728/
[01:30] <davechen1y> current state of play
[01:31] <davechen1y> _thumper_: https://bugs.launchpad.net/juju-core/+bug/1299958
[01:31] <_mup_> Bug #1299958: worker/peergrouper: test failure <ppc64el> <juju-core:Triaged by dave-cheney> <https://launchpad.net/bugs/1299958>
[01:31] <davechen1y> working on this one now
[01:35] <davechen1y> _thumper_: the big difference between gccgo/amd64 failures and gccgo/ppc64 failures is there are no test fixtures for ppc64
[01:35] <davechen1y> _thumper_: I will raise an issue for this by COB
[01:37]  * _thumper_ nods
[01:49] <axw> wallyworld_: sorry, what was that branch again?
[01:49] <wallyworld_> axw: lp:~wallyworld/uju-core/remove-provider-addr-methods
[01:49] <mwhudson> davechen1y: hello, would it be more useful to run juju tests on arm64 from the latest release or bzr tip?
[01:50] <axw> ta
[01:54] <mwhudson> davechen1y: also, is the fix for that test linking bug in trusty yet?
[01:55] <mwhudson> hm seems like it should be
[01:56] <mwhudson> why am i still seeing linker errors then :(
[01:58] <thumper> davechen1y: just proposing a fix for the bzr test failure
[02:01] <thumper> davechen1y: https://codereview.appspot.com/82250045
[02:06] <davechen1y> thumper: /me looks
[02:06] <davechen1y> mwhudson: make sure you have gccgo-go 1.2.1
[02:06] <davechen1y> then you're good
[02:07] <davechen1y> thumper: +1
[02:07] <thumper> axw: do you think your logging dir config changes would have fixed this: https://bugs.launchpad.net/juju-core/+bug/1298663 ??
[02:07] <_mup_> Bug #1298663: juju debug-log broken in 1.17.6 <debug-log> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1298663>
[02:07]  * axw looks
[02:08] <axw> thumper: yeah I think so
[02:09] <axw> thumper: I will find the bug and set as dupe
[02:09] <mwhudson> $ dpkg-query -W gccgo-go
[02:09] <mwhudson> gccgo-go        1.2.1-0ubuntu1
[02:10] <davechen1y> mwhudson: yup
[02:10] <davechen1y> there is one package that still fails to link
[02:10] <davechen1y> it's on my list
[02:10] <mwhudson> ok
[02:10] <mwhudson> davechen1y: is your list online somewhere?
[02:12] <davechen1y> mwhudson: i email it daily to a shittone of people
[02:12] <mwhudson> davechen1y: feel free to add me to the list :-)
[02:12] <davechen1y> mwhudson: https://docs.google.com/a/canonical.com/document/d/1aKWR3kDzS5Og6PXxe9m98Xea75ScVrGWIZ95rSQIdTM/edit
[02:12] <davechen1y> all bugs are tracked in lp
[02:12] <davechen1y> there is no separate bug list
[02:12] <davechen1y> the list of bugs tracked in lp is not exhaustive
[02:12] <mwhudson> thanks
[02:13] <davechen1y> thumper: https://bugs.launchpad.net/juju-core/+bug/1299969
[02:13] <_mup_> Bug #1299969: launchpad.net/juju-core/provider/manual: ssh tests are not properly isolated <ppc64el> <juju-core:Triaged> <https://launchpad.net/bugs/1299969>
[02:13] <davechen1y> looks similar to the bzr bug
[02:14] <axw> wallyworld_: we should be able to remove public/private address from the unit doc too, right?
[02:14] <axw> wallyworld_: if we always wait for the machine to have addresses first
[02:14] <wallyworld_> axw: yeah, when we can support schema changes
[02:14] <axw> wallyworld_: true. we can just ignore it for now I suppose
[02:14] <axw> though it is already, if the machine has addresses
[02:14] <wallyworld_> yeah, i was going to remove the api first
[02:15] <axw> sounds good
[02:15] <wallyworld_> the thing i'm up against now - can subordinate units have addresses?
[02:15] <wallyworld_> i'd like to say no
[02:15] <wallyworld_> will make the refactoring simpler, otherwise i'll need to add a bunch of extra code
[02:16] <axw> wallyworld_: from the docs, "Subordinate units inherit the public/private address of the principal service."
[02:16] <axw> how that's implemented I don't know
[02:17] <wallyworld_> it uses the provider addresses
[02:17] <wallyworld_> the ones i want to delete
[02:17] <wallyworld_> which is kinda sucky
[02:17] <axw> I mean how the subordinate inherits from the principal...
[02:17] <axw> same machine, so it'll just work I guess
[02:18] <axw> wallyworld_: where's that code?
[02:18] <wallyworld_> yeah, but the current assumption is the provider.PublicAddress() works
[02:18] <wallyworld_> state/unit.go
[02:19] <axw> wallyworld_: right, but there's nothign special about subordinates there... is there somewhere else?
[02:19] <axw> wallyworld_: what extra code do you need to land?
[02:19] <wallyworld_> sec
[02:22] <wallyworld_> axw: i think it's in worker/unit/modes.go which calls unit.SetPrivateAddress() which it gets from the provider
[02:22] <axw> wallyworld_: we may be able to get away without waiting for addresses. you may need to check with fwereade or someone else
[02:22] <axw> wallyworld_: yeah but what's special about subordinates there?
[02:23] <axw> wallyworld_: they still live on a machine, and they'll still get their addresses from the machine
[02:23] <wallyworld_> axw: nothing, but that's how subords get the unit doc address set
[02:23] <axw> that's only used if its machine doesn't have addresses
[02:23] <wallyworld_> axw: the unitDoc for sub ords has machne id = ""
[02:23] <axw> oh
[02:23] <axw> right
[02:23] <wallyworld_> so the machineAddresses() bt fails
[02:23] <axw> so, we need to use its principal's machine rather
[02:24] <wallyworld_> so i need to look up the principal unit
[02:24] <wallyworld_> but the state apis return no error :-(
[02:24] <axw> no error for what?
[02:24] <wallyworld_> so i have to do it at the api level or chaneg the method
[02:24] <wallyworld_> PrivateAddress()
[02:25] <wallyworld_> so if i want to look up princiap unit, get assigned machine etc, i need to cater for errors
[02:25] <axw> nor does addressesOfMachine if Machine() errors at the moment
[02:25] <axw> I don't think this is any worse
[02:25] <wallyworld_> true, still sucks though :-(
[02:25] <wallyworld_> but yeah
[02:26] <arosales> davechen1y: thanks for the for the work on manual
[02:26] <wallyworld_> arosales: http://165.225.148.189/wp-admin/install.php
[02:26] <arosales> wallyworld_: thanks for landing the joyent provider
[02:26] <mwhudson> 105 of 141 launchpad.net/juju-core/... package tests fail :/
[02:27] <arosales> wallyworld_: is that off joyent?
[02:27] <wallyworld_> yep :-D
[02:27] <arosales> wallyworld_: woot \o/
[02:27] <arosales> well done
[02:27] <arosales> wallyworld_: any work arounds in place or can I have folks start testing?
[02:27] <wallyworld_> got a few follow up branches to land to fix juju core stuff
[02:27] <arosales> ah ok
[02:27] <arosales> wallyworld_: good stuff
[02:28] <wallyworld_> arosales: i'll land the stuff by today or tomorrow
[02:28] <arosales> wallyworld_: give me a mail when trunk is ready for general testing
[02:28] <arosales> wallyworld_: thanks
[02:28] <wallyworld_> sure, welcome
[02:28]  * arosales returns to dinner
[02:31] <axw> wallyworld_: in addressesOfMachine, you can just use AssignedMachineId instead of u.doc.MachineId
[02:31] <axw> that'll do the right thing for subordinates
[02:32] <wallyworld_> yeah
[02:32] <axw> wallyworld_: deployed a charm to azure, it got addresses
[02:32] <axw> wallyworld_: anything in particular you want me to test?
[02:32] <wallyworld_> axw: nah, just a smoke test, that's great thanks
[02:32] <wallyworld_> lots of code to delete \o/
[02:33] <mwhudson> although
[02:33] <mwhudson> (t-mwhudson)mwhudson@am1:~/juju-core-1.17.7$ date
[02:33] <mwhudson> Thu May  7 09:01:27 UTC 2150
[02:33] <mwhudson> ^ this may be responsible for some of the failures
[02:33] <axw> wallyworld_: yeah, looks like a nice branch :)
[02:33] <wallyworld_> will get better :-)
[02:35] <davechen1y> mwhudson: sad trombole
[02:35] <mwhudson> davechen1y: yay shared porter hardware
[02:36] <davechen1y> da f
[02:36] <davechen1y> 2150
[02:36] <davechen1y> unix time goes that high ?
[02:36] <davechen1y> well, I guess an int is 8 bytes big
[02:36] <davechen1y> on mar64
[02:36] <davechen1y> on arm64
[02:36] <mwhudson> yeah, i guess it does on arm64?  i have no idea what this is about
[02:36] <davechen1y> hyperactive real time clock
[02:39] <mwhudson> fixing that makes 30 more packages' tests pass
[02:40] <mwhudson> hmmf, lots of this:
[02:40] <mwhudson> panic: runtime error: invalid memory address or nil pointer dereference [recovered]
[02:40] <mwhudson>         panic: runtime error: invalid memory address or nil pointer dereference
[02:40] <mwhudson> [signal 0xb code=0x1 addr=0xa0]
[02:41] <mwhudson> which is a bit of a worry
[02:43] <mwhudson> oh, it's some pointer being null inside mgo
[02:43] <mwhudson> oh heh, helps to have juju-mongodb installed i imagine
[02:45] <mwhudson> bah
[02:48] <wallyworld_> thumper: thanks for review. i can land disabled for now but when i propose the followup branch to fix the juju-core address issue i should enable then as 1. i've been asked to get it into trunk so people can test 2. it's ment to go into 1.18
[02:52] <mwhudson> hm, where do logger.Debugf messages end up when running tests?
[02:54] <thumper> wallyworld_: ok
[02:54] <thumper> mwhudson: into the gocheck log
[02:55] <thumper> mwhudson: assuming that you are using something that has the LoggingSuite contained
[02:55] <mwhudson> thumper: which is ... ?
[02:55] <mwhudson> running with -gocheck.vv doesn't make anything appear
[02:55] <mwhudson> is it going into some file somewhere?
[02:55] <thumper> no, the log is only shown if a test fails
[02:55] <mwhudson> well it's panicking?
[02:55] <mwhudson> does that count?
[02:55] <thumper> mwhudson: hmm...
[02:56]  * thumper looks at the code
[02:59] <thumper> mwhudson: c.GetTestLog()
[02:59] <thumper> mwhudson: returns a string
[03:01] <mwhudson> uh
[03:01] <mwhudson> thumper: thanks
[03:01] <mwhudson> although i think this is a silly bug
[03:02] <mwhudson> http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/testing/mgo.go#L112 <- this debugf only makes sense if there was no error right?
[03:02] <mwhudson> i.e. it should be in an } else { from the preceding test
[03:02] <mwhudson> because if inst.server is null it goes bang
[03:04] <mwhudson> err
[03:05] <mwhudson> oh do i have to put the juju-mongodb binaries on $PATH explicitly?
[03:05] <mwhudson> ... yes
[03:08] <thumper> yes
[03:08] <thumper> although I think perhaps the test harness should fix that for you IMO
[03:09] <mwhudson> the failure mode is certainly impressively obscure :)
[03:12] <mwhudson> ok the tests are taking much longer now, that's a good sign :-)
[03:17] <mwhudson> down to 20 failures
[03:17] <mwhudson> much better :-)
[03:17]  * mwhudson goes home
[03:37] <wallyworld_> axw: do you know if instance polling works as expected for the manual provider? I would assume so
[03:38] <axw> wallyworld_: it won't do anything for machines other than machine-0, since hte manual provider does not manage instances
[03:39] <axw> wallyworld_: the machiner will update machine addresses though
[03:39] <wallyworld_> cool, just checking that removing those methods off manual env provider won't brek stuff
[03:39] <axw> wallyworld_: actually, just a moment. it might.
[03:41] <axw> wallyworld_: ah no, addresses are recorded at provisioning time too
[03:41] <wallyworld_> so all good?
[03:41] <axw> wallyworld_: and the hostname is recorded as public
[03:41] <axw> yeah should be good
[03:41] <wallyworld_> i'm going to test local provider
[03:41] <wallyworld_> i think maas should be ok
[03:45] <mattyw> is anyone seeing this error on trunk? http://paste.ubuntu.com/7168714/?
[03:46] <mattyw> ^^ I'm guessing not as things seem to be landing - but I've not changed anything in my branch that 'should' have affected this
[04:31] <hazmat> anybody know windows?
[04:34] <jam> hazmat: "this is unix, I *know* this". but yes, I have some familiarity
[04:35] <hazmat> jam, so i've got a user trying to use the digital ocean plugin on windows.. and the path the plugin code thinks juju is at doesn't quite line up .. i'm just using os.path.expanduser("~/.juju") (taking into account JUJU_HOME)
[04:36] <hazmat> jam, https://github.com/kapilt/juju-digitalocean/issues/16 and https://github.com/kapilt/juju-digitalocean/issues/15
[04:37] <mischief> juju is not very go-gettable is it
[04:37] <hazmat> jam, going through the juju-core code at the moment trying to see the delta.. ic.. HOMEDRIVE and HOMEPATH..
[04:37] <jam> hazmat: I'm pretty sure we don't use $HOME on Windows for our .juju dir, but use the %APPDATA% magic. So probably we need a helper in juju-core that gives you the path to look in
[04:37] <hazmat> mischief, it is.. but go dep management needs help..
[04:37] <jam> hazmat: juju/osenv/home.go APPDATA
[04:37] <hazmat> mischief, you go get.. cat dependencies.tsv.. update the various branches
[04:37] <mischief> yea, i just tried to go get and some package api has changed
[04:37] <mischief> ah
[04:38] <hazmat> mischief, there's some tool that will read dependencies.tsv and do it for you
[04:38] <hazmat> jam, thanks
[04:38] <mischief> i would like that :)
[04:39] <hazmat> mischief, go get launchpad.net/godeps .. see bottom of CONTRIBUTING.txt
[04:39] <hazmat> er.. minus the .txt
[04:40] <hazmat> hmm.. interesting thats docs on how to generate but now how to use
[04:44] <hazmat> jam, so reading through home.go .. its a bit unclear are the functions in  in osenv/var_windows.go  used.. else it just looks like return os.environ['APPDATA'] but that looks like its some how being  setup by magic
[04:44] <hazmat> and in this context the plugin is in a separate process.. not clear if its gets it own APPDATA or if it inherits.
[04:44] <hazmat> hmm
[04:45] <jam> hazmat: so Home() != JujuHome()
[04:45] <jam> hazmat: APPDATA is windows place to put your application stuff
[04:45] <jam> it is C:\Users\$USER\AppData\Roaming\
[04:45] <jam> hazmat: and then we put our own "Juju" under that
[04:45] <hazmat> jam, right.. but JujuHome() calls Home() on linux.. but not
[04:46] <jam> hazmat: right
[04:46] <hazmat> on windows
[04:46] <jam> hazmat: on Windows we don't put it in $HOME
[04:46] <jam> so osenv.JujuHomeDir() is what you should be using.
[04:46] <hazmat> but we have functions to determine Home() on windows from other env vars
[04:46] <hazmat> k
[04:46] <hazmat> yup.. that should do it
[04:46] <hazmat> thanks
[04:46] <jam> hazmat: we also support $HOME for some other reason
[04:52] <hazmat> hmm.. not sure this is going to work.. juju docean depends on an ssh binary
[04:53] <mischief> hazmat: ok finally done
[04:53] <mischief> now i am finally building jujud :)
[04:53] <mischief> i never used godeps before, but it certainly does solve the dependency tracking problem
[04:53] <mischief> there are many tools like it
[04:55] <hazmat> mischief, yup.. lack of leadership ..  fragemented ecosystem tooling for basic problems.. i think there's roughly a dozen different paradigms and tools for this issue.
[05:00] <jam> hazmat: well, I have ssh on my windows box
[05:00] <jam> you can certainly get one
[05:00] <hazmat> jam, putty, etc.. but not openssh i presume
[05:01] <jam> hazmat: both git and cygwin give you openssh
[05:01] <hazmat> jam, i recommended they use cygwin..
[05:01] <hazmat> yeah
[05:01] <jam> and you *can* build it natievly somehow
[05:02] <hazmat> fair enough.. but that's not happening (be building it for users) i can't really support that effectively..  and afaics neither does openssh.. http://www.openssh.com/windows.html
[05:02] <hazmat> s/be/me
[05:03] <hazmat> better would be if i could get digital ocean to support userdata/cloudinit and drop the ssh entirely.. but need them to implement it.. slowly getting more votes on it.. http://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/3736274-support-cloudinit-instance-metadata
[05:18] <mischief> hazmat: it would still appear there is a problem, after use of godeps -u
[05:31] <mischief> http://sprunge.us/GAAV
[05:33] <mischief> i guess i'll use ubuntu ._.
[05:58] <jpds> As most people do.
[06:09] <dimitern> fwereade, jam, i'd appreciate a review on this so i can land it https://codereview.appspot.com/80600044/
[06:12] <jam> dimitern: the first thing that comes to mind is that I thought we specified it as "--network/--exclude-networks" for the Juju deploy command line. 'no-networks' being a MaaS API name, but not as user-friendly.
[06:13] <dimitern> jam, maas'es is actually not_networks, but fair enough --exclude-networks it is
[06:14] <dimitern> jam, and you mean --networks right, not --network for the other one?
[06:14] <jam> dimitern: well, they should be the same plurality
[06:14] <jam> *I* like plural form (networks)
[06:14] <dimitern> jam, btw is our 1-1 in 15m or in 1h 15m ?
[06:14] <jam> I think fwereade was asking for singular
[06:14] <jam> dimitern: 1h15m
[06:15] <dimitern> jam, ok
[06:15] <dimitern> jam, i don't recall that
[06:16] <jam> I certainly recall it, because I remember disagree on this case. We have "--constraints" which is a plural for something that might be one but can hold many
[06:16] <jam> I think --networks fits well in the same vein
[06:16] <dimitern> +1
[06:17] <waigani> thumper: https://codereview.appspot.com/77970043/
[06:19] <dimitern> jam, i found a bug 1299114 in maas when adding networks
[06:19] <_mup_> Bug #1299114: 'ValidationError' object has no attribute 'error_dict' when creating a network <api> <cli> <MAAS:Triaged> <https://launchpad.net/bugs/1299114>
[06:20] <dimitern> jam, now I'm in the process of exporting and uploading to u1 21GB disk image
[06:20] <dimitern> (now my 100mbps fiber will come in handy :)
[06:21] <dimitern> jam, re what fwereade said about mocking api requests to test 1.16 compat code path - any ideas?
[06:22] <jam> dimitern: I did not, I just did manual testing for most of the cross version compat code.
[06:24] <dimitern> jam, yeah, me too; i was thinking of trying to mock it, but there are too many levels of indirection to make it cheap to do
[06:26] <jam> yeap
[06:26] <jam> If we had it in place before, then I would certainly use it.
[06:56] <mattyw> fwereade, rogpeppe1 does one of you have a spare moment to help me out with a test that's failing?
[06:57] <rogpeppe1> mattyw: sure
[06:57] <rogpeppe1> mornin' all
[06:57] <mattyw> rogpeppe1, morning!
[06:57] <rogpeppe1> mattyw: how's tricks?
[07:07] <dimitern> morning!
[07:11] <fwereade> dimitern, jam: sorry, I must have misremembered the mocking -- and I'm fine with --networks/--exclude-networks, I think that was what we agreed? if my preference for singular seems insane to you both then let's go with plural
[07:12] <dimitern> fwereade, plural seems more appropriate
[07:14]  * fwereade has another public holiday, yay malta, and so I have laura at home, and will not be getting much work done
[07:14] <fwereade> but fwiw I will be reviewing things flagged in the channel when laura is otherwise occupied
[07:15] <axw> rogpeppe1: taking it over here
[07:15] <axw> rogpeppe1: ok, understand doing it at bootstrap-state because peergrouper isn't working. for #2, the only address will be machine--0 right? then the client already has the address...?
[07:15] <axw> machine-0 rather
[07:16] <wallyworld_> fwereade: this already has  a +1 but just in case there's something that raises any red flags, it would be great if you did get to look at https://codereview.appspot.com/82470043/
[07:16] <rogpeppe1> the client already has the address it used to dial, but there might be other addresses too
[07:16] <rogpeppe1> axw: ^
[07:16] <axw> rogpeppe1: when would you need another address for the same machine?
[07:17] <rogpeppe1> axw: perhaps you might want to dial it within the cloud
[07:17] <rogpeppe1> axw: and perhaps the public address isn't valid in the cloud
[07:17] <axw> rogpeppe1: we already have api-addresses for that?
[07:18] <rogpeppe1> axw: also, it means we don't need any special casing for the addresses returned by Login
[07:18] <rogpeppe1> axw: it just seems right to me that we should ensure from the very start that APIHostPorts is valid
[07:19] <rogpeppe1> axw: especially since it's user-visible
[07:19] <axw> yes, I suppose so
[07:19] <rogpeppe1> axw: also, there are other things in the agent that watch it
[07:20] <rogpeppe1> axw: and it would be nice not to need to special-case them
[07:20] <axw> rogpeppe1: ok, I will get back to that one now then. now that we have a fully valid config at bootstrap time, it's straight forward to do without any changes to environs/cloudinit and so on
[07:20] <rogpeppe1> axw: yeah
[07:21] <rogpeppe1> axw: the code to set up the replica set already needs the address anyway tbh
[07:27] <fwereade> wallyworld_, I have not reviewed it but I heartily endorse what you did
[07:27] <wallyworld_> fwereade: i thinks it's all ok, stuff works
[07:27] <wallyworld_> just wanted to be sure i hasn't missed any subtle issues
[07:27] <wallyworld_> i need this to land for the joyent provider to work
[07:28] <wallyworld_> i like all the red in the diff
[07:28] <dimitern> jam, i'll be 5m late for 1-1, sorry
[07:29] <jam> dimitern: np
[07:29] <fwereade> wallyworld_, I might review it anyway just to see the red, those CLs do always make me happy
[07:29] <fwereade> wallyworld_, but don't wait on me ;)
[07:29]  * fwereade bbs
[07:30] <wallyworld_> fwereade: sure, np. i have a filing status test to fix anyway
[07:30] <wallyworld_> failing
[07:31] <wallyworld_> fwereade: my main concern is just to check that it is 100% ok to remove the SetAddress calls from the uniter startup in ModeInit(). I'm sure it is but....
[07:37] <dimitern> jam, i've joined
[07:47] <rogpeppe2> axw: i'm trying to understand the comment in https://codereview.appspot.com/81780043/diff2/1:20001/juju/apiconn_test.go?column_width=90
[07:48] <rogpeppe2> axw: i'm not sure what you mean by "we can only create the zero value"
[07:48] <rogpeppe2> axw: the zero value of what?
[07:48]  * axw looks
[07:49] <axw> rogpeppe2: we can only create the  zero value of api.State, because all of its members are private
[07:50] <axw> sorry, not very clear
[07:50] <axw> rogpeppe2: the point is, without a real call to Login we can't change the result of HostPorts
[07:50] <fwereade> wallyworld_, I will be most sad if we are not ready to do that -- they'reonly there as a fallback anyway, we should always be deriving unit addressesfrom machine addresses these days
[07:51] <rogpeppe2> axw: ah yes. hmm. i wonder if we should mock out api.State hre
[07:51] <rogpeppe2> here
[07:51] <rogpeppe2> axw: we're relying on it not crashing when methods are called on its zero value
[07:51] <rogpeppe2> axw: that seems a bit wrong to me
[07:51] <rogpeppe2> axw: it was kind of ok before because we weren't calling any methods on in
[07:51] <rogpeppe2> it
[07:52] <axw> rogpeppe2: sure, I'll look into doing that
[07:53] <rogpeppe2> axw: i think that'll mean you'll have to create an internal version of NewAPIFromStore that returns the possibly-mock api.State, then a thin wrapper that type asserts the returned value back to api.State
[07:53] <rogpeppe2> axw: then in tests you can call the internal version
[07:54] <rogpeppe2> axw: i suppose another possibility would be to actually create a genuine api.State to return.
[07:55] <axw> rogpeppe2: that might be less painful :)
[07:55] <axw> I don't want to create a Mongo test just because though
[07:55] <rogpeppe2> axw: i actually don't think doing the mock thing will be that much hassle
[07:55] <axw> I'll see how hard it is to create an interface here
[07:55] <rogpeppe2> axw: thanks
[07:56] <rogpeppe2> axw: the test was always slightly dodgy (for which i'm fully responsible) but i think the latest changes push it over the boundary into crackfulness.
[07:57] <axw> fair enough :)  I was being a bit too lazy, I admit
[08:18] <wallyworld_> fwereade: that's what i thought, justed wanted some extra eyes cause of the scope of the change
[08:26] <jamespage> anyone know who's working on the joyent cloud provider?
[08:27] <jamespage> fwereade, rogpeppe2 ^^
[08:27] <fwereade> jamespage, wallyworld_ has been doing so most recently, and mgz before him
[08:28] <wallyworld_> jamespage: i have it working. one more branch to land
[08:28] <jamespage> wallyworld_, fwereade: am I right in thinking that introducing this feature is fairly isolated in terms of impact on other code ares?
[08:28] <jamespage> (just assessing for the Feature Freeze Exception)
[08:29] <fwereade> jamespage, yes, it shouldn't be able to affect anything that's not directly joyent-related
[08:29] <wallyworld_> jamespage: yes, but there some old methods need to be deleted
[08:29] <wallyworld_> cause the joyent provider does not implement them
[08:29] <jamespage> great - thanks!
[08:29] <fwereade> jamespage, and indeed some dead code elimination
[08:36] <voidspace> morning everyone
[08:39] <rogpeppe2> voidspace: hiya
[08:40] <voidspace> rogpeppe2: thanks for your emails
[08:41] <voidspace> rogpeppe2: ah, one email and you assigned me a card
[08:41] <voidspace> anyway :-)
[08:41] <rogpeppe2> voidspace: i think it was a card that you were already working on
[08:41] <voidspace> rogpeppe2: yeah
[08:41] <rogpeppe2> voidspace: perhaps slightly changed
[08:41] <voidspace> oh
[08:41] <voidspace> I'd better check :-)
[08:42] <voidspace> that's quite a few cards for HA
[08:43] <voidspace> not changed I don't think
[08:44] <voidspace> weeeee, conflicts in merge from trunk
[08:44] <voidspace> happy Monday morning
[08:44] <rogpeppe2> voidspace: sorry about that
[08:45] <voidspace> heh
[08:45] <voidspace> ah, "someone" moved the declaration of an interface method I've removed
[08:45] <voidspace> easy enough to fix
[08:46] <voidspace> rogpeppe2: ah, the ticket is slightly changed - you want SetStateServingInfo on the ConfigSetter now
[08:46] <rogpeppe2> voidspace: yup
[08:47] <rogpeppe2> fwereade, dimitern: i'm concerned about this bug, that i discovered when live-testing my agent config changes: https://bugs.launchpad.net/juju-core/+bug/1299802
[08:47] <_mup_> Bug #1299802: upgrade-juju 1.16.6 -> 1.18 (tip) fails <juju-core:New> <https://launchpad.net/bugs/1299802>
[08:48] <rogpeppe2> there's something very odd going on there
[08:49] <dimitern> rogpeppe2, is it possible the api server wasn't upgraded first?
[08:50] <dimitern> rogpeppe2, hence DesiredVersion returns 1.16
[08:50] <rogpeppe2> dimitern: no, i don't think so
[08:50] <rogpeppe2> dimitern: note that the unit server had already upgraded to 1.18
[08:50] <dimitern> rogpeppe2, have you investigated why it returns 1.16?
[08:50] <rogpeppe2> dimitern: and *then* downgraded
[08:51] <rogpeppe2> dimitern: i've looked at the code and i can't see how it could possibly happen
[08:51] <rogpeppe2> dimitern: the desired version comes from the agent-version field in the env config
[08:51] <rogpeppe2> dimitern: and an earlier log message confirms that that's previously changed to 1.18
[08:52] <rogpeppe2> dimitern: so there's something very odd happening
[08:54] <dimitern> rogpeppe2, well, a good point to start from is add more debug logging in SetEnvironAgentVersion - that's what get's called (and only that should be called) to change "agent-version" in env config
[08:54] <rogpeppe> dimitern: also, regardless of the api server version, the desired version should always return the same thing
[08:54] <rogpeppe> dimitern: (it just returns what's in the environ config)
[08:54] <dimitern> rogpeppe, i'm not quite clear on what's desiredversion supposed to do
[08:55] <rogpeppe> dimitern: it's supposed to return the desired agent version
[08:55] <rogpeppe> dimitern: which is just the agent-version as stored in the env config
[08:56] <dimitern> rogpeppe, why do we need an api call for that, if we can get if from env config?
[08:56] <dimitern> rogpeppe, the issue seems to be a race is happening changing agent-version
[08:57] <rogpeppe> dimitern: i don't see how that could happen
[08:57] <rogpeppe> dimitern: the environment is stable. we change the agent version once. the environment reacts.
[08:57] <rogpeppe> dimitern: where's a race?
[08:58] <dimitern> rogpeppe, if i knew :)
[08:58] <rogpeppe> dimitern: the reason for an API call is that not all agents are allowed to see the environment config
[08:59] <rogpeppe> dimitern: oh, i thought maybe you had a theory for why it might be a race condition
[08:59] <dimitern> rogpeppe, i'd pull 1.16, add logging around SetEnvironAgentVersion (if it was there in 1.16) and setting environ config in state and try the upgrade
[09:00] <rogpeppe> dimitern: i suspect *some* kind of race somewhere (because the issue isn't entirely deterministic) but i doubt it's when changing the agent version
[09:01] <jam> rogpeppe: 1:1 ?
[09:02] <rogpeppe> jam: i'm there...
[09:02] <jam> rogpeppe: check your calendar entry again, I think I updated the hangout link
[09:03] <jam> https://plus.google.com/hangouts/_/canonical.com/john-roger?authuser=1
[09:06] <jam> dimitern: https://code.launchpad.net/~dimitern/juju-core/370-cli-deploy-networks/+merge/212860 LGTM
[09:06] <dimitern> jam, cheers
[09:09] <mgz> mornin' all
[09:10] <jam> morning mgz
[09:11] <mgz> so, is the alendar right, that everything is gmt still, so it's an hour later for me?
[09:11] <mgz> *calendar
[09:19] <wallyworld_> fwereade: in juju status output, do we want to show public-address of subordinate units? we don't currently in many tests but my change exposes such addresses because we now navigate to the assigned machine. i could just suppress public address output for subords
[09:21] <mgz> wallyworld_: I don't really see why we should
[09:22] <wallyworld_> why we should suppress public address display for subords?
[09:22] <mgz> just because it's the same as the er... what word are we using, main unit. that might not be a good enough reason
[09:23] <mgz> especially for backwards charms that expose via a sub rather than the reverse
[09:25] <wallyworld_> mgz: so the status tests are written wrongly then i think, as they don't set unit addresses directly like what would happen with the provider.PublicAddress() call. But for real deployments we would show them. So I'll just update the tests
[09:51] <fwereade> wallyworld_, IMO we should not show subordinate addresses in status, it's duplicate info and the output is bloated enough already
[09:51] <wallyworld_> fwereade: balls, i submitted the branch. i can do a followup. note that we do show subordinate addr now if set. it's just that some tests didn't set it
[09:52] <wallyworld_> fwereade: mgz also had a concerm about leving it out
[09:53] <voidspace> restarting
[09:56] <fwereade> mgz, the addresses of the subordinates can/should be the same as the principals' in every respect, because they should both just be derived from the machine's address
[09:56] <fwereade> mgz, in relations things get much more interesting
[09:57] <fwereade> mgz, so we'll end up with various addresses per unit, on different networks, and need to bind to, and advertise, the right ones
[10:00] <wallyworld_> anyone for a real quick review? https://codereview.appspot.com/82480043/
[10:07] <wallyworld_> fwereade: so you want a branch to explicitly exclude display of subordinate address info?
[10:10] <jam> wallyworld_: what do we gain by not validating comments here? Is it just to support user keys that are already present that don't have a comment?
[10:10] <wallyworld_> jam: yes. and comments are validated further up the chain anyway
[10:10] <wallyworld_> when keys are added to juju they are validated
[10:10] <jam> mgz: ping
[10:11] <jam> wallyworld_: then LGTM with a comment so that people don't come back later and just re-add the comment checking.
[10:11] <wallyworld_> sure
[10:11] <jam> so a comment on the test that we are explicitly testing the behavior when you don't have a comment
[10:12] <wallyworld_> ok
[10:12] <mgz> jam: hey
[10:12] <jam> mgz: 1:1 ?
[10:15] <voidspace> godeps: cannot parse "dependencies.tsv": cannot find directory for "github.com/joyent/gomanta": not found in GOPATH
[10:16] <voidspace> do I need to manually install the missing dependencies?
[10:16] <mgz> voidspace: or run go get again
[10:17] <voidspace> mgz: yeah, that's what I'm doing - but my branch is currently in flux, so I need to get that compilable first
[10:18] <voidspace> rogpeppe: is the creation of ConfigSetter new?
[10:18] <rogpeppe> voidspace: i'm not sure i understand the question
[10:18] <rogpeppe> voidspace: wanna hang out?
[10:19] <voidspace> rogpeppe: did you add the ConfigSetter interface recently?
[10:19] <voidspace> rogpeppe: sure
[10:19] <rogpeppe> voidspace: yes
[10:19] <voidspace> rogpeppe: right, now the compiler doesn't know about fields on what was the configInternal type because it's using the interface instead
[10:19] <voidspace> rogpeppe: and I need access to the fields
[10:33] <perrito666> morning
[10:36] <voidspace> coffee before standup
[10:45] <jam> fwereade: mgz: standup https://plus.google.com/hangouts/_/canonical.com/juju-core
[11:05] <jam> axw: are you still around for today, or are you done?
[11:10] <dimitern> jam, mgz, fwereade, rogpeppe, https://codereview.appspot.com/82530043 - provisioner api for machine networks, PTAL
[11:21] <wwitzel3> rogpeppe: https://codereview.appspot.com/82550043 .. short one, when you have a moment.
[11:26] <jam> wwitzel3: you're adding a public function, but not adding any tests for that public function, nor updating callers to use that function. I'm not quite sure the utility of the patch
[11:29] <wwitzel3> jam: I must of accidently torched the test, I will get it re-added, the purpose is so that the HA APIs and things like the replicaset worker use the same selection behavior.
[11:29] <axw> jam: I am around and still working (eating atm tho)
[11:29] <jam> wwitzel3: sure, I just would have expected to see something other than just a 3 line change :)
[11:29] <wwitzel3> jam: it was a card from rogpeppe that I started Friday that I was just wrapping up
[11:30] <jam> axw: so we'd like to make sure your stuff lands, I'm happy to hand it off to nate and wayne, but I want to make sure things are moving forward for everyone
[11:30] <axw> jam: nps, I aim to wrap up all my in-progress HA stuff tonight
[11:31] <wwitzel3> jam: when the ensuremongo branch got set back to WIP we added some cards that could be done without having to worry about how that implementation would change.
[11:31] <wwitzel3> jam: so that is the reason for such a trivial implementation
[11:32] <axw> if someone is free to review, there's https://codereview.appspot.com/82450043/ and https://codereview.appspot.com/82520043/ waiting
[11:32] <axw> fixing up https://codereview.appspot.com/81780043/ now
[11:33] <jam> rogpeppe: fwiw, I can't reproduce bug #1299802
[11:33] <_mup_> Bug #1299802: upgrade-juju 1.16.6 -> 1.18 (tip) fails <juju-core:Triaged> <https://launchpad.net/bugs/1299802>
[11:33] <jam> upgrade works smooth here
[11:40] <wwitzel3> jam: review updated, thanks
[11:40] <jam> axw: does that mean you're actually landing the code, or should nate/wayne be doing the review feedback?
[11:42] <axw> jam: 1/3 is LGTMd and I'll land when I've fixed it
[11:43] <axw> 2/3 (the two I pasted before) need reviews
[11:43] <axw> not sure if they came through because my wifi is a bit dodgy
[11:43] <axw> axw> if someone is free to review, there's https://codereview.appspot.com/82450043/ and https://codereview.appspot.com/82520043/ waiting
[11:50] <dimitern> jam, rogpeppe, fwereade, mgz: please, I really need a review on https://codereview.appspot.com/82530043
[11:52] <mgz> I'll do some reviwings
[11:53] <fwereade> dimitern, LGTM
[11:54] <dimitern> fwereade, thanks!
[11:56] <mgz> dimitern: does the Network result want to include the machine id?
[11:57] <dimitern> axw, both reviewed
[11:57] <axw> dimitern: thanks
[11:57] <mgz> otherwise, if there are multiple machines passed, do you need to rely on order to know which networks go with which machines?
[11:57] <dimitern> mgz, no, it's just like Constraints or other calls
[11:57] <wwitzel3> rogpeppe: https://codereview.appspot.com/82550043
[11:57] <dimitern> mgz, yes, as all the other bulk calls do
[11:58] <mgz> dimitern: thanks
[12:00] <rogpeppe> wwitzel3: bzr+ssh://bazaar.launchpad.net/~rogpeppe/juju-core/natefinch-030-MA-HA/
[12:05] <rogpeppe> wwitzel3: func (m *Machine) IsMaster() (bool, error)
[12:08] <jam> hey fwereade, I thought you were off today
[12:08] <jam> fwereade: dimitern said it was a public holiday
[12:10] <dimitern> jam, if you scroll back ~5h you'll see his comment
[12:13] <hazmat> mischief, what distro where you on there?... you can manually specify --series="precise, trusty" to workaround that one
[12:19] <rogpeppe> wwitzel3: http://paste.ubuntu.com/7184551/
[12:20] <rogpeppe> wwitzel3: http://paste.ubuntu.com/7184555/
[12:22] <perrito666> natefinch: out of curiosity, what kind of laptop are you using?
[12:23] <rogpeppe> wwitzel3: func IsMaster(session *mongo.Session, addrs []instance.Address) (bool, error) {
[12:24] <wwitzel3> rogpeppe: +1
[12:27] <jam> rogpeppe: I thought the idea was to have code that took a generic "my address", so that it could be used if you had a direct session, or if you had an API connection ?
[12:27] <jam> wwitzel3: ^^
[12:28] <rogpeppe> jam: i've come round to a slightly different point of view
[12:30] <rogpeppe> wwitzel3: http://paste.ubuntu.com/7184597/
[12:32] <rogpeppe> http://paste.ubuntu.com/7184602/
[12:38] <axw> jam: re layer violation, yes I think you're right. not sure if changing it at this stage is helpful though - how about I create a tech-debt bug and fix it once the MVP is done?
[12:49] <rogpeppe> func IsMaster(session *mgo.Session, m *state.Machine) (bool, error) {
[12:49] <rogpeppe> wwitzel3: ^
[12:52] <rogpeppe> wwitzel3: http://paste.ubuntu.com/7184668/
[12:54] <rogpeppe> wwitzel3: func (m *Machine) State() *state.State
[12:54] <rogpeppe> m.State().MongoSession()
[13:20] <natefinch> perrito666: I'm  on a Dell XPS 15, 2013 haswell revision (9530 model number).  Worked great until umm... yesterday, when the screen started flaking out after I updated.
[13:21] <natefinch> speaking of which, I'm going to reboot to see if that helps
[13:25] <voidspace> finally got the InitializeState tests passing
[13:25] <voidspace> so lunch
[13:28] <fwereade> jam, I am off, but occasionally laura dashes off to do something on her own
[13:28] <natefinch> updated, sort of fixed... at least I *have* a laptop screen now.
[13:29] <perrito666> negronjl: thank you, just wanted to know if upgrading my other laptop :p
[14:18] <Valduare> hi guys
[14:19] <Valduare> got an interesting problem for ya http://pastebin.com/qhK1HJ9Y
[14:20] <wwitzel3> natefinch: I am working on the IsMaster stuff that roger and I had a discussion about, but let me know when you're up and running and want to hangout.
[14:20] <natefinch> Valduare: is juju-wordpress a hostname you can otherwise ssh to?
[14:21] <natefinch> wwitzel3: now is good
[14:21] <Valduare> yes
[14:21] <Valduare> set it up in .ssh/config
[14:21] <Valduare> and i’ve previously add-machine this method
[14:21] <Valduare> im on manual provision setup
[14:21] <Valduare> I even tried blowing away one of the vm’s and reinstalling fresh ubuntu server but still cant
[14:22] <Valduare> then I tried blowing away my local juju installation after destroy-environment manual
[14:22] <Valduare> and reinstalling juju
[14:25] <axw> Valduare: do you have juju-wordpress in /etc/hosts?
[14:25] <Valduare> no its ssh config
[14:26] <Valduare> juju add-machine ssh:juju-wordpress
[14:26] <Valduare> that type of thing
[14:26] <axw> ok
[14:26] <axw> so that may be something we need to improve, but you currently must specify something that can be resolved to an IP (not using ssh)
[14:26] <Valduare> reason being - I have a different port for each vm
[14:27] <Valduare> my juju bootstrap is port 22 at one of my public ip’s
[14:27] <Valduare> then the other vm’s are each on their own ssh port
[14:27] <Valduare> they can all talk to eachother locally no problem
[14:27] <axw> ah, no public IP?
[14:28] <Valduare> juju bootstrap vm is on a public ip
[14:28] <axw> I mean the other machines
[14:28] <Valduare> ah those are NAT
[14:29] <Valduare> I had this all working the other day
[14:29] <Valduare> but catastrophic failure juju status showed a machine I tried to remove as just dead
[14:29] <Valduare> and couldnt re-add it
[14:29] <Valduare> so I reinstalled the vm from scratch - fresh ubuntu server installed and still couldnt add it
[14:30] <axw> fyi you can "juju destroy-machine --force <machine>" to remove things from status if they won't budge
[14:30] <Valduare> it didnt work
[14:30] <Valduare> just left it there as life: dead
[14:30] <axw> huh, ok
[14:35] <Valduare> any ideas how I can fix this
[14:35] <axw> Valduare: if you haven't already, please file a bug with that pastebin - I at least haven't seen that before, and hadn't considered the scenario of an address known to ssh but not to the resolver
[14:36] <Valduare> ok
[14:36] <Valduare> what is the resolver in this case?
[14:36] <wwitzel3> rogpeppe: https://codereview.appspot.com/82550043/
[14:36] <axw> i.e. the hostname->IP resolver
[14:36] <natefinch> axw: do you have stuff that needs to get landed that I can help with?
[14:36] <rogpeppe> axw: if you're around, i've just LGTM'd https://code.launchpad.net/~axwalk/juju-core/bootstrapstate-addresses/+merge/213483
[14:36] <rogpeppe> axw: if you're not, i'll land it anyway
[14:37] <axw> natefinch: not just at the moment thanks
[14:37] <axw> rogpeppe: cheers
[14:37] <axw> just saw
[14:37] <axw> that was quick :)
[14:37] <rogpeppe> axw: ha, just noticed you're still active
[14:37] <rogpeppe> axw: i'm trying :-)
[14:37] <rogpeppe> wwitzel3: looking
[14:38] <natefinch> rogpeppe: what's the state of the config changes you were working on?  Are you planning to merge those into my branch, or put them in trunk first and then merge?
[14:38] <rogpeppe> natefinch: the former
[14:38] <rogpeppe> natefinch: i pushed a branch which gets your branch working again
[14:39] <rogpeppe> natefinch: ~rogpeppe/natefinch-030-MA-HA
[14:39] <natefinch> rogpeppe: great, I can merge that into mine.
[14:39] <rogpeppe> natefinch: well, i ran the cmd/jujud tests, and not any others :-)
[14:39] <natefinch> rogpeppe: ok, I'll run all the tests after merge to make sure
[14:39] <Valduare> axw any suggestions for bug name?
[14:40] <rogpeppe> natefinch: cool
[14:41] <axw> "Valduare: manual provisioning requires target hostname to be directly resolvable"?
[14:41] <axw> err, move the quotes, you get the idea ;)
[14:41] <Valduare> ok wanted to make sure it was something you guys understood lol
[14:41] <axw> Valduare: yeah that'll mean something to me at least ;)
[14:42] <axw> I'll try to take a look in the morning
[14:44] <Valduare> https://bugs.launchpad.net/juju-core/+bug/1300264
[14:44] <_mup_> Bug #1300264: manual provisioning requires target hostname to be directly resolvable <juju-core:New> <https://launchpad.net/bugs/1300264>
[14:44] <Valduare> wow I have the most important bug in the world filed right there :P
[14:44] <Valduare> kinda gives me a warm fuzzy feeling in side
[14:45] <axw> Valduare: thanks for filing that
[14:48] <Valduare> np
[14:48] <Valduare> I currently have one host box, a gigabyte gae350n mobo with 16 gigs of ram (amd e350 proc)  running esxi and a freenas box serving iscsi to it for about 17 vm’s
[14:49] <axw> Valduare: btw, how do the VMs refer to each other? is "juju-wordpress" a usable address between the VMs, or must they use IPs?
[14:49] <Valduare> i’d like to eventually move over to a juju, maas openstack setup
[14:50] <Valduare> I have a smoothwall router vm with 2 nic’s one that holds the public ip address and port forwards to an “internal nic” then all of the vm’s are on that internal nic network
[14:51] <Valduare> I havnt setup ssh configs at all on the vm’s
[14:51] <Valduare> just from workstation to vm
[14:52] <axw> okey dokey
[14:52] <axw> thanks
[14:52] <axw> Valduare: are you set up to build juju from source?
[14:52] <Valduare> not atm
[14:53] <Valduare> I just updated the brew juju.rb the other day to point devel to 1.17.7
[14:53] <Valduare> for mac
[14:53] <axw> nps. there's a bit of code in the manual provisioning path that sets up the machine's addresses. we could just warn if it can't resolve the hostname, and not record any external addresses
[14:53] <axw> ok
[14:55] <Valduare> how long does juju-core take to compile - im on a macbook pro 7.1   2.66 dual core proc 4 gigs of ram (barely any ram available as its all used up by greedy mavericks)
[14:55] <hazmat> axw, fwiw, my manual provider usage.. i stopped bothering recording addresses when injecting machines.. the agent will come up and do the right thing
[14:55] <hazmat> s/recording/passing
[14:55] <axw> Valduare: it should be in the seconds range
[14:56] <axw> hazmat: yeah I figure we can just rely on that if the hostname's not resolvable
[14:56] <axw> hazmat: only thing you don't get then is a "public" address
[14:56] <axw> hazmat: but in this case there really isn't one
[14:56]  * hazmat nods.. 
[14:56] <Valduare> btw - does my setup sound sane?
[14:57] <axw> Valduare: yeah, I think it does
[14:57] <axw> you'll need to manage exposing service ports yourself, but I guess you know that already
[14:59] <Valduare> aye
[14:59] <Valduare> thats where smoothwall has been nice for me in this low power hardware setup heh
[15:00] <Valduare> I have not been able to get a clear answer to how many physical machines are needed for a juju,maas,openstack setup?
[15:06] <axw> Valduare: sorry, I'm not going to be useful there
[15:06] <axw> I'd suggest #juju
[15:06] <Valduare> ok
[15:11] <natefinch> rogpeppe: after that code is merged in, do we need to wait on anything else to get this branch landed?  Just verified all tests pass.
[15:12] <rogpeppe> natefinch: i think there's some commented out code there that can only work when StateServingInfo in the config is landed
[15:12] <rogpeppe> natefinch: the branch doesn't really make sense unless the mongo secrets are coming from the agent config
[15:12] <natefinch> rogpeppe: ok, right.  Is that something you can land?  Is there anything I can do to help?
[15:13] <rogpeppe> natefinch: voidspace is not far off it
[15:13] <natefinch> rogpeppe: awesome
[15:14] <rogpeppe> natefinch: i'd really like to see [HA: agent stores API addresses after api.Open] happen, if wwitzel3 isn't already on it
[15:14] <natefinch> rogpeppe: yep, that's next on my list.  Wayne is finishing up the IsMaster API stuff since he was already in the middle of it.
[15:15] <rogpeppe> axw: apiclient-open-parallel isn't quite right yet
[15:15] <axw> rogpeppe: bugger, it just landed. howso?
[15:15] <rogpeppe> axw: (i know it's too late, but just saying, it needs a little bit of work)
[15:16] <rogpeppe> axw: if one of the attempts succeeds really fast, the dial will fail
[15:16] <rogpeppe> axw: because Try.Start returns ErrStopped if the try has already succeeded
[15:16] <axw> wat
[15:16] <rogpeppe> axw: (this is deliberate, to avoid making excess attempts)
[15:17] <rogpeppe> axw: otherwise if you're going to start 50 dial attempts and the first one succeeds, you're going to do all 50 dials regardless
[15:17] <axw> rogpeppe: I think I'm too tired to understand, would you mind commenting on the CL?
[15:18] <rogpeppe> axw: am doing
[15:18] <axw> I'm going to crash, will take a look in the morning
[15:18] <rogpeppe> axw: thanks hugely for your work
[15:18] <rogpeppe> axw: i can fix the code
[15:18] <natefinch> axw: definitely, huge amount of work done, super awesome.
[15:18] <axw> rogpeppe: ok cool, but leave it if it's too distracting and I can take a look
[15:19] <rogpeppe> axw: it's possible that Start should return nil, but we could provide another method, say Completed to find out if the try has completed
[15:19] <rogpeppe> axw: that might be less wat-ish
[15:19] <axw> rogpeppe: ohhh, I get it now
[15:19] <axw> rogpeppe: no that makes sense
[15:19] <axw> ErrStopped, that is
[15:20] <rogpeppe> axw: cool. it's always difficult to know when an API is bad or just unfamiliar
[15:20] <axw> rogpeppe: I should try reading doc comments sometimes
[15:20] <rogpeppe> axw: :-)
[15:21] <axw> I expected Start to succeed but then the stopped channel to be closed upon entry
[15:21] <axw> but anyway, now I know
[15:22] <axw> anyways, nighty night
[15:22] <wwitzel3> rogpeppe: thanks for the review, updated
[15:27] <mgz> dimitern: if we propose some maas provider wip stuff, can you give us api feedback
[15:28] <dimitern> mgz, sure thing
[15:28] <mgz> dimitern: ta, proposing now with messy bits left in
[15:37] <perrito666> dimitern: hey, could you take a look to https://codereview.appspot.com/82690043/
[15:37] <perrito666> ?
[15:37] <dimitern> perrito666, will look in a moment, thanks
[15:37] <perrito666> tx
[15:38] <arosales> quick question on code URL for juju core (ie to hand out in printed material.  Would folks prefer https://code.launchpad.net/juju-core or https://code.launchpad.net/~go-bot/juju-core/trunk
[15:38] <mgz> the former
[15:38] <arosales> I prefer the first as it is shorter, but thought I should get input here
[15:38] <mgz> or just lp:juju-core where appropriate
[15:38] <arosales> mgz: agreed, thanks :-)
[15:38] <dimitern> mgz, perrito666, was it live-tested on maas?
[15:39] <arosales> mgz: I would be feedback is most folks aren't as familiar with lp :-/
[15:39] <mgz> arosales: right, but if doing sample commands and such like, the short form should be used
[15:40] <mgz> dimitern: nope, not yet
[15:41] <dimitern> mgz, ok
[15:42] <natefinch> mgz: if I didn't work for canonical, I'd think lp:juju-core was a typo or something... but definitely for bzr commands, at least, it's fine (does it work with things besides bzr?)
[15:42] <dimitern> perrito666, mgz, lgtm + a live test
[15:42] <mgz> dimitern: does the maas provider even do live tests?
[15:42] <mgz> or do you just mean it should be checked that it actually does summat useful?
[15:43] <dimitern> mgz, I mean run the GetNetworks code against a maas environment with networks support
[15:43] <mgz> right :)
[15:43] <dimitern> :)
[15:44] <mgz> dimitern: also our naming sucks a bit and should get changed, but that method should provide roughly what we need on provisioning
[15:44] <arosales> mgz: ack on sample commands
[15:44] <dimitern> mgz, that's ok for now
[15:44] <perrito666> mgz: dunno, GetChanged is a pretty bad name too
[15:44] <mgz> natefinch: other launchpaddy tools probably understand the short form
[15:44] <perrito666> :p
[15:45] <mgz> it's time to go swimming! GetChanged()
[15:45] <natefinch> lol
[15:46] <perrito666> mgz: and there you are, awkwardly looking next to a copy of yourself, changed for swimming and json encoded
[15:47] <natefinch> perrito666, mgz: changed is bad, it's an adjective, not a noun
[15:52] <motter>    /win 2
[15:52] <motter> sorry
[15:55] <mgz> hm, no sinzui online currently?
[16:02] <perrito666> mgz: I was looking for him too :) has not been here on friday either
[16:02] <perrito666> holiday?
[16:02] <mgz> he sent mail to the list ealier today I wanted to respond to
[16:10] <rogpeppe> jeeze, g+ really doesn't like me today
[16:10] <mgz> rogpeppe: mumble ftw
[16:10] <mgz> rural broadband can't screw it up
[16:11] <rogpeppe> mgz: i like being able to the screenshare thing without using a tty emulator...
[16:11] <rogpeppe> s/to/to do/
[16:13] <perrito666> rogpeppe: vnc?
[16:14] <rogpeppe> perrito666: maybe, haven't used vnc in years
[16:14] <perrito666> rogpeppe: no one else has :p
[16:15] <rogpeppe> if anyone wants to provide input on the singular worker package design, here's what i'm thinking of going with: http://paste.ubuntu.com/7185512/
[16:15] <perrito666> rogpeppe: but, given a way to publish the port tightvncserver should be more than enough
[16:15] <rogpeppe> actually, this is more accurate: http://paste.ubuntu.com/7185532/
[16:16] <rogpeppe> dimitern, fwereade, jam, natefinch, wwitzel3, voidspace, wallyworld_: ^
[16:24] <natefinch> perrito666, rogpeppe: I use VNC to do remote desktop support.  Free, works great, both people can see and control.
[16:25] <rogpeppe> natefinch: how well does it work with two very differently proportioned displays?
[16:25] <natefinch> rogpeppe: not entirely sure.  I know it supports scaling, but since my screen is always bigger than the other person's, it hasn't come up.
[16:27] <natefinch> rogpeppe: btw, on the Conn interface, IsMaster is ambiguous to me.  I can't tell if it's telling me if I'm the master, or if some other person who is master happens to have the connection right now.
[16:27] <rogpeppe> natefinch: the doc comment is suppose to make that clear
[16:27] <natefinch> rogpeppe: the doc comment is what confused me ;)
[16:28] <rogpeppe> natefinch: if i changed "the connection" to "this connection", would that help?
[16:28] <natefinch> rogpeppe: yes :)  I was trying to figure out why I was confused. That's it.
[16:28] <rogpeppe> natefinch: cool
[16:30] <natefinch> rogpeppe: is "IsMaster reports whether this connection is to the master of the resource" accurate?  "Held by" makes it sound like the master is me, holding the connection to something else, but I assume this is actually a connection to something that is master... right?
[16:31] <rogpeppe> natefinch: no, that's not accurate
[16:31] <rogpeppe> natefinch: we want precisely "held by" semantics
[16:31] <rogpeppe> natefinch: because with mongo, everyone is connected *to* the master
[16:31] <rogpeppe> natefinch: but what we're interested in is whether we're on the same machine as the master
[16:33] <natefinch> rogpeppe: ok, I see.  I find it a little weird to get that information from a connection.  It seems like the connection is just an implementation detail about how we decide if we're master.
[16:33] <rogpeppe> natefinch: well, maybe Conn is the wrong name
[16:33] <rogpeppe> natefinch: other name suggestions?
[16:34] <voidspace> in a full test run I got 6 panics due to "unreachable servers"
[16:34] <rogpeppe> voidspace: all in the same package?
[16:34] <voidspace> running all the tests for each package with a failing test and they all passed
[16:35] <voidspace> is that "normal"?
[16:35] <rogpeppe> voidspace: kinda :-\
[16:35] <voidspace> rogpeppe: mostly in replicasets
[16:35] <voidspace> five out of six I think
[16:35] <rogpeppe> voidspace: that's pretty usual, unfortunately
[16:35] <voidspace> rogpeppe: thanks
[16:35] <rogpeppe> voidspace: (we need to do more investigation)
[16:35] <rogpeppe> voidspace: what was the 6th?
[16:36] <voidspace> rogpeppe: it was in store
[16:36] <voidspace> TestBlitzKey
[16:36] <rogpeppe> voidspace: ha, store is another unreliable one
[16:36] <voidspace> lovely :-)
[16:37] <voidspace> rogpeppe: so I'm at the point where the code for this change is "complete" (I think)
[16:37] <voidspace> rogpeppe: just some missing tests
[16:37] <rogpeppe> voidspace: yay!
[16:37] <voidspace> well...
[16:51] <rogpeppe> natefinch: this is what my implementation turned out like. no tests yet, mind. http://paste.ubuntu.com/7185691/
[16:52] <natefinch> rogpeppe: sorry, got pulled away.  looking
[16:56] <voidspace> any equivalent of setattr for a struct?
[16:57] <voidspace> except through reflection I guess
[16:57] <natefinch> voidspace: there's reflection, but there's usually a better way.  What are you trying to do?
[16:57] <natefinch> voidspace: the short answer is no ;)
[16:57] <voidspace> natefinch: I want to write a test that asserts that a particular function returns false until given a struct with all members populated
[16:57] <mgz> voidspace: see rog's three (!) excellent answers to our question on that last week
[16:57] <mgz> I'll find the irclog
[16:58] <voidspace> I can manually set them one by one
[16:58] <voidspace> but that's tedious :-)
[16:59] <natefinch> voidspace:  there's really no way to do that except the long way.  Note that because Go initializes everything to a zero value "populated" may be ambiguous.
[16:59] <mgz> voidspace: http://irclogs.ubuntu.com/2014/03/26//%23juju-dev.html#t17:59
[17:00] <voidspace> sure, I'll be checking that the "non-zero value" is present
[17:00] <voidspace> mgz: thanks
[17:00] <mgz> and the pastebins from rog under
[17:00] <voidspace> mgz: thanks
[17:02] <rogpeppe> voidspace: i'm not sure those suggestions will help you
[17:02] <natefinch> yeah, I was going to say thatr
[17:02] <voidspace> it turns out to be a philosophical question rather than a practical one
[17:03] <voidspace> the code is actually only testing one field to determine "availability"
[17:03] <voidspace> so I only need one test rather than a bunch
[17:03] <natefinch> voidspace:  well there you go :)
[17:03] <rogpeppe> voidspace: ha ha
[17:03] <voidspace> hah, indeed
[17:03] <voidspace> rogpeppe: so I'm back at the point where all that is missing is the unmarshaller tests
[17:03] <rogpeppe> voidspace: FWIW, in some similar type of situation, i wouldn't be too averse to a bit of reflection
[17:03] <voidspace> rogpeppe: but there's also (now) a conflict with trunk
[17:03] <natefinch> voidspace: really, reflection is what you'd use if you really wanted to do something like that, but reflection is cumbersome (likely on purpose)
[17:04] <voidspace> rogpeppe: I have to go to Krav Maga now, but I can hopefully pick it up again on my return
[17:04] <voidspace> would be nice to get it ready for CL
[17:04] <rogpeppe> natefinch: actually, i don't think that reflection is any more cumbersome than it needs to be
[17:04] <voidspace> well, I'm sure it could do with a helper layer...
[17:04] <rogpeppe> i dunno what that might look like
[17:04] <voidspace> well, without generics it might be hard
[17:05] <voidspace> but you could use reflection to write the helpers
[17:05] <rogpeppe> voidspace: type parameters wouldn't really be that helpful here
[17:05] <voidspace> if there isn't already direct getattr and setattr equivalents
[17:05] <natefinch> rogpeppe: I just mean that it could be a lot more integrated into the language, and it's not.
[17:05] <voidspace> rogpeppe: I've not looked at reflection at all
[17:05] <voidspace> natefinch: a type declaration of "dynamic" that defers member lookup to runtime reflection automatically
[17:05] <voidspace> C# has that
[17:05] <rogpeppe> voidspace: reflect.NewValue(v).FieldByName("foo") is fairly simple
[17:06] <rogpeppe> voidspace: which is pretty much getattr
[17:06] <voidspace> rogpeppe: right
[17:06] <voidspace> rogpeppe: maybe it's easy enough then
[17:06] <voidspace> but that sounds like fun to defer for another day...
[17:06] <rogpeppe> voidspace: i think natefinch is overstating a little
[17:06] <rogpeppe> natefinch: it would make for a much bigger language
[17:07] <voidspace> right, off to Krav Maga.
[17:07] <voidspace> back later
[17:07] <rogpeppe> natefinch: i like the fact that it's just a normal package
[17:07] <rogpeppe> voidspace: ttfn
[17:07] <voidspace> rogpeppe: if you get bored you could look at what I've done and pick out any obviously glaring errors...
[17:07] <voidspace> rogpeppe: https://code.launchpad.net/~mfoord/juju-core/stateservinginfo/+merge/212874
[17:07] <rogpeppe> voidspace: have you pushed it somewherE?
[17:07] <voidspace> but I'm sure have more pressing things to do
[17:07] <rogpeppe> voidspace: great, will take a look
[17:08] <voidspace> see you later all
[17:12] <natefinch> rogpeppe: I'm happy not to have it integrated into the language, don't get me wrong.  I wouldn't want it integrated into the language.
[17:13] <rogpeppe> natefinch: i know what might be quite cool - a package that used go/ast and go/types and parsed go expressions at runtime and generated closures that did appropriate reflection operations from the go expressions.
[17:13] <rogpeppe> natefinch: e.g.
[17:13] <natefinch> rogpeppe: I may be overstating it some.  The API for it is (necessarily) very large, and code that uses it extensively can be hard to read, since everything is a method call instead of just code.  I've done some with it, and it's always easier than it seems (though I wish they would have called Elem() something different)
[17:15] <rogpeppe> accessor, err := reflecthelper.Accessor("x[p1].Foo.Bar()")
[17:15] <rogpeppe> barResult := accessor(someValue)
[17:15] <natefinch> rogpeppe: our very own eval()
[17:15] <rogpeppe> natefinch: indeed :-)
[17:16] <rogpeppe> natefinch: we already have it, actualy
[17:16] <rogpeppe> natefinch: kinda
[17:16] <rogpeppe> afk
[17:34] <rogpeppe> natefinch: are you around for a quick chat?
[17:35] <natefinch> rogpeppe: yep
[17:35] <rogpeppe> https://plus.google.com/hangouts/_/canonical.com/juju-core?authuser=1
[17:35] <rogpeppe> natefinch: or i can join you if you're already in one
[18:36] <natefinch> rogpeppe: you still around?
[18:36] <rogpeppe> natefinch: just...
[18:37] <natefinch> rogpeppe: quick question.  I was looking at the "Save api addresses to agent config" and realized I probably was misinterpreting what it was asking.   Where is that code supposed to live?  It says after we call api.Open, but I'm not sure where we do that.  (I had misread it as state.Open)
[18:38] <rogpeppe> natefinch: we do that in cmd/jujud
[18:38] <wwitzel3> rogpeppe: you in a hangout atm?
[18:38] <rogpeppe> wwitzel3: no
[18:38] <rogpeppe> wwitzel3: you?
[18:38] <wwitzel3> rogpeppe: have a question, yeah, I can invite you
[18:39] <natefinch> https://plus.google.com/hangouts/_/72cpj1cktoghcmpks6aar56570?hl=en
[18:42] <natefinch> rogpeppe: I guess the question is, is this correct?  It's using state.ApiAddressesFromMachines()  https://codereview.appspot.com/82780043/diff/1/cmd/jujud/machine.go?context=&column_width=100
[18:44] <rogpeppe> wwitzel3: api.auth.GetAuthEntity.(*state.Machine)
[18:45] <rogpeppe> wwitzel3: api.auth.GetAuthEntity().(*state.Machine)
[19:11] <bodie_> is there a way to list keys that can be set by juju set?
[19:29] <fwereade> bodie_, `juju get` should describe what's available
[19:30] <bodie_> excellent
[19:30] <bodie_> bits3rpent, jcw4
[19:31] <jcw4> cool
[19:58] <thumper> morning
[19:58] <thumper> hmm... seems like I forgot to close this yesterday
[20:01] <thumper> alexisb: how's your interwebs now?
[20:01] <alexisb> thumper, good
[20:01] <thumper> alexisb: weren't we going to move the call to be 30 minutes earlier?
[20:02] <thumper> alexisb: so it doesn't clash with my later call?
[20:02] <alexisb> thumper, sure :)
[20:02] <alexisb> but I forgot
[20:02] <alexisb> need a few minutes
[20:02] <thumper> that's fine
[20:03] <thumper> I'll join the hangout from the meeting, join when you're ready
[20:06] <natefinch> mornin' thumper
[20:44] <mwhudson> ... value *errors.errorString = &errors.errorString{s:"cannot upload bootstrap tools: environment \"only\" of type dummy does
[20:44] <mwhudson> not support instances running on \"arm64\""} ("cannot upload bootstrap tools: environment \"only\" of type dummy does not supp
[20:44] <mwhudson> ort instances running on \"arm64\"")
[20:44] <mwhudson> what makes that happen and how do i stop it?
[20:44] <natefinch> mwhudson: sounds like you're running tests on arm64?
[20:45] <mwhudson> yes
[20:45] <mwhudson> that is the intent
[20:45] <mwhudson> so "don't run tests on arm64" is not a useful answer, even if accurate :)
[20:46] <natefinch> mwhudson: somewhere in provider/dummy/environs.go there's probably something with a hardcoded list that needs updating
[20:47] <natefinch> mwhudson: that is an error about the environment that gets created with the SampleConfig that you can see at the top of the aforementioned file (environment of type testing, name is "only")
[20:49] <natefinch> mwhudson: I'm not 100% sure what's causing the error, however.
[21:00] <mischief> hazmat: i am using debian.
[21:01] <mischief> hazmat: now, http://sprunge.us/aaDB XD
[21:02] <hazmat> mischief, can you do that with --debug
[21:02] <hazmat> i'd like to see where that's getting raised from
[21:02] <hazmat> mischief, also what provider are you working with?
[21:03] <mischief> local
[21:03] <mischief> http://sprunge.us/dShP
[21:03] <hazmat> mischief, hmmm. interesting.. so with --upload-tools i think the host would need to be ubuntu.. if you do without upload-tools what happens?
[21:04] <mischief> it says with --series i must use --upload-tools
[21:04] <mischief> so.. i used it!
[21:04] <hazmat> mischief, yup.. sorry.. so without upload-tools and series it also bombs?
[21:04] <hazmat> its creating tools 1.17.7.1-unknown-amd64
[21:05] <hazmat> cause it can't identify the distro series.. but if you have default-series: precise for the provider and the lxc package there has ubuntu-cloud template (dpkg -L lxc) then it should pull the tools down from the global bucket/cdn
[21:05] <mischief> yea it just says
[21:05] <mischief> error: --series requires --upload-tools
[21:05] <hazmat> mischief, right.. if you drop --series and drop --upload-tools what happens?
[21:06] <mischief> the original error from yesterday, seen here with --debug http://sprunge.us/VaUG
[21:07] <hazmat> hmm.. that's also trying to upload tools
[21:07] <hazmat> there's an implicit fallback to upload-tools
[21:08] <hazmat> mischief, i'd suggest filing a bug
[21:08] <hazmat> https://bugs.launchpad.net/juju-core
[21:08] <mischief> haha
[21:08] <mischief> i guess i have two bugs to file now
[21:08] <mischief> one to support plan 9 and one to support debian :-D
[21:08] <hazmat> mischief, hmm.. can you try going back to the 1.17.7 tag
[21:08] <hazmat> mischief, your on trunk and thats not available from the global bucket/cdn
[21:09] <mischief> um
[21:09] <hazmat> mischief, if your client matches up though it can pull those from the cdn global bucket instead of hitting the issue/bug that your running into re uploading from a different distro
[21:09] <hazmat> mischief, cd $GOPATH/src/launchpad.net/juju-core
[21:09] <mischief> i am using https://launchpad.net/juju-core/trunk/1.17.7/+download/juju-core_1.17.7.tar.gz
[21:09] <hazmat> oh.
[21:09] <hazmat> hmm
[21:09] <mischief> i did not use the source from go get because i wasn't able to line up all the dependencies
[21:09] <hazmat> strange its coming out as version 1.17.7.1
[21:10] <mischief> maybe i missed a step like sacrifice a goat to the juju-god
[21:10]  * hazmat checks the dev bucket
[21:10] <mischief> juju version says '1.17.7-unknown-amd64'
[21:12] <hazmat> k, yeah.. that causes issues  on upload.. but if you have default-series: precise it should pick up the right tools from http://streams.canonical.com/juju/tools/streams/v1/com.ubuntu.juju:released:tools.json
[21:12] <hazmat> i gotta run.. bbiab
[21:12] <mischief> ok, thanks for the tips
[21:12] <mischief> oh btw i do i have 'default-series: precise' in ~/.juju/environments.yaml under local :)
[21:13] <mischief> i just got a dedicated server though, i'm gonna set up openstack there and worry about a local provider later.
[21:40] <mwhudson> heh there appears to be a bootstrap test that explicitly checks arm64 is unsupported
[21:41] <thumper> ?!
[21:42] <mwhudson> grep arm64 src/launchpad.net/juju-core/cmd/juju/bootstrap_test.go
[21:43]  * mwhudson recommends ia64 for that test instead
[22:14] <davecheney> morning all
[22:14] <davecheney> morning all
[22:15] <davecheney> waigani: do you have your own ppc vm ?
[22:15] <waigani> hang on - chatting with tim
[22:16] <davecheney> thumper: maybe it would be faster if you added waigani 's keys to your vm
[22:16] <thumper> davecheney: I was thinking that too
[22:16] <thumper> waigani: how about this one ?https://bugs.launchpad.net/juju-core/+bug/1300032
[22:16] <_mup_> Bug #1300032: charm: gccgo test failure <gccgo> <ppc64el> <juju-core:Triaged> <https://launchpad.net/bugs/1300032>
[22:16] <thumper> davecheney: you aren't doing that one are you?
[22:16] <davecheney> thumper: do that, i'll ask mr moser for more vm's
[22:16] <davecheney> thumper: waigani that is a good bug
[22:16] <davecheney> probably related to http_proxy not being isolated in the environment
[22:16]  * thumper nods
[22:17] <thumper> we shouldn't be hitting the store in the tests
[22:17] <thumper> the entire test suite should run disconnected
[22:17] <davecheney> i'm glad that wasn't juju-core/store
[22:17] <davecheney> i would have thrown a shoe
[22:18] <davecheney> waigani: thumper http://paste.ubuntu.com/7182685/
[22:18] <davecheney> i'll raise a bug, if i haven't already done so after this morning's run
[22:18] <davecheney> waigani: thumper https://docs.google.com/a/canonical.com/document/d/1m9R2n6LPLNLGjdopcNkQYVG8D5V4FTyvc1vvn-9ZifM/edit
[22:18] <davecheney> you'll need this
[22:21] <davecheney> https://bugs.launchpad.net/bugs/1300321
[22:21] <_mup_> Bug #1300321: manual provider bootstrap fails if curl isn't installed <juju-core:New> <https://launchpad.net/bugs/1300321>
[22:21] <davecheney> this looks like something we should fix
[22:21] <davecheney> and it shouldn't be hard
[22:21] <davecheney> curl is usually installed, so it'll be a noop
[22:21] <davecheney> and we can just add it to the cloud-init add-package stanza
[22:23]  * mwhudson has now gotten to the point where the juju-core tests take a long time on arm64, at least
[22:24] <davecheney> mwhudson: then everything is working as expected :)
[22:24] <davecheney> mwhudson: takes ~30 mins on a dual core vm
[22:24] <davecheney> for me
[22:24] <davecheney> (ppc64)
[22:24] <mwhudson> i've not been timing, but it's around that i think
[22:25] <mwhudson> machine is also building glibc
[22:25] <mwhudson> ah
[22:25] <mwhudson> eglibc build was spinning due to yesterdays time fun
[22:26] <davecheney> :(
[22:26] <davecheney> mwhudson: is this real tin
[22:26] <davecheney> or the fast model ?
[22:27] <thumper> davecheney: what is the other login that waigani needs for power access? the jump off point?
[22:27] <davecheney> batuan
[22:27] <davecheney> i was just going to raise the RT
[22:27] <mwhudson> real
[22:27] <davecheney> thumper: are you doing it ?
[22:27] <davecheney> mwhudson: orly
[22:27] <thumper> I'll go poke on #is
[22:27] <davecheney> thumper: right o, probably faster
[22:27] <davecheney> mwhudson: can you tell me about this arm64 kit
[22:28] <davecheney> or is it sekrit ?
[22:28] <mwhudson> davecheney: probably not
[22:28] <mwhudson> not on freenode anyway :)
[22:28] <davecheney> mwhudson: another day then
[22:28] <thumper> davecheney: I'll file it if I need it
[22:29] <davecheney> thumper: roger
[22:30] <waigani> davecheney: lunch and finish up current branch - then I'll jump into gccgo test failures
[22:31] <davecheney> waigani: okie dokes
[22:33] <thumper> davecheney: cc'ed you on the RT
[22:33] <davecheney> thumper: thanks mate
[22:33] <thumper> is being actioned now(ish) AFAICT
[22:37] <mwhudson> davecheney, thumper, waigani: current status: http://paste.ubuntu.com/7187184/
[22:38] <mwhudson> (this is with two hacks: one to not strip tools, one to make the dummy provider support arm64)
[22:39] <davecheney> mwhudson: that matches what I see
[22:39] <mwhudson> cool
[22:39] <davecheney> i have fixes for line 15 in review
[22:39] <davecheney> line 13 i'm going to dummy spit
[22:39] <davecheney> line 9 will be hard
[22:39] <davecheney> 3 and 4 will be medium
[22:40] <davecheney> many fail because there are no text fixtures for ppc64
[22:40] <davecheney> or arm64 for that matter
[22:40] <mwhudson> yeah, that seems to be a theme
[22:40] <mwhudson> "no tools available" messages or similar
[22:40] <davecheney> line 7 is worrying, that might be a compiler error
[22:40] <davecheney> mwhudson: yeah, followed by a hundred lines of debug
[22:41] <davecheney> mwhudson: my big item for today is to figure out how to add fixture data
[22:41] <davecheney> once that is done I can copy pasta it for arm64
[22:41]  * davecheney goes to kick up a stink about the store tests
[22:41] <thumper> line 2 is what waigani is about to fix
[22:42] <davecheney> cool
[22:42] <thumper> davecheney: those failres with simple stream data are test isolation failures
[22:42] <mwhudson> the error for rpc is "panic: interface conversion: interface is nil, not error"
[22:42] <thumper> not simple stream failures
[22:42] <thumper> please don't fix test ioslation bugs with data for the local environ
[22:42] <thumper> s/environ/arch/
[22:43] <davecheney> thumper: orly
[22:43] <mwhudson> anyway it sounds like you guys have things under control, and that fixing ppc is mostly
[22:43] <mwhudson> fixing arm64
[22:43] <davecheney> wallyworld_: said they were because there were no test fixtures
[22:43] <davecheney> mwhudson: yup
[22:43] <davecheney> thumper: this is going to make things harder
[22:44] <davecheney> because 'precise' is probably baked into a lot of places
[22:47] <thumper> davecheney: hmm...
[22:47] <thumper> davecheney: there are ways to handwave over it
[22:47] <thumper> for example, patching version.Current
[22:48] <thumper> anyway, I have to go and drop gym gear off for my daughter before my gym class
[22:48] <thumper> catch soon
[22:50] <davecheney> ok
[23:09] <davecheney> http://paste.ubuntu.com/7187301/
[23:09] <davecheney> ^ useful ppc aliases
[23:15] <mwhudson> davecheney: i hate src/cmd/go/build.go
[23:16] <davecheney> mwhudson: i feel you
[23:16] <davecheney> thumper: /var/lib/juju/tools/1.17.8.1-trusty-ppc64/jujud: error while loading shared libraries: libgo.so.5: cannot open shared object file: No such file or directory
[23:16] <davecheney> 2014-03-31 23:16:03 ERROR juju.environs.manual bootstrap.go:101 bootstrapping failed, removing state file: rc: 1
[23:17] <davecheney> did someone recently change the way --upload-tools works
[23:17] <davecheney> say, to make it *always* rebuild local tools ?
[23:21] <davecheney> hmm, looks like there are stale tools on that instance
[23:23] <davecheney> 2014-03-31 23:23:28 DEBUG juju.environs.tools build.go:223 forcing version to 1.17.8.9001
[23:23] <davecheney> ITS OVER 9000!
[23:29] <davecheney> Whoot
[23:29] <davecheney> manual provider on ppc
[23:30] <davecheney> http://paste.ubuntu.com/7187355/
[23:51] <wallyworld_> davecheney: that is good news. i tried again on the power vm to bootstrap into ec2 because they said that more ports were opened but no luck. so i'll park that
[23:53] <davecheney> wallyworld_: yup, put it on the back burner