User1: User3 another intermittent test failure fix: http://reviews.vapour.ws/r/1877/
 * thumper looks
User2: User1 can I bother you for a small txn assert fix? http://reviews.vapour.ws/r/1879/
User1: User2 sure
User1: looking
User2: thanks
User1: User2 is the single worker responsible for block device updates a singular worker?
User2: User1 hah, good point. I'll check, but it doesn't actually matter anyway
User1: User2 yeah I think I agree, but if it isn' then one of your points isn't accurate :)
User2: User1 it's instancepoller, and no it's not (should it be?)
User2: User1 I'll update the description ;)
User1: User2 not sure if it should be or not
User1: User2 i don't know much about instancepoller
User1: User2 does setAddresses get called with the complete list of current addresses?
User2: User1 it's called with the in-memory ones. hmm, I guess it should really refresh shouldn't it
User1: User2 that's what I was thinking
User1: User2 otherwise there is a concurrent update problem
User2: User1 I'll write a test and fix, and poke you again in a bit
User1: User2 sounds good
User1: User2 i'll publish the one minor comment I had now
User2: thanks
User3: coffee time
User2: User4 thanks for fixing that bug
User4: User2 np :) thanks for the review
User2: User1 PTAL. I changed it to not use a txn loop anymore, since it'll never leave the state that fails the assertion
User1: User2 will do. otp
User1: User2 i think your change is probably ok b/c everyone who sets address should be trying to set the same thing
User1: User2 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
User2: User1 that would still happen before. it'd just have gone through the txn loop twice
 * menn0 nods
User1: User2 i guess it would
User2: User1 it shouldn't be a major issue anyway, since the updates are periodic
User1: User2 and i just noticed that the addresses are refreshed before every update as well now too
User1: User2 which helps
User2: yep, thanks for picking that up
User1: User2 ship it!
User2: User1 thanks
User1: User3 big debuglog refactoring... preparation for upcoming db log changes: http://reviews.vapour.ws/r/1883/
User1: User3 another refactoring branch to come
User3: User1 done
 * thumper heads off
User5: Bug #1462874 opened: Collapse workload-state and agent-state into state <juju-core:New> <https://launchpad.net/bugs/1462874>
User6: jam, morning
User6: jam, 1:1 ?
User7: User6 ping
User6: TheMue, sorry, omw
User6: TheMue, in the mean time http://reviews.vapour.ws/r/1884/ ? :)
User7: User6 hehe, ok
User7: User6 thx for fixes, looks good
User6: TheMue, thanks for the review :)
User8: User6 hangout?
User9: User6 it's pushed http://reviews.vapour.ws/r/1860/
User9: User6 when you have time
User6: voidspace, cheers, will have a look shortly
User9: User6 you've frozen
User6: voidspace, where?
User9: User6 are you still in the hangout?
User6: voidspace, no
User9: heh
User9: ok
User6: voidspace, :)I'm looking at your PR and will join our 1:1 hangout in a bit
User9: User6 ok, I'll grab coffee
 * TheMue is afk, bike ride to co-location office
User6: voidspace, LGTM, I'm in the hangout btw
User9: User6 omw
User10: Morning al
User9: User6 do I need to manually merge my branch into a feature branch?
User9: User6 https://github.com/juju/juju/pull/2493
User9: User6 I thought the bot could handle feature branches
User9: mgz_: ^^^
User9: User6 mgz_: never mind...
User9: my page was just stale
User9: it has already happened...
User9: :-)
User6: voidspace, yeah, all good
User5: Bug #1461529 changed: juju upgrade-charm has no effect for subordinate charms <subordinate> <upgrade-charm> <juju-core:Invalid> <https://launchpad.net/bugs/1461529>
User6: voidspace, we need to sync up the devices branch with master
User6: voidspace, before it diverges too much
User9: User6 ok, I'll create a PR
User6: voidspace, cheers!
User6: dooferlad, omw
User9: User6 https://github.com/juju/juju/pull/2520
User5: Bug #1462966 opened: worker/provisioner: multiple data races <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1462966>
User6: voidspace, it's just a straight merge right?
User6: voidspace, LGTM
User9: User6 yup, straight merge
User11: jam: you around for the system image meeting?
User12: hi frankban_, now that i'm home i see the results from 'make fcheck' i ran friday afternoon
User13: User12 cool, any problems?
User12: User13 yeah, quite a few failures
User13: User12 weird it works here
User12: User13  let me paste them
User12: User13 http://paste.ubuntu.com/11648474/
User12: User13 was i supposed to have an environment bootstrapped before running the tests?
User13: User12 so those seems related to the charm hook failing rather than quickstart.
User13: User12 no, no environment should be bootstrapped
User13: User12 I presume this is related to the lp outage
User12: User13 ah, yes.
User13: User12 functional tests use the network
User13: User12 because charm isntallation requires network access
User13: User12 perhaps if you run them again you'll see them passing
User13: User12 make ftest could be faster
User12: User13 ok, i'll try again. i have no idea if LP is more accessible today than friday
User13: User12 yeah, but I run ftests this morning for another branch and they passed
User12: ok
User11: User2 User10 just finishing another meeting, be there is a sec
User14: User15 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
User14: User15 1st day of the iteration, shouldn't be too much
User5: Bug #1461954 opened: failed to unmarshall 503 <ci> <juju-core:Triaged> <juju-quickstart:Invalid> <https://launchpad.net/bugs/1461954>
User5: Bug #1463047 opened: TestUpgraderRetryAndChanged fails <ci> <intermittent-failure> <test-failure> <juju-core:Incomplete> <juju-core 1.24:Triaged> <juju-core jes-cli:Triaged> <https://launchpad.net/bugs/1463047>
User15: User14 standup was as you'd expect :)
User5: Bug #1463053 opened: NetworkSuite setup fails <ci> <intermittent-failure> <unit-tests> <juju-core:Incomplete> <juju-core feature-proc-mgmt:Triaged> <https://launchpad.net/bugs/1463053>
User9: User6 ping
User6: voidspace, pong
User9: User6 so in the container broker we're *already* populating the MAC address
User9: User6 using the template
User9: User6 const MACAddressTemplate = "00:16:3e:xx:xx:xx"
User9: User6 so the current code will put that into the XML for every KVM instance... :-)
User9: User6 I seem to recall you wanted to deliberately override any mac address coming from anywhere else
User9: User6 can you remember why?
User9: User6 this is lxc-broker.go:566
User6: voidspace, that's because the lxc package understands :xx:xx and renders them to be unique
User6: voidspace, we have to do the same for kvm I guess
User6: voidspace, feel free to drop or changethe MACAddressTemplate
User9: User6 well, I'll replace it with a *specific* mac address
User9: a generated one
User9: still within that template
User9: that template range
User10: mmpf, does anyone else have the problem of the comment button on rb not creating a text box?
User6: voidspace, sgtm
User9: User6 I think the rand package on play.golang.org may not be entirely random...
User9: User6 this code always generates the same MAC address...
User9: User6 http://play.golang.org/p/0wHt2bd9YX
User9: either that or results are cached
User9: User6 note that in that code I have to use []interface{} to pass to Printf (or Sprintf in the real code)
User6: voidspace, will look in a bit
User9: User6 ok
User9: User6 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
User9: and []string can't be converted to []interface{}
User9: User16 you'd probably know
User9: User16 : http://play.golang.org/p/0wHt2bd9YX
User9: User16 change []interface{} to []string and watch it fail
User9: User16 that surprised me
User9: (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)
User16: User9 well, you're passing a []string into something expecting a []interface{}.... so it is you :)
User9: User16 well, I'm unpacking it
User9: User16 the call is "digits..."
User16: right
User9: so I'm *not* passing the slice
User9: I suspect that as Printf is packing back into a slice there's a shortcut that is a cast
User16: 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
User9: which doesn't work
User9: User16 right, but it's *not* passing them in spearately
User9: casting a string to an interface{} would work, right?
User16: correct
User6: voidspace, generating the same mac address seems to be related to not initializing rand seed (or just a quirk of the playground)
User9: User6 yeah, I expect so
User9: was noting it more than asking a question :-)
User9: it was the failed cast that I actually wondered about
User16: User9 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.
User16: from http://golang.org/ref/spec#Passing_arguments_to_..._parameters
User6: voidspace, why not generating a slice of uint8 and converting that to a mac address?
User16: User9 that snippet of your was very pythonic, btw
User9: User6 would that actually be less code?
User9: User16 thank you
User14: User15 cool, ty :)
User16: User9 it's not a good thing when you're writing go ;)
User9: User16 it's *always* a good thing  ;-)
User9: Python has better primitives for generating hex strings... like a hex built-in
User9: although maybe Go has one too, I didn't look very far to be fair
User9: ah, I can use %x
User6: voidspace, I don't know, just a suggestion :)
User9: User6 using hex.EncodeToString seems the best way - I still need to generate three of them
User9: User6 as I need them colon separated
User9: User16 thanks for that reference by the way, useful
User9: User16 it is surprising, and has the downside that you can never unpack a slice into a call that accepts []interface{}
User7: User6 leaving from colocation now back home, but should be there when net meeting is starting
User9: User16 would you still say this is pythonic?
User9: User16 http://play.golang.org/p/QfCqUYZ5P3
User9: User16 if so, could you explain what a more go-thonic approach would be?
User9: (I could just put three calls to rand.Intn(256) into the Printf call - but that seems a bit gross)
User16: User9 haha, I have exactly that code in my playground buffer
User9: User16 heh, cool
User9: I just didn't know about %x
User9: but then I didn't look very hard
User9: User16 thanks
User16: User9 I can't make it 0 pad the result though... so <17 is a single difit
User16: digit
User16: er <16
User9: ah
User9: yes
User16: %0x should work , but doesn't somehow
User9: maybe generating 6 digits is better then
User6: TheMue, no problem
User6: voidspace, EncodeToString sounds reasonable
User9: User6 %x does that anyway (under the hood)
User10: User16  :%02x"
User10: User9 ^
User9: User10 thanks
User16: oh, right...
User16: User10 the documentation for that is not good
User10: User16 it is not I just learned all that stuff by trial and error while doing nolog
User16: User10 it's the way C/C++ do it... but the actual language in the Go doc is confusing.
User10: it is not the clearest formatting indeed
User17: Did we make any changes to juju-log in the latest 1.24-beta release?
User17: i'm not seeing anything in the project milestone changes that would indiciate it has  https://launchpad.net/juju-project/+milestone/1.24-beta5
User17: 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.
User17: heres what i have, and hopefully its got enough information to reproduce: https://bugs.launchpad.net/juju-core/+bug/1463117
User5: Bug #1463117: Juju 1.24-beta6.1 unit commands hang indefinately <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1463117>
User5: Bug #1350171 changed: windows service needs to implement Exists <juju-core:Fix Released> <https://launchpad.net/bugs/1350171>
User5: Bug #1449617 changed: service.Service implementations are missing functional tests. <systemd> <upstart> <windows> <juju-core:Fix Released by gabriel-samfira> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1449617>
User5: Bug #1463117 opened: Juju 1.24-beta6.1 unit commands hang indefinately <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1463117>
User10: User17 thanks for the report, I think I bumped into that a couple of weeks ago and then missed it
User17: User10 yeah, its really confusing at how specific and isolated it is
User17: 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.
User17: and it only cropped up in this beta 6.1, it was working as expected in beta-5
User10: User14 I swear I am not trolling
User14: User10 lol
User10: worth the clarification
User14: User10 as someone who did not grow up with twitter, the 140char limit is infuriating
User10: User14 it is and it outlived its purpose long ago
User14: User10 what i mean to say is patterns are the canonical way to solve a problem. they have been uncovered by people over the years
User14: User10 if someone uses the wrong tool for the job, that doesn't make the pattern wrong, it makes the developer wrong
User10: User14 patterns are the canonical way to communicate a solution, at least from my pov
User14: User10 yes, and that label implies a way of doing something
User10: User14 yes, but, as any other convention it is only useful if properly adopted
User14: User10 yep
User14: User10 but i disagree with the rally cry of "down with design patterns"
User10: 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
User14: User10 to me it is tantamount to saying "down with vocabulary"
 * perrito666 will hold a troll comment about english vocabulary :p
User14: User10 but we're not talking about conventions, really. patterns are patterns because no one has discovered a better way.
User14: User10 ignoring past exploration into the problem makes no sense to me.
User16: 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)
User10: User16 well if someone implements a pattern verbatim then its cargo culting
User16: also, they tend to overcomplicate the problem for dubious benefit
User10: 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
User10: the issue is that there are a ton of cutpasters that call themselves developers
User10: aghh why do I keep having to do changes to things that lack tests and end up implementing the whole thing
User16: heh
User14: sorry, actual work stuff distracting me :) User16 if they don't have a benefit, then you shouldn't be using them
User10: User14 did you just tautologized nate?
User10: :p
User14: User10 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"
User14: User10 i'm trying to point out that the utility is a f(developer) not f(pattern)
User16: User14 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.
User16: for example, the visitor pattern turns simple iteration into callback hell.  Case in point: http://golang.org/pkg/path/filepath/#Walk
User14: User16 i don't think you understood me. patterns are just code that solve specific problems, and the community has given them names
User14: User16 if the costs outweigh the benefits, then don't use that code
User14: User16 but that doesn't make the code intrinsically useless
User16: User14 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!"
User14: User16 once again, problem with the person, not the label
User16: User14 but a *lot* of people.
User7: User14 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
User14: User7 right
User16: User18 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?
User14: User16 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"
User5: Bug #1449617 opened: service.Service implementations are missing functional tests. <systemd> <upstart> <windows> <juju-core:Triaged by gabriel-samfira> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1449617>
User5: Bug #1463133 opened: migrateLocalProviderAgentConfigSuite teardown fails <ci> <intermittent-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1463133>
User5: Bug #1463135 opened: TestUniterHookSynchronisation fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1463135>
User16: User14 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.
User7: User16 you're right that many developers think that they have to code and name exactly like in the patterns, that's surely naive.
User14: User16 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 :)
User14: User16 this is a great example
User7: User16 oh, coming to go, even go has "patterns". they are only called idioms here. ;)
User16: User14 Oh, I'm not ignoring them.  I'm actively trying to kill them with fire ;)
User14: User16 that's like trying to kill the number 5, it makes no sense
User16: User14 I hate the number 5.
User16: :D
User18: User16 correct
User14: User16 and yet its existence is implicit to the universe, with no regard to your feelings ;)
User16: User18 that was not the answer I expected :)
User18: User16 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
User18: QA considered it because we really want to upload just one agent per arch and OS
User16: User18 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?
User18: User16 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
User18: User16 absolutely. That might also help us get to a smaller client.
User16: User18 true, but don't you already need a PPA for juju-local?
User18: User16 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
User16: User18 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"
User18: User16 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.
User16: User18 well, you just gave me my Friday labs project :)
User18: I look forward to test the local provider with an untainted jujud
User10: wasnt going to be a lxd thing?
User16: User10 I'm not holding my breath
User16: it just now occurred to me that charms are basically plugins for juju
User16: ericsnow, katco, User15 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
User14: User16 looks like it was in archive. moved it back for ya
User16: User14 oh, thanks, archive was scrolled off my screen, so I forgot it existed
User16: User19 I see now what you were talking about all this time with modules... interesting approach.
User19: User16 yeah :)
User14: and another lightbulb goes on :)
User16: User19 should this be "args []string"?  https://github.com/ericsnowcurrently/juju/blob/ww3-container-mgmt/procmanager/plugin.go#L11
User19: User16 perhaps
User19: User16 if anything it would probably be a struct
User16: User19 right
User16: User19 also, do you really need to pass the description to launch?
User19: User16 probably not
User16: User19 ok :)
User19: User16 keep in mind that the Plugin (and PluginResource) interface were created mostly to sketch out the concept
User19: User16 it may be that those two types are unnecessary
User19: User16 I expect that in the end something like them will exist, though
User16: User19 no problem, was just making sure I wasn't missing important things you guys had already hashed out.
User19: User16 k
User16: User19 what is the ID in "register <options> PROC-NAME ID" ?
User19: User16 the ID that comes back from the plugin
User19: User16 same as UniqueID in LaunchDetails
User14: User16 User19 is the high-level architecture documented anywhere?
User16: User19 so proc-name is the juju-name for it, and id is the plugin's name
User14: User16 User19 to scale this conversation to the team?
User19: User16 pretty much
User19: User14 not really (yet)
User14: User19 User16 now's a great time :) "make it so"
User16: User14 I'm working off this: https://docs.google.com/document/d/1PcRQXaerlsACro4y1y5LWD-uvhfHya2CkOcoljyFyCU/edit#
User19: User16 that doesn't specify much about the plugins though
User14: User16 that doc doesn't really document the architecture
User16: I know :)
User16: sort of my point ;)
User14: User16 specs != architectural docs
User14: the questions are coming up naturally now, so it's a good time to write down the answers
User16: katco, User19 I started a doc on the plugin spec: https://docs.google.com/document/d/1qlHneZ7UHoNgGska46XKhqyYOHLKUSob41puQyG80GQ/edit#
User16: katco, User19 I can start one on the high level architecture
User16: architecture/glossary :)
User14: User16 doesn't have to be anything too elaborate. just a high-level component diagram, maybe a sequence diagram
User19: User16 k
 * natefinch didn't sign up for diagrams....
User16: :)
User14: User16 ericsnow can walk you through what we're doing on min version
User16: 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
User14: User16 use plantuml. declarative, and very quick
 * natefinch debates drawing stuff on his tablet with his finger
User3: katco, User16 saw what appeared to be a long twitter conflab about patterns, decided quickly not to get involved...
User3: took effort though
User16: User3 haha
User14: :p
User16: User3 twitter is so bad for arguments
User3: true
User16: we finished it up (for some value of finished) here
User3: although we like to call them discussions :)
User14: User3 well at any rate it's good that you are silently agreeing with me. >:D
User16: rofl
User16: I gotta run.  Will be back later to work on specs & arch docs for process mgmt stuff
User3: User4 re bug 1463117 change happened between beta5 and beta6
User5: Bug #1463117: Juju 1.24-beta6.1 unit commands hang indefinitely <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1463117>
User4: User3 cheers
User14: User15 ping
User15: User14 pong
User14: User15 do you know why you handed this to sergey? https://bugs.launchpad.net/juju-core/+bug/1449210
User14: User15 https://plus.google.com/hangouts/_/canonical.com/juju-release?authuser=1 if you're interested in verbally giving a report
User15: User14 he fixed it last time
User15: User14 it just wasn't visible that he did it because he didn't have an LP account at the time
User15: User14 I can forward you the email chain, it might of been someone else from the cloudsigma team and not sergey who fixed it, but it isn't a bug with juju, it was fixed in the remote API last time.
User14: User15 that would be great. ty for the insight
User15: User14 forwarded, yep, np
User10: Wallyworld axw I am a couple of mins late
User11: ok
User20: ericsnow, you still there?
User20: if you are gsamfira may have questions for you
User19: User20 yep
User20: gsamfira, ^^^
User21: thanks. Forking && fixing
juju-dev
Ubuntu IRC