[00:00] <davecheney> wallyworld: bigjools needs gwacls updated on the bot ?
[00:00]  * bigjools needs gwacl updating on there so I can land a dependent core branch
[00:00] <wallyworld> i think i can. never done it. let me try
[00:00] <bigjools> mucho grassy ass
[00:07] <wallyworld> bigjools: i can ssh into the bot machine and i've found the src tree but when i do a bzr status in the gwacl directory i get: bzr: ERROR: No such file: u'/home/tarmac/trees/src/launchpad.net/gwacl/.bzr/checkout/shelf'
[00:07] <wallyworld> nfi
[00:07] <bigjools> can you just do a "bzr up"
[00:07] <bigjools> seems like it's a checkout
[00:08] <wallyworld> why wouldn't bzr status work?
[00:08] <bigjools> nfi
[00:08] <bigjools> does bzr info work?
[00:08] <wallyworld> yes
[00:09] <wallyworld> there's a lock preventing update right now. but there's also a build running
[00:09] <wallyworld> i'll try again after the build
[00:09] <bigjools> how often does tarmac run?
[00:09] <bigjools> you might need to disable it temporarily
[00:09] <wallyworld> actually, it's a permission denied
[00:10] <bigjools> O_o
[00:10] <wallyworld> because i'm logged in as ubuntu and it seems i need to be ~tarmac
[00:11] <wallyworld> and i don't know the password to su
[00:11] <wallyworld> i'll see if it's in an email somewhere
[00:11] <bigjools> can you ssh tarmac@ ... ?
[00:12] <wallyworld> no, permission denied public key
[00:12] <bigjools> ah well
[00:12] <wallyworld> i'll try and find a password
[00:12] <bigjools> thanks man
[00:23] <wallyworld> bigjools: done
[00:23] <bigjools> wallyworld: \o/  thanks
[00:23] <bigjools> coffee++
[00:23] <wallyworld> np. rev is 207
[00:23] <wallyworld> yeah coffee
[01:10] <thumper> wallyworld: while you are in the landing bot, care to update loggo?
[01:10] <davecheney> heads up, 1.12.0  has been released https://launchpad.net/juju-core/1.12/1.12.0
[01:10] <wallyworld> thumper: sure
[01:12] <jcastro> heya davecheney and thumper!
[01:12] <thumper> hi jcastro
[01:13] <davecheney> jcastro: sup!
[01:13] <jcastro> shiny 1.12!
[01:14] <davecheney> jcastro: yeah, just doing the paperwork now
[01:14] <thumper> wallyworld: to deploy wordpress in a container on machine 0 I can do `juju deploy wordpress --to lxc:0` ?
[01:15] <thumper> wallyworld: and for a new machine "--to lxc"
[01:15] <wallyworld> thumper: supposedly :-)
[01:15] <thumper> ?
[01:15] <thumper> wallyworld: I'll try
[01:15] <thumper> my eyes are funny
[01:15] <wallyworld> the --to lxc doesn't work i don't think
[01:15] <thumper> I think it is lack of oxygen or something
[01:15] <jcastro> I deployed an entire wordpress stack to one AWS node today, it was glorious
[01:15] <thumper> jcastro: yeah, saw the blog post
[01:16]  * thumper waits for scp so he can bootstrap
[01:16] <thumper> then I can go do something else while it boots
[01:16] <thumper> jcastro: do you have any test maas environments?
[01:17] <wallyworld> thumper: loggo on tarmac says no new revisions to pull
[01:17] <jcastro> thumper: nope
[01:17] <thumper> wallyworld: check to see if it is a branch or checkout
[01:17] <thumper> wallyworld: also check revno
[01:17] <jcastro> thumper: I do know the world wants constraints for the maas provider
[01:18] <thumper> wallyworld: want 39
[01:18] <wallyworld> thumper: yep, it is
[01:18] <thumper> oh... ok
[01:18] <thumper> seems updated then
[01:18] <thumper> \o/
[01:18] <wallyworld> coolio
[01:19] <thumper> jcastro: perhaps I should ask sabdfl for access to his maas :)
[01:20] <jcastro> I was going to recommend that exact thing
[01:20] <jcastro> mims is on holiday so it's probably sitting idle
[01:20] <davecheney> https://docs.google.com/a/canonical.com/document/d/1eeHzbtyt_4dlKQMof-vRfplMWMrClBx32k6BFI-77MI/edit#heading=h.o3idq0wwl0yz
[01:20]  * thumper turns the lights on in bigjools's room
[01:20] <davecheney> ^ nudge, please add agenda items for tonight
[01:20] <davecheney> evilnickveitch: ping
[01:21] <thumper> davecheney: ack

[01:23] <davecheney> still can't access all hands ...
[01:30] <wallyworld> thumper: i didn't know bigjools liked it with the light on?
[01:31] <bigjools> true, you normally turn it off for us
[01:31] <wallyworld> yep, but then i can't watch :-(
[01:34] <davecheney> axw: do you think https://canonical.leankit.com/Boards/View/103148069/105051172 is done ?
[01:35] <davecheney> (sorry if you don't have perms for leankit)
[01:35] <axw> davecheney: looking
[01:35] <axw> I do now
[01:35] <axw> davecheney: it works fine for me
[01:35] <axw> I have the 13.04 packaged version
[01:36] <axw> never saw any of the weirdness that was logged in the LP bugs
[01:36] <davecheney> cool, assign to yourself and move it to the RHS
[01:36] <axw> okey dokey
[01:36] <evilnickveitch> davecheney, hi
[01:37] <wallyworld> m_3: marcoceppi: thanks for the replies. could you copy to the list also so others can see your thoughts? sorry, i should have cc'ed you to the original juju-dev email
[01:37] <marcoceppi> wallyworld: yeah, just joined the juju-dev mailing list. Surprised I wasn't already on it
[01:38] <davecheney> axw: how about this one ? https://canonical.leankit.com/Boards/View/103148069/106071705
[01:38] <axw> davecheney: no. thumper has something in the works that changes logging, so I'm holding off for now
[01:38]  * thumper is back
[01:38] <marcoceppi> wallyworld: cc'd
[01:38] <wallyworld> thanks :-)
[01:39] <davecheney> ok
[01:39] <thumper> davecheney: yeah I have a branch pending that messes with logging somewhat
[01:40] <davecheney> thumper: ok
[01:40] <davecheney> cool
[01:41] <jcastro> hey, remove-unit also takes the instance down right?
[01:41] <axw> davecheney: when you say move to the right, do you mean into the review column?
[01:41] <davecheney> jcastro: yes
[01:42] <jcastro> that's what I thought
[01:42] <davecheney> axw: at your judgement, if it isn't reviewable, then drop it in merged
[01:42] <davecheney> i look in that column when writing the release notes
[01:42] <axw> ok
[01:47] <thumper> wallyworld: so... how do I deploy something into a new machine in a container
[01:47] <thumper> what's the syntax?
[01:47] <wallyworld> thumper: let me check. i thought you needed to use add-machine first
[01:48] <wallyworld> there was a constraint also
[01:48] <thumper> right
[01:48] <thumper> I'm hoping I can just go 'juju deploy mysql --constraints container=lxc
[01:48] <thumper> something like that
[01:50] <wallyworld> thumper: yes that will work
[01:50] <wallyworld> but it's not what big mark likes
[01:51] <thumper> :)
[01:51] <wallyworld> he prefers add-machine
[01:51] <wallyworld> to create a container
[01:51] <wallyworld> then --to to select
[01:51]  * thumper tries it
[01:51] <wallyworld> thumper: we haven't publicised the constraints version
[01:51] <wallyworld> because it is verboten
[01:51] <thumper> ok, that is starting
[01:52] <wallyworld> but the code was already committed
[01:52]  * thumper waits 25 minutes
[01:52] <thumper> I have wordpress coming up in 0/lxc/0
[01:52] <thumper> and mysql in 1/lxc/0
[01:52] <bigjools> thumper: I see node 2 startting
[01:52] <wallyworld> yay
[01:52] <thumper> and we'll see if they can talk to each other
[01:52] <bigjools> that one has a VGA cable on it :)
[01:52] <wallyworld> don't forget to add a relation
[01:52] <thumper> bigjools: yep, up it comes
[01:53] <thumper> relation added
[01:53] <thumper> now we wait
[02:10] <axw> if anyone's bored, I would appreciate some more eyes on this: https://codereview.appspot.com/12019043/
[02:10] <axw> davecheney: I yoinked the code out of your old branch for debug-hooks
[02:11] <axw> thanks
[02:11] <axw> :)
[02:11] <bigjools> thumper: it's booting locally now
[02:12] <thumper> \o/
[02:15] <bigjools> thumper: might be done
[02:22] <thumper> bigjools: no, it is downloading the cloud image for the container now
[02:23] <bigjools> thumper: my interwebs don't look that busy, so I suspect not
[02:23] <thumper> ah... dumb bug
[02:23] <thumper> I saw the same bug on ec2
[02:25] <thumper> bigjools: how's those interweb tubes now?
[02:25] <bigjools> thumper: busy
[02:26] <bigjools> I see blinkenlights
[02:26] <thumper> \o/
[02:26] <bigjools> two lots of routers, three lots of switches and a modem all looking furious with you
[02:38] <thumper> oh fark
[02:38]  * thumper stabs maas
[02:38] <thumper> the uniter internally dies inside the container
[02:39] <thumper> /var/lib/juju/MAASmachine.txt: no such file or directory
[02:39] <bigjools> is container a verb here? :)
[02:39]  * thumper hacks something
[02:40]  * davecheney containers something
[02:40] <thumper> aahgg
[02:40]  * thumper stabs the nearest thing
[02:41]  * davecheney goes for lunch
[02:44] <thumper> poo bum
[02:44]  * thumper grrs
[02:45] <thumper> I know what that failed now
[02:47] <thumper> bigjools: hey
[02:47] <bigjools> yarp
[02:47] <thumper> bigjools: is there a monitor attached to your maas controller?
[02:47] <thumper> and keyboard?
[02:47] <thumper> bigjools: if you hit http://10.0.0.208 what do you see?
[02:47] <thumper> bigjools: I'm hoping for a wordpress error page
[02:47] <thumper> saying no db configured
[02:48] <bigjools> you mean the server or one of the nodes?
[02:48] <thumper> or something like that
[02:48] <thumper> bigjools: just something on the 10 net
[02:48] <thumper> bigjools: the server is fine
[02:48] <bigjools> I don't, I would only ssh into the server and use wget
[02:49] <thumper> :(
[02:49] <thumper> ok
[02:49] <bigjools> but you can do that too :)
[02:50]  * thumper noes
[02:50] <bigjools> the 10. network is totally isolated for safety, I only access via ssh to the maas server
[02:50] <bigjools> you could port forward with ssh
[02:50] <bigjools> remember how -L works
[02:51] <bigjools> -L localport:remotehost:remoteport
[02:51] <bigjools> where remotehost is the IP as seen from the host you're sshing into
[02:55] <thumper> oh yeah...
[02:56] <thumper> wallyworld: definitely got a problem with the machine watcher
[02:56] <thumper> on new machines
[02:56] <thumper> wallyworld: where it is looking for containers
[02:56] <thumper> wallyworld: it isn't getting initial state
[02:56] <wallyworld> that bit was rewritten by william i think
[02:57] <thumper> :(
[02:57] <wallyworld> there was a large refactoring some weeks back
[03:13] <thumper> agent-state-info: 'hook failed: "config-changed"'
[03:13] <thumper> jpw dp O fox tjat?
[03:13] <thumper> hehe
[03:13] <thumper> how do I fix that?
[03:13] <thumper> that was an unintentional weird right hand shift cypher
[03:44]  * thumper sets up two ssh tunnels
[03:44]  * thumper wonders if this weird shit will work
[03:44]  * thumper has broken juju in a number of ways today
[03:54] <thumper> *sad face*
[03:54]  * thumper needs debug hooks
[04:08] <axw> thumper: https://codereview.appspot.com/12019043/ ;)
[04:08] <thumper> shortly, off to make a coffee and drown my woes in caffeine
[04:09] <axw> heh :)
[04:21] <davecheney> axw: do you think debug hooks will land this week ?
[04:36] <thumper> axw: I have a feeling that review is going to take longer than I can actually give right now
[04:36]  * thumper hands it to wallyworld
[04:36]  * thumper writes up learnings
[04:36]  * wallyworld is trying to get ^#@!%^^! tests to pass
[04:40] <axw> davecheney: sorry, was making lunch. not sure - still at 0 LGTMs ;)
[04:41] <axw> thumper: nps
[04:56]  * thumper back for the meeting later
[06:07] <davecheney> wallyworld: https://docs.google.com/a/canonical.com/document/d/1WpyfTgaChhmYFqPESBvfavbqLD1Fsj16NLW5PhmWxis/edit#
[06:07] <davecheney> ^ as you've made everyone very happy with the --to flag
[06:07] <davecheney> could you write a line or two about it
[06:07] <davecheney> natefinch: bonjour!
[06:08] <wallyworld> davecheney: when is the release? friday?
[06:09] <davecheney> yup
[06:09] <davecheney> or next week
[06:09] <davecheney> but it's been two weeks since we did one
[06:09] <wallyworld> davecheney: i have to go get my kid from school, i'll do it a bit later
[06:09] <davecheney> wallyworld: no hurry
[06:11] <wallyworld> davecheney: --to was already released in 1.11.3
[06:11] <davecheney> wallyworld: really ?
[06:11] <davecheney> did we call it out ?
[06:11] <wallyworld> yeah
[06:11] <wallyworld> i just checked the relese notes
[06:11] <davecheney> oh well, ignore it then
[06:12] <wallyworld> ok :-)
[06:12]  * wallyworld drives to do school pickup
[06:33] <davecheney> wallyworld:  https://codereview.appspot.com/12232043/
[06:34] <davecheney> ^ won't this CL drive bigjools even more mental ?
[06:34] <davecheney> ie, we're moving state out of the state, back to the local disk ?
[06:54] <wallyworld> davecheney: it's not state but rather configuration
[06:55] <wallyworld> stuff that was in env.yaml but will now be separate
[06:55] <wallyworld> it's as per big mark and william's design
[06:55] <davecheney> fair enough
[06:55] <davecheney> i'm sure they know what they are doing
[06:55] <wallyworld> let's hope so ;-)
[06:55] <davecheney> config is a cluster fuck
[06:55] <wallyworld> yep
[06:55] <davecheney> it' can't get any worse
[06:56] <wallyworld> yep :-)
[06:56] <wallyworld> this will make it much easier for users
[06:56] <wallyworld> it's one step of many
[06:56] <davecheney> i'm sure it's written down
[06:56] <wallyworld> to clean up env.yaml
[06:56] <davecheney> i just missed it
[06:57] <wallyworld> davecheney: https://docs.google.com/a/canonical.com/document/d/1ncsNzDHauV_9Fwsm59GjX0-O-_g48UYnObefwtBStG0/edit
[06:57] <davecheney> that's the ticket
[06:57] <rogpeppe> mornin' all
[06:57] <rogpeppe> davecheney: hiya
[06:57] <wallyworld> g'day
[06:57] <rogpeppe> davecheney: do you know where i can get hold of a copy of juju v1.12 ?
[06:58] <davecheney> rogpeppe: https://launchpad.net/juju-core/1.12/1.12.0
[06:58] <rogpeppe> davecheney: does that have the dependencies too?
[06:58] <davecheney> rogpeppe: yes
[06:59] <rogpeppe> davecheney: great, thanks!
[06:59] <davecheney> untar it, set your GOPATH to the base of the tar
[06:59] <davecheney> go install ...
[06:59] <rogpeppe> davecheney: the idea with config is that bootstrapping gives us a nugget of information that we store to the local disk (or in some other service).
[06:59] <rogpeppe> davecheney: we then use that to connect back to the environment
[07:00] <rogpeppe> davecheney: it's definitely a change of model, but i think it makes some kind of sense
[07:00] <rogpeppe> davecheney: and we've already moved in that direction by storing the CA cert locally
[07:01] <davecheney> rogpeppe: wallyworld not arguing with you two in anyway
[07:01] <davecheney> but bigjools with go ape balls
[07:01] <davecheney> that may or may not be a concern
[07:01] <rogpeppe> davecheney: i'm interested in your reaction, because this is definitely a change in direction and i don't think it's been widely discussed
[07:02] <rogpeppe> davecheney: and i'm interested what concerns bigjools might have too
[07:02] <davecheney> rogpeppe: in as much as I am repeating what bigjools said, he doesn't like all the stuff we store in ~/.juju
[07:02] <davecheney> i take no position on the matter as I have not been invovled in the design
[07:03] <wallyworld> the long term goal is to store it in the cloud, for jaas etc
[07:03] <wallyworld> it's all in the doc
[07:03] <rogpeppe> davecheney: do you know why he doesn't like the stuff we store in ~/.juju ?
[07:03] <davecheney> rogpeppe: he has more than one computer
[07:03] <wallyworld> hence the long term goal :-)
[07:03] <rogpeppe> davecheney: presumably he has to replicate his environments.yaml across all his computers
[07:04] <wallyworld> and this isn't adding anything more locally
[07:04] <wallyworld> just moving the deck chairs a little
[07:04] <rogpeppe> davecheney: i guess he only has to do that once though (now), for a given environment
[07:04] <rogpeppe> wallyworld: actually i think this *is* adding more locally
[07:04] <wallyworld> and it will still be only once
[07:04] <rogpeppe> wallyworld: it's manufacturing a control bucket
[07:04] <wallyworld> we do that *now*
[07:04] <wallyworld> with juju init
[07:05] <rogpeppe> wallyworld: that's different
[07:05] <rogpeppe> wallyworld: you don't need to use juju init
[07:05] <wallyworld> but most people do
[07:05] <rogpeppe> wallyworld: and it's a manual editing step
[07:05] <davecheney> i've read that documenta nd mow even more confused
[07:05] <wallyworld> sorry, whats manual?
[07:05] <rogpeppe> wallyworld: and it only happens once for a given environment, no matter how many times that env is bootstrapped
[07:05] <rogpeppe> wallyworld: you edit environments.yaml manually
[07:05] <wallyworld> that's all that happens with the new stuff too
[07:06] <wallyworld> it's on;y done once
[07:06] <wallyworld> no need to edit env.yaml with juju init
[07:06] <wallyworld> so long as your env variables contain creds
[07:06] <rogpeppe> wallyworld: so you don't create a new .environments/xxx file every time an env is bootstrapped?
[07:06] <wallyworld> nope
[07:06] <wallyworld> just the first time
[07:06] <wallyworld> for a given environment
[07:07] <rogpeppe> wallyworld: hmm, interesting. i'm not sure that's right actually, but i'll reserve judgement
[07:07] <wallyworld> so new env.yaml + local = old env yaml
[07:07] <wallyworld> so same info, just now in 2 places
[07:07] <wallyworld> env.yaml is the user facing bit
[07:07] <wallyworld> we want to make that as simple as possib;e
[07:08] <wallyworld> users don't need to edit admin secret or control bucket
[07:08] <wallyworld> that's internal juju magic
[07:08] <wallyworld> that shouldn't be exposed
[07:09] <davecheney> wallyworld: oh, so is this CL just hiding those two config options and setting them automatically ?
[07:09] <davecheney> you're not actually deleteing hte concept of a control bucket ?
[07:09] <wallyworld> yep
[07:09] <wallyworld> nope :-)
[07:09] <rogpeppe> wallyworld: the difficulty is that now we're assuming that the control bucket we automatically generate (out of the user's control) is going to be ok to use for all time
[07:09] <davecheney> right, objection withdrawn, i completely misunderstood what you were proposing
[07:09] <davecheney> +1, carry on
[07:09] <wallyworld> :-)
[07:10] <wallyworld> rogpeppe: i gotta take the dog for a walk, happy to discuss later
[07:10] <rogpeppe> wallyworld: enjoy!
[07:14] <mgz> someone remind me to reboot five mins before the meeting please :)
[07:14] <axw> wallyworld: I don't understand all the implications, but I was confused by those things in environments.yaml when I came across them. Wasn't sure what, if anything, I was meant to do with them.
[07:29]  * bigjools reads scrollback and thinks that davecheney thinks I'm an ogre
[07:29] <rogpeppe> bigjools: you're not?
[07:29] <rogpeppe> bigjools: :-)
[07:30] <bigjools> I am simply impatient with fuckwittery :)
[07:31] <rogpeppe> bigjools: makes you scary to all us fuckwits :-)
[07:31] <bigjools> ha
[07:31] <bigjools> it's probably the meds I am taking, they make me do crazy things
[07:31] <rogpeppe> bigjools: i am interested in your thoughts on this direction BTW
[07:32] <bigjools> can you summarise?  I didn't read scrollback in detail
[07:32] <TheMue> morning
[07:32] <rogpeppe> bigjools: basically, we're moving towards a model where bootstrapping an environment yields a nugget of information that's later used to connect to that environment
[07:32] <davecheney> bigjools: i was recalling your conversation when you found out how much environment specific state we stored on the client
[07:33] <rogpeppe> bigjools: that will currently be stored in local disk, but later can be stored in the cloud
[07:33] <bigjools> ah right
[07:33] <davecheney> TOO THE CLOUD!
[07:33] <bigjools> my thoughts are that this should be as HA as anything else
[07:33] <davecheney> https://twitter.com/riskybusiness/status/362456762521120768
[07:33] <rogpeppe> bigjools: this makes it possible to elimininate currently manually specified attributes such as control-bucket, and possibly admin-secret and others
[07:33] <bigjools> I know that film...
[07:34] <bigjools> rogpeppe: +1 to config elimination
[07:34] <davecheney> rogpeppe: it sounds like you and wallyworld are working at cross purposes
[07:34] <davecheney> wallyworld: is just making them take sensible defaults
[07:34] <davecheney> and you are trying to move them
[07:35] <rogpeppe> bigjools: obviously we can't eliminate config *entirely* because we need cloud credentials
[07:35] <rogpeppe> davecheney: i don't *think* so
[07:35] <bigjools> well obviously, but there's some stuff that's always been unnecessary
[07:36] <rogpeppe> davecheney: there's no sensible default for control-bucket, because of s3's global name space
[07:36] <davecheney> rogpeppe: a guid is a sensible default
[07:36] <rogpeppe> davecheney: sure, but then you need to store that guid somewhere
[07:36] <davecheney> rogpeppe: hence why i say that you and wallyworld are working at cross purposes
[07:37] <rogpeppe> davecheney: you may well be right
[07:37] <rogpeppe> davecheney: i'm coming from my understanding of fwereade and big mark's discussions
[07:37] <davecheney> i read that document
[07:37] <rogpeppe> davecheney: which may well be critically flawed
[07:37] <davecheney> it appears unrelated
[07:38] <bigjools> davecheney: btw I'll let you know tomorrow about azure improvements
[07:38] <rogpeppe> davecheney: search for "# write local state as follows:" in the document
[07:39] <rogpeppe> davecheney: that's the related piece
[07:49] <rogpeppe> wallyworld: it looks to me from https://codereview.appspot.com/12232043/diff/1/cmd/juju/bootstrap.go that the local state *is* written every time we call Bootstrap
[07:53] <davecheney> natefinch: it's dangerous to go alone, take this https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.mut2dk4mvoj39eq8jqni20ukoc?authuser=1
[07:54] <axw> mgz: 5 mins (or so)
[07:55] <natefinch> davecheney: thanks
[07:56] <mgz> axw: ta!
[08:01] <rogpeppe> fwereade: meeting?
[08:02] <dimitern> fwereade: meeting?
[08:02] <dimitern> wallyworld: ^^
[08:28] <thumper-afk> mramm: I'm counting on you cancelling the managers meeting in 2.5 hours :)
[08:29] <thumper> mramm: just saw the notification \o/
[08:30] <mramm> thumper: cool
[08:30] <mramm> see you in a couple of days ;)
[08:31] <thumper> mramm: yep
[08:31] <thumper> travel safe
[08:36] <natefinch> ok, back to bed for me.
[08:36] <axw> night
[08:36] <rogpeppe> fwereade, wallyworld: lost you
[08:48] <wallyworld___> rogpeppe: dimitern: stupid network died again, will talk to you guys after dinner
[08:48] <rogpeppe> wallyworld___: ok
[08:52] <rogpeppe> ([a-z]+:)?[0-9]+(/[a-z]+/[0-9]+)*
[08:53] <mgz> enlightening
[08:53] <rogpeppe> mgz: :-)
[08:53] <mgz> doesn't match
[08:54] <rogpeppe> lxc:0/kvm/12
[08:54] <fwereade> rogpeppe, lxc:0/kvm/12 is meaningless, I think
[08:54] <fwereade> ah I see
[08:54] <rogpeppe> fwereade: orly?
[08:55] <fwereade> rogpeppe, yeah, ignore me
[08:55] <fwereade> rogpeppe, wallyworld___, dimitern: my internets seem to be maybe functional again
[08:56] <fwereade> rogpeppe, wallyworld___, dimitern: so I'm back in the team meeting hangout if I'm wanted
[08:56] <rogpeppe> fwereade: i'm suggesting that we should have something in the names package that understands that syntax, and knows at least how to split off the new container part
[08:56] <fwereade> rogpeppe, still don't really think it's about names
[08:57] <axw> rogpeppe: are you okay with my response to your destroy-environment comments? okay to land?
[08:59] <wallyworld___> rogpeppe: dimitern: try again?
[09:06] <dimitern> wallyworld___: i filed bug 1207230 for it
[09:06] <_mup_> Bug #1207230: cmd/juju/addmachine.go might fail with unsupported container <juju-core:Confirmed> <https://launchpad.net/bugs/1207230>
[09:07] <dimitern> it's not urgent, i'll take care of it today or tomorrow
[09:07] <wallyworld___> dimitern: there error is that is not rejecting a machine id as an arg with a friendly message
[09:07] <dimitern> wallyworld___: oh?
[09:08] <dimitern> wallyworld___: isn't it supposed to accept both type:machine and machine?
[09:08] <wallyworld___> the arg has to be either an container type (lxc) or a container with machine (lxc:1)
[09:08] <wallyworld___> no
[09:08] <wallyworld___> remember it is adding a machine
[09:08] <dimitern> exactly, that's what i was saying
[09:08] <wallyworld___> add-machine machine-id makes no sense
[09:08] <dimitern> aaa
[09:08] <dimitern> ok
[09:09] <dimitern> so it should be "type:machine" or "type" only
[09:09] <wallyworld___> the error is the syntax check above the split is broken
[09:09] <wallyworld___> yes
[09:09] <dimitern> yep, ok will amend the bug
[09:09] <wallyworld___> thanks, sorry that i was initially unclear
[09:09] <wallyworld___> i had to cast my mind back
[09:11] <dimitern> no worries, thanks for clarifying
[10:22]  * fwereade back much later
[10:23] <dimitern> rogpeppe, TheMue: https://codereview.appspot.com/12198044 - StringsWorker
[10:26] <axw> good night
[10:35] <TheMue> dimitern: you've got a review
[10:35] <dimitern> TheMue: cheers
[10:36] <dimitern> rogpeppe: ping
[10:36] <rogpeppe> dimitern: pong
[10:36] <dimitern> rogpeppe: can you take a look at https://codereview.appspot.com/12198044
[10:36] <rogpeppe> dimitern: will do
[10:37] <dimitern> rogpeppe: thanks
[10:46] <mgz> rogpeppe: after that, can you look at the branches I've put up and tell me where I'm going wrong?
[10:46] <rogpeppe> mgz: i'll have a look
[10:46] <mgz> thanks
[11:18] <rogpeppe> dimitern: reviewed
[11:19] <rogpeppe> mgz: which branch should i look at first?
[11:22] <natefinch> I feel like I was just here...
[11:23] <dimitern> rogpeppe: thanks!
[11:24] <dimitern> rogpeppe: no Stop() ?
[11:24] <rogpeppe> dimitern: indeed.
[11:24] <dimitern> rogpeppe: i don't get it
[11:24] <rogpeppe> dimitern: not necessary
[11:24] <dimitern> rogpeppe: expand please
[11:25] <rogpeppe> dimitern: worker.Stop(typeWithKillAndWaitOnly) == w.Stop()
[11:25] <rogpeppe> dimitern: oops, didn't mean to send that
[11:25] <rogpeppe> dimitern: basically, nothing needs Stop - it's entirely implementable with Kill and Wait
[11:25] <rogpeppe> dimitern: and the only thing we need workers for is to pass to worker.Runner
[11:25] <dimitern> rogpeppe: but there are tests about stopping it cleanly
[11:25] <rogpeppe> dimitern: which does not require a Stop method
[11:26] <rogpeppe> dimitern: well then they should check that worker.Stop(w) stops it cleanly
[11:26] <dimitern> rogpeppe: wait, so there is a global Stop method in worker?
[11:26] <rogpeppe> dimitern: function, yes
[11:26] <dimitern> s/method/function/
[11:26] <dimitern> I see
[11:27] <dimitern> rogpeppe: ok then
[11:33] <TheMue> standup, lunch is waiting ;)
[11:33] <TheMue> dimitern, rogpeppe: ^^^
[11:33] <natefinch> or breakfast, for some of us ;)
[11:34] <wallyworld_> or more wine :-)
[11:49] <natefinch> rogpeppe: let me know when you'd like to do the code walkthrough, whenever is good for you is fine with me.
[11:49] <rogpeppe> natefinch: now's good if you like
[11:49] <natefinch> Sure
[11:49] <rogpeppe> natefinch: shall we reuse the standup hangout?
[11:50] <natefinch> rogpeppe: yep
[11:53]  * TheMue => lunchtime
[12:07] <ahasenack> hm, is something going on with the amazon tools bucket and juju?
[12:07] <ahasenack> 2013-08-01 12:07:09 ERROR juju supercommand.go:254 command failed: Get https://juju-dist.s3.amazonaws.com/tools/juju-1.11.4-precise-amd64.tgz: EOF
[12:07] <ahasenack> error: Get https://juju-dist.s3.amazonaws.com/tools/juju-1.11.4-precise-amd64.tgz: EOF
[12:07] <ahasenack> wget works on that url
[12:10]  * ahasenack freshens trunk
[12:12] <rvba> ahasenack: ohoh!  That's something thumper saw with the MAAS provider as well… I think it's worth filing a bug.
[12:14] <ahasenack> rvba: ok, let me just see if a recent trunk has it too. Mine is from yesterday
[12:15] <ahasenack> rvba: do you know if there is some rate limiting being applied to that bucket? I was trying sync-tools a few times before, testing --public (filed a bug), and now without --public and it started happening
[12:16] <rvba> ahasenack: no idea, maybe mgz/jam will know…
[12:18] <bigjools> this is the potential Go bug
[12:18] <rvba> bigjools: yes :)
[12:18] <rvba> That's him in person :)
[12:23] <ahasenack> rvba: it's working now. Either it was the delay (I waited until a new copy of trunk was downloaded and build), or the new code
[12:23] <ahasenack> I'm on Go 1.1.1
[12:24] <ahasenack> the bug I filed before about sync-tools and --public is https://bugs.launchpad.net/juju-core/+bug/1207294
[12:24] <rvba> ahasenack: I think it was just a genuine but transient problem… maybe rooted in Go itself.
[12:24] <_mup_> Bug #1207294: sync-tools fails with --public <juju-core:New> <https://launchpad.net/bugs/1207294>
[12:24] <ahasenack> I'm working around that bug now by making my control bucket temporarily named juju-dist ;)
[12:42] <ahasenack> I have a question, when generate-image is run and outputs this:
[12:42] <ahasenack> $ juju-metadata generate-image -i 65a1e7ba-eb56-48e6-9b4e-8f7c0c05e779  -s precise -r serverstack
[12:42] <ahasenack> Boilerplate image metadata files "index.json, imagemetadata.json" have been written to /home/andreas/.juju.
[12:42] <ahasenack> Copy the files to the path "streams/v1" in your cloud's public bucket.
[12:42] <ahasenack> that path, "streams/v1"
[12:42] <ahasenack> does that mean a bucket called streams?
[12:42] <ahasenack> or is that inside the juju-dist bucket? Or your control bucket?
[12:45] <ahasenack> since the public bucket url doesn't have a bucket component
[12:46] <mgz> rogpeppe: sorry, missed your question earlier. one branch depends on t'other, but they're pretty seperate. the machine one is the first.
[12:49] <marcoceppi> Has anyone gotten this error before?
[12:49] <marcoceppi> error: cannot get latest charm revision: charm not found in "/home/marco/Projects/charms": local:precise/relation-sentry
[12:49] <rogpeppe> mgz: ta
[12:50] <marcoceppi> However, ~/Projects/charms/precise/relation-sentry does indeed exist
[12:55] <dimitern> rogpeppe: updated https://codereview.appspot.com/12198044
[12:56] <dimitern> oops, missed one typo
[12:58] <dimitern> and one extra return, will repropose again after running tests
[12:58] <ahasenack> marcoceppi: hm, I might have, but I don't remember when or how now
[12:59] <marcoceppi> ahasenack: bleh, I'm really at a loss as to why it's freaking out. There are 5 charms in this local repo: wp, mysql, two custom subs, and this one standalone, and juju just does not like this charm
[13:00] <ahasenack> marcoceppi: I would check if that path is bzr branch, has or not a revision file, and if it's the same charm ou actually deployed, if you have deployed one already
[13:00] <ahasenack> marcoceppi: could it be that you have two or more metadata.yaml files with the same charm name inside? The directory of the charm dosn't matter
[13:01] <marcoceppi> ahasenack: checked that and it's not the case. These three charms are being auto-generated so I'm really just trying to focus on what I did wrong
[13:02] <marcoceppi> It has a .bzr dir and has revision information, I added a revision file to the charm (the other two that dpeloy don't have it and worked OK), metadata.yaml are all unique wrt names
[13:02] <marcoceppi> charm proof only complains about things like copyright file, etc
[13:03] <ahasenack> marcoceppi: -v?
[13:03] <marcoceppi> ahasenack: OH
[13:03] <marcoceppi> this is a problem
[13:03] <ahasenack> do tell
[13:04] <marcoceppi> first of all, feel really silly for not using -v, total shame on me over here
[13:04] <marcoceppi> 2013-08-01 13:03:37 WARNING juju repo.go:341 charm: failed to load charm at "/home/marco/Projects/charms/precise/relation-sentry": charm "relation-sentry" using a duplicated relation name: "mysql_db-wordpress_db"
[13:04] <marcoceppi> I have a provide and require using the same relation name, didn't realize that was a no-no
[13:05] <marcoceppi> This makes things a little more complicated, but I can work around it. ahasenack thanks!
[13:06] <ahasenack> marcoceppi: still, totally incorrect error message before
[13:06] <dimitern> rogpeppe: updated https://codereview.appspot.com/12198044/ now with all suggestions; sorry for the spam
[13:06] <ahasenack> marcoceppi: worth a papercut bug
[13:06] <marcoceppi> ahasenack: yeah, I'll open a bug about the wording for it
[13:06] <marcoceppi> ahasenack: and charm proof can be updated to catch things like this as well
[13:06] <rogpeppe> dimitern: np - am giving nate a walkthrough, will be a little while, sorry
[13:06] <ahasenack> marcoceppi: where can I get charm proof?
[13:06] <dimitern> rogpeppe: no worries
[13:06] <marcoceppi> ahasenack: charm-tools project
[13:07] <ahasenack> marcoceppi: got a ppa handy or is it just in a branch?
[13:07] <marcoceppi> ahasenack: it's in ppa:juju/pkgs
[13:07] <marcoceppi> to be moved to ppa:juju/<whatever we decide for tools>
[13:07] <ahasenack> marcoceppi: that's the one with pyjuju too, right?
[13:07] <marcoceppi> ahasenack: correct
[13:08] <marcoceppi> speaking of which ahasenack, I'm tempted to bite the bullet make a ppa:juju/tools and dump charm-tools, amulet, deployer, etc to it
[13:08] <ahasenack> marcoceppi: I like that name
[13:08] <marcoceppi> I don't think stable is the best name for it since a lot of these are just using build recipies
[13:08] <ahasenack> right
[13:08]  * marcoceppi pulls trigger
[13:31] <rogpeppe> dimitern: reviewed
[13:34] <dimitern> rogpeppe: cheers
[13:40] <marcoceppi> ahasenack: there's a ppa:juju/tools now, if you want to move the builds for juju-deployer/api over to it
[13:41] <ahasenack> ok
[13:42] <ahasenack> marcoceppi: do I have upload permissions?
[13:42] <marcoceppi> ahasenack: are you in the ~juju group?
[13:42] <ahasenack> let me check
[13:43] <ahasenack> marcoceppi: I'm not
[13:43] <ahasenack> marcoceppi: let's just let hazmat copy the branches and recipes and use them in ~juju
[13:43] <marcoceppi> ahasenack: works for me
[13:49] <rogpeppe> mgz: could you re-propose https://codereview.appspot.com/12218043/ please; i'm getting a chunk mismatch
[13:53] <ahasenack> :( I can't get juju to use my custom image
[13:55] <mgz> rogpeppe: wha?
[13:55] <rogpeppe> mgz: it's a not-uncomming rietveld/lbox error (i don't know which one's to blame)
[13:55] <mgz> 'ing reitveld
[13:55] <rogpeppe> uncommon
[13:57] <rogpeppe> mgz: your TestSetAddresses function isn't testing what you think it is
[13:57] <mgz> that's what I suspect
[13:57] <rogpeppe> mgz: the state.address type is broken
[13:57] <mgz> but... I'm not sure what the right way of asserting that stuff actually arrives in state is
[13:58] <rogpeppe> mgz: i suggest marshalling instance.Address directly (but change it so it doesn't embed the network scope)
[13:58] <rogpeppe> mgz: the usual thing is to call Machine again (or call Refresh)
[13:58] <rogpeppe> mgz: because otherwise you're not actually reading from mgo
[13:59] <rogpeppe> mgz: the reason that the address type is currently broken is that the fields are not exported
[13:59] <mgz> I may well end up sticking instance.Address straight in, but wanted parallel types for now so the serialisation is seperate from the various populating logic
[13:59] <mgz> ...gah, I changed that per a review comment
[14:00] <mgz> no wonder I was sure this worked previously :)
[14:00] <mgz> just recapitalise then?
[14:00] <rogpeppe> mgz: just use instance.Address :-)
[14:01] <rogpeppe> mgz: if it's got some "bson:" struct tags then it should be obvious that it's being serialised
[14:01] <rogpeppe> mgz: although i do really want some more formal controls on changes to structs that are serialised
[14:03] <rogpeppe> right, i need lunch
[14:05] <mgz> okay, that fails then passes correctly
[14:06] <dimitern> rogpeppe, TheMue: next in line https://codereview.appspot.com/12254043 - Deployer and MinUnitsWorker use StringsWorker now
[14:10] <TheMue> dimitern: reviewed
[14:10] <dimitern> TheMue: thanks
[14:21] <mgz> well, that was easy to make working at least
[14:22] <mattyw> I was going to take a look at https://bugs.launchpad.net/juju-core/+bug/1020322, but it looks like it's already been done?
[14:22] <_mup_> Bug #1020322: Unit not found message is repetitive <bitesize> <papercut> <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1020322>
[14:25] <dimitern> mgz: you've got a review
[14:25] <dimitern> mgz: also, please live test this
[14:26] <TheMue> hmmpf
[14:27] <TheMue> set --default would also introduce a behavior change
[14:28] <TheMue> empty strings as configuration values are alowed then
[14:28] <TheMue> dunno if this leads to compatibility problems
[14:29] <mgz> dimitern: I don't understand this comment of yours:
[14:30] <dimitern> mgz: and another one
[14:30] <dimitern> mgz: yeah?
[14:30] <mgz> > Also it's good to check this before that:
[14:30] <mgz> > c.Assert(machine.Addresses(), HasLen, 0)
[14:30] <mgz> that will never be the case I think? the issue I had was I got non-zero length even though the addresses never got in the doc
[14:31] <dimitern> mgz: I mean check there are no addresses before calling SetAddresses, then check the same once more before calling Refresh, and then check they're set after Refresh
[14:31] <mgz> but with the refresh, it will still be non-zero length, it will just also reload to actually exercise state
[14:31] <dimitern> mgz: hmm? i wonder why's that
[14:32] <mgz> ah, you meant right at the start after making the machine?
[14:32] <dimitern> mgz: so there should be a test to check what's the state when you never called SetAddresses on a fresh machine, and they should be an empty slice, i think
[14:32] <mgz> okay.
[14:32] <dimitern> rogpeppe: got a moment?
[14:37] <dimitern> mgz: could you return the favor by reviewing https://codereview.appspot.com/12254043/ ? :)
[14:40] <mgz> sure :)
[14:40] <dimitern> thanks!
[14:41] <mgz> oo, it even looks educational
[14:41] <rogpeppe> dimitern: just back from lunch, yes i've got a mo
[14:41] <dimitern> rogpeppe: about https://codereview.appspot.com/12254043/
[14:46] <mramm> hey hey
[14:47] <mramm> so we need to get provider specific constraints on the roadmap for the next few weeks
[14:48] <dimitern> mramm: like instance-type and such?
[14:50] <rogpeppe> dimitern: reviewed
[14:50] <dimitern> rogpeppe: thanks
[14:50] <dimitern> well, what do you know.. i ran out of stuff to do this week :)
[14:51] <dimitern> looking at bugs currently though
[14:52] <dimitern> mramm: is there a plan who's going to work on bugs and who on the remaining api stuff until the end of next week?
[14:53] <dimitern> rogpeppe: is this card merged now? Upgrader API only worker
[14:54] <rogpeppe> dimitern: nope
[14:54] <rogpeppe> dimitern: i'm just testing the 1.10->1.12->current upgrade path now
[14:55] <dimitern> rogpeppe: I see
[15:03] <mramm> dimitern: I think if you are working on API and can safely continue to do so it makes sense that you do
[15:04] <mramm> I don't think there is a "plan" from above
[15:04] <dimitern> mramm: ok then
[15:04] <mramm> I think you guys can work it all out ;)
[15:08] <dimitern> rogpeppe: I think I can start implementing the uniter API now, with the UA having connection to the API already, right?
[15:08] <rogpeppe> dimitern: well, it will have a connection to the API when my CL lands
[15:09] <rogpeppe> dimitern: which only has one review so far (https://codereview.appspot.com/12183043/ hint hint anyone :-])
[15:09] <dimitern> rogpeppe: yeah, but it'll happen soon anyway, and I won't be ready with it for a few days perhaps
[15:10] <dimitern> mgz: perhaps? ^^
[15:12] <dimitern> mgz: you hate responding to comments on rietveld, right? :)
[15:26] <mgz> somewhat :)
[15:27] <natefinch> rogpeppe: (or anyone else) got a second to help the newbie?  I made a small change that requires changes to several tests, so I want to make sure it's the right thing to do before I go changing 8 different tests
[15:27] <dimitern> natefinch: sure, bring it on :)
[15:27] <natefinch> Looking at this bug: https://bugs.launchpad.net/juju-core/+bug/1154938
[15:27] <_mup_> Bug #1154938: juju status should give the same help as juju bootstrap <bitesize> <cmdline> <ui> <juju-core:Triaged by natefinch> <https://launchpad.net/bugs/1154938>
[15:28] <natefinch> It says juju status should give the same message, but really ,wouldn't it be an appropriate message for any command that needs the default environment file?
[15:28] <dimitern> natefinch: ok, but where's your CL?
[15:29] <mgz> hm, the state package really doesn't use loggo anywhere?
[15:29] <natefinch> I'll check it in, it just breaks some tests as-is... wasn't sure if I should check in and then ask
[15:29] <dimitern> mgz: not yet
[15:29] <dimitern> natefinch: if it breaks tests, then definitely don't :) the bot won't let you anyway
[15:31] <natefinch> dimitern: ok, good.  So... the change is just to have environs.ReadEnvirons to return a specific error if it can't read the default environments.yaml file... and then in cmd/Main() check for the file and output that error message to the context's stderr  (just like it did for bootstrap)
[15:32] <dimitern> natefinch: can I see a link to the branch please?
[15:34] <natefinch> like I said, the changes are only local right now, they're not commited.
[15:34] <natefinch> Maybe I'm not using the right terminology for bzr... I'm still new to it.
[15:34] <dimitern> natefinch: can you push it on LP so I can have a look? you can do lbox propose -wip
[15:34] <natefinch> dimitern: thanks... new to LP too :)
[15:35] <mgz> natefinch: bzr diff|pastebinit
[15:35] <dimitern> natefinch: that way it's pushed on LP, and a CL on rietveld is created, but no mails are sent
[15:35] <dimitern> natefinch: ah, sorry
[15:35] <mgz> for the even more lo-fi method
[15:35] <dimitern> natefinch: do you have lbox working?
[15:35] <natefinch> it's installed, haven't run it, so....
[15:36] <dimitern> then, in your work dir with the branch, bzr commit it, and then run lbox propose -wip
[15:37] <dimitern> -wip is for work-in-progress = don't send review emails, just push it to codereview.appspot.com (rietveld)
[15:42] <natefinch> dimitern: rietveld appears to be asking for google login credentials? How does that work with SSO?
[15:42] <dimitern> natefinch: do you want to have a g+ chat, so I can help you as you go?
[15:43] <natefinch> dimitern: yeah
[15:43] <dimitern> natefinch: just a sec, i'll start a hangout
[15:45] <dimitern> man they changed g+ *yet again*! how do I start a hangout now?
[15:45] <natefinch> haha
[15:46] <natefinch> upper right
[15:47] <dimitern> i don't want to invite, i just want the link
[15:47] <dimitern> ah.. it's hidden down there https://plus.google.com/hangouts/_/375c6630051efe7089a102bc829f8afd25fb80d9?hl=en
[15:47] <dimitern> natefinch: ^^
[15:55] <rogpeppe> dimitern: just tested the upgrade path from 1.10 -> 1.12 -> api-based upgrader branch and it all seems to work
[15:55] <dimitern> rogpeppe: woohoo!
[15:56] <rogpeppe> dimitern: :-)
[15:57] <rogpeppe> dimitern: unfortunately fwereade not-LGTM'd a prereq branch so i can't get anything in until he's available again
[15:57] <rogpeppe> please someone: another review of https://codereview.appspot.com/12183043/ would be much appreciated
[15:59] <TheMue> rogpeppe: looking
[15:59] <rogpeppe> TheMue: thanks
[16:06] <TheMue> rogpeppe: done
[16:06] <rogpeppe> TheMue: thanks!
[16:06]  * TheMue still thinks about setting empty strings in config
[16:07] <TheMue> setting to default now works, but the empty string leads to changes deep in the charm config
[16:12] <rogpeppe> TheMue: have you implemented juju set --default now?
[16:14] <TheMue> rogpeppe: set --default works, but set option= to set it to empty string not
[16:14] <TheMue> rogpeppe: currently discussing is on #juju
[16:14] <rogpeppe> TheMue: ah
[16:15] <mgz> dimitern: where's a simple non-horrible example of table tests?
[16:15] <TheMue> rogpeppe: in that case I have to change config in .../charm
[16:16] <TheMue> rogpeppe: that could break charms
[16:16]  * rogpeppe looks for a particularly nice table-based test
[16:17] <mgz> ta rog
[16:17] <TheMue> mgz: cmd/juju/config_test.go
[16:18] <mgz> thanks!
[16:18] <TheMue> mgz: an about string/info string, input args, a possible error and the expected results
[16:19] <rogpeppe> mgz: charm/url_test.go has a few reasonable simple examples
[16:19] <rogpeppe> mgz: although actually Commentf stuff is a bit antiquated now
[16:19] <rogpeppe> s/Comment/the Comment/
[16:20] <rogpeppe> mgz: version/version_test.go is another nice example
[16:21] <rogpeppe> mgz: i think we'd probably add some more identifying information to the Logf statement now
[16:44] <rogpeppe> hmm, oops: http://paste.ubuntu.com/5936989/
[16:49]  * rogpeppe needs to go
[16:49] <rogpeppe> g'night all
[17:01]  * TheMue has to go too
[17:01] <TheMue> cu tomorrow
[20:39] <thumper> morning
[20:39] <thumper> I'm going to be in and out today as I organise stuff for travel
[20:47] <sidnei> hey thumper! i'd love some comment on the cloud-init message. mramm suggested talking to fwereade but i guess he's en-route too
[23:40] <davecheney> arosales: ping