[00:21] thumper: http://stackoverflow.com/questions/7222062/mongodb-composite-key [00:30] davecheney, thumper wow... that looks very intriguing [00:30] jcw4: yeah, I'm going to write an email to juju-dev about keys in multi-environment servers [00:31] I'd like agreement and consistency before we dive head-first into schema changes [00:31] +1 [00:32] thumper: oh, I thought we were all going to propose out champion [00:32] then fight it out, thunderdome style [00:32] oh wait [00:32] that would be a bad idea [00:32] mad max did come from down under didn't he? [00:33] http://upload.wikimedia.org/wikipedia/commons/9/9d/07._Mad_Max_Car_at_Silverton_Hotel,_Silverton,_NSW,_07.07.2007.jpg [00:34] last of the V8 interceptors [00:34] sweet... I've been through that town dozens of times and never saw that [00:34] not [00:35] davecheney: I love that car [00:35] hmm... why am i staring down a variable named x if i'm not dealing with a coordinate system... [00:35] looks awesome [00:35] katco: haha, +1 on making it mean something [00:40] it is now named fishAndChips [00:40] (or configKeyValues... one or the other) [00:47] katco: like schrodingers cat? [00:47] well, it's definitely one or the other :) [00:48] hehe [00:55] does the Machiner api expose http://godoc.org/github.com/juju/juju/state#Machine? [00:57] btw, im working on a python3 api client for juju https://github.com/battlemidget/cloud-installer/blob/patch-split-core-logic/cloudinstall/juju/client.py [00:57] now trying to figure out the api requests for accessing the Machine data [01:01] or maybe api call to pull http://godoc.org/github.com/juju/juju/state/api#MachineStatus [01:04] stokachu: only the client api end points are callable by non-agents [01:04] stokachu: what is it you are really trying to do? [01:04] 17 minutew to land a change [01:04] NOICE [01:04] davecheney: \o/ [01:04] a grand improvement from this time last week [01:04] thumper, want to access the machine data without having to call juju status [01:05] o/ axw and wallyworld [01:05] stokachu: I don't think we allow that [01:05] davecheney: howdy [01:05] thumper, b/c no code exists or some other reason? [01:05] davecheney: yeah, I wish I made that change ages ago :/ [01:06] I think the fastest I've seen so far is 16m. It should be considerably faster again when we have a dedicated instance for the lander [01:06] our cloud-installer relies on calling out to juju and i want to remove all that in favor of the api [01:07] like i do with maas [01:07] stokachu: it think it was more to do with security [01:07] stokachu: so we didn't expose things to people who don't need them [01:08] so if i file a bug will it get closed wontfix? [01:08] not if there is a clear and useful need for it [01:08] and it doesn't expose places where we can get screwed up [01:09] if you're just exposing mostly read only it should be ok right? [01:09] and its already exposed in juju status so we could just mimic that [01:10] besides there is an api call to forcedestroy machines so i think you couldnt do worse than that :) [01:11] stokachu: could you not just use the status API? [01:11] why do you need another one? [01:11] thumper, the status api only returns machine_id: {InstanceId} [01:11] our cloud-installer requires information that isn't exposed by the api [01:12] stokachu: you want to get machine status? http://godoc.org/github.com/juju/juju/state/api#Client.Status ? [01:12] {"RequestId":2,"Response":{"Machines":{"0":{"InstanceId":"localhost"},"1":{"InstanceId":"adam-local-machine-1"},"2":{"InstanceId":"adam-local-machine-2"},"3":{"InstanceId":"adam-local-machine-3"}}}} [01:12] thats all thats returned from the Status api call [01:12] huh [01:13] stokachu: what version of juju? [01:13] 1.18.4 [01:13] menn0: ^^ does this have anything to do with the FullStatus changes? [01:13] I think there may be some fallback code for 1.18 [01:13] stokachu: that just seems wrong [01:13] theres a LegacyStatus call [01:14] status definitely returns more than that [01:14] godoc.org/github.com/juju/juju/state/api#MachineStatus [01:14] https://github.com/battlemidget/cloud-installer/blob/patch-split-core-logic/cloudinstall/juju/client.py#L80-L83 [01:14] thats the request parameters i use [01:15] stokachu: I think you actually want to call "FullStatus" from 1.18+ [01:15] lemme try that [01:15] it's hidden by the API [01:16] https://github.com/juju/juju/blob/master/state/api/client.go#L145 [01:16] line 157 shows "FullStatus" being called [01:17] axw, calling FullStatus works [01:17] \o/ [01:17] should Status call that in later versions I guess? [01:18] cool [01:18] or is FullStatus in process of being documented [01:18] stokachu: in the Go code it does: the client method is called Status, but it calls FullStatus under the hood [01:19] was that introduced after 1.18.x? [01:19] just trying to understand why calling Status failed [01:19] well failed to pull FullStatus [01:20] i see where its called in the latest api code [01:20] we don't have versioning (yet) on APIs, so if the structure of the parameters becomes incompatible we have to change the API name [01:21] ah ok [01:21] thumper, yea this was what i was looking for [01:22] stokachu: so it was actually introduced as a stub in 1.16, but I think full functionality didn't arrive till 1.18 [01:22] gotcha [01:23] func (c *Client) Status() (api.LegacyStatus, error) { < - this api.LegacyStatus why it doesn't show the FullStatus properly? [01:28] stokachu: I don't really recall whether that was all it ever had, or if it was purposefully hobbled. We used to go directly to mongo to get the status of entities, but I can't remember what part the API had [01:28] ok cool [01:43] you don't need to explicitly call setupsuite on an embedded suite if you only have one right? [01:44] waigani: correct [01:46] thumper: thanks [02:12] what are some examples of jujuconnsuite being overused/wrongly used? [02:12] menn0: ^? [02:14] waigani: I believe there's some suites that don't actually use an API connection but still embed JujuConnSuite (probably due to copy and paste) [02:14] waigani: there's also a bunch of suites that should be mocking the API instead of using a real API connection [02:14] menn0: ah right, thanks [02:18] when testing ops on docs, should that be mocked or not (that sounds like a bad Dr Seuss rhyme)? [03:13] a bunch of NUCs with SSDs actually makes deployment with juju and maas quite painless [03:20] waigani: wallyworld axw thumper https://github.com/juju/testing/pull/19 [03:20] small cleanups for the testing package [03:22] davecheney: given that you are always telling us not to throw away the err... [03:22] why are you? [03:24] i can't be bothered extending that massive if condition [03:24] someone else can later if they want [03:54] axw: is the environment name for machine placement actually every checked? [03:54] thumper: I forget. it's mainly there for future usage [03:54] I'll check [03:54] hmm... [03:54] I'm trying to hide the EnvName from the environment command [03:55] so I can allow passing of everything through command line or environment [03:55] so may not have a name referring to something on disk [03:56] thumper: it is checked in apiserver/client.Client.addOneMachine [03:57] thumper: why do you want to hide EnvName? [03:57] I don't quite understand [03:57] because env name is getting confused [03:57] it isn't really the env name at all [03:58] but a local alias to an environment uuid/username pair [03:58] in order to support better scripting [03:58] right [03:58] we want to be able to have a script define an environment [03:58] a set of env vars [03:58] that the juju commands can just use [03:58] so the machine that the script is run on [03:58] * axw nods [03:58] doesn't need the cached environment connection files [03:58] so... [03:58] EnvName may well be blank [03:59] so in a prep branch [03:59] I'm trying to hide it [03:59] ok [03:59] and provide functions to get a client api [03:59] and other bits where it is used [03:59] it is surprising how much data creep there is [04:00] thumper: I *guess* the placement scope should be translated from environment name (alias) to uuid+username then [04:00] if you have something public, people will use it [04:00] heh :) [04:00] and use it in unexpected ways [04:00] right [04:00] axw: uuid would probably be sufficient [04:00] yeah I guess, user is implied [04:00] * thumper nods [04:08] axw: actually, there is a problem with this code... [04:08] axw: if I rename my connection file [04:09] axw: this won't work [04:09] axw: because it will say "invalid environment name" [04:10] yeah... that will need to change if we're not requiring the .jenv to be there [04:10] axw: also if I just rename my jenv file [04:11] my local aliase won't match the environment name [04:11] oh man [04:11] so much for being a quick and easy branch [04:11] fucking tenticles everywhere [04:12] thumper: I thought we were going to have a command to create a .jenv file from connection settings? [04:12] we probably are [04:12] but if I specify everything on the environment [04:12] I don't want it touching the file system [04:12] fair enough [04:35] coffee time === vladk|offline is now known as vladk === vladk is now known as vladk|offline === benonsoftware is now known as Guest69253 === vladk|offline is now known as vladk === vladk is now known as vladk|offline === vladk|offline is now known as vladk === vladk is now known as vladk|offline === urulama is now known as uru-afk === vladk|offline is now known as vladk [06:48] morning === uru-afk is now known as urulama === vladk is now known as vladk|offline === vladk|offline is now known as vladk [07:46] morning [08:37] voidspace: morning [08:56] TheMue, voidspace, hey [08:57] I'd love a review on this https://github.com/juju/juju/pull/243/ [08:57] the parsing of environment.yaml fails if there is a line with a tab ('\t') but without entry of attributes. looked at LP for such bug and couldn't find one. using juju 1.19.4 [08:58] let me know if this is not reported yet [09:05] dimitern: *click* [09:06] urulama, so is it valid yaml? [09:06] TheMue, ta [09:06] dimitern: yes, replacing tabs with spaces worked [09:07] dimitern: the parsing only fails if there are tabs as prefixes to attributes [09:07] urulama, using tabs in a yaml file is forbidden [09:07] urulama, http://www.yaml.org/faq.html [09:08] dimitern: yes, however, imagine user with an editor that automatically ads tabs ... [09:09] urulama, I'm not saying it can't happen, but this is like saying "invalid html should still show up correctly" :) [09:10] urulama, what's the error you're getting? [09:10] dimitern: not saying it's a bug, maybe a "usability error" ... maybe adding "don't use tabs" in description could help a bit [09:11] dimitern: it's simply "ERROR: couldn't read the environment" [09:11] urulama, right, I agree it's a usability issue and please, file a bug for it, so we can keep it in mind [09:11] dimitern: ok [09:14] urulama: yaml is a ridiculous format :-) [09:20] mgz, hey [09:20] mgz, is goose still on launchpad ? [09:22] dimitern: you’ve got a review [09:23] voidspace: still troubles merging the replica set test? [09:26] TheMue, thanks [09:28] dimitern: it’s nice to see how IPv6 soaks into the code (hope I took the correct verb) [09:31] TheMue, yeah :) [09:58] TheMue: yep [09:58] mgz: ping [10:00] morning [10:00] perrito666: morning [10:00] mgz: https://github.com/juju/juju/pull/238 [10:00] mgz: this got a "merge request accepted" 18 hours ago but hasn't been run [10:00] mgz: meanwhile other ones have [10:11] voidspace: looking [10:13] voidspace: see job 371 [10:13] ec2 fell over, I'll requeue on the bot [10:15] ah, I did have a look to see if it ran [10:15] I must have missed that [10:15] mgz: ah, but it was marked as failure - the bot didn't see it though? [10:16] " [10:16] InvalidInstanceID.NotFound: The instance ID 'i-7444355f' does not exist" [10:16] yeah, made teh job fall over in such a waay as it didn't get to the reporting back step [10:17] wwitzel3: ping for when you're around [10:17] wwitzel3: and fully caffinated === urulama is now known as uru-afk === uru-afk is now known as urulama [10:45] dimitern: TheMue: I'll be five minutes late to stdup - sorry [10:45] voidspace, no worries [10:47] vladk, standup? [10:58] how do standups work when everyone's remote? [11:02] I would greatly appreciate a second look at https://github.com/juju/testing/pull/18 [11:02] ChrisW: hangout [11:03] voidspace: it failed again, really strange [11:04] perrito666: will take a look in a few moments, just have to change place (too warm on the verranda) [11:04] TheMue: 1st world problems :p [11:04] hehe, indeed [11:08] TheMue: yep, they look completely unrelated though [11:08] TheMue: I tried again locally and everything passes [11:10] voidspace: so there seems to be something different on the ec2 hosts [11:10] voidspace: looks like the run's tests failed, but the pr should be back in a sane state now [11:11] TheMue: mgz: yeah, I've tried again in the hope that it's spurious [11:12] that one of the failures is in a new test (..BothIPv4AndIPv6) isn't encouraging [11:12] juju-gui totally written in JS? [11:12] looks like new flakiness [11:14] ChrisW: yes, it uses a Python server when deployed using the Juju GUI charm, which enables some additional features (like bundle deployments) but the core application is client-side JS [11:15] fascinating :-) Interesting to see that most of the juju-gui team appear to be ex plone/zope people :-) [11:18] ChrisW: :-) it used to be like that, but now we have some great JS guys in the team [11:19] perrito666: review done, with a minor comment. [11:19] TheMue: thank you very much [11:19] perrito666: yw [11:19] heh, you saying plone/zope guys aren't great with JS? ;-) [11:54] voidspace: yay, it merged [11:58] awsome [11:58] TheMue: at last :-) [12:01] voidspace: somehow strange that it had so much troubles. if it would be a failing test, and always the same, then the problem can easily be located [12:01] voidspace: but it looks absolutely strange here, once even a panic during build [12:42] hi all, it seems 1.20 inadvertently changed the structure returned by the mega-watcher for machines. please see bug 1337831. Even if the quickstart fix should be easy enough, it's worth noting this seems to be an accidental change to the public API [12:42] <_mup_> Bug #1337831: Quickstart crashes when used with juju 1.20 [12:42] fwereade: ^^^ === psivaa-afk is now known as psivaa === vladk is now known as vladk|offline === vladk|offline is now known as vladk [13:35] fwereade: shall we have that chat some time? [13:38] people anyone would like to take a second look to https://github.com/juju/utils/pull/4 before I merge it? It has only been reviewed by me === urulama is now known as uru-food [13:42] perrito666: *click* [13:43] TheMue: you are the on call reviewer and I am making your day hell? [13:43] uh, I am on call reivewer [13:44] :p [13:44] its a good thing I have been reviewing since I got up [13:44] *lol* === vladk is now known as vladk|offline === vladk|offline is now known as vladk === uru-food is now known as urulama === vladk is now known as vladk|offline === wallyworld is now known as Guest27426 [14:34] morning all [14:34] blam blam 'murca [14:35] good morning all :) [14:38] i came across a curious few lines. should this panic be removed? c.Assert(scripts[0].line, gc.Matches, pats[0].line, gc.Commentf("line %d", scripts[0].index)) [14:38] panic("unreachable") [14:39] katco: morning, isnt today a holiday for you? [14:39] perrito666: it is [14:39] but i want this change in before boston so i don't lose that velocity. i'm almost done. really should have finished it yesterday [14:40] plus coding is what i do for fun :) [14:41] i promise i'm not this much of a workaholic... i just like to do deep dives to get going. i hope i'm not giving a bad impression =/ [14:42] katco: you're on probation... too much of this workaholic stuff and BAM [14:42] :) [14:42] lol [14:42] katco: morning [14:42] no really, back when i was a lead i actively discouraged this kind of thing. [14:43] but i don't like staying new for too long ;p [14:43] TheMue: good morning :) [14:43] katco: +1 [14:44] katco: those unreachable-panics are from earlier times, when Go wanted a return (or panic). today it detects when a code is unreachable. [14:44] katco: so IMHO they can be removed [14:44] TheMue: ahh! ok that makes a lot more sense [14:46] gosh... changing upstart config files just breaks all kinds of tests [14:46] spending more time fixing the tests than the bug [14:47] that is true for almost anything in juju [14:47] I am still fixing ripples from 2 lines I changed on agent [14:47] hmm... i have been watching with great interest discussions about what level of testing is sane, and how not impact architecture just for the sake of testing === vladk|offline is now known as vladk [15:12] so, preparing for football, I’m off [15:12] katco: that's a very interesting subject [15:12] katco: it's something i struggle with all the time [15:12] rogpeppe: i really think so. testing has kind of crept in and become this thing you automatically do [15:12] rogpeppe: as always, have to find the middle way :) [15:13] katco: i think that 100% testing is often a necessity in dynamically typed languages, but i think can be overkill in a statically type lang [15:14] katco: i personally don't mind leaving "obviously trivial" pieces of code untested, particularly when the impact of failure will be obvious when the code is actually run [15:14] katco: but then again, i have also had my share of places where those pieces of code were actually wrong in some way [15:15] rogpeppe: yeah, same here [15:16] katco: the classic example is: func SomeValue() string {return "some value"}; then the test is func TestSomeValue(c *gc.C) {c.Assert(pkg.SomeValue(), gc.Equals, "some value")} [15:16] katco: is that test really worth writing? [15:16] i would say no on that one :) [15:16] katco: it's a slippery slope :-) [15:16] i operate on the philosophy that tests reduce velocity, so they need to be on trial [15:16] but yes, definitely a slipperly slope [15:17] i also operate on the philosophy that smart devs are smart, and we should rely on their good judgement and not make uniform statements like, "all code should be tested" :) [15:17] katco: i agree entirely. i love tests of tricky code, but the tests in juju are also a real burden we are constantly having to bear [15:18] i have spent the last day trying to understand a test... i don't know, i know i'm new, but that seems like an issue [15:19] heheh... there are some really hairy ones [15:19] this particular one sets up a giant string, then there's a function that splits it on newlines, loops over the newlines, and performs regex escaping magic [15:19] about drove me batty! :p [15:20] check out worker/uniter/uniter_test.go.... that's where I've been poking around for a week or two [15:20] I've never seen anything quite like it [15:20] lol [15:20] should tests be more complicated than the code they're testing? [15:20] interesting question [15:21] there's a cost/benefit between ease of test creation, vs simple extendability if you're testing a very featureful package, I think === urulama is now known as uru-away [15:22] that uniter test is a great example, because while it looks huge, and weird, and complicated at first glance, it makes it very simple to add new tests as sequences of steps === vladk is now known as vladk|offline [15:23] yeah, i see the benefit of that angle [15:23] and, there are tons of tests in it (which is itself probably not a great thing) [15:23] i suppose in that case a few comments explaining the framework would go a long way [15:23] yes... lol [15:24] well this is very interesting. i don't feel quite as dumb as i did yesterday ;) [15:24] having said that... i think i'm _finally_ ready to land this change [15:25] and then i can get on with my holiday! :p [15:25] it was a bit of a ramp up for me as well, but somehow the illusion of complexity keeps dissolving into clear simplicity as I keep digging [15:25] I'm not sure whether to blame Go or the smart people writing this code :) [15:26] go does seem to force me towards good simple code. it's one of the reasons i love it [15:27] katco: usually that is the programmers skill, I have yet to see a language that forces people into writing good code [15:28] perrito666: i definitely agree. but i have hit brick walls in go, and a week later i realize it's because there's a much simpler way. i.e.: i was fighting the language [15:29] ok here we go... 2nd PR: https://github.com/juju/juju/pull/245 [15:29] definitely appreciate feedback on this one [15:31] katco: did you do the autosquash part before submitting this? [15:31] perrito666: no i forgot... i thought about going back, but the documentation says "optionally" [15:31] i can definitely go back and do it if you like [15:33] katco: hey, if it says optionally, who am I to say something :p [15:34] perrito666: lol i really don't mind. i plan on doing it in the future. i just want to land this thing! [15:53] perrito666: happy to discuss in addition to the comment i just made. just lmk. i think it's a relatively safe change. [15:59] perrito666: i have to step away for a bit. please lmk if/when i can land this so i can sign off for the weekend! [15:59] bbiab [16:05] katco: ok, with context now, it seems fine, if you want to get another review from someone here even better if not, go ahead and merge it, I trust you ran all the tests :) [16:11] perrito666, katco I scanned through and it LGTM too [16:11] I can add a comment if wanted [16:33] fwereade: are you done yet, or time for a little more resources discussion? [16:34] rogpeppe, let's, but gimme 5 mins [16:34] fwereade: sure [16:37] perrito666: jcw4: tyvm; i did run through all the tests. landing now [16:42] katco: you're being a guinea pig for me, don't be alarmed by spam on or pr [16:43] mgz: haha ok [16:43] keep in mind that after this lands i'm outta here! [16:44] katco: ideally, you won't see anything, so it should be fine :) [16:44] jsut futzing with the landing job [16:44] mgz: sure, sure! i've heard that before! ;) [16:48] pro tip: vivaldi's "summer" makes anticipating the build result much more exciting [16:50] katco: not The Ride of the Valkyrie's ? [16:50] rofl [16:50] hm, labix.org seems to be being not super-reliable [16:50] summer is more dynamic... will it build? it will! or will it?? (bites nails) [16:50] hehe [16:50] mgz: his cert expired [16:50] ah, thanks [16:59] workflow question: supposing this lands successfully, do i mark the bug on launchpad as "Fix Committed"? [17:01] katco: yup [17:16] hallelujia i'm done with this change! lol [17:16] alright all, i will see you fine people next week! [17:16] happy 4th! [17:16] same! [17:18] katco: see you next week :) === vladk|offline is now known as vladk [18:42] g'night all [18:42] some of you I'll see on Monday [19:38] fwereade_: you around? [19:38] bac, kinda sorta [19:38] bac, what can I do for you? [19:38] fwereade_: should be quick. can you explain ian's point in the last comment at https://bugs.launchpad.net/juju-core/+bug/1316174 [19:38] <_mup_> Bug #1316174: 'precise-updates/cloud-tools' is invalid for APT::Default-Release [19:39] fwereade_: on precise i have installed juju-core and juju-local. i expect that to be sufficient but i cannot bootstrap an lxc environment due to this bug. [19:41] bac, I think he's saying "we will fix this by checking whether the user can get the right version of mongodb and fail before getting that far", and I hope it also implies "we will explain what the problem is and how to resolve it in the error message"" [19:41] fwereade_: is there a work-around? [19:43] bac, I'm not immediately sure, I'm afraid, but I had *thought* that installing juju-local should be sufficient [19:43] fwereade_: ok. i'm trying to qa juju-quickstart and it is currently broken on precise. i'll update the bug with questions for ian. thanks for your time past eod. [19:45] bac, i suspect that https://bugs.launchpad.net/juju-core/+bug/1289316 and https://bugs.launchpad.net/juju-core/+bug/1290890 are also relevant, but I don't have enough context to know what';s really going on [19:45] <_mup_> Bug #1289316: lxc not installed from ubuntu-cloud.archive on precise

[19:45] <_mup_> Bug #1290890: juju 1.17.5 RC cannot deploy to precise

[19:45] wwitzel3, ^^ === vladk is now known as vladk|offline