[00:41] I now have -3 open reviews in my RB incoming review queue [00:41] is that a minus? [00:41] davecheney: those are your reviews I think [00:41] haha [00:41] if it is, that's funny [00:43] thumper: how many (negative) reviews do you have ? [00:44] personal ones are positive, juju-team shows -3 [00:44] davecheney: that seems like double entendre [00:44] jcw4: I'm looking at yours now [00:44] thumper: cool... I hope it's not negative [00:44] * jcw4 cracks himself up [00:45] yay software [00:50] * thumper wonders what jcw4 will think of this... [00:51] * jcw4 waits with anticipation [00:52] unless you hit publish in the next 2 minutes though my anticipation will have to stretch til after family supper. [00:52] ;) [00:52] the man knows how to negotiate [00:52] haha [00:52] * thumper recoils from that idea after reading the code, and goes back to the review [00:53] * jcw4 suspects recoil isn't usually used in context of a happy review [00:54] it isn't too bad, just getting my head around this [00:54] thumper: you should know that you bang your head on your desk a lot in irc... my thin skin can't take too much of that m'kay? [00:55] :) [00:56] jcw4: do we have a way to remove actions and their results yet? [00:57] thumper: no [00:57] thumper: we do have a forthcoming 'Cancel' API call [00:57] thumper: but that's not quite the same thing [00:57] pretty sure I'm not going to want every call around for ever :) [00:58] hmm... [00:58] thumper: +1... should that be handled with an API call (ArchiveActions) or within Jujud somehow? [00:58] jcw4: probably some api call [00:59] * jcw4 adds that to the actions api branch [01:02] * jcw4 is off to supper [01:05] oh FFS [01:05] * thumper wanted to edit that [01:05] wrong button [01:08] thumper: pong (it was a public holiday yesterday) [01:08] axw: hey, guessed that in the end [01:08] axw: got a few minutes? [01:08] sure [01:09] axw: https://plus.google.com/hangouts/_/gvxqrkm74ije2z64ochcr5bbhia?hl=en [01:11] hey there o/ :) [01:11] i'm building a juju api client [01:13] but i don't know why i only can connect to the socket ws://juju-gui:8001/ws [01:13] which i suppose is being proxyed or something like that [01:14] sebas5384: well the juju-gui talks to a proxy service on the charm [01:14] because that socket is already knowing to which environment to communicate [01:14] hmmm yeah [01:14] sebas5384: it does that to provide services like bundle deployments which the juju api doesn't have at this time. So it intercepts some calls to do actions manually [01:14] rick_h_: hi o/ [01:15] sebas5384: but most calls it just proxies through to the state server [01:16] hmmm i was imagining something like that [01:16] can you show me the code of that proxy ? [01:17] I want to use it as an example of how to connect to the api state server [01:17] sebas5384: yep, looking now, it's the 'guiserver' bit http://bazaar.launchpad.net/~juju-gui-charmers/charms/trusty/juju-gui/trunk/files/head:/server/guiserver/ [01:18] i'm taking a look at it [01:20] sebas5384: http://bazaar.launchpad.net/~juju-gui-charmers/charms/trusty/juju-gui/trunk/view/head:/hooks/utils.py#L140 might be of interest to you [01:20] hmmmm here it is:) [01:20] http://bazaar.launchpad.net/~juju-gui-charmers/charms/trusty/juju-gui/trunk/view/head:/server/guiserver/handlers.py [01:20] sebas5384: since it sounds like you really want the real ip addr of the state server [01:20] yeah exactly!! [01:21] sebas5384: but yea, there's some magic bits in the juju-gui charm so worth going through some of that. [01:21] sebas5384: hope that helps [01:21] definitively rick_h_ ! [01:22] thanks man! you are always helpful :) [01:22] rick_h_ ++ [01:22] np, have fun. I'm out for the night. [01:23] rick_h_: o/ [01:26] thumper: I just saw your email from yesterday about the 403s; it *shouldn't* be using the proxy for uploading to provider storage (probably the no_proxy mask isn't quite right) [01:27] thumper: that wouldn't happen on master tho [01:41] thumper: responded to your comments... great review. thank you. [01:43] jcw4: the old name or the new name? [01:43] jcw4: if Name -> Id [01:43] and Id() returns the localID [01:43] all good [01:43] thumper: good [01:44] thumper: did you get your first question about old vs. new name answered? [01:44] oh... I think it all goes together [01:44] it does :) [01:44] in which case I'm clear and that's cool [01:44] good [02:02] jcw4: names.Tag represents any tag [02:02] k [02:02] jcw4: names.UnitTag is a concrete implementation of a tag [02:02] right [02:02] since the design leans towards different receiver types [02:02] ah [02:02] it makes sense to be a names.Tag rather than a UnitTag [02:02] got it [02:02] we can then do type switches on it [02:03] and know that it is well formed [02:03] tags have become more than just API level [02:03] they are typed key values [02:03] so if we use Tags instead of string ids for the receiver, we make the parameter the general Tag type [02:03] thumper: okay, so it's okay to use them internally [02:03] the document should keep a string value [02:03] but it is internal [02:03] the public interface to the Action should use a Tag [02:04] IMO [02:04] +1 [02:04] jcw4: state.User now takes a names.UserTag arg [02:04] but the string repr. is the tag version instead of the internal Name() version [02:04] so we know that it is valid [02:04] k [02:04] jcw4: no, just store the Id() of the tag [02:04] right [02:04] which is the same value you are storing now [02:04] hmm; I see in the case of Units yes [02:05] I was distracted because the internal representation of action* id's are different than the tag version [02:18] thumper, do you have a minute to review https://github.com/juju/juju/pull/862 [02:18] * thumper looks [02:19] sinzui: do we have a good power build now? [02:19] thumper, we don't know yet. I have update all the machines and sent 1.20.9 off to the builders to find out [02:20] sinzui: ok, thanks for the info [03:17] jam: for bug #1375507 , should I be looking at going the NonValidatingClient route? should we generate new certs and leave the client as is? [03:17] Bug #1375507: rsyslog worker continuously restarts due to x509 error following upgrade

[03:23] menn0: what provider did you use when you noticed the bug ^ [03:56] wwitzel3: local [03:57] wwitzel3: it's probably not relevant but I can give you the script I was using to set up the 1.20 env [04:02] menn0: actually, that'd be helpful .. my local is giving me a bit of a different error [04:03] ok [04:03] wwitzel3: i'll email it to you know [04:03] thanks [04:03] menn0: also were you using 1.20 from the git tag? Or a pre-built? [04:04] wwitzel3: pre-built - I noticed the problem coming from both 1.20.7 and 1.20.8 from the stable PPA [04:04] menn0: k [04:06] wwitzel3: just sent the script [04:07] wwitzel3: I was using it to test upgrades for the units collection migration to using env uuids in the _id [04:07] wwitzel3: the rsyslog issue is just something I noticed incidentally [04:08] wwitzel3: wait for all agent-states to be "started" before running "juju upgrade-juju --upload-tools" with the juju built from master [04:12] menn0: thanks again, I'll give it a whirl right now [04:12] wwitzel3: ok [04:40] * thumper feels much better after a few hours coding [04:40] * thumper EODs [04:40] jam: FWIW, just implemented 'juju api-info' with nice options [04:40] jam: will propose tomorrow [04:40] thumper: sounds good [04:43] jam: are you still maintaining the old juju landing bot? I tried to land a contribution to gwacl, and it spat the dummy [04:43] `/bin/sh: 1: Syntax error: "&&" unexpected` [04:44] axw: mgz is probably more aware of that bot than I am. [04:44] okey dokey [04:44] thanks [04:44] axw: I'll see if I can find it [04:44] axw: can you link the MP ? [04:45] jam: https://code.launchpad.net/~mark-sheahan-ms/gwacl/cert-args/+merge/235889 [04:45] I can merge manually if it's too much hassle, unit tests should be pretty a safe bet === uru_ is now known as urulama [05:40] morning all [05:41] dimitern: morning [05:42] wwitzel3, hey, isn't it way to late there? [05:42] :) [05:43] dimitern: isn't it a bit too early there :) [05:43] I think its only about midnight for wwitzel3 [05:44] jam, 8:44, nice and early :) [05:44] dimitern: yeah, it isn't super late, but mostly I'm sick and not sleeping well, so figure I'd be productive since I was up anyway [05:44] wwitzel3, oh, get well soon then! [05:45] dimitern: my goal is to not be sick at the sprint, that would be awful [05:46] wwitzel3, yeah, I almost managed to get a cold in the past few days, but it's ok now [05:47] dimitern: I hung out with some friends who have kids on Saturday and felt it coming on Sunday .. I should know better than to leave the house :P [05:47] jam, can I bother you for a couple of early reviews? :) http://reviews.vapour.ws/r/123/ and http://reviews.vapour.ws/r/125/ [05:48] wwitzel3, is it cold already in fl ? [05:49] dimitern: my friends tell me no, not yet, I'm up in NC [05:49] (north carolina) [05:49] wwitzel3, ah, right [05:51] fwereade, hey, I know it's awful early, but can you take a look as well when you can? ^^ [05:59] dimitern: commented on http://reviews.vapour.ws/r/123/ [05:59] fwereade: I'd like your input on the idea of "Does adding a method require us to bump the API version" [06:05] dimitern: and a comment on http://reviews.vapour.ws/r/125/ [06:05] jam, thanks! [06:06] jam, well, it's the agent api, and if we needed to do that for the uniter api, we already missed the train a few times with the actions and metrics, etc. [06:07] dimitern: "we made mistakes in the past, so clearly we shouldn't stop making mistakes now" [06:07] jam, :) [06:27] jam, btw Tag() returning names.Tag is wrong [06:27] jam, it's only like that in state because of FindEntity() and things like that [06:28] jam, in other places, esp. in the api we should use proper tag types - return them and take them as args; that was one of davecheney's comments on one of my previous PRs [06:31] jam, introducing versions into the uniter api server facade, considering how big it is, will require massive changes to the PR [06:31] dimitern: grep -rnI "func.*Tag()" . shows an awful lack of common implementations [06:31] jam, yes, but we're moving towards better consistency in the implementations [06:31] dimitern: type UniterV1 struct { Uniter } is not particularly large [06:32] jam, and testing both versions without much code duplication will need all test suites to be refactored [06:33] dimitern: so I agree we should move towards consistency, though (IMO) having a consistent "you can call Tag() on objects to get a Tag describing it" seems useful, and Go tends to require that if you ever want to put those objects into an Interface the method has to return identical types [06:33] jam, like what I did for the firewaller [06:34] jam, yeah, that kinda sucks, esp. having to do apiuniter.Unit(stateUnit.Tag().(names.UnitTag)) [06:35] dimitern: I feel like the pain of Versioning is a pain we need to endure sooner rather than later, as there will always be "its a lot of work" for anything we want to do. [06:35] dimitern: I can live with us agreeing it isn't worth it [06:35] but we should discuss that with more than just 2 people [06:36] jam, much of the stir around serializing and deserializing tags for the api can be solved by making the tags handle that and use tags instead of strings in params/results [06:38] jam, so how about instead of adding a new version of the api in this PR, I add some fallback code in the uniter to handle IsCodeNotImplemented ? [06:39] dimitern: as stated, I don't want it to just be you and I that come up with what is good enough in this case. I want at least fwereade and maybe a wider agreement from the list. [06:39] dimitern: there is lots of ways we can reduce the work (like just using what you have right now which is even easier for you) [06:40] dimitern: but whatever we do is going to be precedent (like Metrics, etc), and I'd like the group to have decided what we are doing [06:41] jam, considering the rush to implement a lot of features in the past months, by different teams, even outside contributors, the mess will only get worse if we don't gate api changes with some process we agree upon [06:49] jam, ok, while waiting for consensus I'll switch to container addressability to prepare some tasks for breakdown and estimation [09:01] reviewboard's dead? :( === Spads_ is now known as Spads [09:36] axw, works for me btw [09:36] dimitern: it started working again [09:36] guess someone restarted it ... === fabrice_ is now known as fabrice|lunch [10:44] morning [10:47] morning perrito666 [10:47] jam, standup? [11:03] hi [11:04] I'm having problems trying to bootstrap a juju environment on amazon using the latest master [11:04] http://paste.ubuntu.com/8465277/ [11:08] fwereade: ping me if you have a spare moment [11:09] perrito666, I have to be out in 10 mins, let's be quick === jacekn_ is now known as jacekn === fabrice|lunch is now known as fabrice [12:21] mattyw: remember to get approval from someone more senior than I [12:22] perrito666, thanks very much for the review [12:22] and I will [13:50] ericsnow: wwitzel3 I am in the noisiest place ever, I am bailing out [13:50] of the call [13:50] perrito666: pity [13:50] perrito666: I need to talk to you about backups at some point [13:52] ericsnow: well if you need to I can squeeze myself into a quieter place [13:52] perrito666: it can wait [13:52] they seem to have these meeting booths [13:52] ericsnow: gimme a moment and Ill be there [13:52] cameraless as usual [13:55] ericsnow: I am in === cmars` is now known as cmars [14:16] ericsnow: wwitzel3 you both just froze [14:16] I guess itsme [14:16] perrito666: yep [14:18] ericsnow: I am having some form of connection error to hangouts [14:18] :( [14:18] man rainy days really kill internets here [14:18] I have lost dns [14:19] perrito666: :( [14:23] ericsnow: so, yes, scp approach is far from perfect if you are doing an upload/download mechanism I am sure there are better things to use [14:23] ericsnow: I dont remember very well now but voidspace had done something for download [14:23] perrito666: I'll see what I can come up with [14:23] maybe that can be used as a start point [14:23] perrito666: yeah, that's what I'm doing [14:23] perrito666: :) [14:52] oh, looks like my test error is a race. interesting, but ok, logically it made no sense [14:56] could somebody take a look at http://reviews.vapour.ws/r/124/ and http://reviews.vapour.ws/r/131/ ? Much appreciated! [14:56] tasdomas: looking [14:57] perrito666, thanks! [14:59] tasdomas: 131 has already been reviewed by me earlier [14:59] perrito666, thanks === seelaman is now known as IS_hr_bot === b is now known as Guest78070 === fabrice is now known as fabrice|family === urulama is now known as urulama-afk === Guest78070 is now known as bac === IS_hr_bot is now known as seelaman [15:32] tasdomas: done [15:54] perrito666, thanks [16:13] perrito666: care to stamp a trivial dep change for me? [16:14] perrito666: [16:15] mgz: looking === Ursinha is now known as Ursinha-afk [16:18] mgz: lgtm [16:19] ta [16:22] brb lunch === fabrice is now known as fabrice|family === uru_ is now known as urulama === Ursinha-afk is now known as Ursinha [18:47] 0 [18:48] I guess that is the number of things I'm winning at today [18:49] is there an easy way to get rendered URL and params of a FacadeCall? [18:51] figure a well placed Debugf should give me that .. [19:01] perrito666, what is your twitter handle? [19:02] klflvlv [19:02] v [19:02] v [19:02] v [19:02] v [19:02] v [19:02] v [19:02] v [19:03] hmmm [19:04] Going down. === urulama is now known as urulama-afk [20:15] alexisb: extremelite late ping, my twitter handle is: perrito666 [20:16] no surprise there :p [20:37] thanks thumper [20:37] np === Ursinha is now known as Ursinha-afk [21:04] thumper, hangout? or should i reschedule +1 hour [21:05] cmars: can we reschedule for 30min? [21:05] thumper, np [21:10] thumper: working on deploying to a power8 maas cluster from a amd64 client [21:11] thumper: we try to use --arch=ppc|64|64el|64le with no luck [21:11] looking at the juju help it does not list ppc* as a supported arch [21:12] shouldn't that be constraints? [21:12] thumper: do you know what the recomended way to deploy from an x86 client to ppc maas cluster [21:12] no I don't, sorry [21:12] juju deploy --constraints arch=ppc* [21:13] s/deploy/constraints/ [21:13] thumper can you confrirm ppc64* is a valid arch? [21:14] yes [21:14] I think ppc64, ppc64el and ppc64le all work [21:15] so 'juju bootstrap --constraints arch=ppc64' should work [21:15] * thumper crosses fingers [21:15] from x86 it fails miserably [21:16] trying from ppc64el [21:16] machine [21:18] arosales: fails how? and bug plz? [21:21] thumper: will file, just trying to get something to work. === Ursinha-afk is now known as Ursinha [21:21] mbruzek: has the details, but he is trying to get 1.20.9 to test that hypothesis [21:22] thumper: still cleaning up in response to your other points, but I updated http://reviews.vapour.ws/r/127/ with a couple questions for you [21:33] * thumper looks [21:33] jcw4: don't see your answers [21:34] thumper: hmm; last two points you made [21:34] basically you suggested when searching for actions or actionresults by actionreceiver that we could just use the receiver name instead of using docID on the receiver name [21:35] I was asking 1) don't we need to still include the EnvUUID prefix in the filter [21:35] and 2) can we safely ignore using QuoteMeta on the combination of env uuid and receiver name [21:38] 1) yes, but you can specify the uuid field [21:38] 2) avoid regex [21:38] thumper: +1 [21:38] thumper: so just reconstruct the prefix with uuid + receiver name [21:39] thumper: but can I search for matching actions by prefix without regex? is there a simple prefix search method I can use in the bson package? [21:39] jcw4: just look for the specific fields bson.D{{'env-uuid': envuuid},{'reciever': receiver}} [21:39] thumper: doh [21:39] thumper: got it [21:41] thumper: thanks [21:42] cmars: still around? [21:52] thumper: fuck [21:52] ingore mu half sent mail [21:52] PEBKAC [21:52] ack === thumper is now known as thumper-afk [22:27] anyone know where the FacadeCall stuff gets distilled down in to just a URL with params? I'm trying to Debugf the URL for the rsyslog facade calls. === mjs0 is now known as menn0 [23:09] menn0, can i trouble you to take a look at my versioned login API PR, https://github.com/juju/juju/pull/392 ? === benji is now known as Guest48087 [23:55] cmars: sorry, was having lunch. looking now. [23:56] hi