[01:16] <axw> jw4 katco: yep, that was baby's first plantuml diagram :)
[01:16] <jw4> axw: lol
[01:38] <katco> anastasiamac: lmk when you've forwarded it
[01:39] <katco> ACK! one of my rules was deleting it!
[01:41] <jw4> katco: you mean the 'killfile anastasiamac' rule?
[01:42] <katco> jw4: lol no
[01:42] <jw4> :)
[01:42] <katco> jw4: it deleted an email from alexisb as well =|
[01:42] <katco> jw4: gmails filtering syntax doesn't work like i thought it did apparently =|
[01:42] <jw4> urg.
[01:42] <anastasiamac> katco: waht rule do u have? delete all from anyone starting with "A"?
[01:42] <jw4> hahaha
[01:42] <katco> anastasiamac: LOL
[02:44] <wallyworld_> axw: here's a trivial 1.22 fix when you get a chance http://reviews.vapour.ws/r/927/
[02:44] <axw> looking
[02:45] <axw> wallyworld_: are all the clouds updated?
[02:46] <wallyworld_> axw: the packaging change is for the deb in the cloud archive repo
[02:46] <axw> right, ok
[02:46] <wallyworld_> so the cloud images don't need updating
[02:47] <axw> wallyworld_: LGTM
[02:47] <wallyworld_> ty
[03:08] <axw> wallyworld_: http://www.reddit.com/r/golang/comments/2vo357/if_you_use_jetbrains_intellij_for_development_the/
[03:08] <axw> you use intellij right?
[03:08] <wallyworld_> yeah
[03:09] <wallyworld_> i use a go plugin from someone on github
[03:09] <wallyworld_> this might be a different one
[03:10] <wallyworld_> oh, no same one
[03:11] <wallyworld_> i normally compile from source as i've done a patch or two to it
[03:14] <axw> wallyworld_: http://reviews.vapour.ws/r/923/, PTAL
[03:14] <wallyworld_> sure
[03:20] <wallyworld_> axw: did you push? still the old rev
[03:20] <axw> wallyworld_: bleh, I guess the hook didn't transfer to RB
[03:20] <wallyworld_> np, i look in gh
[03:32] <axw> wallyworld_: I've just rebased and pushing again, I've deleted that file
[03:32] <wallyworld_> ok
[03:33] <axw> wallyworld_: btw I don't think the storage/pool package should be depending on storage/provider, it should be the other way around if anything
[03:33] <axw> storage/provider is common providers... I don't think the pool package doesn't need to know about it
[03:33] <wallyworld_> yeah, the dependencies are a little messy
[03:34] <wallyworld_> pool uses provider to reference ProviderType
[03:35] <wallyworld_> maybe defaultpool should move
[03:38] <wallyworld_> axw: done, i hate it how gh sends comments before you have a chance to correct them
[03:38] <axw> wallyworld_: heh yeah :)
[03:38] <axw> sorry, I should've waited
[03:39] <wallyworld_> np :-)
[03:56] <anastasiamac> axw: how idid u come accross the idea article? r u thinking of converting to the dark side?
[04:04] <axw> anastasiamac: I just saw it on http://www.reddit.com/r/golang
[04:04] <axw> and no, I am not :)
[04:05] <anastasiamac> axw: ic :D
[04:06] <anastasiamac> axw: m sure if they got runtime debugging going, it would convert a few ..
[04:14] <wallyworld_> works for me
[04:19] <anastasiamac> wallyworld_: debugging works for u? like stepping through at runtime?
[04:20] <wallyworld_> yep
[04:20] <wallyworld_> but it doesn't go over the api
[04:20] <wallyworld_> so limited use
[04:20] <anastasiamac> oh i c...
[04:23] <katco> anastasiamac: i can step through code in emacs as well :)
[09:11] <Muntaner> good morning!
[09:13] <TheMue> Muntaner: o/
[09:59] <perrito666> morning
[09:59] <dimitern> perrito666, o/
[10:00] <TheMue> heya perrito666
[10:01] <dimitern> voidspace, dooferlad, standup?
[10:01] <TheMue> dimitern: see you're in but it doesn't work
[10:02] <voidspace> dimitern: omw
[10:17] <perrito666> frankban: ping
[10:17] <frankban> perrito666: morning
[10:17] <perrito666> hello :)
[10:17] <perrito666> frankban: I broke your code and defintely could use a bit of guidance fixing it
[10:18] <frankban> perrito666: hope I can help, what's up?
[10:19] <perrito666> frankban: so, this is the deal, I am working on having agent status and unit status split up
[10:19] <perrito666> what used to be status for unit, now is status for an agent entity, that holds nothing else other than status
[10:19] <perrito666> and unit now has a different status with a new globalKey
[10:20] <perrito666> so, for transitions sake, unit uses the same globalKey than it used to for most things except status
[10:21] <perrito666> with your last addings to mega/multi watcher it seems that if I am watching agent (that is what you actually want to know) it never gets informed when ports change
[10:21] <perrito666> and if I watch unit, it never gets informed of the other changes :)
[10:21] <perrito666> I might add agent and unit to the watcher and split things up
[10:21] <perrito666> but I will most likely break whatever you are using the watcher for
[10:22] <perrito666> so I could use some light in that department
[10:23] <perrito666> oh and al of this before coffee
[10:23] <frankban> :-)
[10:24]  * perrito666 tries to defeat the lazyness to turn on the expresso machine
[10:26] <frankban> perrito666: so the status for the unit is already updated by watching a separate collection right?
[10:26] <perrito666> if I let the code as is, yes, it watches the unit and gets updates for port changes (although the states are not the one you would expect)
[10:26] <perrito666> and then you loose the agent statuses
[10:27] <perrito666> if I change it to watch agent instead, you loose the ports
[10:27] <perrito666> so I definitely need to watch both
[10:28] <frankban> perrito666: I am not sure I understand how status and ports are related, perhaps you can show me some code, or we could have an hangout?
[10:29] <perrito666> frankban: I can do both :)
[10:30] <frankban> perrito666: https://plus.google.com/hangouts/_/canonical.com/gogogo?authuser=1
[10:31]  * perrito666 checks that he can speak english this early, check
[10:31] <frankban> lol
[10:32] <perrito666> frankban: hold a sec, my computer jsut los sound... because of reasons
[10:32]  * perrito666 restart
[10:38]  * perrito666 is in trying to join the call to long
[10:38] <perrito666> there, you go, wrong authuser
[10:49] <perrito666> frankban: you froze
[10:50] <perrito666> frankban: but that's ok I got the info I needed, Ill let you know whenever this is ready to land so you can take a look
[10:52] <frankban> perrito666: my machine decided to freeze :-/ I am back in the hangout
[10:53] <perrito666> frankban: brt
[10:55]  * perrito666 wonders who designed his computer and didn't add a kb key for play/pause
[10:57] <mgz> I filed bug 1421606 as a blocker
[10:57] <mup> Bug #1421606: TestAddServiceStorageConstraints fails on ppc64 <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1421606>
[10:57] <perrito666> frankban: look into chrome://gpu if your hardware acceleration is dissabled you migh need to hack a bit your chrome launcher to bypass dri check
[10:58] <frankban> perrito666: good to know, ty
[11:07] <aznashwan> time-appropriate greetings to everyone! just wanted to consult you guys a little on something
[11:08] <aznashwan> I'm currently working on getting CentOS fully supported (cloudinit and sshinit-capable), my first point of concern being abstracting away the differences between apt and yum (mostly for sshinit purposes)
[11:10] <aznashwan> my question is, how necessary is it we set up apt-package pinning, I see it's only actually done in a couple of places and does not seem (from what I can discern) to be that necessary really. would dropping the whole pinning process be too much to take?
[11:13] <perrito666> aznashwan: without knowing where and why I cant tell you for sure
[11:14] <aznashwan> perrito666: my bad. they're declared here: https://github.com/juju/juju/blob/master/cloudinit/cloudinit.go#L32
[11:15] <perrito666> aznashwan: not very explicit of what is that for
[11:15] <perrito666> aznashwan: doesn't yum support some sort of pinning?
[11:16] <aznashwan> perrito666: and the only place one is used (apart from a couple of test files), is here: https://github.com/juju/juju/blob/master/environs/cloudinit/cloudinit.go#L370
[11:16] <perrito666> that is a rather important one
[11:16] <aznashwan> perrito666: yes it does, but for settling priorities for whole repositories, not for a single package available in multiple sources
[11:17] <perrito666> aznashwan: you dont want to en up with an unsupported cloud tools
[11:18] <perrito666> aznashwan: my take, just add a mock implementtion of pining for the moment
[11:19] <aznashwan> perrito666: true, but this gets us to a bigger problem: that's a cloud tools repo full of .deb's (which is a topic we'll be pitching next week, about how we also need rmp's for all the specific stuff, like the juju specific mongo package you guys have...)
[11:20] <perrito666> aznashwan: I dont think that old app to install debs in redhat still exist right ? :)
[11:22] <aznashwan> perrito666: that's a good question, either way it wouldn't be too much work, just the juju-mongodb package and these tools, which I suspect you guys have built automatically, and the main juju package for CentOS...
[11:22] <aznashwan> perrito666: will look further into the matter, and will take your advice for now and just work around this
[11:24] <perrito666> aznashwan: seems the easiest way for the moment
[11:24] <aznashwan> perrito666: much obliged :D
[11:36] <Muntaner> gsamfira: o/
[11:36] <Muntaner> I'll be back at work on windows + juju on Monday
[12:15] <jam> perrito666: is someone looking at https://bugs.launchpad.net/juju-core/+bug/1421606 I just saw its blocking trunk
[12:15] <mup> Bug #1421606: TestAddServiceStorageConstraints fails on ppc64 <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1421606>
[12:16] <jam> i realize that ideally axw or wallyworld_ would be looking at it
[12:16]  * perrito666 looks
[12:16] <jam> but I think its past their EOD
[12:16] <jam> (and thus past their EOW, I believe)
[12:16]  * perrito666 hears an incoming email from axw as soon as jam said that
[12:20] <wwitzel3> perrito666: he sets them up on notifies from IRC
[12:20] <perrito666> lol
[12:20] <perrito666> jam: but short answer is no, no one was looking at that, I guess we will have to since that seems to lock CI :)
[12:20] <jam> perrito666: ype
[12:20] <jam> yep
[12:21] <perrito666> jam: incidentally, isn't today like saturday for you?
[12:21] <jam> perrito666: yeah, but I had a big meeting, so I was around, and tried to submit one of my backlog packages, respond to email, etc.
[12:27] <wwitzel3> jam: lots of people or very important? ;)
[12:28] <jam> wwitzel3: very important
[12:28] <jam> spec review with Mark, though hopefully we'll get that regularly scheduled on a workday for me :)
[12:28] <perrito666> ah the infamous: "meeting on saturday or unemployment on monday" :p
[12:28] <wwitzel3> jam: ahh, which spec?
[12:29]  * perrito666 runs to see his spec to make sure it hasn't changed
[12:29] <jam> wwitzel3: well, we're hopefully going to be doing regular weekly chats about features we're working on. though today's was about the Juju Unit and Service States (aka charm health)
[12:29] <jam> s/States/Status/
[12:29] <perrito666> jam: :( I thought we where done with that
[12:30] <jam> perrito666: nothing major. mostly just moving the stuff we discussed in the overview into the core of the doc
[12:30] <wwitzel3> jam: nice
[12:47] <TheMue> hmm, is writing "shit it" due to friday afternoon?
[12:48] <perrito666> TheMue: ?
[12:48] <perrito666> dislexic are we
[12:48] <perrito666> ?
[12:49] <TheMue> typo during review, thankfully not published w/o correction
[12:49] <TheMue> ;)
[13:10]  * dimitern steps out for ~1h
[13:10] <ashipika> hi all.. a question: trying to bootstrap my ec2 environment in eu-west-1.. but i'm getting the following error: error: invalid value "arch=amd64 cpu-cores=1 cpu-power=100 mem=1740M root-disk=8192M availability-zone=eu-west-1a" for flag --hardware: unknown characteristic "availability-zone"
[13:10] <ashipika> 13:56
[13:10] <ashipika> juju version 1.22-alpha1-trusty-amd64
[13:11] <ashipika> also juju (at least this version) does not seem to know about t2.micro instances (free tier eligible ) if i specify --constraints 'instance-type=t2.micro'
[13:14] <wwitzel3> ashipika: you can type juju help ec2-provider for specific help with EC2, but the placement directive should just be zone, not availability-zone
[13:14] <wwitzel3> ashipika: also looking at our instance types, you are right, we only know about t1.micro atm
[13:17] <ashipika> wwitzel3: zone=<availability-zone-name>
[13:19] <ashipika> wwitzel3: but then it says: unknown constraint zone
[13:21] <wwitzel3> ashipika: right, the zone placement should be outsize the constraints
[13:23] <wwitzel3> ashipika: juju bootstrap zone=name --constraints=""
[13:24] <ashipika> wwitzel3: juju bootstrap zone="eu-west-1c" —upload-tools    ->  unrecognized args ["zone=....
[13:26] <ashipika> wwitzel3: ah.. juju bootstrap —to zone=eu-west-1c ....
[13:28] <wwitzel3> ashipika: you got there first :), was just typing that, my fault .. I've never actually used zone with bootstrap, only with add-machine, and with add-machine you don't need to specifiy a --to
[13:30] <ashipika> wwitzel3: not solved the problem, though.. still getting
[13:30] <voidspace> dimitern: so when you say forwarding needs to be setup in container initialisation, you mean from the "initialiseAndStartProvisioner" method of ContainerSetup.
[13:30] <ashipika> wwitzel3: error: invalid value "arch=amd64 cpu-cores=1 cpu-power=100 mem=1740M root-disk=8192M availability-zone=eu-west-1c" for flag --hardware: unknown characteristic "availability-zone"
[13:30] <ashipika> ERROR failed to bootstrap environment: subprocess encountered error code 1
[13:33] <wwitzel3> ashipika: right, you need to remove that availability-zone from your constraints
[13:33] <ashipika> wwitzel3: i ran -> juju bootstrap --to zone=eu-west-1c --upload-tools
[13:38] <ashipika> wwitzel3: and the same error without —to
[13:38] <wwitzel3> ashipika: try running a destroy-environment (you may have to use --force), to clean up, then retry bootstrap
[13:38] <ashipika> wwitzel3: did.. a few times already.. after every failed attempt
[13:40] <wwitzel3> ashipika: you can check ~/.juju/environments , probably an old amazon.jenv hanging around
[13:40] <ashipika> wwitzel3: nah.. deleted .juju and ran juju init..
[13:42] <wwitzel3> ashipika: hrmph .. then I don't know, you may have found a bug, unless someone else here has some ideas?
[13:44] <ashipika> wwitzel3: trying with region set to us-east-1 in the .yaml config.. if that fails i'll create a bug report
[14:00] <TheMue> dimitern: btw, why do we use int for ports, instead of uint16?
[14:18] <Muntaner> gsamfira: ping
[14:43] <turicasto> hi to everyone!
[14:46] <dimitern> TheMue, it's doesn't matter in practice
[14:47] <dimitern> TheMue, i.e. saving a few bytes at (de)serialization time is negligible
[14:48] <TheMue> dimitern: I'm not talking about parameters, but as a field type which only allows uint16 values. a port number -1 would be strange ;)
[14:50] <jw4> turicasto: o/
[14:51] <rogpeppe> TheMue: using int means that you get a better failure mode if someone happens to get some arithmetic wrong and passes a negative number
[14:52] <TheMue> rogpeppe: a better one? uints can't even be negative
[14:53] <rogpeppe> TheMue: if you accidentally substract 64 from 62 and pass -2, you don't really want it to be treated as 65534
[14:54] <rogpeppe> TheMue: better to have it fail with an out of bounds error
[14:54] <TheMue> rogpeppe: arg, yes, this arithmetic behavior
[14:54] <rogpeppe> TheMue: there's a similar argument for not allowing negative slice indexes like in python
[14:55] <dimitern> TheMue, you mean in network.Port ?
[14:55] <TheMue> dimitern: yep
[14:55] <dimitern> TheMue, yeah, that sounds like a good idea, I'd suggest adding this to your list of things to change in the next PR :)
[14:56] <TheMue> dimitern: Number is an int and so could have invalid values
[14:56] <TheMue> dimitern: shit, I shouldn't have asked
[14:56] <TheMue> :D
[14:56] <dimitern> TheMue, they are validated internally, but yeah
[14:56] <dimitern> ;)
[14:57] <TheMue> dimitern: one of the arguments for static typed languages is to have more safety. thankfully go provides very detailed types here (ok, not uint48 *lol*)
[14:58] <TheMue> or uint128 for uuids, but that better would be a bitstring
[14:58] <dimitern> TheMue, +1
[15:00] <jw4> do we do pull requests for just adding a deprecation comment?  https://github.com/juju/charm/pull/84
[15:00] <dimitern> TheMue, I'd even go further and suggest having a type PortType uint16 in the network package and use it everywhere for port values
[15:00] <TheMue> dimitern: +1
[15:01]  * TheMue always likes the simple type definition in Go
[15:03] <dimitern> TheMue, yeah, and you can even have methods on it;)
[15:03] <TheMue> dimitern: yeah, that's cool
[15:05] <perrito666> ericsnow: wwitzel3 ?
[15:08] <rogpeppe> dimitern, TheMue: a large but totally trivial change: https://github.com/juju/juju/pull/1601/files
[15:09] <rogpeppe> dimitern: i'd appreciate a quick review so that it doesn't get stale, if poss - there are no manual changes there at all.
[15:09] <dimitern> rogpeppe, will have a look
[15:09] <rogpeppe> dimitern: ta!
[15:09] <TheMue> rogpeppe: currently standup, but will look then
[15:09] <rogpeppe> TheMue: ta
[15:16] <wwitzel3> TheMue: http://reviews.vapour.ws/r/932/
[15:16] <wwitzel3> TheMue: that is for fixing https://bugs.launchpad.net/juju-core/+bug/1417875
[15:16] <mup> Bug #1417875: ERROR juju.worker runner.go:219 exited "rsyslog": x509: certificate signed by unknown authority <canonical-bootstack> <logging> <regression>
[15:16] <mup> <juju-core:In Progress by wwitzel3> <juju-core 1.21:Triaged by wwitzel3> <juju-core 1.22:Triaged by wwitzel3> <https://launchpad.net/bugs/1417875>
[15:16] <TheMue> wwitzel3: already opened, will review after standup
[15:17] <wwitzel3> TheMue: thanks
[15:29] <TheMue> wwitzel3: +1
[15:31] <dimitern> rogpeppe, LGTM
[15:32] <rogpeppe> dimitern: thanks!
[15:32] <rogpeppe> dimitern: aw, remind me of the juju magic word for submitting a PR please?
[15:33] <dimitern> rogpeppe, $$anything-between-two-dollar-signs$$
[15:33] <dimitern> :)
[15:35] <TheMue> dimitern: thx, you've been faster
[15:35] <dimitern> np
[15:35] <TheMue> rogpeppe: won't merge due to missing fix, but is reviewed. so should be comming soon
[15:36] <rogpeppe> TheMue: cool. hopefully it won't conflict.
[15:36] <katco> dimitern: hey sorry, what are you meaning when you say "d"?
[15:36] <perrito666> katco: delete
[15:37] <katco> perrito666: ty
[15:37] <dimitern> katco, :) d==delete this line
[15:37] <katco> dimitern: so are you referring to whitespace in a lot of those?
[15:37] <perrito666> katco: which you would know if you used vi :p
[15:37] <dimitern> katco, but d it's nicer and geeky :D
[15:37] <katco> haha
[15:37] <katco> perrito666: shouldn't it be dd?
[15:37] <mgz>  dd would be clearer :P
[15:38] <dimitern> katco, yeah, I don't mind it that much though
[15:38] <mgz> katco won...
[15:38] <perrito666> d-> is enough :p
[15:38] <dimitern> dd only if you use vim
[15:38] <katco> dimitern: i tend to use whitespace to aid in readability
[15:38] <perrito666> katco: I actually interrupted my lunch to troll you, and you counter troll me
[15:38] <perrito666> :p
[15:38] <dimitern> and C-k is longer to type :)
[15:38] <katco> perrito666: i muahaha at you sir!
[15:39] <dimitern> katco, I understand
[15:39] <TheMue> *LOL*
[15:39] <dimitern> katco, so I'll leave it up to you ;)
[15:39] <katco> dimitern: ok, ty for the review :)
[15:39] <dimitern> katco, I'm not done yet :)
[15:39] <katco> dimitern: oh i know, but i wanted to say ty :)
[15:40]  * katco making some tea
[15:40] <dimitern> katco, np
[15:56] <dimitern> katco, you have a review
[15:56] <katco> dimitern: tyvm!
[15:57] <katco> dimitern: hey rq about the SignedURL
[15:57] <katco> dimitern: i thought this might come up... the new v4 signing messes with request headers, so there's no concept of a signed url
[15:58] <dimitern> katco, I'd like to read about this more if you have the source
[15:59] <katco> dimitern: check out aws/sign.go
[15:59] <dimitern> katco, also, is the v4 signing process now mandatory for all s3 operations?
[15:59] <katco> dimitern: https://github.com/go-amz/amz/blob/v1/aws/sign.go#L82
[15:59] <katco> dimitern: it is not; you pass in which signing you'd like into S3 ctor
[16:00] <dimitern> katco, ok so for older versions URL and SignedURL still make sense to exist, and at least URL should be implementable for V4
[16:01] <katco> dimitern: for v2, signedurl could still work
[16:02] <katco> dimitern: for URL, it didn't make much sense to me. what would you do with it?
[16:03] <dimitern> katco, get a link to something in your bucket that's accessible to public (permission-wise)
[16:04] <katco> dimitern: ah ok
[16:04] <dimitern> katco, :)
[16:04] <dimitern> katco, we do still use this in juju IIRC
[16:05] <dimitern> katco, and even if we didn't and URL/SignedURL no longer make sense, we can't just drop them - such a change needs a version bump (e.g. a separate PR for v3-unstable)
[16:05] <katco> dimitern: that was the idea :)
[16:06] <ericsnow> jam: thanks for the reply re: fakes
[16:06] <katco> dimitern: so if you'd like to keep SignedUrl, how should we detect that the signing method supports a signed url?
[16:06] <ericsnow> jam: I sent a follow-up to get some clarification
[16:06] <dimitern> katco, I see, well - is this something we'll need to use in juju soon?
[16:06] <katco> dimitern: it's targetted for 1.23. feature freeze is 2w from today.
[16:07] <dimitern> katco, so that's why it needs to go in v2, but because of the versioning rules, we can't also drop stuff from the exported interface
[16:07] <dimitern> katco, ...in v2, but we can in v3-unstable
[16:08] <katco> dimitern: is versioning of goamz tied to something? why can't we do a cut?
[16:08] <dimitern> katco, out of respect for any potential users
[16:08] <katco> dimitern: they're free to remain on v2 aren't they?
[16:08] <dimitern> katco, yes
[16:09] <dimitern> katco, but once your change lands, their code won't compile anymore with v2
[16:09] <dimitern> if they use URL and/or SignedURL
[16:09] <katco> dimitern: my change is targetted against v3-unstable isn't it?
[16:09] <dimitern> katco, aww :/
[16:09] <dimitern> katco, that's my bad, sorry - I should've looked
[16:10] <katco> dimitern: oh no worries.. i was very confused! lol
[16:10] <dimitern> katco, and I actually asked you to re-target it :)
[16:10] <dimitern> katco, ok, then it's fine
[16:10] <dimitern> katco, still isn't URL worth keeping?
[16:10] <katco> dimitern: sure, i can add that back in
[16:10] <dimitern> katco, thanks
[16:11] <dimitern> katco, I'll update the review - how about the live tests?
[16:11] <katco> dimitern: it will be a function that is: .Region.ResolveS3BucketEndpoint(b.Name)+"/"+path
[16:11] <katco> dimitern: i still need to do that
[16:11] <dimitern> katco, however, just a sec
[16:11] <katco> dimitern: as you pointed out, obviously unit tests pass
[16:12] <dimitern> katco, if this needs to go in juju for 1.23, then you'll need to cherry-pick what's relevant from this and backport it to v2, isn't it?
[16:12] <katco> dimitern: any reason we can't move juju to v3?
[16:13] <dimitern> katco, we could, but this'll mean carefully integrating changes from v2, renaming v3-unstable to v3 and branching v4-unstable of it
[16:13] <dimitern> katco, as we can't depend on v3-unstable for a release in juju
[16:13] <katco> dimitern: right
[16:14] <katco> dimitern: i'm good with whatever you suggest
[16:14] <dimitern> katco, there are not many things to port from v2 to v3 IIRC
[16:15] <dimitern> katco, then let's agree to do this migration - I have a couple of PRs for goamz which I'll need to land before the freeze, so I'll re-target them to v3 as well
[16:15] <katco> dimitern: ok cool
[16:16] <dimitern> katco, cheers!
[16:16] <dimitern> katco, I didn't quite get your response on whether you've run go test -check.v -amazon in s3/
[16:16] <katco> dimitern: :) and progress marches inexorably forward!
[16:17] <katco> dimitern: no i haven't done that yet
[16:17] <dimitern> katco, as it should :)
[16:17] <dimitern> katco, ok, just a reminder then
[16:17] <katco> dimitern: yep, ty i didn't know about that flag
[16:17] <katco> dimitern: i was going to test manually
[16:18] <dimitern> katco, that's fine (ideally we'd like a live test using both s3test and live AWS), but at minimum let's ensure no existing local/live s3test/AWS tests break
[16:19] <katco> dimitern: will do. thanks for the pointers and your help.
[16:20] <dimitern> katco, no worries, thank's for bearing up with me :)
[16:20] <katco> dimitern: it was not a burden; great questions
[16:20] <dimitern> thanks even
[16:20] <dimitern> :)
[17:21] <voidspace> dimitern: ping
[17:21] <dimitern> voidspace, pong
[17:21] <voidspace> dimitern: hey, hi
[17:21] <voidspace> dimitern: I'm really struggling to test the lxc-broker changes
[17:22] <voidspace> dimitern: I could just mock out the call that takes the NetworkInfo and check that the results of PrepareContainerInterfaceInfo are used
[17:22] <voidspace> dimitern: but that seems yucky
[17:22] <dimitern> voidspace, hmm, let me think
[17:22] <voidspace> dimitern: and as far as I can tell the results of calling broker.StartInstance don't include network details to check
[17:22] <voidspace> surprisingly result.NetworkInfo is empty (nil) so I can't inspect that
[17:22] <dimitern> voidspace, do you have a wip branch up to have a look?
[17:23] <voidspace> dimitern: yep, hang on
[17:23] <voidspace> dimitern: I'll push what I have
[17:23] <dimitern> voidspace, cheers
[17:23] <voidspace> ah, there might be an lxc.conf file I can look at...
[17:23] <voidspace> just discover3ed
[17:23] <dimitern> voidspace, so the result of StartInstance after PCII() did its job must have NetworkInfo populated
[17:23] <voidspace> dimitern: shall I check that first?
[17:24] <dimitern> voidspace, yes please
[17:24] <voidspace> well, it doesn't but I can confirm that our code is being called...
[17:24] <voidspace> dimitern: I'll check the conf file and see if it has testable info
[17:24] <dimitern> voidspace, because this is later needed in other cases
[17:25] <dimitern> voidspace, so, the result of PCII() is used to generate lxc.conf, cloud-init userdata, and to run a few commands essentially
[17:25] <voidspace> right
[17:25] <dimitern> voidspace, so all these should be testable, but I might've missed something
[17:26] <voidspace> testing the commands would just duplicate the production code in the tests so seems pointless
[17:27] <voidspace> dimitern: see TestNetworking in this branch
[17:27] <voidspace> dimitern: https://github.com/voidspace/juju/compare/container-prepareprovisioner
[17:27] <dimitern> voidspace, looking
[17:27] <voidspace> dimitern: the output of lxc.NetworkInfo is "[]network.InterfaceInfo(nil)"
[17:28] <voidspace> so NetworkInfo on the StartInstanceResult is not populated
[17:28] <voidspace> (and I haven't moved forwarding setup to container initialisation yet because that's trivial to do - although also not easy to test)
[17:29] <ericsnow> niemeyer: thanks for the feedback on "fakes"
[17:29] <dimitern> voidspace, not in my demo branch, but it should be populated
[17:29] <ericsnow> niemeyer: it's very insightful and has given me plenty to think about :)
[17:29] <voidspace> dimitern: oh, you mean this is something additional that should be done?
[17:31] <dimitern> voidspace, well, my plan is to support passing non-empty args.NetworkInfo to StartInstance() for cases like "start with statically configured network" or "create these 3 nics like this", etc.
[17:31] <voidspace> ok
[17:32] <niemeyer> ericsnow: Glad it's being useful
[17:32] <dimitern> voidspace, then, inside PCII() handle what's needed and return an updated NetworkInfo which is then returned by StartInstance for other uses
[17:33] <dimitern> voidspace, e.g. to update the firewall rules or something else that happens on the host of the newly provisioned container
[17:33] <voidspace> ok
[17:33] <voidspace> dimitern: by the way, pretty sure we'll get the keys to the new house on Wednesday
[17:33] <voidspace> dimitern: so I'll be in Monday and Tuesday
[17:33] <dimitern> voidspace, +1, sure
[17:34] <voidspace> dimitern: thanks
[17:34] <dimitern> voidspace, so coming back to your question
[17:34] <dimitern> voidspace, these are a few ideas of what needs testing there
[17:35] <dimitern> voidspace, 1. given a networkInfo and provided networking and address allocation is supported, verify we get an updated networkInfo out of start instance
[17:36] <dimitern> (updated like - having an Address, DNSServers and GatewayAddress, as well as ConfigStatic)
[17:37] <dimitern> voidspace, 2. test local dns servers are parsed and added, when available (mocking where you read them from ofc)
[17:38] <dimitern> voidspace, 3. the necessary commands for setting up routes, etc. are called (also by mocking - there are a few similar examples in the cmd/ package IIRC and around cloudinit/sshinit)
[17:39] <dimitern> voidspace, 4. for lxc specifically, check the lxc.conf is updated as expected, and the cloud-init userdata gets updated
[17:39] <dimitern> voidspace, all these are just the happy path tests
[17:40] <dimitern> voidspace, the failures need testing as well - like if PCII fails or one of the other steps fail
[17:41] <dimitern> voidspace, how does this sound?
[17:43] <voidspace> dimitern: so that will mean *adding* the networkInfo :-)
[17:43] <voidspace> dimitern: lxc.conf does include some details from PCII() (network name and MAC)
[17:43] <voidspace> dimitern: testing 2 & 3 will effectively mean duplicating the commands straight from the code into the test
[17:44] <voidspace> dimitern: so they're not very good tests
[17:44] <dimitern> voidspace, well, not quite :)
[17:44] <voidspace> dimitern: mock and record the calls, check the calls match the expected calls
[17:44] <dimitern> voidspace, the command tests can separately test the behavior around parsing resolv.conf and setting up iptables, etc.
[17:45] <voidspace> dimitern: what do you mean by "command tests"?
[17:45] <dimitern> voidspace, while the start instance tests can just check the commands get called or fail
[17:45] <voidspace> voidspace: executeCommands is called several times (3 I believe)
[17:45] <voidspace> oops, dimitern ^^
[17:45] <dimitern> voidspace, I mean the tests around localDNSServers etc.
[17:46] <voidspace> dimitern: the only way to test that localDNSServers is used is to record what executeCommands is called with and check it matches the production code
[17:46] <voidspace> dimitern: I mock readFile and I can check the pre-canned data is used, so I can test the file is read
[17:47] <dimitern> voidspace, let's have a chat on monday ;)
[17:47] <voidspace> which more-or-less amounts to the same thing
[17:47] <voidspace> dimitern: just to clarify though
[17:47] <dimitern> voidspace, I need to sit down and write this first
[17:47] <voidspace> dimitern: you need the NetworkInfo populated on StartInstanceResult?
[17:47] <dimitern> voidspace, I'm thinking of several levels of tests
[17:47] <dimitern> voidspace, yes, indeed
[17:47] <voidspace> right
[17:47] <voidspace> I'll look at adding that
[17:48] <dimitern> voidspace, ta!
[17:56] <dimitern> happy weekends everyone! ;)
[17:57] <perrito666> dimitern: likewise
[17:57] <dimitern> perrito666, ;) cheers
[18:15] <marcoceppi> natefinch  : any chance we could get this looked at? It's break charm testing and has kind of a weird long standing low priority https://bugs.launchpad.net/juju/+bug/802117
[18:15] <mup> Bug #802117: juju ssh/scp commands cause spurious key errors <ssh> <Amulet:Triaged> <pyjuju:Triaged> <juju-core:Triaged> <juju (Ubuntu):Triaged> <https://launchpad.net/bugs/802117>
[18:21] <sinzui> marcoceppi, ci works around the issue with a rule like this
[18:21] <sinzui> host 10.* 172.* 54.85.* 15.185.*
[18:21] <sinzui>   StrictHostKeyChecking no
[18:21] <sinzui>   UserKnownHostsFile /dev/null
[18:22] <marcoceppi> sinzui: I can't expect every user to do that though
[18:23] <sinzui> marcoceppi, I expect ever cloud user and lxc user has come across this given time and has realised they don't want those ips in the files
[18:24] <marcoceppi> :\ I have several long running instances in Amazon that I would like hostkeychecking with
[18:37] <alexisb> dude marcoceppi that bug has been around a long time
[18:54] <marcoceppi> alexisb: yeah, it totally has! Someone just hit it on the mailing list. I've always just removed offending keys but surely we can do better
[18:54] <alexisb> marcoceppi, we can it is a matter of prioritizing it amount the 800+ other bugs
[18:54] <alexisb> so tag it, and send me a mail
[18:57] <marcoceppi> Tag it what?
[18:57] <natefinch> marcoceppi: just got back to the keyboard.  Sounds like alexisb has you covered.
[18:58] <natefinch> haha, that bug is older than all my kids
[18:58] <alexisb> natefinch, mine too! ;)
[18:58] <alexisb> marcoceppi, that is an excellent question, we need better tags, for now send me a note with the bug number
[18:59] <marcoceppi> alexisb: ack
[19:00] <natefinch> haha that's from before the project was called juju :)
[19:01] <marcoceppi> Yeah, it's been lingering around for a bit ;)
[19:01] <natefinch> Hey, sweet, monday is a holiday in the US
[19:03] <perrito666> natefinch: here too, and also tuesday
[19:03] <perrito666> natefinch: what is it there?
[19:03] <voidspace> right
[19:03] <voidspace> EOW
[19:03] <voidspace> g'night all
[19:03] <voidspace> see you on Monday
[19:03] <voidspace> except natefinch ...
[19:04] <sinzui> marcoceppi, "charmers" is the official tag for ecosystems stakeholders
[19:04] <natefinch> perrito666: George Washington's birthday (first President of the US).... guessing that's not what you're celebrating ;)
[19:04] <perrito666> natefinch: carnival :p
[19:06] <sinzui> marcoceppi, and ha ha. regarding those ssh rules I pasted. we don't have those rules for azure and this just just failed http://juju-ci.vapour.ws:8080/job/azure-quickstart-bundle/211/console
[19:06] <marcoceppi> <3
[19:14] <natefinch> wwitzel3: you wanted some pictures of the snow?  Here you go: http://imgur.com/a/yqfQS
[19:16] <TheMue> so, 8:15pm, time for a Single Malt, bye folks, enjoy your weekends
[19:18] <natefinch> I love the way that I can search for gimp in the software center and it comes up, but if I click on it, it says it can't be found
[19:18] <perrito666> natefinch: ???
[19:19] <natefinch> $ sudo apt-get install gimp
[19:19] <natefinch> [sudo] password for nate:
[19:19] <natefinch> Reading package lists... Done
[19:19] <natefinch> Building dependency tree
[19:19] <natefinch> Reading state information... Done
[19:19] <natefinch> Package gimp is not available, but is referred to by another package.
[19:19] <natefinch> This may mean that the package is missing, has been obsoleted, or
[19:19] <natefinch> is only available from another source
[19:19] <natefinch> E: Package 'gimp' has no installation candidate
[19:20] <mbruzek> jog ping?
[19:21] <jog> mbruzek, pong
[19:21] <mbruzek> jog is the link to the kubernetes reports http://reports.vapour.ws/kubernetes ?
[19:21] <mbruzek> Is my url incorrect or is it not working again?
[19:22] <jog> http://reports.vapour.ws/charm-summary/kubernetes
[19:24] <mbruzek> jog thanks I spaced on the URL
[19:24] <jog> mbruzek, http://reports.vapour.ws/charm-summary is the top level for charms and lists all that have test results. If you want to narrow it down to a particular charm you can append /"short charm name" to the URL
[19:25] <mbruzek> jog that is logical, I was not aware
[19:26] <jog> mbruzek, or you can find the charm you are interested in on the top level page and just click on it's Charm column entry to get the filtered page.
[19:33] <natefinch> perrito666: for reference, somehow "main" got unchecked from my list of package sources
[19:33] <perrito666> ouch
[19:34] <natefinch> yay for utopic :/
[19:35] <perrito666> you should try vivid
[20:56] <ericsnow> natefinch: could you take a quick look at https://github.com/juju/testing/pull/51
[20:56] <ericsnow> natefinch: niemeyer convinced me Fake wasn't the right name :)
[20:59] <katco> ericsnow: fwiw that's the nomenclature i've always seen as well (mocks, stubs)
[21:07] <natefinch> ericsnow, katco:  I generally use stub as a verb, to stub out an interface, which generally means "make it compile but don't have any logic".  However, if there are some well-known nomenclatures, it makes sense to follow those, even if I think they're silly :)
[21:07] <ericsnow> natefinch: yep
[21:08] <ericsnow> natefinch: so all that patch does it change the name
[21:08] <katco> natefinch: i was the same, but wallyworld pointed out to me awhile ago that stub had an actual meaning.
[21:09] <katco> natefinch: as far as agreeing on nomenclature, that's rather important... i.e. it's how humans communicate ;)
[21:09] <perrito666> katco: oh no biggie, we can code a shim to translate between our nomenclatures
[21:10] <ericsnow> katco: see http://martinfowler.com/articles/mocksArentStubs.html#TheDifferenceBetweenMocksAndStubs
[21:10] <katco> perrito666: whassa shim? you mean facade? (tongue firmly in cheek)
[21:10] <natefinch> ha
[21:10] <katco> ericsnow: yeah that's exactly what i read a few months ago
[21:10] <ericsnow> katco: Fowler cites http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html
[21:10] <katco> ericsnow: also, regarding the end-to-end vs. mock/stub debate
[21:10] <ericsnow> katco: and that guy has the noble goal of sorting out the nomenclature :)
[21:11] <katco> ericsnow: i feel like we're rehashing this. i sent out an email a bit ago about the new top-level featuretests package
[21:11] <ericsnow> katco: eh, I'll still argue both have their place :)
[21:11] <katco> ericsnow: and my understanding of what the team had agreed upon for going forward: mocks/stubs embedded along-side code. happy-path end-to-end functional tests in featuretests/*
[21:12] <ericsnow> katco: right
[21:12] <katco> ericsnow: maybe i confused myself. it just seemed like we were headed back towards that conversation on the ML
[21:30] <ericsnow> natefinch: thanks