[00:16] thumper: another intermittent test failure fix: http://reviews.vapour.ws/r/1877/ [01:44] * thumper looks [01:47] menn0: can I bother you for a small txn assert fix? http://reviews.vapour.ws/r/1879/ [01:52] axw: sure [01:52] looking [01:53] thanks [01:56] axw: is the single worker responsible for block device updates a singular worker? [01:56] menn0: hah, good point. I'll check, but it doesn't actually matter anyway [01:57] axw: yeah I think I agree, but if it isn' then one of your points isn't accurate :) [01:57] menn0: it's instancepoller, and no it's not (should it be?) [01:57] menn0: I'll update the description ;) [01:58] axw: not sure if it should be or not [01:58] axw: i don't know much about instancepoller [02:05] axw: does setAddresses get called with the complete list of current addresses? [02:07] menn0: it's called with the in-memory ones. hmm, I guess it should really refresh shouldn't it [02:08] axw: that's what I was thinking [02:08] axw: otherwise there is a concurrent update problem [02:09] menn0: I'll write a test and fix, and poke you again in a bit [02:09] axw: sounds good [02:09] axw: i'll publish the one minor comment I had now [02:09] thanks [02:10] coffee time [02:37] waigani: thanks for fixing that bug [02:37] axw: np :) thanks for the review [02:38] menn0: PTAL. I changed it to not use a txn loop anymore, since it'll never leave the state that fails the assertion [02:38] axw: will do. otp [03:10] axw: i think your change is probably ok b/c everyone who sets address should be trying to set the same thing [03:11] axw: the only problem I can see is if one of the address setting processes is slow and so ends up overwriting a more recent (and correct) set of addresses with a stale set [03:12] menn0: that would still happen before. it'd just have gone through the txn loop twice [03:13] * menn0 nods [03:13] axw: i guess it would [03:14] menn0: it shouldn't be a major issue anyway, since the updates are periodic [03:15] axw: and i just noticed that the addresses are refreshed before every update as well now too [03:15] axw: which helps [03:15] yep, thanks for picking that up [03:17] axw: ship it! [03:17] menn0: thanks [05:13] thumper: big debuglog refactoring... preparation for upcoming db log changes: http://reviews.vapour.ws/r/1883/ [05:13] thumper: another refactoring branch to come [05:33] menn0: done [05:33] * thumper heads off [05:57] Bug #1462874 opened: Collapse workload-state and agent-state into state [07:01] jam, morning [07:01] jam, 1:1 ? [08:06] dimitern: ping [08:06] TheMue, sorry, omw [08:07] TheMue, in the mean time http://reviews.vapour.ws/r/1884/ ? :) [08:07] dimitern: hehe, ok [08:55] dimitern: thx for fixes, looks good [08:56] TheMue, thanks for the review :) [09:02] dimitern: hangout? [09:09] dimitern: it's pushed http://reviews.vapour.ws/r/1860/ [09:09] dimitern: when you have time [09:09] voidspace, cheers, will have a look shortly [09:20] dimitern: you've frozen [09:20] voidspace, where? [09:20] dimitern: are you still in the hangout? [09:21] voidspace, no [09:21] heh [09:21] ok [09:21] voidspace, :)I'm looking at your PR and will join our 1:1 hangout in a bit [09:21] dimitern: ok, I'll grab coffee [09:32] * TheMue is afk, bike ride to co-location office [09:33] voidspace, LGTM, I'm in the hangout btw [09:33] dimitern: omw [09:38] Morning al [09:57] dimitern: do I need to manually merge my branch into a feature branch? [09:57] dimitern: https://github.com/juju/juju/pull/2493 [09:57] dimitern: I thought the bot could handle feature branches [09:58] mgz_: ^^^ [09:58] dimitern: mgz_: never mind... [09:58] my page was just stale [09:59] it has already happened... [09:59] :-) [09:59] voidspace, yeah, all good [10:07] Bug #1461529 changed: juju upgrade-charm has no effect for subordinate charms

[10:14] voidspace, we need to sync up the devices branch with master [10:14] voidspace, before it diverges too much [10:25] dimitern: ok, I'll create a PR [10:25] voidspace, cheers! [10:31] dooferlad, omw [10:34] dimitern: https://github.com/juju/juju/pull/2520 [10:37] Bug #1462966 opened: worker/provisioner: multiple data races

[10:41] voidspace, it's just a straight merge right? [10:42] voidspace, LGTM [11:04] dimitern: yup, straight merge [12:03] jam: you around for the system image meeting? [12:44] hi frankban_, now that i'm home i see the results from 'make fcheck' i ran friday afternoon [12:45] bac: cool, any problems? [12:45] frankban_: yeah, quite a few failures [12:45] bac: weird it works here [12:45] frankban_: let me paste them [12:46] frankban_: http://paste.ubuntu.com/11648474/ [12:47] frankban_: was i supposed to have an environment bootstrapped before running the tests? [12:47] bac: so those seems related to the charm hook failing rather than quickstart. [12:47] bac: no, no environment should be bootstrapped [12:47] bac: I presume this is related to the lp outage [12:48] frankban_: ah, yes. [12:48] bac: functional tests use the network [12:48] bac: because charm isntallation requires network access [12:48] bac: perhaps if you run them again you'll see them passing [12:48] bac: make ftest could be faster [12:49] frankban_: ok, i'll try again. i have no idea if LP is more accessible today than friday [12:49] bac: yeah, but I run ftests this morning for another branch and they passed [12:49] ok [13:00] axw: perrito666: just finishing another meeting, be there is a sec [13:22] wwitzel3: fyi, they cable company is messing with my line. i might go dark for a bit. if i do, just have the standup w/o me [13:23] wwitzel3: 1st day of the iteration, shouldn't be too much [14:29] Bug #1461954 opened: failed to unmarshall 503

[14:29] Bug #1463047 opened: TestUpgraderRetryAndChanged fails

[14:34] katco: standup was as you'd expect :) [14:38] Bug #1463053 opened: NetworkSuite setup fails

[15:01] dimitern: ping [15:03] voidspace, pong [15:04] dimitern: so in the container broker we're *already* populating the MAC address [15:04] dimitern: using the template [15:04] dimitern: const MACAddressTemplate = "00:16:3e:xx:xx:xx" [15:04] dimitern: so the current code will put that into the XML for every KVM instance... :-) [15:05] dimitern: I seem to recall you wanted to deliberately override any mac address coming from anywhere else [15:05] dimitern: can you remember why? [15:05] dimitern: this is lxc-broker.go:566 [15:05] voidspace, that's because the lxc package understands :xx:xx and renders them to be unique [15:05] voidspace, we have to do the same for kvm I guess [15:06] voidspace, feel free to drop or changethe MACAddressTemplate [15:06] dimitern: well, I'll replace it with a *specific* mac address [15:06] a generated one [15:07] still within that template [15:07] that template range [15:07] mmpf, does anyone else have the problem of the comment button on rb not creating a text box? [15:08] voidspace, sgtm [15:21] dimitern: I think the rand package on play.golang.org may not be entirely random... [15:21] dimitern: this code always generates the same MAC address... [15:21] dimitern: http://play.golang.org/p/0wHt2bd9YX [15:21] either that or results are cached [15:21] dimitern: note that in that code I have to use []interface{} to pass to Printf (or Sprintf in the real code) [15:21] voidspace, will look in a bit [15:22] dimitern: ok [15:22] dimitern: I wondered why, I think that go is doing a shortcut when you unpack a slice in a call and collect them back up in a function definition [15:22] and []string can't be converted to []interface{} [15:22] natefinch: you'd probably know [15:23] natefinch: : http://play.golang.org/p/0wHt2bd9YX [15:23] natefinch: change []interface{} to []string and watch it fail [15:23] natefinch: that surprised me [15:23] (although I know you can't cast an arbitrary slice to []interface{} - but in this case it's Go doing the cast not my code) [15:26] voidspace: well, you're passing a []string into something expecting a []interface{}.... so it is you :) [15:26] natefinch: well, I'm unpacking it [15:26] natefinch: the call is "digits..." [15:26] right [15:26] so I'm *not* passing the slice [15:27] I suspect that as Printf is packing back into a slice there's a shortcut that is a cast [15:27] I think that's just syntactic sugar, so that Go knows you mean to pass each value in separately, rather than the whole slice as a single value [15:27] which doesn't work [15:27] natefinch: right, but it's *not* passing them in spearately [15:27] casting a string to an interface{} would work, right? [15:27] correct [15:27] voidspace, generating the same mac address seems to be related to not initializing rand seed (or just a quirk of the playground) [15:28] dimitern: yeah, I expect so [15:28] was noting it more than asking a question :-) [15:28] it was the failed cast that I actually wondered about [15:31] voidspace: I do think it's a little surprising, but it is actually documented as simply being passed in that way: If the final argument is assignable to a slice type []T, it may be passed unchanged as the value for a ...T parameter if the argument is followed by .... In this case no new slice is created. [15:31] from http://golang.org/ref/spec#Passing_arguments_to_..._parameters [15:31] voidspace, why not generating a slice of uint8 and converting that to a mac address? [15:33] voidspace: that snippet of your was very pythonic, btw [15:33] dimitern: would that actually be less code? [15:34] natefinch: thank you [15:34] wwitzel3: cool, ty :) [15:34] voidspace: it's not a good thing when you're writing go ;) [15:34] natefinch: it's *always* a good thing ;-) [15:35] Python has better primitives for generating hex strings... like a hex built-in [15:35] although maybe Go has one too, I didn't look very far to be fair [15:36] ah, I can use %x [15:40] voidspace, I don't know, just a suggestion :) [15:40] dimitern: using hex.EncodeToString seems the best way - I still need to generate three of them [15:40] dimitern: as I need them colon separated [15:40] natefinch: thanks for that reference by the way, useful [15:41] natefinch: it is surprising, and has the downside that you can never unpack a slice into a call that accepts []interface{} [15:41] dimitern: leaving from colocation now back home, but should be there when net meeting is starting [15:47] natefinch: would you still say this is pythonic? [15:47] natefinch: http://play.golang.org/p/QfCqUYZ5P3 [15:47] natefinch: if so, could you explain what a more go-thonic approach would be? [15:48] (I could just put three calls to rand.Intn(256) into the Printf call - but that seems a bit gross) [15:48] voidspace: haha, I have exactly that code in my playground buffer [15:48] natefinch: heh, cool [15:48] I just didn't know about %x [15:49] but then I didn't look very hard [15:49] natefinch: thanks [15:49] voidspace: I can't make it 0 pad the result though... so <17 is a single difit [15:49] digit [15:49] er <16 [15:49] ah [15:49] yes [15:49] %0x should work , but doesn't somehow [15:49] maybe generating 6 digits is better then [15:50] TheMue, no problem [15:50] voidspace, EncodeToString sounds reasonable [15:51] dimitern: %x does that anyway (under the hood) [15:51] natefinch: :%02x" [15:51] voidspace: ^ [15:52] perrito666: thanks [15:52] oh, right... [15:53] perrito666: the documentation for that is not good [15:53] natefinch: it is not I just learned all that stuff by trial and error while doing nolog [15:54] perrito666: it's the way C/C++ do it... but the actual language in the Go doc is confusing. [15:55] it is not the clearest formatting indeed [16:30] Did we make any changes to juju-log in the latest 1.24-beta release? [16:30] i'm not seeing anything in the project milestone changes that would indiciate it has https://launchpad.net/juju-project/+milestone/1.24-beta5 === kadams54 is now known as kadams54-away [17:45] Does anyone have a moment to help me troubleshoot what info i shoudl be dumping into a bug? i've been able to reproduce the above consistently in the latest juju-1.24-beta6.1 release with unit commands hanging indefinately while attacehd to the unit via debug-hooks. [18:07] heres what i have, and hopefully its got enough information to reproduce: https://bugs.launchpad.net/juju-core/+bug/1463117 [18:07] Bug #1463117: Juju 1.24-beta6.1 unit commands hang indefinately

[18:08] Bug #1350171 changed: windows service needs to implement Exists [18:08] Bug #1449617 changed: service.Service implementations are missing functional tests.

[18:08] Bug #1463117 opened: Juju 1.24-beta6.1 unit commands hang indefinately

[18:09] lazyPower: thanks for the report, I think I bumped into that a couple of weeks ago and then missed it [18:10] perrito666: yeah, its really confusing at how specific and isolated it is [18:11] the fact when you detach and re-execute, leads me to beleive its something minor like a variable not making it into the context for auth w/ the socket or something. [18:11] and it only cropped up in this beta 6.1, it was working as expected in beta-5 [18:13] katco: I swear I am not trolling [18:13] perrito666: lol [18:13] worth the clarification [18:13] perrito666: as someone who did not grow up with twitter, the 140char limit is infuriating [18:13] katco: it is and it outlived its purpose long ago [18:14] perrito666: what i mean to say is patterns are the canonical way to solve a problem. they have been uncovered by people over the years [18:14] perrito666: if someone uses the wrong tool for the job, that doesn't make the pattern wrong, it makes the developer wrong [18:14] katco: patterns are the canonical way to communicate a solution, at least from my pov [18:14] perrito666: yes, and that label implies a way of doing something [18:15] katco: yes, but, as any other convention it is only useful if properly adopted [18:15] perrito666: yep [18:15] perrito666: but i disagree with the rally cry of "down with design patterns" [18:15] so if the amount of people using a convetion in the wrong way is larger than the people using it right, it means the convetion is not useful since people cannot adopt it [18:15] perrito666: to me it is tantamount to saying "down with vocabulary" [18:16] * perrito666 will hold a troll comment about english vocabulary :p [18:16] perrito666: but we're not talking about conventions, really. patterns are patterns because no one has discovered a better way. [18:17] perrito666: ignoring past exploration into the problem makes no sense to me. [18:17] to me, too often it obscures the actual logic behind the code. "Visit" should never be a function name in your code (unless you're running AirBNB or something) [18:17] natefinch: well if someone implements a pattern verbatim then its cargo culting [18:17] also, they tend to overcomplicate the problem for dubious benefit [18:18] like, if I tell you "solve this with a product consumer" you will most likely know what I mean but not implement the example out of wikipedia [18:19] the issue is that there are a ton of cutpasters that call themselves developers [18:20] aghh why do I keep having to do changes to things that lack tests and end up implementing the whole thing [18:20] heh [18:22] sorry, actual work stuff distracting me :) natefinch: if they don't have a benefit, then you shouldn't be using them [18:24] katco: did you just tautologized nate? [18:24] :p [18:24] perrito666: well that's kind of my point... the argument against patterns seem to be "but when i don't need a pattern and i use it, it doesn't provide value" [18:24] perrito666: i'm trying to point out that the utility is a f(developer) not f(pattern) [18:25] katco: that's what I keep telling people who keep using patterns, but they were published in a book by some people known as a gang, so they must be good. [18:26] for example, the visitor pattern turns simple iteration into callback hell. Case in point: http://golang.org/pkg/path/filepath/#Walk [18:27] natefinch: i don't think you understood me. patterns are just code that solve specific problems, and the community has given them names [18:27] natefinch: if the costs outweigh the benefits, then don't use that code [18:27] natefinch: but that doesn't make the code intrinsically useless === kadams54-away is now known as kadams54 [18:29] katco: but by giving it a name and a default structure, it makes people think they have to use the whole thing, or it's "wrong", rather than just using the idea behind the pattern. "Hey, you can let the object handle its own iteration, so you don't have to duplicate that code everywhere!" "Oh, neat idea!" [18:30] natefinch: once again, problem with the person, not the label [18:30] katco: but a *lot* of people. [18:31] katco: I wouldn't use the term "code" for patterns, they are just an idea on how entities can collaborate elegantly to solve a task, simplifying the communication about it between developers [18:31] TheMue: right [18:32] sinzui: I have a bizarre thought.... do we really need anything other than the juju client built via ubuntu's methods? Jujud just gets downloaded via simplestreams... in theory that jujud could be built however we want it to be, right? [18:32] natefinch: a pattern is a truth. it exists regardless of adoption. saying "don't use it" is like saying "a lot of people get predicate calculus wrong, so no one use it" [18:32] Bug #1449617 opened: service.Service implementations are missing functional tests.

[18:32] Bug #1463133 opened: migrateLocalProviderAgentConfigSuite teardown fails

[18:32] Bug #1463135 opened: TestUniterHookSynchronisation fails

[18:33] katco: a lot of the reason I like go is because it takes a lot of existing solutions and says "don't do that". For example, pointer arithmetic, operator overloading, etc. [18:33] natefinch: you're right that many developers think that they have to code and name exactly like in the patterns, that's surely naive. [18:34] natefinch: my talk at gophercon will be attempting to convince people that go is not an excuse to ignore the lessons learned over the past 30, 40 years :) [18:34] natefinch: this is a great example [18:34] natefinch: oh, coming to go, even go has "patterns". they are only called idioms here. ;) [18:34] katco: Oh, I'm not ignoring them. I'm actively trying to kill them with fire ;) [18:34] natefinch: that's like trying to kill the number 5, it makes no sense [18:35] katco: I hate the number 5. [18:36] :D [18:36] natefinch: correct [18:36] natefinch: and yet its existence is implicit to the universe, with no regard to your feelings ;) [18:36] sinzui: that was not the answer I expected :) [18:37] natefinch: We build the Jujud using Lp, now, We used to let ubuntu do. Not any more. CI makes the Win and centos agents. We already have the infrastucture to make all jujuds separate from client packaging [18:38] QA considered it because we really want to upload just one agent per arch and OS [18:39] sinzui: so, in theory, if we really needed to, we could keep the client 1.2.1 compatible, but still use 1.4.2 with Jujud? [18:40] natefinch: The only spanner in the works is that local-provider will not use streams. You cannot force it. Ubuntu want their packages to provide both client and server for local-host [18:40] natefinch: absolutely. That might also help us get to a smaller client. [18:40] sinzui: true, but don't you already need a PPA for juju-local? [18:42] natefinch: no. anyone making the source package will get juju-core anf juju-local…but we both know the jujud wasn’t provided by juju-local. The client package still containers jujud [18:54] sinzui: so it sounds like the answer is "no, we can't have jujud require 1.4.2 unless we have 1.4.2 in ubuntu" [19:04] natefinch: I don’t think that is true. The SRU is all aout the client. If core fixes local-provider to work with streams, then we and foundations change the packaging to be just about the client, then a user will get the new juju cllient, bootstrap, and still get a local env. [19:05] sinzui: well, you just gave me my Friday labs project :) [19:06] I look forward to test the local provider with an untainted jujud [19:15] wasnt going to be a lxd thing? [19:16] perrito666: I'm not holding my breath === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [19:36] it just now occurred to me that charms are basically plugins for juju [19:50] ericsnow, katco, wwitzel3: I think I nuked the workload process technology plugins card.... I tried to drag it into "in progress" and when I dropped it, it zooped up and away semewhere [19:51] natefinch: looks like it was in archive. moved it back for ya [19:52] katco: oh, thanks, archive was scrolled off my screen, so I forgot it existed === brandon is now known as web [20:06] ericsnow: I see now what you were talking about all this time with modules... interesting approach. [20:07] natefinch: yeah :) [20:07] and another lightbulb goes on :) [20:35] ericsnow: should this be "args []string"? https://github.com/ericsnowcurrently/juju/blob/ww3-container-mgmt/procmanager/plugin.go#L11 [20:36] natefinch: perhaps [20:36] natefinch: if anything it would probably be a struct [20:36] ericsnow: right [20:36] ericsnow: also, do you really need to pass the description to launch? [20:37] natefinch: probably not [20:37] ericsnow: ok :) [20:37] natefinch: keep in mind that the Plugin (and PluginResource) interface were created mostly to sketch out the concept [20:38] natefinch: it may be that those two types are unnecessary [20:38] natefinch: I expect that in the end something like them will exist, though [20:43] ericsnow: no problem, was just making sure I wasn't missing important things you guys had already hashed out. [20:44] natefinch: k [20:50] ericsnow: what is the ID in "register PROC-NAME ID" ? [20:51] natefinch: the ID that comes back from the plugin [20:51] natefinch: same as UniqueID in LaunchDetails [20:51] natefinch: ericsnow: is the high-level architecture documented anywhere? [20:51] ericsnow: so proc-name is the juju-name for it, and id is the plugin's name [20:51] natefinch: ericsnow: to scale this conversation to the team? [20:51] natefinch: pretty much [20:52] katco: not really (yet) [20:52] ericsnow: natefinch: now's a great time :) "make it so" [20:52] katco: I'm working off this: https://docs.google.com/document/d/1PcRQXaerlsACro4y1y5LWD-uvhfHya2CkOcoljyFyCU/edit# [20:53] natefinch: that doesn't specify much about the plugins though [20:53] natefinch: that doc doesn't really document the architecture [20:53] I know :) [20:53] sort of my point ;) [20:53] natefinch: specs != architectural docs [20:54] the questions are coming up naturally now, so it's a good time to write down the answers [20:54] katco, ericsnow: I started a doc on the plugin spec: https://docs.google.com/document/d/1qlHneZ7UHoNgGska46XKhqyYOHLKUSob41puQyG80GQ/edit# [20:54] katco, ericsnow: I can start one on the high level architecture [20:55] architecture/glossary :) [20:55] natefinch: doesn't have to be anything too elaborate. just a high-level component diagram, maybe a sequence diagram [20:55] natefinch: k [20:55] * natefinch didn't sign up for diagrams.... [20:55] :) [20:55] natefinch: ericsnow can walk you through what we're doing on min version [20:56] I can do diagrams. Not my forte, but I'll make do, and someone who's better will come along and make them look nice [20:56] natefinch: use plantuml. declarative, and very quick [20:56] * natefinch debates drawing stuff on his tablet with his finger [20:56] katco, natefinch: saw what appeared to be a long twitter conflab about patterns, decided quickly not to get involved... [20:56] took effort though [20:56] thumper: haha [20:57] :p [20:57] thumper: twitter is so bad for arguments [20:57] true [20:57] we finished it up (for some value of finished) here [20:57] although we like to call them discussions :) [20:58] thumper: well at any rate it's good that you are silently agreeing with me. >:D [20:59] rofl [20:59] I gotta run. Will be back later to work on specs & arch docs for process mgmt stuff === natefinch is now known as natefinch-afk === kadams54 is now known as kadams54-away === brandon is now known as web [21:38] waigani: re bug 1463117 change happened between beta5 and beta6 [21:38] Bug #1463117: Juju 1.24-beta6.1 unit commands hang indefinitely

[21:39] thumper: cheers === kadams54-away is now known as kadams54 [22:01] wwitzel3: ping [22:02] katco: pong [22:02]