[01:44]  * thumper watches the tumbleweed roll past
[01:49] <axw> it is rather quiet
[01:49] <axw> wallyworld_: LP just crapped out on an email notification; I've LGTM'd your two simplestreams branches
[01:49] <wallyworld_> axw: awsome thanks :-)
[01:50] <wallyworld_> i'm finishing another soon then i'll poke the landing bot
[02:04] <wallyworld_> axw: with the location of the interfaces in interfaces.go - I prefer them to be in separate files like you suggest, but others on the project want all the interfaces declared in one big file :-(
[02:04] <axw> wallyworld_: my comment is more about the package location than the file
[02:05] <axw> if something other than an Environ is to implement HasConfig, then it probably shouldn't be in environs
[02:05] <wallyworld_> same thing in a way - i would want to define the HasConfig interface in environs.config, but other times got pushback from stuff like that
[02:06] <wallyworld_> HasConfig returns a environs.config.Config
[02:06] <axw> yeah, that's why I thought it would be better there
[02:06] <wallyworld_> me too
[02:07] <axw> your call - just letting you know what I think :)
[02:07] <wallyworld_> but for some reason, people don't like cohesion and loose coupling :-(
[02:07] <axw> lol
[02:07] <wallyworld_> i agree with you fwiw, i just knew the pushback i'd get
[02:08] <wallyworld_> i figured i'd have enough to argue about wrt the interface names :-)
[02:08] <axw> hehe
[02:09] <axw> why'd the standup change time?
[02:15] <wallyworld_> axw: cause if conflicted with breakfast time for nate
[02:15] <axw> ah
[03:10] <bigjools> I have a juju debug log writing to my terminal, yet I have no actual debug-log running in it ...
[03:10] <bigjools> wtf
[03:12] <axw> wallyworld_: Path isn't meant to be relative?
[03:12] <wallyworld_> axw: it is in the metadata, but when used, a full url is required
[03:13] <wallyworld_> cause the tools can then be retrieved via wget
[03:13] <axw> mmk. just slightly confusing that ToolsMetadata.Path has different forms based on whether it's input/output
[03:13] <wallyworld_> if you are looking at a mp i just posted, i'm fixing a few other things
[03:14] <axw> yeah I am
[03:14] <wallyworld_> i can add a new attr
[03:14] <wallyworld_> Path is only used internally
[03:14] <wallyworld_> outside of simplestreams, the Tools struct is used
[03:15] <axw> I'll keep looking, it's probably okay if it doesn't escape
[03:17] <wallyworld_> i probably should add an absolute path for clarity, even if it is internal only
[03:20] <axw> wallyworld_: yeah, I think I'd prefer adding either a BaseURL or URL field
[03:21] <wallyworld_> can do if it aids clarity
[04:12] <bigjools> is the only was to pass config to a charm initial deployment via the --config directive?
[04:12] <bigjools> s/was/way/
[04:20] <wallyworld_> nfi
[04:21] <wallyworld_> bigjools: where does maas and azure keep a copy of the tool tarballs? or are they just downloaded from the shared s3 bucket?
[04:21] <bigjools> haha
[04:22] <bigjools> there's a public storage account for azure that only I know how to upload to
[04:22] <wallyworld_> which wget works with?
[04:22] <bigjools> yes
[04:22] <bigjools> maas doesn't have public tools AFAIK
[04:22] <wallyworld_> so s3?
[04:22] <bigjools> since it's not a public cloud
[04:22] <wallyworld_> or --upload-tools
[04:22] <bigjools> NFI whatever juju does
[04:23] <wallyworld_> s3 then, unless upload-tools is used
[04:23] <bigjools> I normally use --upload-tools
[04:24] <wallyworld_> bigjools:  does maas provider support unuathenticated access to files in its storage using the Storage.URL() method?
[04:24] <bigjools> it used to but not any more
[04:24] <wallyworld_> yes, looks like it
[04:24] <wallyworld_> oh?
[04:24] <wallyworld_> code seems to be there
[04:24] <bigjools> it's a security hole
[04:25] <bigjools> I think we still need to fix it :)
[04:25] <wallyworld_> hmmm. amazon supports it
[04:25] <bigjools> maas is not amazon
[04:26] <bigjools> maas has a backward compatibility mode for unauth access IIRC
[04:26] <bigjools> jtv1: can you remember the details for this?
[04:26]  * wallyworld_ is sad that our key interfaces that all providers are supposed to implement are not universally supported
[04:26] <wallyworld_> which means interface design is wrong
[04:27] <bigjools> yeah
[04:27] <bigjools> very hard to get right though
[04:27] <jtv1> bigjools: for storage?  Do you mean the anon URLs?
[04:27] <bigjools> jtv1: yes
[04:28] <jtv1> Oh, and we had the weirdness with the transition between single-tenant and multi-tenant storage, didn't we?
[04:28] <bigjools> jtv1: I recall that rvb stuffed in some egregious hack
[04:28] <bigjools> yes exactly that
[04:28]  * jtv looks
[04:30] <jtv> There's FileStorage.anon_resource_uri...  it evaluates to a URL where the file can be retrieved anonymously.  To keep the file secret, keep the URL secret.
[04:30] <wallyworld_> but that is deprecated?
[04:31] <jtv> Doesn't say so in the source...
[04:31] <wallyworld_> bigjools seemed to think it may be going away?
[04:31] <jtv> Key-based access.  That was the way we dealt with this.  You pass the file's key to get its anonymous URL.
[04:32] <jtv> There were two related issues.  One was legacy files from the single-tenant era, which have no owner.  The other is anonymous access.
[04:32] <jtv> Ownerless files should go away.  I don't know if we'll ever fully be rid of the code, but we should at least keep up the pretense.
[04:33] <wallyworld_> sounds like i shouldn't count on anon access
[04:33] <jtv> Key-based anonymous access was meant to last, as I remember it.
[04:35] <wallyworld_> ok
[04:36] <bigjools> I think this hack was put in to make juju work
[04:36] <bigjools> if memory serves (which it doesn't much these days)
[04:37] <bigjools> thumper: if I want to pass a chunk of data to a charm, what's the best way?
[04:37] <bigjools> a huge ugly piece of yaml?
[04:37]  * thumper shrugs
[04:37] <thumper> how about base64 encoded bson?
[04:38]  * thumper ducks
[04:38] <bigjools> well it's an ssh private key so it's already encoded
[04:38] <thumper> in all honesty though, NFI
[04:38] <bigjools> but it's just unwieldy in a charm config
[04:38] <bigjools> I was hoping there might be a config that says "throw the contents of this file at the charm"
[04:39] <thumper> sometimes I'm amazed at peoples ability to accept so much boilerplate and copy and paste in tests
[04:39]  * thumper refactors
[04:39] <bigjools> :(
[04:40]  * thumper headdesks
[04:40] <thumper> it is worse than I thought
[04:40]  * thumper umms
[04:40] <thumper> to fix it all now, or to make others do it...
[04:41] <thumper> fuck it
[04:41]  * thumper fixes
[04:41]  * thumper chooses appropriate music
[04:41] <bigjools> Ugly Kid Joe? :)
[04:41] <thumper> Device will do
[04:41] <thumper> heh first track is "You Think You Know"
[04:41] <thumper> second is "Penance" followed by "Vilify"
[04:44]  * bigjools discovers multiline config in yaml
[04:47] <wallyworld_> thumper: it's not just tests - the !#^^!@! boilerplate is everywhere. it seems to be the Go way :-(
[04:48] <jtv> Not just Go.  We used to do it in Launchpad as well.  I think cultural isolation has also been contributing to the repetition of mistakes.
[04:49] <jtv> Although Go _is_ the first language where I've seen "we'd rather repeat code to minimize dependencies" stated as policy.
[04:52] <wallyworld_> yep :-(
[04:54] <bigjools> so thumper, I can't ctrl-c out of juju debug-log
[04:54] <bigjools> nor, worryingly, ctrl-z
[04:54] <bigjools> vartdafark?
[04:55] <jtv> Isn't that the "suspend" signal?
[04:55] <bigjools> yes
[04:55] <bigjools> I very rarely see it fail to suspend a shell job
[04:55] <jtv> Quite.
[04:56] <bigjools> only special things like ssh catch it and redirect
[04:56]  * bigjools files a bug
[04:59]  * thumper sighs
[04:59] <thumper> bigjools: I ctrl-C'ed out of debug-log before
[05:00] <bigjools> it's consistent for me
[05:00] <bigjools> each new env
[05:02] <thumper> I've got a brain dead review for someone
[05:02] <jtv> I'll take it.
[05:02] <jtv> Appropriately.,
[05:02]  * thumper is waiting on damn lbox
[05:02] <jtv> It's already on Launchpad.
[05:02] <thumper> so many of these songs are appropriate for hacking/refactoring
[05:02] <thumper> War of Lies
[05:02] <thumper> Opinion
[05:03] <thumper> Haze
[05:03] <thumper> Through it all
[05:03] <thumper> Out of Line
[05:03] <thumper> ah fark... still waiting
[05:03]  * thumper twiddles thumbs
[05:04]  * thumper hands jtv the lp review
[05:04] <thumper> https://code.launchpad.net/~thumper/juju-core/open-api-as-new-machine/+merge/184012
[05:04] <thumper> \
[05:04] <thumper> lbox still isn't done
[05:05] <jtv> Argh.  Somebody has to stop this "while we're here, let's change the gocheck import" insanity.
[05:05] <thumper> sorry
[05:05] <thumper> eventually it'll all be done
[05:06] <jtv> Not at this rate.  Birthday paradox.
[05:06] <thumper> we aren't adding more
[05:06] <thumper> so eventually we'll fix it
[05:06] <thumper> oh reitveld is finally done
[05:06] <jtv> A new change will come along before it's done.
[05:06]  * thumper ignores it
[05:08] <thumper> jtv: I was busy copying tests, as you do, and I saw this setup step. I thought "hey I'd like to use that, I'll factor it out"
[05:08] <thumper> then I saw the function in the ConnTestSuite
[05:08] <thumper> and thought who is using that
[05:08] <thumper> low and behold, lots of duplicate code
[05:08] <jtv> thumper: what does "creates a new machine in state" mean?
[05:08] <thumper> so create a function that does what you actually care about
[05:09] <thumper> state is the "state of the system" duh, obvious isn't it?
[05:09] <thumper> that was the answer I got when I first asked
[05:09] <thumper> and since the package and main variable is called state
[05:09] <jtv> I see the duplication in the diff...  awesome.  You get the coveted Negative Lines Of Code productivity rating.
[05:09] <thumper> I'm passing it on
[05:10] <thumper> 10 files changed, 58 insertions(+), 134 deletions(-)
[05:10] <jtv> So... we don't know what it means and nobody will explain?
[05:10] <thumper> I can explain
[05:10] <thumper> adding a machine to state is like adding a machine row in a db table
[05:10] <thumper> except we don't have tables
[05:10] <thumper> or a row in the machine table
[05:11] <thumper> but we aren't using a relational database for our relational data
[05:11] <thumper> because mongo has legs
[05:11] <jtv> So "create a machine in state" is not the same as "create a machine that lies in state"?
[05:11]  * thumper leaves off the sarcasterisc
[05:11] <thumper> the whole codebase lies
[05:11] <thumper> but that isn't what you mean
[05:11] <jtv> I don't know what I mean any more.  :)
[05:12] <thumper> I'd rather say "lives in state"
[05:12] <thumper> you ok with that?
[05:12] <jtv> But if "state" is the global, general, universal state of everything, why bother saying it in the first place?
[05:12] <thumper> / OpenAPIAsNewMachine creates a new machine entry that lives in system state, and
[05:12] <thumper> / then uses that to open the API.
[05:13] <thumper> could just say "create a new machine and use that..."
[05:13] <jtv> Definitely clearer.
[05:13] <jtv> Either is fine by me.
[05:13] <thumper> do you perfer more verbose
[05:13] <thumper> I'll leave it with what I have
[05:14] <thumper> new revision pushed
[05:14] <thumper> jtv: and the diff will update automagically \o/
[05:14] <jtv> "s.st"...  the thing about cratily si ahtt si't leasiy ostl.
[05:14]  * thumper agrees
[05:14] <thumper> I HATE it
[05:14] <thumper> and if I could you bold, 24 point, I would
[05:15] <thumper> using psychologically damaging RED
[05:15]  * jtv starts looking for the Health & Safety manual
[05:15]  * thumper waits for jtv to click approve
[05:16] <jtv> Mind if I just review the Launchpad proposal?
[05:16] <thumper> not at all
[05:18] <jtv> Done.
[05:18] <thumper> thanks
[05:18]  * thumper ducks out for a while
[05:18] <jtv> For the maas & azure providers, I just went in and applied the new import rules throughout.  Not a lot of work, and then it's over with.
[05:35] <bigjools> is there any way I can force a service to re-install so I can debug its install hook?
[05:39] <jpds> bigjools: juju resolved --retry service
[05:40] <bigjools> aha
[05:40] <bigjools> thanks
[05:40] <bigjools> jpds: error: unit "tarmac/0" is not in an error state
[05:41] <jpds> bigjools: Ah, so; destroy-service and redeploy ?
[05:41] <bigjools> jpds: won't the debug hook disconnect?
[05:42] <jpds> I would debug-log at that point.
[05:42] <bigjools> it's a bit of a race getting that in place before the install hook runs and I lose
[05:42] <bigjools> yes, I am going to have to debug-log :(
[05:42] <bigjools> or perhaps force an error so I can use resolved
[05:42] <jpds> bigjools: juju ssh into the box, and look at the log in /var/log/juju/ ?
[05:43] <bigjools> yeah I am doing that but I need to work out why a command isn't doing what I expect
[05:44] <jpds> One thing I can think of its juju add-machine; wait for the agent to come up then deploy --to=machine.
[05:44] <bigjools> could work
[05:44] <bigjools> but debug-hooks needs a service unit which is not there yet
[05:52] <bigjools> jpds: ah that worked!
[06:02] <jpds> bigjools: Brilliant.
[06:20] <bradm> is it a bad idea to try opening and closing ports in a juju charm by calling /usr/bin/close-port or /usr/bin/open-port ?  that means you need juju installed on the units, right?
[06:39] <wallyworld_> bradm: i don't know, but i'll ask later when some more people come online and find out
[06:41] <bradm> wallyworld_: pretty sure the problem is that squid-reverseproxy is hard coded to call /usr/bin/close-port, when its moved into  /var/lib/juju/tools somewhere
[06:41] <wallyworld_> yeah i thought close-port was py-juju, but not sure
[06:42] <bradm> /var/lib/juju/tools/1.13.3-precise-amd64/close-port exists on the node
[06:42] <bradm> so I'm guessing removing the path might help
[06:42] <wallyworld_> on the units, jujud is installed automatically, via the tools tarball
[06:42] <wallyworld_> that path above indicates it's symlinked to jujud
[06:42] <wallyworld_> and comes from the tools tarball
[06:43] <bradm> oh, interesting
[07:11] <bradm> ok, I submitted a fix for the squid-reverseproxy thing, its a really trivial patch
[07:11] <bigjools> damn, this juju stuff works!
[07:54] <wallyworld_> fwereade: i'd love a design chat, maybe in an hour or so after dinner?
[07:56] <fwereade> wallyworld_, sgtm
[07:56] <fwereade> wallyworld_, I'm actually doing your review now fwiw
[07:56] <fwereade> wallyworld_, sorry for the delay
[08:01] <wallyworld_> fwereade: np. i want to move the new interfaces. the HasConfig one to environ.config. The other oe elsewhere
[08:02] <wallyworld_> i only put them in environs/interfaces.go because that was a stated preference but one i do't agree with
[09:06] <mattyw> is someone able to anwer a quick api question? When I send the json to deploy a service with CharmURL: cs:precise/wordpress I get the error "charm url must include revision". What's the correct way of getting it to deploy the latest version of a charm? I thought you used to be able to do that?
[09:08] <dimitern> mattyw: this sounds like a bug in the api deploy command
[09:09] <mattyw> dimitern, there's code in client/client.go:135 to do it
[09:09]  * dimitern is looking
[09:11] <dimitern> mattyw: well, by definition rev == -1 means "latest"
[09:11] <dimitern> mattyw: and it's the default if not set I think
[09:12] <mattyw> dimitern, looking at parseURL it looks like the default is -1 yeah
[09:12] <mattyw> dimitern, shall I file a bug?
[09:14] <dimitern> mattyw: actually looking at the commit log, this changed in rev 1262 by fwereade
[09:15] <fwereade> damn, what did I do?
[09:15] <dimitern> mattyw: there's an explicit test for "cs:precise/wordpress" -> "must include revision"
[09:15] <fwereade> dimitern, mattyw: ah right
[09:15] <fwereade> dimitern, mattyw: the GUI already has access to the charm store, and the charm store will tell you the latest revision of a given charm
[09:16] <dimitern> fwereade: I knew there was more to it :)
[09:16] <fwereade> dimitern, mattyw: and in fact the gui is necessarily using a particular version, with a specific readme, and specific config settings and metadata
[09:17] <fwereade> dimitern, mattyw: so my position is that the gui should be knowably deploying exactly that version, rather than opening ourselves up to rare and surprising confusion in which you deploy charm X with config Y and are told that it doesn't actually work
[09:17] <fwereade> mattyw, does this break something you need?
[09:18] <mattyw> fwereade, dimitern ok understood, but doesn't make the api harder to use if you aren't the gui?
[09:18] <mattyw> fwereade, nothing important, I'm just playing with a few side projects
[09:18] <mattyw> fwereade, I was playing with writing a client in elixir
[09:18] <wallyworld_> fwereade: are you free for a quick chat?
[09:20] <fwereade> mattyw, sorry for the inconvenience -- hopefully the charm store api is itself not too painful to use, though?
[09:20] <mattyw> fwereade, it's no problem at all! :). where can I find the charm store api?
[09:21] <dimitern> fwereade: there it is https://codereview.appspot.com/13559043 - RUW completed
[09:21] <fwereade> wallyworld_, yeah, sgtm, but I may eat at you for some of it
[09:21] <fwereade> dimitern, sweet, I'll look as soon as I can
[09:21] <fwereade> mattyw, er, let me look around a mo
[09:21] <wallyworld_> np. https://plus.google.com/hangouts/_/ff292c4c07ae7359f6cd87925661e2868636a3bd
[09:23] <wallyworld_> fwereade: ^^^^^  if you are busy we cs\n do it
[09:23] <wallyworld_> betweem the meetings
[09:32] <dimitern> fwereade: btw I tested with debug hooks and the steps you suggested - it all works fine
[09:37] <fwereade> dimitern, <3
[09:38] <fwereade> mattyw, it looks pretty weak, but there's this: https://juju-docs.readthedocs.org/en/latest/internals/charm-store.html#upgrades
[09:38] <fwereade> mattyw, I'm not actually sure what the original source of that was
[09:39] <fwereade> mattyw, presumably the internals/ docs in pyjuju
[09:39] <fwereade> mattyw, but it should still be accurate, because it's talking about the exact same charm store
[09:39] <fwereade> mattyw, it's pretty narrow but it *will* tell you the latest versions :)
[09:40] <mattyw> fwereade, ok thanks, I'll have a play around and see what I can come up with, thanks a lot for your help
[09:41] <fwereade> mattyw, cheers, always a pleasure
[09:41] <fwereade> mmm, leftover pistachio pizza
[09:49] <dimitern> :)
[10:02] <thumper> mgz: meeting ping
[10:13] <dimitern> fwereade: so how about that review?
[10:14] <fwereade> dimitern, better finish ian's first
[10:14] <dimitern> fwereade: ah, ok
[10:14] <natefinch> so, is manual provider available in trunk now?  I thought I saw something about that
[10:18] <mgz> it's on trunk, but needs some more work, see the thread in response to the last release announcement
[10:35] <yolanda> hi, i need to send static contents like images on a charm, is that possible in some way?
[10:36] <mgz> yolanda: yes, more details on exactly what? base64 and yaml into config or a relation works fine, for instance
[10:37] <yolanda> mgz, i have a gerrit charm and i'd like to have some way to configure look&feel
[10:37] <yolanda> it includes sending html and css files, but also some images if needed
[10:37] <yolanda> such as a canonical logo or whatever
[10:45] <yolanda> mgz, i used that to send some contents but not sure if that will work for a list of images, we need to upload image content and image name
[10:49] <mgz> yolanda: it could work, but may be rather ugly (eg, list of key-value path/base64 contents would be fine)
[10:50] <mgz> I wonder if other charms have similar use cases, and what they've done? for instance I know jenkins and horizon allow of front end customisation
[10:50] <yolanda>  mgz, i'll take a look at those then
[10:51] <mgz> yolanda: maybe look at one of those, or poke james or adam for suggestions?
[10:51] <yolanda> mgz, i'm sending some values to charm with base64 encoding, but for a defined field, not a list, so looked ugly to me
[11:03] <fwereade> yolanda, mgz: sending a readable reference to a place to get the files would be rather nicer, really
[11:04] <fwereade> yolanda, mgz: ideally humans looking at how you've configured your charm ought to be able to derive some sort of meaning from it directly
[11:05] <dimitern> fwereade: so i saw ian's review's done :)
[11:05] <fwereade> dimitern, yeah, a meeting is happening... I will try to multitask it :)
[11:06] <yolanda> fwereade, so what do you suggest, maybe point to some directory where to upload all the images?
[11:06] <mgz> fwereade: where though? we don't really give charms access points into filestore, or provide tools to stick stuff in there
[11:07] <fwereade> yolanda, mgz: IIRC wordpress lets you set a repo url for that sort of thing
[11:07] <fwereade> yolanda, mgz: it is true we don't provide tools to help directly
[11:07] <dimitern> fwereade: thanks, no rush, just poking
[11:07] <mgz> hm, I guess a seperate versioned branch does make some sense
[11:30] <yolanda> mgz, fwereade, i really like the wordpress approach, but what do you do in case of deployments that don't allow to get content from external sources? you just first copy it locally?
[11:31] <mgz> yolanda: you'd need a branch that your cloud could access, yeah
[11:31] <yolanda> mgz, so setting that on a launchpad branch sounds good
[11:31] <yolanda> it's a clean approach
[11:33] <mgz> all, are we doing standup today, or just going on to the new time tomorrow?
[11:33] <TheMue> mgz: as i understood jam we'll continue tomorrow with the new time
[11:34] <natefinch> mgz: yeah, my understanding as well
[11:34] <TheMue> mgz: the calendar shows no more standups on thursday with the change of the meeting time
[11:35] <mgz> okay, shall code onwardst then
[13:02] <dimitern> fwereade: still meeting?
[13:02] <fwereade> nah, I'm actually doing your review :)
[13:02] <dimitern> cheers :)
[13:06] <fwereade> dimitern, LGTM
[13:07] <dimitern> fwereade: thanks!
[13:16] <sidnei> uhm, anyone interested in upgrade bugs? im trying to do upgrade-juju from ~1.15.0.1 to ~1.15.0.2 and it's stuck in a restart loop
[13:18]  * TheMue => late lunch
[13:20] <fwereade> sidnei, I'm interested
[13:20] <dimitern> sidnei: are you upgrading from a release to a trunk version?
[13:21] <fwereade> sidnei, are these just your own changes between, or did you merge in as well?
[13:21] <sidnei> dimitern: both are from source, not from release, but the version number differs
[13:22] <dimitern> sidnei: you did go install . in cmd/juju and cmd/jujud before trying --upload-tools, right?
[13:22] <sidnei> dimitern: nope, only go install launchpad.net/juju-core/...
[13:23] <dimitern> sidnei: well, there's that thing - if you use --upload-tools from source, you should always do these two install steps, otherwise you'll get older binaries
[13:23] <dimitern> sidnei: pretending to be newer version
[13:24] <sidnei> dimitern: ok. still didn't solve the issue anyway.
[13:25] <dimitern> sidnei: np, just wanted to make sure that's out of the way
[13:25] <dimitern> sidnei: then it seems there's a bug
[13:26] <sidnei> dimitern, fwereade: http://paste.ubuntu.com/6066470/
[13:30] <fwereade> sidnei, ah, hell, that looks like https://bugs.launchpad.net/juju-core/+bug/1214676
[13:30] <_mup_> Bug #1214676: upgrade-juju in local environment causes bootstrap machine agent to restart continuously <juju-core:Triaged> <https://launchpad.net/bugs/1214676>
[13:35] <sidnei> indeed
[13:43] <natefinch> jam, fwereade, etc: You guys have anything they think I should be working on? I'm kinda out of stuff. I could look at bugs, but not sure if there's something more appropriate
[13:43] <fwereade> natefinch, oddly enough, that upgrade that sidnei just pointed out above is a pretty big deal
[13:43] <natefinch> fwereade: I'd be happy to look at it
[13:43] <fwereade> natefinch, I was just thinking "gaah who will look at that"
[13:43] <fwereade> natefinch, <3
[13:45] <mgz> :)
[13:48] <dimitern> fwereade: if I have a suite A that embeds another suite B, do I need to define A.SetUpTest, just so it will call B.SetUpTest ?
[13:49] <dimitern> fwereade: provided that's the only thing A.SetUpTest has to do?
[13:56] <fwereade> dimitern, it *will* but it's prone to accidental screwing-up so we prefer to be explicit
[13:56] <mgz> gah, editor lag meant my change didn't get in that file? why did I not look at the diff again before landing...
[13:57] <dimitern> fwereade: ah, ok - it seems to work both ways, but I too prefer to be explicit
[13:58] <sidnei> fwereade: https://bugs.launchpad.net/juju-core/+bug/1190985 is another one I'd love if you could prioritize
[13:58] <_mup_> Bug #1190985: Confusing upgrade-charm and deploy -u behavior <juju-core:Triaged> <https://launchpad.net/bugs/1190985>
[14:03] <fwereade> sidnei, ha, yes, that is an ugly one
[14:12] <dimitern> a quick, trivial review anyone? https://codereview.appspot.com/13561043
[14:12] <mgz> dimitern: can I have a rubber stamp on cl 13562043
[14:12] <mgz> swap you :)
[14:12] <dimitern> mgz: sure
[14:12] <mgz> was typing before you asked :)
[14:13] <dimitern> mgz: stamped! :)
[14:16] <mgz> hm, same // Note in both new files, and some other dup still, but not a bad +484/-434 considering it's much clearer overall
[14:16] <mgz> lgtmed.
[14:19] <dimitern> thanks
[14:19] <dimitern> will fix the note
[14:19] <dimitern> what other dup?
[14:20] <mgz> I think the note is correct, it's just... odd having the same long comment in two different tests in different files
[14:22] <dimitern> ah, the watcher note, yeah
[14:23] <mgz> the dup is mostly just that every action takes three lines
[14:24] <mgz> create something; assert err is nil, assert actual assertion... and several tests have three or more actions before they get to what they actually are about
[14:25] <natefinch> mgz: sounds like we need a checker that takes err, realValue and does that for us
[14:25] <mgz> hm, actually, some of these later tests just create a unit then check the error, and don't also assert Life() is alive
[14:26] <dimitern> well, the unit is alive
[14:26] <dimitern> it's created every time
[14:26] <dimitern> only in refresh and life tests it's explicity asserted over
[14:26] <mgz> right, so maybe that check is actually redundant in the earlier tests (if we get there and the thing isn't alive, we have bigger problems other tests would break on)
[14:29] <fwereade> oh, hell, I have to look at houses again in a few minutes, and it's the cross-team call imminently
[14:29] <mgz> there doesn't seem to be much easy reduction to do though, the tests are just verbose
[14:29] <fwereade> can I deputise someone to attend and let them know what we're up to please?
[14:29] <mgz> fwereade: I could cross-team is there anything particular you wanted to saY?
[14:29] <fwereade> mgz, not really
[14:30] <mgz> have fun looking at houses :)
[14:30] <fwereade> mgz, oh, I am
[14:30] <fwereade> mgz, this week is so much better than normal weeks ;p
[14:31]  * fwereade shouldn't grumble
[14:32] <natefinch> fwereade: if we didn't grumble, how would anyone know we're programmers? :)
[14:34] <fwereade> haha :)
[14:38] <natefinch> am I supposed to be able to SSH into the lxc container with juju ssh 0?  I get connection refused
[14:41] <mgz> natefinch: with lxc, you ssh into the units, not the machines
[14:41] <natefinch> mgz: ahh, ok
[14:42] <natefinch> mgz: I'm guessing this is probably bad: agent-state-info: '(error: container "nate-local-machine-1" is already created)'
[14:43] <mgz> that does seem bad, but you may be able to straight resolve it
[14:43] <natefinch> mgz: I had been diddling with local provider a while back... maybe some  cruft left over
[15:12]  * natefinch is ramping up his lxc-fu
[15:14] <mgz> all the way to lxc-fuuuuu
[15:14] <natefinch> rofl.... exactly
[15:14] <natefinch> I think that's a short ramp
[15:16] <TheMue> natefinch: tell me about your installation experiences so that i can possibly change the docs (if i have)
[15:17] <TheMue> natefinch: here it worked, but we today already have seen troubles with the firewall, so i changed the doc (it's proposed)
[15:17] <natefinch> TheMue: the biggest problem I had was that my go installation was local to my normal account, so when I do sudo juju bootstrap, it couldn't find the go executable
[15:19] <natefinch> (so it could build jujud)
[15:46] <TheMue> natefinch: so, back again, had a talk with robbiew
[15:48] <TheMue> natefinch: yep, doing it as a juju developer is different, the docs are for users on a clean system. but i'll talk to the others about adding a kind of box "local provider for juju contributors"
[16:01] <mgz> TheMue: did robbiew poke you, or did you just join the call?
[16:02] <robbiew> mgz: I'll join..running late
[16:02] <mgz> robbiew: no problem, just wanted to make sure I was in the right place :)
[16:03]  * mgz proposes merge in the meantime
[16:19] <TheMue> mgz: had my 1:1