[00:02] <lazypower> Is this bit just some spam or have i encountered a bug? http://paste.ubuntu.com/13118294/
[00:02] <davechen1y> lazypower: yeah, that's not an awesome message
[00:02] <davechen1y> it doesn't give a hint _why_ the dependency is unavailable
[00:03] <davechen1y> ie, should you wait, or should you declare defcon 4
[00:04] <lazypower> I just noticed that i dont have a leader in the service pool. Possibly related?
[00:06] <davechen1y> almost certainly
[00:06] <davechen1y> but that log message is shit
[00:06] <davechen1y> please log a bug
[00:19] <mup> Bug #1513667 opened: Better error messaging around uniter failure <juju-core:New> <https://launchpad.net/bugs/1513667>
[00:22] <mup> Bug #1513667 changed: Better error messaging around uniter failure <juju-core:New> <https://launchpad.net/bugs/1513667>
[00:25] <mup> Bug #1513667 opened: Better error messaging around uniter failure <juju-core:New> <https://launchpad.net/bugs/1513667>
[00:40] <mup> Bug #1513671 opened: juju bootstrap fails <local-provider> <network> <wily> <juju-core:New> <https://launchpad.net/bugs/1513671>
[00:43] <mup> Bug #1513671 changed: juju bootstrap fails <local-provider> <network> <wily> <juju-core:New> <https://launchpad.net/bugs/1513671>
[00:46] <mup> Bug #1513671 opened: juju bootstrap fails <local-provider> <network> <wily> <juju-core:New> <https://launchpad.net/bugs/1513671>
[01:20] <menn0> thumper: phew. here's the machine agent symlink improvements: http://reviews.vapour.ws/r/3082/
[01:21] <thumper> m'kay
[01:21] <menn0> this makes setting the symlink for juju-dumplogs a piece of cake
[01:21] <thumper> just going through the rename branch suggestions you had
[01:24] <thumper> menn0: http://reviews.vapour.ws/r/3072/
[01:24]  * menn0 looks
[01:29] <thumper> menn0: shipit
[01:30] <menn0> thumper: thanks
[01:30] <thumper> np
[01:38] <menn0> thumper: ship it with a bunch more things to change
[02:03]  * thumper sighs
[02:03] <thumper> oh FFS
[02:03] <thumper> I feel that this is never ending
[02:04]  * thumper looks for a knife so he can finish it all...
[02:14] <natefinch> thumper: have you looked at using gorename?  It won't find things to rename, but it should type-safely rename all copies of type/method/etc
[02:15] <thumper> natefinch: that isn't the problem...
[02:15] <thumper> there are many methods with System in the name
[02:15] <thumper> system in docs
[02:15] <thumper> help docs
[02:15] <thumper> variable names
[02:15] <thumper> spewed everywhere
[02:15] <thumper> environment rename will be worse
[02:21] <davechen1y> thumper: tried the vpn
[02:21] <davechen1y> no job
[02:21] <davechen1y> joy
[02:21] <davechen1y> see email, i'm waitin on the ibm contact to fix
[02:21] <thumper> davechen1y: did you try using the name rather than the ip address?
[02:22] <thumper> I think that was in the email thread
[02:25] <davechen1y> i'm using the openconnect strink that popey used
[02:25] <davechen1y> i have no problem conneting to the service
[02:26] <davechen1y> but my credientials expired 5/11/2015
[02:26] <davechen1y> i don't know which timezone that is
[02:26] <davechen1y> but they need to be refreshed and I cannot do that because the interface to do so is behind the vpn
[02:38] <thumper> hazaah
[02:38] <thumper> magical
[02:39]  * thumper goes back to smashing his head against the table
[02:47]  * thumper sadface
[02:47] <thumper> just came across another intermittent failure in worker/provisioner
[02:47] <davechen1y> thumper: would you care for a break and a chat about the various charm.* types in state ?
[02:48] <menn0> thumper: juju-dumplogs work is done: http://reviews.vapour.ws/r/3075/diff/#
[02:48] <thumper> sure, two minutes
[02:48] <menn0> this is what you've reviewed + the symlink stuff
[02:48] <menn0> no rush
[02:48] <natefinch> thumper: what's the error you're seeing?  I was getting a weird error in provisioner earlier today
[02:49] <natefinch> thumper: http://pastebin.ubuntu.com/13115387/
[02:49] <thumper> nope, http://paste.ubuntu.com/13121047/
[02:49] <natefinch> hmm
[02:52] <thumper> davechen1y: 1:1 hangout
[02:52] <davechen1y> thumper: yup
[02:52] <davechen1y> just getting my other laptop
[02:54] <davechen1y>         return insertAnyCharmOps(&charmDoc{
[02:54] <davechen1y>                 DocID:        curl.String(),
[02:54] <davechen1y>                 URL:          curl,
[03:10] <davechen1y> thumper: oh oh, maybe reflect.DeepEqual will do all the magic we need
[03:10] <davechen1y> gonna run some test
[03:10] <davechen1y> gonna run some tests
[03:11]  * thumper feels sad
[03:11] <thumper> we have a method ConnectStream that takes a path and attrs
[03:11] <thumper> and every single test passes nil for the attrs
[03:13] <cherylj> wallyworld: ping?
[03:14] <davechen1y> thumper: if that parameter is 99% unused, especially in the default case
[03:14] <davechen1y> it should be removed
[03:14] <davechen1y> and a second method added for the case that needs the second parameter
[03:14] <thumper> no, real use passes it in
[03:14] <thumper> but our tests don't test
[03:15] <davechen1y> where is the emoji for jaw hitting table
[03:25] <thumper> menn0: looks like I'm implementing the juju/api and apiserver bits for NoTail for debug log just to get the freaking tests passing...
[03:26] <menn0> thumper: well that takes care of the that bug 1390585 then  :)
[03:26] <mup> Bug #1390585: juju debug-log and EOF <debug-log> <landscape> <juju-core:Triaged by menno.smits> <https://launchpad.net/bugs/1390585>
[03:26]  * menn0 assigned the card to thumper and moves it to "in progress" :-p
[03:26] <thumper> \o/
[03:32] <davechen1y> thumper: I have 7 version of juju/charm in my GOPATH
[03:32] <davechen1y> 4 released, 3 unreleased
[03:32] <thumper> \o/
[03:32] <davechen1y> this scares the piss out of me
[03:33] <davechen1y> how did we not manage to insert invalid data into mongo ?
[03:41] <natefinch> did something change with how machine numbers are assigned?  I seem to be getting machine 0, 1, 3, 8 (+-1) instead of reliably 0 1 2 3 4
[03:41] <davechen1y> natefinch: yes, they are now assigned exponentially
[03:41] <menn0> natefinch: didn't you change something in this area recently?
[03:42] <natefinch> menn0: yeah, the unit assignment now runs on a worker... but in theory that shouldn't have changed how the machine  numbers are assigned.  That code is the same, it's just getting run slightly later.
[03:42] <menn0> natefinch: granted, but given the locality of the change...
[03:43] <natefinch> menn0: oh sure, my first assumption was that it was my fault :)
[03:43] <menn0> :0
[03:43] <menn0> :) even
[03:46]  * thumper chucks it in for the week
[03:46] <thumper> laters
[04:21] <natefinch> well crap, I suppose I should just revert my unit assigner merge until such a time as I can fix these bugs....
[04:36] <natefinch> gah, what the hell is the magic incantation to tell CI that I'm trying to merge the fix to the blocker?
[04:38] <natefinch> sinzui: don't suppose you're around?
[04:43] <natefinch> wallyworld: you around?
[04:43] <natefinch> or menn0 ?
[04:43] <wallyworld> maybe :-)
[04:44] <natefinch> how the hell do I mark my PR as fixing the blocking bug?
[04:44] <wallyworld> zup?
[04:44] <menn0> natefinch: $$fixes-NNNNNN$$
[04:44] <wallyworld> $$fixes-12345$$
[04:44] <menn0> ha :)
[04:44] <natefinch> I friggin' have that in my first comment...
[04:44] <wallyworld> which pr?
[04:44] <natefinch> https://github.com/juju/juju/pull/3679
[04:45] <wallyworld> it needs to go in the merge command
[04:45] <wallyworld> not the cover description
[04:45] <menn0> actually, I don't think it has to be in the merge command
[04:45] <wallyworld> sure?
[04:45] <menn0> but it has to be in a comment, not the description
[04:46] <wallyworld> yup
[04:46] <natefinch> dumb
[04:46] <wallyworld> that's what i meant
[04:46] <menn0> yeah, i'm pretty sure you can do fixes-NNNNNNN in one comment and then separately do $$merge$$ later
[04:46] <menn0> $$fixes-NNNNNN$$ is just the most convenient way to do it
[04:49] <natefinch> it would be nice if the error message more clearly indicated how to fix the problem.
[04:51] <natefinch> (and if we checked the description as well :/)
[04:52] <wallyworld> natefinch: Build failed: Does not match ['fixes-1513552']   is not clear enough?
[04:53] <natefinch> wallyworld: no.  It doesn't say how to get the PR to merge. It says something does not match something else.  There's zero context.
[04:53] <wallyworld> there is a tiny bit of assumed knoweldge there
[04:54] <natefinch> It only takes 30 seconds to write a better error message to avoid confusion.  For example, it could say that the string 'fixes-NNN' must be in a comment, not the description.
[04:55] <menn0> natefinch: suggest it to mgz_ and it might happehn
[04:56] <natefinch> Target branch is blocked by a critical bug (http://pad.lv/NNNNN).  If this PR would fix that bug, include the string 'fixes-nnnn' in a comment (not the description) on this PR, before using $$merge$$.
[04:57] <natefinch> menn0: will do
[05:09] <natefinch> davechen1y: what is this, java? https://github.com/juju/juju/blob/master/state/unit.go#L739
[05:11] <natefinch> davechen1y: related: https://github.com/juju/juju/blob/master/apiserver/client/status.go#L660
[07:57] <frobware> j
[08:18] <davechen1y> natefinch, nailed it
[09:51] <rogpeppe1> wallyworld: ping
[09:59] <voidspace> dimitern: frobware: grabbing coffee, be three minutes
[10:00] <dimitern> omw as well
[10:07] <voidspace> omw
[10:08] <voidspace> dimitern: frobware: gah, firefox misbehaving - having to restart browser
[10:44] <perrito666> wallyworld: still here?
[11:48] <wallyworld> perrito666: hey
[12:46] <wallyworld> rogpeppe1: hi, you rang?
[12:46] <rogpeppe1> wallyworld: hiya
[12:47] <rogpeppe1> wallyworld: yeah, i just discovered that a PR of yours (that I reviewed!) broke stuff, and just wanted to check that you thought the fix was ok: https://github.com/juju/charm/pull/167
[12:47] <wallyworld> oh no, looking
[12:48] <wallyworld> rogpeppe: seriously? I mesed up capitisation?
[12:48] <wallyworld> sigh
[12:48] <rogpeppe> wallyworld: np
[12:48] <rogpeppe> wallyworld: easy to do
[12:48] <wallyworld> ty for fixing
[12:49] <wallyworld> rogpeppe: i'll update the dep for core on monday
[12:50] <rogpeppe> wallyworld: FWIW i recently started on a tool for automatic API compatibility checking. i'll try and move it forward - it would've helped here i think: https://github.com/rogpeppe/apicompat
[12:50] <wallyworld> oh, sounds nice, i'll look
[12:51] <rogpeppe> wallyworld: (that's just a one day spike to see if it was viable so no tests or docs...)
[12:51] <wallyworld> sure :-)
[12:52] <wallyworld> rogpeppe: too tired to look properly now, but on my todo list
[12:54] <rogpeppe> wallyworld: the basic idea is that you write out type info on all the types you're interested in (e.g. all the types that have been serialised/deserialised) to a file; then later you can check that the types are still compatible with what you wrote before
[12:56] <wallyworld> ok
[13:21] <cherylj> frobware: looks like this old bug has now become part of a crit sit:  https://bugs.launchpad.net/juju-core/+bug/1382556
[13:21] <mup> Bug #1382556:  "cannot allocate memory" when running "juju run" <cpe-critsit> <run> <juju-core:Triaged> <https://launchpad.net/bugs/1382556>
[13:21] <cherylj> frobware: got anyone who can take a look?
[13:22] <cherylj> alexisb, fyi ^^
[13:24] <frobware> cherylj, I can take a look as my current bug has stalled (broken tests).
[13:26] <cherylj> thanks, frobware
[13:30] <dimitern> fwereade, hey, so it seems you got back online before me :)
[13:31] <fwereade> dimitern, haha, yeah
[14:28] <katco> frobware: hey
[14:28] <frobware> katco, what's up?
[14:28] <katco> frobware: can i move the cards from sapphire's kanban to moonstone's for those bugs?
[14:28] <frobware> katco, please do
[14:28] <katco> frobware: the ones that won't be finished anyway
[14:29] <katco> frobware: perfect, ty!
[14:29] <frobware> dooferlad, if you have chance today could you post links to your scripts for the HA bug, or better yet update the bug to reflect their location
[14:29] <katco> frobware: lol oops, looks like i don't have permissions
[14:29] <frobware> katco, ^^^
[14:30] <katco> frobware: dooferlad: yes, updating the bug would be perfect! ty for creating those
[14:31] <dooferlad> frobware: will do
[14:31] <frobware> katco, just updated your profile on kanban board, care to try again?
[14:32]  * katco attempting
[14:32] <katco> frobware: looks like it's working... ty
[14:38] <katco> frobware: am i blind? i can't seem to find more than 1 card for all those bugs
[14:39] <frobware> katco, did you move the HA card?
[14:39] <katco> frobware: yeah, that's the only one i could find
[14:40] <frobware> katco, I'm trying to remember whether they were there this morning (from planning) or they got nuked...
[14:41] <frobware> frobware, as I notice our archive has now been compressed to show 0 cards...
[14:41] <frobware> dimitern, ^^ did you do some cleanup in the kanban board?
[14:42] <katco> frobware: looks like there are some in the archive'd super-card
[14:43] <frobware> katco, I wouldn't dig through our trash - create a new card...
[14:43] <katco> frobware: haha ok
[14:45] <dimitern> frobware, nope, it automatically does that I think after 2 weeks
[14:46] <frobware> dimitern, eco friendly. :)
[14:47] <katco> dimitern: o/ looking forward to seeing you again in dec.
[14:49] <dimitern> katco, hey - yeah, it will be a change of pace for sure :)
[16:01] <mup> Bug #1513671 changed: juju bootstrap fails <local-provider> <network> <wily> <juju-core:Invalid> <https://launchpad.net/bugs/1513671>
[16:41] <natefinch> katco, ericsnow: that last 1 pointer is merging now... made the code review changes eric suggested and will do the IOC stuff in a separate PR.
[16:42] <ericsnow> natefinch: cool
[16:42] <katco> natefinch: but... but! i want to bikeshed more!
[16:54] <fwereade> katco, I am inspecting something that might be a bikeshed right now... trying to figure out whether it's actually a good idea to close watcher Changes chans when the watcher stops
[16:54] <katco> fwereade: ah i think i remember when that came up
[16:55] <fwereade> katco, because I *think* that it's an artifact of the lack of something-like-catacomb
[16:55] <katco> fwereade: wasn't the consensus that it's fine not to close it because the process would be torn down momentarily?
[16:55] <katco> lol
[16:55] <katco> something-like-catacomb
[16:55] <katco> hoenycomb?
[16:55] <katco> paris?
[16:56] <fwereade> katco, http://reviews.vapour.ws/r/3079/ ;p
[16:56] <fwereade> katco, so I think the forces are
[16:56] <katco> oh catacomb is actually a thing
[16:57] <fwereade> katco, when using a watcher you generally start it, defer a stop, and then select on changes forever
[16:57] <fwereade> katco, and so your only (heh) channel for notification of watcher problems is the changes chan
[16:58] <fwereade> katco, and closing it seems, eh, nice and idiomatic because then you could range over it, and it means "you're not getting any more values" so it seems to fit perfectly
[16:58] <fwereade> katco, and so we can make the select loop aware of problems
[16:58] <fwereade> katco, and then every select needs to check for that condition
[16:59] <fwereade> katco, and `if !ok { return watcher.EnsureErr(w) }`
[17:00] <katco> fwereade: this idea seems very good... reading through code
[17:00] <fwereade> katco, but I think the flaw is basically: just because you *can* use the changes chan for that notification does not mean you *shoul*
[17:01] <fwereade> katco, so, with something like catacomb, if you bind the watcher's lifetime to the containing worker's and the worker's life to the watcher's lack of failure
[17:01] <fwereade> katco, you'll get the something-is-wrong notifications direct to the Dying chan
[17:02] <fwereade> katco, and the worker's tomb will actually have been hit with (something much more likely to be) the *first* error encountered in that goroutine tree
[17:02] <katco> yeah... on the surface i really like the idea of encapsulating that coupling in a codified type
[17:03] <fwereade> katco, another thing that I like is that it means we don't have to `defer watcher.Stop(`
[17:03] <katco> fwereade: it removes some of the discipline required to get watchers right
[17:03] <fwereade> katco, which I have just realised is almost always subtly wrong
[17:04] <fwereade> katco, because when the loop errors out and then a watcher fails for boring reasons, the watcher faillure hits the worker's tomb first
[17:04] <katco> fwereade: re: doc comment; i wouldn't worry about # of goroutines
[17:04] <katco> fwereade: i doubt we could spawn enough for it to really matter
[17:05] <fwereade> katco, well, it is a fundamental difference -- a catacomb needs its own lifetime management
[17:05] <fwereade> katco, once you New() you're responsible for it
[17:05] <fwereade> katco, but maybe it's not important at that point in the doc
[17:11] <natefinch> fwereade: you need to move the core worker code into its own repo, so that catacomb can live in its own repo... we gotta stop hiding all this good code deep in the juju internals
[17:12]  * fwereade blushes
[17:12] <fwereade> natefinch, but, yeah, there is a chunk of worker-related functionality that's starting to want to move into its own repo
[17:13] <natefinch> fwereade: I think the quality of code goes up when we decide we want to be able to share it with the entire world, rather than keeping it buried in juju somewhere.
[17:16] <fwereade> natefinch, yeah, could well be
[17:16] <fwereade> natefinch, and this + dependency.Engine should go nicely together
[17:17] <natefinch> fwereade: yeah, all our really generic code like worker, dependency engine, catacomb, etc.  I think would be valuable to share with people.  Who knows, we might even get PRs against them (I know I have with some of my repos)
[17:17] <fwereade> natefinch, although it's also seeming a bit like catcomb wants/ought to do error-ranking like dependency engine (and worker.Runner) do
[17:17] <fwereade> natefinch, so I'm suspicious that I haven't got stable enough interfaces
[17:18] <natefinch> I think putting it in its own repo helps with that, too.  Easy to show to people, easy to view the godoc on godoc.org, forces you to write better documentation, include a readme, etc.
[17:18] <fwereade> natefinch, on the one hand, that increases the resistance to putting it in its own repo; on the other, that's no goddamn excuse really, is it ;)
[17:19] <natefinch> you can certainly put a disclaimer at the top that says it's still in flux.  I did that for https://github.com/juju/deputy
[17:20] <fwereade> natefinch, yeah... but, sorry, gtg, bbiab I hope?
[17:20] <natefinch> ..which, hey, has a PR against it :)
[17:20] <fwereade> nice :D
[17:20] <natefinch> fwereade: kk
[17:20] <katco> fwereade: ty
[17:21] <natefinch> gah
[17:22] <natefinch> I can't merge PRs under github.com/juju anymore :/
[17:23] <natefinch> katco: can you give me write access to github.com/juju/deputy so I can merge PRs to it?
[17:25] <katco> natefinch: done
[17:28] <natefinch> katco: thanks!
[17:36] <jcastro> can a core dev give a nice answer to this one? http://askubuntu.com/questions/693689/juju-charms-rest-api
[17:47] <mgz_> natefinch: can we just set access on juju/deputy to the hackers group? or does it need to be just you?
[17:49] <katco> mgz_: i almost did the hackers group, but wanted to ask you first
[17:50] <mgz_> katco: we gernally have either that or bots - if the project has a good test suite we can make it gated and use bots, otherwise hackers means the magic erge button appears for all of us
[17:51] <cherylj> hey evilnick__ , someone pointed out to me today that the command usage statements on this page all have "no-highlight" in front of them:  https://jujucharms.com/docs/devel/commands
[17:51] <katco> mgz_: i could go either way
[17:54] <evilnick__> cherylj, ah yes, thanks for pointing it out - that is a bug in the rendering of the site. After a new release, the page gets automatically regenerated and in this case, it hasn't been patched to fix the problem. I will take care of it.
[17:55] <cherylj> thanks, evilnick__ !
[17:57] <katco> cherylj: are we going to do a 1.24.8?
[17:59] <cherylj> katco: that is the $64,000 question
[17:59] <katco> cherylj: i'm going to mark the milestone as inactive. we can always turn it back on
[17:59] <cherylj> I think we'd like to avoid it, since we're going to try and get 1.25 back into trusty
[18:14] <dimitern> cherylj, in that line of thought, I've just proposed the fix for bug 1483879
[18:14] <mup> Bug #1483879: MAAS provider: terminate-machine --force or destroy-environment don't DHCP release container IPs <bug-squad> <destroy-machine> <landscape> <maas-provider>
 <juju-core:Triaged> <juju-core 1.24:In Progress by dimitern> <juju-core 1.25:In Progress by dimitern> <https://launchpad.net/bugs/1483879>
[18:16] <cherylj> awesome, thanks dimitern
[18:16] <cherylj> I'll take a look this afternoon
[18:16] <dimitern> frobware, ^^
[18:17] <dimitern> cherylj, sure, I'd appreciate it - it's a bit quick-and-dirty in a few places, because I really want to get it out the door (1.24.8 will be the last 1.24 I hope), it should be tested better for 1.25/master
[18:29] <cmars> jcastro, i don't have a working stackexchange account, but this would probably be helpful: https://github.com/juju/juju/blob/master/doc/api.txt
[18:29] <cmars> jcastro, short of a nice library for accessing the api, which we don't have yet
[18:31] <mgz_> cmars: you can sso using lp, no?
[18:32] <cmars> mgz_, oh, maybe so, there's a lp for this one, isn't there. ok
[18:33] <mgz_> well, anything that just needs an open id endpoint like stack overflow etc you can just paste your lp user page
[18:35] <natefinch> mgz_, katco: I'm fine with using the bot.  deputy has 94% test coverage.
[18:35] <cmars> mgz_, got it. ok, i'll answer it :)
[18:54] <wwitzel3> natefinch, katco, ericsnow: ping
[18:54] <katco> wwitzel3: hey
[18:58] <katco> wwitzel3: tried to bootstrap lxd and got an error on the unix socket. controller machine is started. what am i doing wrong?
[19:01] <wwitzel3> katco: that's odd
[19:02] <wwitzel3> katco: what is the head of your lxd-branch?
[19:02] <katco> wwitzel3: 0a01db9
[19:03] <katco> oh jees
[19:03] <katco> that's what's wrong
[19:03] <katco> 3 weeks ago
[19:03] <katco> i must not have pulled
[19:03] <wwitzel3> lol
[19:03] <katco> there we go... this should be a lot better
[19:04] <katco> this provider is so nice
[19:04] <katco> no mongo on my host ^.^
[19:04] <wwitzel3> I uninstalled mongo
[19:04] <wwitzel3> completely, it is great
[19:04] <katco> i recently switched machines and never installed juju-local
[19:04] <katco> it's beautiful
[19:06] <natefinch> don't you need mongo to run the tests?
[19:07] <katco> natefinch: i don't typically run all the tests, just the ones around what i'm working on
[19:07] <katco> natefinch: so far, hasn't been a problem, but i'm atypical
[19:10] <mup> Bug #1513552 changed: master cannot deploy charms <blocker> <charm> <ci> <deploy> <regression> <juju-core:Fix Released by natefinch> <https://launchpad.net/bugs/1513552>
[19:13] <natefinch> ericsnow, katco: is the bot supposed to work on the lxd-provider branch?
[19:13] <katco> natefinch: yeah
[19:13] <ericsnow> natefinch: yes, but it won't run our tests (runs Go 1.2)
[19:13] <natefinch> ericsnow: right
[19:14] <ericsnow> natefinch: so we have some failing tests that got merged
[19:15] <natefinch> ericsnow: ahh, I see the problem, I forgot to mark my test file as go1.3
[19:27] <katco> ericsnow: natefinch: wwitzel3: you all ready to do the demos?
[19:27] <ericsnow> katco: yep
[19:28] <wwitzel3> katco: yep
[19:28] <natefinch> yep
[22:02] <natefinch> katco: can you make that juju/version repo and give juju-hackers write access to it?
[22:02] <katco> natefinch: sec, in a hangout debugging a charm
[22:02] <natefinch> katco: no rush, just wanted to be able to work on that later on tonight...
[22:11] <perrito666> natefinch: see you have killer friday nights
[22:29] <mup> Bug #1513982 opened: Juju can't find daily image streams from cloud-images.ubuntu.com/daily <streams> <juju-core:Triaged> <https://launchpad.net/bugs/1513982>
[22:30] <jog> ericsnow, I just opened bug 1513982, it may be a dup of 1287949 but I'd like input from someone else, are you able to look it over?
[22:30] <mup> Bug #1513982: Juju can't find daily image streams from cloud-images.ubuntu.com/daily <streams> <juju-core:Triaged> <https://launchpad.net/bugs/1513982>
[22:32] <perrito666> k EOD
[22:32] <perrito666> EOW
[22:32] <perrito666> game set match :p cheers
[22:33] <ericsnow> jog: it could be related to metadata signing; I seem to recall Sergey mentioning something about this
[22:34] <ericsnow> jog: this is vsphere-specific, right?
[22:35] <jog> yes... I'm trying to test an updated OVA for use by vsphere, that utlemming has pushed into daily
[22:46] <ericsnow> jog: yep, I'm pretty sure Sergey had a work-around that he used when manually testing the provider
[22:47] <ericsnow> jog: if I remember right, it involved commenting out some line of code somewhere to disable that signed image check
[22:49] <jog> I'll subscribe him to the bug and see if he can give some guidance. Although I was able to test this image when I used a locally hosted image stream and set image-metadata-url