[00:41] <ericsnow> wallyworld: I'm becoming less convinced that merging the charm store call is worth trying before we've settled the charm store API with Uros and co.
[00:42] <wallyworld> ericsnow: it's not settled? how is the new worker been done then?
[00:42] <ericsnow> wallyworld: making it work will require touches in the charmrepo code that may not be desireable
[00:42] <wallyworld> if there's no api?
[00:43] <ericsnow> wallyworld: I'm talking about the call to the charm store (the worker part isn't a problem)
[00:43] <wallyworld> so the worker doesn't do anything?
[00:44] <ericsnow> wallyworld: it only runs the updater that got passed in to the worker's config
[00:44] <wallyworld> and that is a stub then i guess?
[00:44] <ericsnow> wallyworld: ultimately the worker triggers an API call and the charm store API call happens on the controller
[00:45] <wallyworld> ok, i guess i was expecting the api to be sorted before starting on the worker
[00:45] <ericsnow> wallyworld: I'm talking about the charm revision updater and I think you might be talking about the new resource poller :)
[00:45] <wallyworld> we're talking about both i think?
[00:46] <ericsnow> wallyworld: k
[00:46] <wallyworld> anyways, if the api is not done, then yeah we need to sort that first
[00:46] <ericsnow> wallyworld: anyway, the API server makes a call to charmrepo.CharmStore.Latest(), which gives back a slice of ints (for charm revisions)
[00:47] <wallyworld> yes
[00:47] <ericsnow> Latest, in turn, uses that "meta" GET to get that info
[00:47] <wallyworld> yes
[00:47] <ericsnow> and that does not support resources yet, AFAIK
[00:48] <wallyworld> ok, that's what i wasn't sure of, i thought it would if we were polling for respource updates
[00:48] <ericsnow> so that will have to happen plus the CharmStore.Latest() method will have to change its signature
[00:48] <wallyworld> yep
[00:49] <wallyworld> given a charm is now a tuple, it makes sense for Latest() to need updating
[00:49] <ericsnow> I would not be surpised if the charm store API grew a more dedicated way to get the combined  info we want for the worker
[00:50] <wallyworld> possibly
[00:50] <ericsnow> I will still combine the workers, even if (for now) we are making multiple charm store API calls
[00:50] <wallyworld> that would be good
[00:50] <wallyworld> less moving parts
[00:51] <cherylj> can I get a review?  https://github.com/juju/juju/pull/4514
[00:51] <cherylj> It's a backport of a PR that's been merged into master
[00:51] <cherylj> and is reviewboard not picking up PRs?
[00:51] <wallyworld> cherylj: rb has been flakey this week
[00:51] <wallyworld> looking
[00:51] <ericsnow> wallyworld: and necessary once we consolidate the 2 charm store API calls
[00:51] <wallyworld> yep
[00:51] <wallyworld> fits the model better too
[00:52] <alexisb> wallyworld, tab completion has stopped working for me also
[00:52] <alexisb> with the latest master
[00:52] <wallyworld> alexisb: damn, i thought there was something wrong
[00:52] <wallyworld> not surprised
[00:53] <alexisb> ug
[00:53] <wallyworld> because cli has changed so radically
[00:53] <wallyworld> hence i raised it :-)
[00:53] <alexisb> I didnt remove any tab completion code though
[00:53] <alexisb> and it was working with my last commit
[00:53] <alexisb> this is new
[00:53] <wallyworld> no, but the code uses the cli to figure out what to tab complete
[00:53] <wallyworld> hmmm, ok
[00:54] <wallyworld> maybe false alarm, i'll try running the make target
[00:56] <natefinch> I filed a few bugs about our tab completion.. in many cases it just panics
[00:56] <natefinch> or at least it did in 1.x
[00:57] <wallyworld> alexisb: i just ran the make target "install-etc" and it seems to wrok again
[00:57] <wallyworld> maybe that was all i was missing before
[00:58] <wallyworld> cherylj: +1 on that pr
[00:58] <alexisb> weird the only thing I changed in my setup was a new pull of master
[01:00] <natefinch> alexisb: I had problems with tab completion barfing if the "current" environment (now, model) wasn't bootstrapped
[01:00] <wallyworld> if any command returns an error, it won't work
[01:01] <natefinch> wallyworld: the problem I had was that it would spew out garbage into the terminal in that case
[01:01] <wallyworld> as it uses the CLI "juju help commands" to figure stuff out
[01:01] <alexisb> natefinch, interesting
[01:02] <alexisb> let me mess with that for a minute
[01:02] <wallyworld> garbage on terminal would do it yeah
[01:02] <natefinch> wallyworld: oh yeah, the ridiculous code that reads the stdout of a run of the command... good lord
[01:03] <natefinch> wallyworld: I remember making a ton of tests fail by inserting a fmt.Printf() for some debugging code and BOOM all this code that reads stdout failed
[01:04] <wallyworld> sometimes our tests look at what's written to the user but that makes them fragile
[01:05] <alexisb> ok my issue was different
[01:05] <alexisb> I had a conflict on the alias and it toasted the whole thing
[01:05] <alexisb> sorry for the false alarm
[01:06] <wallyworld> alexisb: this scares me
[01:06] <wallyworld> # juju-core.bash_completion.sh: dynamic bash completion for juju cmdline,
[01:06] <wallyworld> # from parsed (and cached) juju status output.
[01:06] <natefinch> ahh, yeah, I've done that
[01:06] <wallyworld> juju status output is now all different
[01:06] <wallyworld> so completion will fail for machines, services etc
[01:07] <alexisb> wallyworld, lovely
[01:07] <wallyworld> i have no idea how the cli completion stuff works, just saw the comment in the file
[01:07] <wallyworld> we'll need to fix that, yay
[01:07] <alexisb> wallyworld, its magic ;)
[01:08] <wallyworld> i think in this case it is
[01:08] <alexisb> well for right now it is working for me
[01:08] <alexisb> so I ill go back to storage, but put it on the list of to-dos
[01:32] <axw> wallyworld: sorry had to cut you off before, was there anything else to discuss?
[01:33] <wallyworld> axw: no problem at all, we covered it all. i have pushed changes to that beta1 cleanup pr
[01:34] <axw> wallyworld: LGTM, thanks
[01:34] <wallyworld> ta
[01:55] <menn0> thumper: I think I've found out why the apiserver appears to be dying before the logsink request is done
[01:55] <menn0> thumper: the waitgroup is only increment for "normal" api requests
[01:56] <thumper> and...
[01:56] <menn0> thumper: the "streaming" style requests don't appear to be counted
[01:56] <thumper> ah..
[01:56] <menn0> so /log, /tools, /charms etc all don't count
[01:56] <menn0> interestingly, fwereade_ emailed me last night as he's seeing the same problem
[02:13] <axw> wallyworld: teeny one https://github.com/juju/juju/pull/4515
[02:13] <wallyworld> looking
[02:15] <wallyworld> axw: ship it, thanks for fixing
[02:15] <axw> wallyworld: ta
[03:49] <wallyworld> axw: http://reviews.vapour.ws/r/3940 should be go for another look when you get a chance
[04:42] <axw> wallyworld: sorry, had to go get jeremy. furiously trying to finish this branch, will look soon
[04:43] <wallyworld> no hurry, all good
[04:56] <natefinch> man I hate the new bootstrap.  The error messages are all horrible
[04:57] <natefinch> error: controller name and cloud name are required
[04:57] <natefinch> ...no, no they're not.  And actually, cloud name isn't even something you can specify
[05:00] <natefinch> I wish we had a juju env command that would print out what directories juju thinks it's supposed to be using.
[05:00] <natefinch> (among other environment variables... but right now I'm concerned that it's using some other JUJU_DATA directory... but I don't know what one it thinks it's supposed to be using
[05:06] <natefinch> wallyworld. axw, menn0: did we break the lxd provider? I don't seem to be able to switch to it anymore (I'm on wily using go1.4, so it
[05:07] <natefinch> it's definitely getting compiled etc)
[05:07] <wallyworld> natefinch: we didn't, lxd did
[05:07] <natefinch> wallyworld: ahh
[05:07] <natefinch> wallyworld: well shit
[05:07] <wallyworld> they changed stuff upstream without any regard for juju :-(
[05:08] <wallyworld> john is working with them to fix
[05:08] <natefinch> wallyworld: so uh... I guess I have to test on amazon, since there's no more local?
[05:08] <wallyworld> for now yes :-(
[05:08] <wallyworld> unless you pin lxd beta2
[05:08] <natefinch> hmm, pinning is probably easier
[05:09] <wallyworld> not sure if debs are still around somewhere
[05:09] <wallyworld> google may help find them
[05:11] <natefinch> wallyworld: oh, like lxd itself, not the API library. I see.  Well, crap
[05:11] <wallyworld> yup
[05:13] <natefinch> whelp, guess I'll mess with that in the morning
[05:51] <axw> wallyworld: sorry  :(  https://github.com/juju/juju/pull/4517
[05:51] <wallyworld> np :-)
[05:51] <axw> wallyworld: I had to change the format of show-controllers/list-controllers, so something to look out for and see if you agree with
[05:51] <wallyworld> ok
[05:52] <axw> well I didn't *have* to, but I think it makes more sense this way
[05:53] <axw> wallyworld: were you not able to move the LocalControllerByName into modelcmd?
[05:54] <wallyworld> axw: ah, yeah, i kept it separate, i should have moved it
[05:55] <wallyworld> i'll do that next
[05:55] <axw> wallyworld: I think that would be good. keeps the policy away from storage
[05:55] <axw> wallyworld: ok, thanks, will continue reading
[06:24] <wallyworld> axw: lgtm, a lot is mechanical. i look forwar dto resolving all the conflicts :-)
[06:25] <axw> wallyworld: I'll bet. thanks!
[06:28] <axw> wallyworld: in case it wasn't obvious from my last PR, it should be possible to stop using configstore in most commands now. it's now only used for bootstrap config in juju/api.go
[06:28] <wallyworld> axw: i noticed :-)
[06:28] <wallyworld> just shitloads of tests to fix
[06:28] <axw> wallyworld: indeed
[06:29] <axw> wallyworld: sorry, mind's all over the place - did you tell me this morning what was next after this PR?
[06:29] <wallyworld> axw: yes, but now i've forgotten, let me think
[06:30] <axw> heh :)
[06:31] <wallyworld> axw: that's right, we talked about doing the "admin" model thing, but i need to email qa. one quick fix - can we write to jujuclient store earlier in bootstrap process so we don't get a stupid error trying to run status before bootsttap has finished?
[06:31] <wallyworld> so the "admin" work can be started, and i'll email qa overnight
[06:32] <wallyworld> we also have login/logout
[06:32] <axw> wallyworld: sure. yep, was intending to work on login next
[06:32] <wallyworld> axw: the error i refer to is "no controller defined"
[06:32] <axw> wallyworld: can't see it getting done before I leave tho
[06:33] <axw> (login command that is)
[06:33] <wallyworld> can make a start, keep the prs small
[06:41] <axw> wallyworld: have you confirmed with cmars about storing macaroons in accounts.yaml? if not, I'll send an email now
[06:41] <axw> sorry, probably asked and answered already
[06:42] <wallyworld> axw: we discussed it verbally in capetown and it's in the spec so i haven't sent email but feel free to double check
[06:47] <axw> wallyworld: I think we're going to have to prompt the user to set an admin password after bootstrap
[06:47] <axw> wallyworld: or I suppose we could just print out the random string...
[06:48] <axw> wallyworld: but anyway, if the user has to input their password to login, they need to know what it is :)
[06:48] <wallyworld> axw: we now would store that admin password in accounts.yam right
[06:48] <axw> wallyworld: indeed. do we want to continue supporting password as well as macaroon?
[06:49] <wallyworld> i think so in order to not have them lose admin access
[06:49] <axw> wallyworld: I was thinking macaroon exclusively. this will help for restoring a backup too: after restoring, you plug your password back in to authenticate
[06:49] <wallyworld> ah, wait sorry, got that wrong
[06:50] <wallyworld> macaroon replaces password till it expireds
[06:50] <axw> wallyworld: at which point you type it in manually, right? otherwise why use a macaroon at all
[06:51] <wallyworld> i think looing up password in yaml is better than what we have now, we can iterate on making it easier
[06:51] <wallyworld> yes, you'd type it in
[08:26] <wallyworld> axw: here's part 1 of autoload-credentials http://reviews.vapour.ws/r/3954/ i'm off to soccer soon so no rush
[08:39] <axw> wallyworld: will take a look a bit later on
[08:39] <wallyworld> np
[10:01] <dimitern> jam, dooferlad, voidspace,
[10:01] <dimitern> standup
[10:02] <voidspace> dimitern: omw
[10:50] <dimitern> frobware, dooferlad, voidspace, here it is: http://paste.ubuntu.com/15186527/
[10:52] <perrito666> morning
[10:55] <perrito666> dimitern: ping?
[10:55] <dimitern> perrito666, morning :)
[10:56] <perrito666> morning, have a question, are you a go-amz member?
[10:56] <perrito666> in github I mean
[10:57] <dimitern> I used to be at least... maybe I still am
[10:58] <perrito666> I have a lgtm https://github.com/go-amz/amz/pull/66 could you merge please?
[10:59] <dimitern> perrito666, merged
[10:59] <perrito666> thank you
[11:20] <dimitern> voidspace, bootstrap error is due to spaces discovery indeed: "GET /MAAS/api/1.0/spaces/?op=list HTTP/1.1" 400 276 "-" "Go-http-client/1.1"
[11:22] <dimitern> here's the line causing it https://github.com/juju/juju/compare/maas-spaces2#diff-9f2d224cfe3d5b5450772b51d95b625aR67
[11:23] <dimitern> that would've been caught by a simple live bootstrap
[11:28] <dooferlad> dimitern: Are we returning to https://plus.google.com/hangouts/_/canonical.com/juju-sapphire ?
[11:29] <dimitern> dooferlad, I guess so, omw
[11:30] <dooferlad> voidspace: we are starting if you are interested
[11:38] <voidspace> dimitern: ok, thanks
[12:16] <voidspace> "juju help" lists "juju init" as a command, but it isn't...
[12:28] <voidspace> dimitern: how do you set the oauth key?
[12:29] <voidspace> dimitern: I've done "auth-types: AAAA...." using auth-types instead of maas-oauth from the doc you suggested
[12:29] <voidspace> dimitern: but that gets me an "unmarshall error" when I add the cloud
[12:31] <voidspace> dimitern: i.e. what does your yaml look like to add-cloud please
[12:33] <dimitern> voidspace, here's what I have in ~/.local/share/juju/clouds.yaml: http://paste.ubuntu.com/15186890/
[12:34] <voidspace> dimitern: ah, a *literal* [oauth1]
[12:34] <dimitern> :) that seemed odd to me as well, but the previous example was using 2 types
[12:35] <voidspace> dimitern: where do you add the key then?
[12:35] <voidspace> dimitern: now when I bootstrap it says "credentials not found"
[12:36] <dimitern> voidspace, in ~/.local/share/juju/credentials.yaml
[12:36] <voidspace> dimitern: oh...
[12:36] <voidspace> dimitern: can you pastebin me the format for that too please :-)
[12:37] <voidspace> dimitern: never mind, found it
[12:37] <dimitern> voidspace, :) ok, just a sec
[12:37] <voidspace> dimitern: in that same email
[12:37] <dimitern> voidspace, yeah
[12:37] <dimitern> it's all in there
[12:38] <voidspace> dimitern: I appear to be bootstrapping now
[12:38] <voidspace> dimitern: now testing the fix for the discovery bug
[12:39] <voidspace> dimitern: http://reviews.vapour.ws/r/3955/ (but testing this first)
[12:43] <dimitern> voidspace, reviewed
[12:47] <dimitern> dooferlad, frobware, voidspace, so interfaceDoc -> linkLayerDoc, state.Interface -> state.LinkLayer ? (what?)
[12:48] <dimitern> state.LinkLayerLink ? LinkLayerDevice ?
[12:49] <dooferlad> dimitern: state.LinkLayer
[12:49] <dimitern> maybe LinkLayerConfig
[12:49] <dimitern> dooferlad, link layer whay?
[12:49] <dimitern> what
[12:49] <dooferlad> if that is what it returns...
[12:49] <dimitern> I need a sensible singular name
[12:49] <dooferlad> oh, I see.
[12:50] <dooferlad> LinkLayerConfig seems reasonable
[12:50] <dimitern> ok, then the doc can be linkLayerConfigDoc and the collection - linkLayerConfigsC
[12:52] <dooferlad> yes, that sounds good
[14:02] <voidspace> dimitern: https://github.com/juju/gomaasapi/pull/6
[14:03] <voidspace> dimitern: if we merge this then we don't need an additional test in juju because the current code will fail with this revision of gomaasapi
[14:03] <voidspace> dimitern: I will verify that - and obviously the juju PR needs to switch gomaasapi revision
[14:13] <natefinch> Good got, it took 7 minutes for xchat to start up
[14:13] <natefinch> s/got/god
[14:16] <natefinch> alexisb: do we have a timeline for when the lxd team will get in a fix so Juju can use lxd?
[14:16] <alexisb> natefinch, we discussed this morning, there is about 2 more days of development work from jam
[14:17] <frobware> voidspace: adding you as assignee for master (for your current PR). Would be good to get in today as next beta build will be cut this thursday.
[14:18] <frobware> voidspace: ah, scrap that. I suspect this change isn't on master anyway, correct?
[14:18] <natefinch> alexisb: ok, didn't realize we were the ones responsible for the fix. That's unfortunate.
[14:19] <alexisb> well it is a team effort
[14:19] <alexisb> tych0 has helped us on juju core things
[14:19] <natefinch> alexisb: that's true
[14:19] <alexisb> the teams are working together
[14:19] <natefinch> alexisb: well good, I think we could use some collaboration
[14:20] <mgz> collaboration is for the weak?
[14:21]  * natefinch considers using manual provider for local work
[14:26] <alexisb> natefinch, I have been using vmaas
[14:26] <alexisb> but I also have the old lxd installed :)
[14:26] <alexisb> vmaas is working well for me
[14:27] <natefinch> I have tried setting up vmaas a couple times and could never get it to work right...
[14:27] <natefinch> honestly, all I need is a single machine to test my stuff against.  Hell, I could almost use manual provider against local machine, if I wasn't afraid it would hose my machine
[14:28] <tych0> natefinch: alexisb: as in the launchpad bug + the old PR, i can cherry pick just the API fix if you want and make a PR
[14:29] <alexisb> tych0, that would be awesome if you have time
[14:29] <tych0> i'm not sure that ever needed to get rolled into a feature branch
[14:29] <tych0> but i don't really know how your guys' process works :)
[14:29] <tych0> sure, i'll post it this morning.
[14:29] <alexisb> tych0, yea we need to do a better job of educated community contributors
[14:30] <tych0> or just make the contribution process less complicated :)
[14:30] <alexisb> both really
[14:31] <alexisb> tych0, please do use the latest master
[14:31] <tych0> yes, of course
[14:31] <alexisb> mgz, would you be available for tych0 if he has questions
[14:31] <tych0> should be pretty simple. what i really need is reviewers :)
[14:31] <alexisb> I will be out for a but this morning and cherylj is currently transporting kiddo
[14:31] <mgz> yeah, I can review too
[14:32] <alexisb> mgz, thanks!
[14:32] <alexisb> what tych0 is working on would hopefully unblock master
[14:33] <natefinch> do we still support the manual provider?
[14:35] <natefinch> do we have docs about how to use bootstrap?  Because, seriously, the error messages and help text are infuriating
[14:36] <alexisb> jam  you still around today?
[14:36] <cherylj> natefinch: yes, we still support manual provider.  Are you trying to use it with the 2.0 cloud credentials stuff?  (I haven't tried it with the new changes yet)
[14:40] <perrito666> natefinch: I use vmaas creating from instructions cherylj passed me with some modifications
[14:40] <dimitern> voidspace, sorry, I've missed your message earlier, but you've got LGTM on the gomaasapi PR
[14:42] <natefinch> cherylj: yeah... I added a "manual" provider to my environments.yaml in the new juju data directory and bootstrap just says ""
[14:42] <natefinch> er
[14:42] <natefinch> "error: controller name and cloud name are required"
[14:42] <natefinch> which is hugely unhelpful
[14:43] <natefinch> given that it doesn't actually give you a way to specify controller name or cloud name
[14:43] <cherylj> yeah the help needs to be updated
[14:43] <natefinch> unless the help docs are wong
[14:43] <natefinch> wrong
[14:44] <mup> Bug #1456757 opened: TestAddressChange fails <ci> <go1.5> <intermittent-failure> <test-failure> <wily> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1456757>
[14:44] <cherylj> natefinch: try juju bootstrap my-manual-controller manual/<ip of manual machine>
[14:45] <natefinch> so, the help docs are completely wrong?
[14:45] <cherylj> natefinch: yes.  it's going to be addressed
[14:45] <cherylj> natefinch: check the release notes for some better info
[14:46] <natefinch> cherylj: I'm pretty aghast that we let major changes to commands land without changes to the help docs
[14:46] <cherylj> natefinch: the docs team is leading an effort to improve the help text for all the commands
[14:46] <cherylj> which is nice
[14:47] <natefinch> cherylj: there's no excuse for us not updating our CLI help docs.
[14:47] <tych0> mgz: ok, false alarm on the fire drill. i'm guessing jam has already done all of this, so i'd say let's wait for him to update lxd-container-type
[14:47] <cherylj> natefinch: I understand your concern, and it does make a poor user experience.  But, the command changes barely made it in to beta1 as it was
[14:47] <cherylj> too much to do, not enough people :(
[14:47] <natefinch> sorry, i gotta run and pick up my daughter from school, she's evidently sick
[14:47] <cherylj> yikes!
[14:48] <natefinch> back in a bit
[14:48] <mgz> tych0: okay
[15:05] <jam> alexisb: I'm in and out
[15:05] <alexisb> tych0, had some questions on how he could help out
[15:05] <alexisb> jam, ^^
[15:06] <jam> tych0: my work towards it is in github.com:jameinel/juju lxd-container-type-no-disk if you want to give that a poke
[15:06] <jam> tych0: unfortunately it isn't just API issues
[15:06] <jam> we need to get rid of the disk files
[15:06] <jam> because we fixed our test suite to not allow you to write to $HOME during a test
[15:06] <tych0> jam: what do you mean "get rid of the disk files"?
[15:06] <jam> and that's where the LXD code was writing files
[15:06] <ericsnow> katco, natefinch-afk: FYI, my patches landed (in the feature branch)
[15:06] <tych0> oh, right
[15:07] <tych0> jam: is it updated to use your new APIs that you made for LXD?
[15:07] <jam> tych0: we should be using the EnvironConfig structure that we already have
[15:07] <jam> tych0: I'm working through that, yes.
[15:07] <tych0> jam: ok, sounds good. should i just leave you to it?
[15:08] <jam> tych0: well, I only have a couple hours left today if you could give it some time (right now is dinner, and soon bedtime for my son)
[15:08] <jam> good/bad is that "go test' in tools/lxdclient is running but segfaulting
[15:08] <jam> so you should have some hints what needs to be fixed
[15:08] <tych0> :)
[15:08] <jam> tych0: did you get the first branch merged? (NewClientFromInfo )?
[15:09] <tych0> jam: well, i took out your merge commit and rebased it
[15:09] <tych0> just waiting for stgraber to come online and hit merge (or if you want to do the same, i can close mine and do that)
[15:09] <jam> that's fine, as long as the change is there
[15:09] <tych0> yeah, i'm +1. if you want to rebase instead of merge then I can merge it myself :)
[15:09] <jam> I'm not a big fan of rebase, so if you want to do that part for me, feel free.
[15:10] <tych0> yep, i did
[15:10] <tych0> just waiting on stgraber to merge, and then we'll have both in lxd master
[15:11] <tych0> and we can use a "real" hash for the juju deps file
[15:11] <tych0> anyway, let me try and sort out a make file issue for a different project, then i'll give your branch a look
[15:11] <jam> tych0: so the things I'm aware off
[15:12] <jam> 1) we want to use ENvironConfig and set the client cert in there and have it passed into the lxdclient code
[15:12] <jam> instead of having it generated
[15:12] <jam> 2) we need to fix Architecture (which I think I've done)
[15:12] <tych0> and then the ClientStatus thing too, i suppose?
[15:12] <jam> 3) We need to fix provider/lxd/instance.go so that Addresses() makes a call back into lxdclient to get the addresses
[15:12] <jam> rather than having them cached
[15:13] <jam> my thought was that since both provider/lxd and container/lxd are going to need Addresses
[15:13] <jam> then we should have the code to convert ClientStatus => network.Addresses in lxdclient
[15:14] <tych0> makes sense
[15:19] <katco> ericsnow: awesome
[15:19] <katco> ericsnow: natefinch-afk: morning
[15:19] <ericsnow> katco: \o
[15:23] <natefinch> katco: morning
[15:28] <natefinch> katco: this not having lcd or local provider is kind of screwing my productivity btw
[15:28] <natefinch> s/lcd/lxd
[15:29] <katco> natefinch: lxd is borked in our branch?
[15:30] <natefinch> katco: not the provider, lxd itself changed
[15:31] <natefinch> katco: thus breaking our provider
[15:31] <katco> natefinch: oh, right... yeah. can you pin an older version?
[15:31] <katco> natefinch: probably worth it to get that functionality back
[15:31] <natefinch> katco: probably, but I have no idea how to do that (get some older version of the lxd deb...?)
[15:33] <katco> natefinch: haven't done this in quite some time, but check out 3.10: http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html
[15:34] <katco> natefinch: this looks even easier: http://blog.andrewbeacock.com/2007/03/how-to-install-specific-version-of.html
[15:35] <perrito666> natefinch: version of ubuntu?
[15:36] <natefinch> perrito666: wily
[15:36] <perrito666> you have lxd from the ppa?
[15:36] <natefinch> I think installing the older version with apt-get is worker
[15:38] <natefinch> I don't know how to tell that
[15:38] <dimitern> dooferlad, frobware, voidspace, here's the giant rename PR: http://reviews.vapour.ws/r/3959/ - please focus on the second commit, as even though I tried not to miss something, a few doc comments might need fixing
[15:38] <sinzui> natefinch: katco  the "=x.y.*" technique works with non-superdeded packages. Other wise you need to find a ppa with the old paackages or download them directly from Lp
[15:39] <perrito666> natefinch: I presume you have the ppa, just removing the ppa and deinstall-reinstall should workI am pretty sure lxd provider works without the ppa in willy
[15:40] <dimitern> dooferlad, frobware, voidspace, that PR needs to land before I can continue
[15:40] <dimitern> or whichever version of it gets approved
[15:41] <dooferlad> dimitern: looking
[15:41] <dimitern> dooferlad, cheers
[15:41] <frobware> dimitern: dooferlad: will look in a bit
[15:41] <dimitern> thanks
[15:43] <dooferlad> dimitern: could you remind me what linkLayerDeviceDoc.Index is used for and why we don't expect it to change over a reboot?
[15:44] <dimitern> dooferlad, it can change, we don't expect it to be immutable
[15:44] <dooferlad> dimitern: thats OK then :-)
[15:45] <dimitern> dooferlad, :) ta
[15:45] <dooferlad> dimitern: what do we use it for?
[15:46] <dooferlad> dimitern: and, I guess, where does it come from? If we are looking at the output of 'ip link' then I think we can use names instead of indexes for commands to update stuff
[15:46] <dimitern> dooferlad, I think it's nice to have it, as it can be used for as an extra thing use along with the MAC for matching observed devices to stored-in-state devices
[15:46] <dooferlad> dimitern: If that is all, I would drop it.
[15:47] <dimitern> dooferlad, why so?
[15:47] <dimitern> dooferlad, that argument applies to any of those fields basically
[15:47] <dooferlad> dimitern: the MAC shouldn't change. One thing is enough.
[15:48] <dimitern> dooferlad, I'm not sure that's guaranteed, but yeah
[15:48] <dooferlad> dimitern: personally I would make all commands that interact with the network to work with names, but always check that the name still matches the MAC.
[15:49] <dimitern> dooferlad, the model at least does not presume the macs are immutable
[15:49] <dooferlad> dimitern: the MAC isn't immutable (Intel cards for example will let you change it), but the idea is they are fixed and globally unique.
[15:50] <dimitern> dooferlad, yeah, or at least locally unique depending on the format
[15:50] <dimitern> dooferlad, for virtual interfaces or e.g. bonds macs can absolutely change
[15:51] <dimitern> but that's ok
[15:51] <dooferlad> dimitern: I think it is fine for us to break if it changes at runtime. From the point of view of Ethernet, if the MAC changes it is just a different device on the same bit of wire.
[15:52] <dimitern> dooferlad, agreed - a changed mac can be handled as a new device appearing with the same name
[15:52] <dooferlad> dimitern: absolutely what I was writing.
[15:54] <dimitern> dooferlad, those cases will be handled by the update ops
[15:54] <dimitern> dooferlad, i.e. "merge as best as you can what you already know's there on the machine with what we've just observed"
[15:55] <dooferlad> dimitern: sounds good.
[15:56] <voidspace> dimitern: maas space fetching PR updated, manually tested, plus tested that the tests fail without the new gomaasapi revision but pass with it
[15:56] <voidspace> dimitern: http://reviews.vapour.ws/r/3955/diff/#
[15:57] <dimitern> voidspace, ok, but I see no changes to add a test or bump dependencies.tsv ?
[15:57] <voidspace> dimitern: dammit, there was
[15:57] <voidspace> I don't see it either
[15:57] <voidspace> think I reverted it
[15:58] <dimitern> looks like it
[15:58] <voidspace> dimitern: it's there now
[15:58] <katco> natefinch: hey sorry, did you get it figured out?
[15:59] <xnox> calendar: hi, could you please review https://github.com/juju/juju/pull/4480/files ?
[15:59] <xnox> hm nick not found.
[15:59] <dimitern> voidspace, yeah, I can see the deps bump, but please add a quick test as well
[15:59] <xnox> dear "On-call reviewer" -> where is the calendar =)))))
[15:59] <voidspace> dimitern: as I commented before - it doesn't need one
[15:59] <voidspace> dimitern: if you run the tests with the old code but the new gomaasapi then tests fail with bad request
[16:00] <voidspace> dimitern: there's a new test for that code path in gomaasapi though
[16:00] <katco> ericsnow: hey got time for a quick chat?
[16:00] <ericsnow> katco: sure
[16:00] <dimitern> voidspace, hmm, ok then
[16:00] <katco> ericsnow: moonstone
[16:00] <dimitern> voidspace, makes sense, let's get it in
[16:00] <voidspace> dimitern: cool, thanks
[16:01] <dooferlad> xnox: the calendar is, I think, private to the Canonical Juju team. Todays reviewers are cherylj and mattyw.
[16:01] <natefinch> katco: yeah pretty much.... perrito666 helped me clean out the PPA version, the regular version from wily seems to work fine
[16:01] <voidspace> dimitern: if you need convincing, bump the gomaasapi revision on maas-spaces2 and run the maas provider tests
[16:02] <dimitern> voidspace, yeah, I did that :)
[16:02] <voidspace> :-)
[16:03] <xnox> dooferlad, thanks!
[16:03] <xnox> cherylj, mattyw: please review https://github.com/juju/juju/pull/4480/files
[16:03] <mattyw> xnox, I'm around if you want me to take a look at something
[16:03] <mattyw> xnox, will do
[16:09] <katco> natefinch: hey can you hop into moonstone rq?
[16:11] <natefinch> katco: sure
[16:12] <natefinch> huzzah for having LXD back and working
[16:19] <cherylj> hmm, I think tip of master is broken.
[16:26] <cherylj> ah, it doesn't like it when I switch to a different controller while it's bootstrapping
[16:29] <katco> cherylj: pushing the boundaries!
[16:29] <cherylj> yeah
[16:29] <cherylj> and finding bugs!
[16:29] <cherylj> check out this error:  2016-02-24 16:08:28 ERROR cmd supercommand.go:448 getting model details: model maas:admin@local:amazon not found
[16:30] <cherylj> I was bootstrapping amazon and switched to my already bootstrapped maas while it was working
[16:49] <dimitern> dooferlad, thanks for the review - Index dropped as discussed
[16:50] <dimitern> voidspace, frobware, any objections to landing http://reviews.vapour.ws/r/3959/ ?
[16:56] <natefinch> katco: given that we have meetings scheduled for 5am-6am and 3:30pm-7pm tomorrow, do you think I could take a couple hours off before the 3:30 to spend with my kids?  I know the 3:30 might not run that long, but I can't guarantee that, and 7pm is the kids' bedtime.
[16:57] <katco> natefinch: sec in a meeting
[16:58] <voidspace> dimitern: no objections from me
[17:00] <xnox> mattyw, also https://github.com/juju/xml/pull/5
[17:01] <dimitern> voidspace, cheers
[17:06] <natefinch> gonna go to lunch a little early today since the kids are all home sick
[17:06] <natefinch> back in an hour
[17:30] <voidspace> frobware: dooferlad: I need this fix in gomaasapi https://github.com/juju/gomaasapi/pull/7
[17:31] <dooferlad> voidspace: +1
[17:34] <voidspace> dooferlad: thanks
[18:07] <katco> natefinch: hey
[18:07] <kilty> I'm receiving the errors shown in this pastebin when bootstrapping from 2.0 beta1: http://pastebin.com/pCYg4YnE  Any ideas?
[18:08] <katco> kilty: that looks like the new signed streams stuff by anastasiamac
[18:08] <katco> cherylj: do you know much about this? ^^
[18:08] <natefinch> katco: howdy
[18:09] <katco> natefinch: hey
[18:09] <katco> natefinch: re. tomorrow's schedule
[18:09] <mgz> looks like an ugly variation on the normal private cloud thing?
[18:10] <katco> natefinch: how have the core team meetings been going? what is discussed? i haven't attended in quite some time
[18:12] <natefinch> katco: they're pretty hit or miss.  Sometimes almost no one shows up, or we only talk for 10 minutes, sometimes we talk the full hour, like what happened  last week.
[18:13] <katco> natefinch: i'd say skip the one for that tz and aim to go to the one on the 3rd
[18:13] <katco> natefinch: that way your day isn't terribly long
[18:13] <natefinch> katco: sounds like a plan
[18:28] <tych0> jam: hi, so i fixed the seg fault and implemented Addresses()
[18:28] <tych0> (it's on my github gh:tych0/juju with the same branch name)
[18:28] <tych0> as well as a few other little nits
[18:28] <tych0> but i'm trying to understand what you mean by EnvironConfig generating the certs, and I'm a bit lost
[18:29] <jam> tych0: hi. I'm about to head to bed, but I'll try to point you in the right way. Thanks for working on it, btw.
[18:29] <tych0> jam: np. any pointers are good pointers, as long as they're not null :)
[18:31] <jam> so every "Provider" has an EnvironConfig which is where we put things like authorized-keys/user/password/hostname/auth-url, etc.
[18:32] <jam> There are a bunch of common items in https://github.com/jameinel/juju/blob/master/environs/config/config.go
[18:32] <jam> the LXD one should be an extension of the base one: https://github.com/jameinel/juju/blob/master/provider/lxd/config.go
[18:32] <jam> for comparison I tend to look at the openstack one https://github.com/jameinel/juju/blob/master/provider/openstack/config.go
[18:33] <tych0> jam: oh, i see
[18:33] <jam> tych0: but the general idea is that we generate the LXD client cert during bootstrap
[18:34] <jam> and save it in the environ config under a particular key
[18:34] <tych0> jam: right, i guess the config gets initialized during bootstrap?
[18:34] <jam> and we'll keep passing that information in
[18:34] <jam> right
[18:34] <tych0> sounds good
[18:34] <jam> the only bit I'm not 100% sure on is if we want to save the server's cert so that we can ensure the server hasn't changed.
[18:34] <jam> for LXD provider, we can do that just fine
[18:34] <jam> for container/LXD each machine is going to have a different one.
[18:35] <jam> so we'll have to think a bit more carefully there.
[18:35] <tych0> jam: well, i don't think we'll even have to bother for container
[18:35] <tych0> jam: because we can always talk over the unix socket
[18:35] <jam> ah right
[18:35] <tych0> jam: which won't require cert auth at all
[18:35] <jam> no certs,
[18:35] <tych0> so i think just the server's cert, then?
[18:35] <jam> and if it wants a cert for some weird nesting thing, it can get it out of the socket.
[18:35] <tych0> yep
[18:35] <tych0> but hopefully at least initially it won't :)
[18:36] <jam> yeah, we shouldn't to start
[18:38] <jam> tych0: thanks again for picking up the work, I'll grab your branch in the morning if it hasn't already been landed. :)
[18:38] <tych0> jam: sure, sounds good. i should just pr this to lxd-container-type?
[18:38] <jam> tych0: yes
[18:38] <tych0> jam: will do, thanks
[18:38] <jam> tych0: you'll also want to update dependencies.tsv
[18:38] <jam> so that it includes the latest lxc/lxd code
[18:38] <tych0> jam: yep, i did that already
[18:38] <tych0> acutally i'm going to do it again though, and export a few more functions
[18:38] <tych0> to share some more code with LXD
[18:46] <jam> tych0: sgtm. I'd like to have less code on our wrapper when it makes sense.
[19:01] <natefinch> I need a gofmt replacement that turns a.something := foo   into a.something = foo  ... you know what I mean, just fix it.
[19:13] <cherylj> kilty, katco did you get an answer on the streams question yet?  Looks like not...
[19:15] <cherylj> kilty, katco the index2.sjson message is a known issue where juju is looking in the wrong place for image streams first, but will fall back to the right place.
[19:16] <cherylj> kilty: I saw a message similar to the "ERROR index file has no data for cloud" message you posted when messing with the rackspace provider
[19:17] <cherylj> kilty: I was able to work around it in that case by setting the image-stream to "released" rather than "daily".
[19:18] <cherylj> kilty: i.e.  juju bootstrap jujucontroller dr --config image-stream="released"
[19:19] <katco> cherylj: sorry was otp, not did not get a definitive answer for kilty afaik
[19:19] <katco> cherylj: i think mgz started to weigh in
[19:20] <mgz> yeah, from the error it looked like a private openstack
[19:20] <mgz> which isn't going to have image streams at our public locations anyway
[19:20] <natefinch> katco, ericsnow: review up when you have time: http://reviews.vapour.ws/r/3949/
[19:20] <cherylj> katco: ah, ok.  just ftr - the bug for that index2 message is bug #1547891
[19:20] <mup> Bug #1547891: Juju searches for index2.sjson in image streams <streams> <juju-core:Triaged> <https://launchpad.net/bugs/1547891>
[19:20] <ericsnow> natefinch: k
[19:20] <cherylj> mgz: yeah, that's what I was thinking too.
[19:21] <mgz> so I suspect some needed config didn't get brought over from 1.x to 2.0
[19:21] <katco> natefinch: TAL
[19:21] <katco> cherylj: ta
[19:34] <kilty> cherylj: thanks for the suggestion, though I got the same error
[19:35] <kilty> mgz: correct, it is a private openstack
[19:36] <cherylj> kilty: I think that message may indicate that it cannot find an appropriate image to use.  What images do you have available?
[19:36] <cherylj> (it's a pretty crummy message, though, doesn't tell you how to fix anything)
[19:37] <kilty> image like like 14.04?
[19:37] <cherylj> yes
[19:37] <cherylj> and did this work with 1.x?
[19:37] <kilty> yea I have 14.04 and 15.10
[19:37] <kilty> no we couldn't get 1.x to work so we were hoping 2.0 would fix everything =)
[19:38] <kilty> 1.x actually gave the same error: "ERROR index file has no data for cloud {RegionOne http://192.168.4.11:5000/v2.0} not found"
[19:38] <natefinch> ericsnow: just saw your alignStoreResources method.... are you sure that's correct?  What happens when a new version of the charm gets pushed out and it has a different number of resources?
[19:39] <cherylj> ah, ok.    How do you have your images indexed?
[19:39] <cherylj> kilty ^^
[19:40] <mgz> kilty: read https://jujucharms.com/docs/1.25/howto-privatecloud
[19:40] <cherylj> hey, that's handy, mgz
[19:41] <ericsnow> natefinch: for a given charm revision the same set of resource names will be associated, though the resource *details* (including revision) may be different, hence the number of resources will remain the same
[19:41] <mgz> kilty: that gives the background, all you really need is to tell juju about the images you put in glance, which isn't too painful
[19:41] <mgz> but I'm not quite sure how the config has changed in 2.0
[19:41] <ericsnow> natefinch: and service's are tied to a charm revision
[19:42] <natefinch> ericsnow: ahh, ok, yeah, so the number of resources can't change unless the charm revision changes, in which case, we'll download the new resource data... though I can imagine this breaking after a charm-upgrade, since we don't remove old resources (do we?)
[19:42] <ericsnow> natefinch: if a service switches to use a different charm revision then the resources will be synced up
[19:42] <ericsnow> natefinch: yep
[19:42] <natefinch> ericsnow: ahh, awesome. Nevermind then :)
[19:42] <kilty> mgz, cherylj: well I'll go through that page first and see where we end up, thanks!
[19:43] <ericsnow> natefinch: glad you asked
[19:43] <natefinch> ericsnow: still makes me sad that updates returns an error that will almost always be nil unless we have a bug, though
[19:43] <mgz> kilty: all you should need is the `juju metadata generate-image` bits and set image-metadata-url
[19:43] <ericsnow> natefinch: c'est la vie :)
[19:44] <mgz> cherylj: how do we actually set image-metadata-url in a 2.0 world...
[19:44] <kilty> mgz: i didn't do the metadata generation for the 2.0 setup (it wasn't in the wiki I found)
[19:45] <natefinch> ericsnow: I don't know... that'll break the juju list-resources command entirely if you ever get into that state... I wonder if it's better to just log an error or something.. I dunno.
[19:47] <ericsnow> natefinch: like you said, an error indicates something went unexpectedly wrong (e.g. data mangled across API), meaning the output from list-resources would likely be invalid anyway
[19:49] <natefinch> ericsnow: yeah, I guess you're right...
[19:54] <natefinch> ericsnow: damn your validation, now my test values need to actually be legitimate ;)
[19:54] <ericsnow> natefinch: mwahaha
[20:05] <natefinch> man I wish I didn't have to give a controller name... if I don't specify, just make it the same as the provider name, geez
[20:06] <perrito666> I believe the spec had that
[20:10] <kilty> cherylj: I do get some possibly prohibitive errors when generating metadata: http://pastebin.com/xzVwNLKV
[20:26] <natefinch> I should really learn to just double whatever expected time it'll take for tasks that involve the uniter
[20:31] <natefinch> katco: does work done on Friday count for this iteration, or are we now switching to iterations starting on Friday, given that our retros will likely always be Thursdays now?
[20:34] <katco> natefinch: that's a good question. for this iteration let's count friday
[20:34] <katco> natefinch: and then we can revisit tomorrow for the following iteration
[20:42] <mgz> kilty: supply `-m NAME_OF_MODEL_CFG_THING`?
[20:43] <kilty> mgz: I'm not entirely sure what model is, and googling 'juju model' shows me strange things
[20:44] <mgz> it's what used to be an environment before we decided to confuse everyone
[20:44] <kilty> oh so I still need the environment.cfg
[20:45] <kilty> er .yaml
[20:47] <natefinch> kilty: yeah, it lives under $XDG_DATA_HOME now... which ends up defaulting to ~/.local/share/juju
[20:51] <katco> ericsnow: natefinch: meet in ~9 for testing discussions?
[20:51] <ericsnow> katco: k
[20:52] <natefinch> katco: yep
[21:03] <katco> ericsnow: natefinch: in moonstone
[21:03] <jose> rick_h_: hey, did you get to put your idea on the wiki?
[21:04] <natefinch> katco: oops coming
[21:04] <rick_h_> jose: sorry no, had wiki issues and meant to go back to it
[21:04] <jose> no worries
[21:10] <perrito666> mm github got issue templates, we should make one for our bugs since we cannot make a magic redirection to launchpad
[21:10] <perrito666> or even better, we should make one that says "Please report this in launchpad"
[21:14] <perrito666> table tests produce an excessive logging :(
[21:19] <thumper> morning flks
[21:19] <thumper> perrito666: that they do
[21:19] <thumper> especially if they are uniter tests
[21:20]  * thumper goes to make another coffee
[21:52] <ericsnow> katco, wallyworld, natefinch: I remembered
[21:52] <ericsnow> katco, wallyworld, natefinch: the revision updater polls the charm store unauthorized
[21:53] <ericsnow> katco, wallyworld, natefinch: so charms that require authorization are ignored
[21:53] <ericsnow> katco, wallyworld, natefinch: that surprised me
[21:54] <wallyworld> ericsnow: when that was written, there were no private charms
[21:54] <ericsnow> katco, wallyworld, natefinch: so does the revision updater need to be updated?
[21:54] <wallyworld> ericsnow: yeah, think so
[21:54] <ericsnow> wallyworld: yuck
[21:55] <wallyworld> ericsnow: but we can leave it for now
[21:55] <ericsnow> wallyworld: that means keeping a macaroon in state and having some way of keeping it alive (or reviving it if it expires)
[21:56] <ericsnow> wallyworld: I'm glad to punt on it :)
[21:56] <ericsnow> wallyworld: as long as that means doing the same for resources :)
[21:56] <wallyworld> ericsnow: worth taking a look to see what's needed
[21:57] <ericsnow> wallyworld: k
[21:57] <ericsnow> wallyworld: who on core is most familiar with the support for private charms?
[21:57] <wallyworld> ericsnow: but right now, probably not the most important thing
[21:57] <wallyworld> ericsnow: casey etc
[21:58] <ericsnow> wallyworld: k
[22:05] <thumper> menn0: ping
[22:06] <menn0> thumper: hi
[22:06] <thumper> menn0: state/constraints.go, I was removing extra st.docId calls
[22:06] <thumper> menn0: setConstraintsOp replaces the doc
[22:07] <thumper> menn0: will the model-uuid get set automatically?
[22:07] <menn0> maybe :)
[22:07]  * menn0 checks the code
[22:08] <thumper> ah poo...
[22:08] <thumper> constraints doc is one of those documents that doesn't embed any form of key
[22:09] <thumper> so you can't just read the entire collection using a slice of docs...
[22:09] <thumper> f**xor
[22:09] <menn0> thumper: the model-uuid will get set automatically
[22:10] <thumper> need to do the same thing as settings and read as bson.M
[22:10] <thumper> menn0: cool, I'm just removing them as I go
[22:10] <menn0> see multiModelRunner.mungeBsonDUpdate() in state/txns.go
[22:10] <thumper> k
[22:10] <menn0> thumper: yeah, doc structs with the _id sucks
[22:11] <thumper> you mean without?
[22:11] <menn0> without :)
[22:13] <menn0> thumper: I just found the source of those panics in the apiserver. it's basically what I thought it was yesterday but even more subtle
[22:13] <thumper> oh
[22:13] <thumper> fixable?
[22:14] <menn0> yep I have a fix. there's a few parts to it.
[22:17] <menn0> basically what was happening is that the goroutine that the server infrastructure had spun up to handle a /logsink API request was only just starting when the apiserver was told to shut down. even incrementing the apiserver's WaitGroup at the top of logsink request handler wasn't enough because the goroutine hadn't gotten to that part yet, so the apiserver still thought all requests were done even though one was about to start up.
[22:18] <menn0> so the apiserver closed it's State and then the handler got to try and use it and boom
[22:18] <menn0> i've got a clean fix
[22:19] <menn0> but it can only be safely applied to API handlers that pay attention to the server's tomb. if they could run for a long time without checking the tomb then the fix could block the apiserver from shutting down.
[22:20] <katco> ericsnow: ah yeah, that. cmars just sent me an email that i think assures us that he'll be keeping us in the loop
[22:21] <ericsnow> katco: yeah, it's good because we'll have the same concerns with resources
[22:22] <katco> ericsnow: just forwarded the email... haven't read through fully
[22:22] <ericsnow> katco: thanks
[22:23] <katco> natefinch: hey, went ahead and assigned the "upgrade-charm --resources" card to you. we should talk about expected completion. week from today sound ok? 3/2?
[22:27] <katco> natefinch: i'll send an email in case you miss this ping
[22:27] <thumper> menn0: but blocking the apiserver from shutting down is better than panicing no?
[22:30] <menn0> thumper: not if it blocks the apiserver indefinitely
[22:30] <thumper> menn0: well, true that
[22:30] <menn0> thumper: the best solution is to not block *and* not panic
[22:31] <menn0> thumper: and when I'm done that will be the case for the /log and /logsink endpoints
[22:31] <menn0> thumper: there will still be the chance of panics in the charm and tools up/download etc
[22:31] <menn0> thumper: but they've always been there
[22:32] <menn0> thumper: and the panic is handled by the server infrastructure
[22:32] <menn0> thumper: it doesn't take down the process
[22:32] <thumper> k
[22:42]  * perrito666 finishes addressing 50 comments on a commit and falls asleep on the kb
[22:46] <perrito666> wallyworld: sorry I am pretty sure my last answer just blowed a vein in your forehead
[22:46] <wallyworld> perrito666: already blown
[22:47] <perrito666> wallyworld: https://dylansfilmandtv.files.wordpress.com/2013/07/149968-daria-mr-demartino.jpg
[22:47] <wallyworld> yep
[23:14] <perrito666> wallyworld: standup or no standup today?
[23:14] <wallyworld> perrito666: in meeting, we can talk if this one finishes before next one
[23:15] <perrito666> just asking to know if I can EOD or not
[23:17] <mgz> no rest for the wkd
[23:17] <perrito666> says the guy that lives on the country where its the middle of the night
[23:17] <mgz> hey, it's not quite midnight yet
[23:19] <wallyworld> axw: perrito666: anastasiamac: let's do standup
[23:20] <axw> wallyworld: brt, can't stay too long tho
[23:24] <perrito666> mgz: hey testing something I think I just created a joyent controller in CIs account but given that my test failed I cannot delete it, could you via web interface?
[23:24] <mgz> perrito666: with what name?
[23:24] <wallyworld> cmars: can i schedule a meeting with you for this time tomorrow regarding login?
[23:25] <mgz> perrito666: consoles.txt in cloud-city has all our logins btw
[23:25] <cmars> wallyworld, definitely
[23:25] <wallyworld> cmars: ty, will do invite soon
[23:27] <mgz> perrito666: I don't see anything recent, just cwr-joyent from yesterday?
[23:30] <perrito666> mgz: great, then it doesnt even creates the thing
[23:31] <mgz> axw: thanks for fixing the bootstrap ssh issue btw
[23:32] <axw> mgz: nps
[23:52] <anastasiamac> cmars: menn0: could u plz have a look at http://reviews.vapour.ws/r/3958/ and/or http://reviews.vapour.ws/r/3957/