[00:00] <waigani> we might be able to do a version check?
[00:01] <waigani> nop, that will not work
[00:11] <waigani> ah, we could only restrict API access once  UpgradedToVersion >= 1.21
[00:36] <bradm> anyone able to help me with a juju bootstrap issue?  I've got a maas+juju environment setup where when I bootstrap it, all I see in the debug logs is a endless loop of trying to ssh into the bootstrap node, even though I can connect manually
[00:52] <waigani> menn0: ping
[00:58] <bradm> interesting, before destroying the instance, it complains about /var/lib/juju/nonce.txt does not exist
[01:00] <bradm> this is looking like LP#1314682
[01:01] <menn0> waigani: pong
[01:01] <waigani> heyhe
[01:01] <bradm> hah!  creating /var/lib/juju/nonce.txt and things start moving forward
[01:02] <waigani> menn0:  so I'm thinking splitting the migration over two versions is probably best
[01:03] <menn0> waigani: not restricting the API while upgrades are in progress is doable
[01:03] <waigani> menn0: I looked into a few workarounds, but they add a whole bunch of kluge
[01:03] <perrito666> ok ppl gotta go sleepto be up early in the AM, cheers
[01:03] <menn0> l8r perrito666
[01:03] <perrito666> cu all tomorrow AM
[01:03] <waigani> menn0: yeah, so that is what i got halfway into coding but ...
[01:04] <waigani> menn0: it adds boilerplate that we could avoid if we simply add restricted logins in the next version
[01:05] <menn0> waigani: true. what is the downside of not restricting logins
[01:06] <waigani> menn0: it means that MESS is not complete
[01:06] <waigani> that is all
[01:06] <waigani> so it would be one step at a time towards MESS
[01:07] <menn0> maybe let's do that for now and check with thumper tomorrow
[01:07] <waigani> menn0: but 1.22 could have restricted API and we are back on track
[01:07] <menn0> it's the least invasive thing to do
[01:08] <menn0> so removing that check fixes the issue?
[01:08] <waigani> menn0: I'm just testing that now..
[01:08] <bradm> what's supposed to create the /var/lib/juju/nonce.txt on a juju unit?
[01:08] <menn0> waigani: sweet
[01:08] <menn0> waigani: I've got to get some lunch ready for the fam. back in a bit.
[01:08] <waigani> menn0: yep, np
[01:09] <menn0> waigani: I assigned the bug to myself earlier on this morning. you should grab it.
[01:09] <waigani> ok
[01:14] <wallyworld> bradm: just saw your questions - the juju bootstrap process sets up a cloud init script which creates the nonce
[01:14] <wallyworld> bootstrap process = start instance
[01:15] <wallyworld> it you look in /var/log/cloud-init-output.log you should see the bash command to echo to the nonce.txt file
[01:16] <bradm> wallyworld: ok, let me rebootstrap it and have a look
[01:16] <bradm> wallyworld: if I create the file by hand, things start moving again, but errors out when it tries to start juju-db
[01:17] <wallyworld> bradm: that implies the cloud init script has not been run
[01:18] <bradm> wallyworld: this is a maas setup, not sure if that means anything
[01:18] <wallyworld> bradm: yeah, we've just seen this on maas
[01:19] <bigjools> still got the nonce problem?
[01:19] <wallyworld> cause the node is acquired and doesn't run cloud init
[01:19] <wallyworld> bigjools: bradm does
[01:19] <bigjools> old version?
[01:19] <bradm> LP#1314682 sounds vaguely familiar with the symptoms
[01:19] <bradm> bigjools: of maas?  its 1.5.2+bzr2282-0
[01:20] <bigjools> no it's a fix in maas's clients
[01:20] <bigjools> they supply the nonce to the API
[01:20] <wallyworld> that bug concluded that the node which was acquired didn't run cloud init
[01:20] <wallyworld> might be wrong?
[01:20] <bradm> this is kinda important to fix, its for bootstack.
[01:21] <bigjools> did you find any errors in the logs?
[01:21] <bradm> ok, so my bootstrap node is back up, lets see what it has
[01:22] <bradm> 2014-09-18 01:19:35,042 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-001 [3]
[01:22] <bradm> 2014-09-18 01:19:35,045 - cc_scripts_user.py[WARNING]: Failed to run module scripts-user (scripts in /var/lib/cloud/instance/scripts)
[01:22] <bradm> 2014-09-18 01:19:35,045 - util.py[WARNING]: Running scripts-user (<module 'cloudinit.config.cc_scripts_user' from '/usr/lib/python2.7/dist-packages/cloudinit/config/cc_scripts_user.pyc'>) failed
[01:22] <bradm> that doesn't look good
[01:23] <bradm> thats some custom scripts we have to create the nova instance dirs if it has a /dev/sdb
[01:23] <bradm> let me knobble that for now.
[01:24] <bigjools> do failures there make the whole cloud init script bail out?
[01:25] <bradm> looks like it must be
[01:25] <bradm> I'll comment these out and rebootstrap
[01:25] <bradm> it has some checks to see if the device is there or not, I can't see why its failing immediately though
[01:33] <bradm> ok, the cloud init scripts seem to have finished properly, although I now can't ping the host
[01:33] <bradm> but I can see it creating the nonce.txt, so there's something else going on here
[01:33] <bradm> progress is good, thanks guys.
[01:35] <bradm> must be something wrong in the preseeds
[01:43] <menn0> waigani: where are things now? can I help with anything?
[01:43] <waigani> menn0: I'm currently hunting down where the "environemnt not found" err is coming from
[01:43] <bradm> ah, what, it does a ifdown eth0?  what the?
[01:45] <bradm> and indeed, thats what breaks it, if I do a ifup eth0 things start working
[01:47] <bradm> wallyworld, bigjools: any idea why cloud-init is doing a ifdown eth0?  and what I can do to stop it? :)
[01:48] <bigjools> dunno, I thought it only did what the user data told it to do
[01:48] <wallyworld> bradm: that was done for maas to set up networking, but it can be disabled
[01:48] <wallyworld> let me check
[01:49] <bradm> I logged into the host and did a ifup eth0, I now have a successfully bootstrapped juju env \o/
[01:49] <bradm> so if I can stop it doing that, we're in much better shape.
[01:50] <wallyworld> bradm: disable-network-management
[01:50] <wallyworld> set that to true in your yaml
[01:50] <bradm> LP#1341524
[01:50] <wallyworld> but be aware that you may ten need to do stuff by hand that juju otherwise would try to do
[01:50] <wallyworld> bug 1341524
[01:50] <mup> Bug #1341524: juju/MAAS deployed host with bonding configured via preseed missing eth0 from bond on first boot <maas-provider> <juju-core:Invalid by niedbalski> <https://launchpad.net/bugs/1341524>
[01:51] <wallyworld> bradm: what version of juju are you using?
[01:51] <bradm> wallyworld: 1.20.7, apparently.
[01:51] <wallyworld> cause the fix is only in 1.20.8
[01:52] <wallyworld> which is not formally released yet
[01:52] <bradm> aha!
[01:52] <wallyworld> but will be available for testing tomorrow
[01:52] <wallyworld> and released early next
[01:52] <bradm> this is a staging environment for bootstack, we can use whatever version of juju that is appropriate
[01:52] <wallyworld> bradm: you can try 1.21-aplha1
[01:52] <wallyworld> that is released
[01:53] <wallyworld> and has the fix also
[01:53] <wallyworld> email was sent to canonical-juju
[01:53] <wallyworld> with the details
[01:53] <bradm> I suspect I'm not on that list.
[01:53] <wallyworld> you'll need to use a custom tools-metadata-url
[01:53] <wallyworld> ok, i can forward the email
[01:53] <wallyworld> it was also sent to juju-dev i think
[01:54] <bradm> aha, found a juju 1.21-alpha1 release email
[01:54] <bradm> sent to juju@lists.u.c
[01:54] <wallyworld> good :-)
[01:55] <bradm> ooh, --keep-broken, that sounds awesome
[01:55] <bigjools> ha
[01:56] <wallyworld> bigjools: allows for debugging when maas breaks :-P
[01:56] <bradm> wallyworld: so to confirm, that disable-network-management: true is only in the still to be released 1.20.8, or the currently released 1.21-alpha1?
[01:57] <wallyworld> bradm: it's in both those releses
[01:57] <bradm> wallyworld: excellent.
[01:57] <wallyworld> 1.21 is here now to try
[01:57] <bradm> wallyworld: ok, I can probably test out 1.21-alpha1 in staging, but we'll want to stick with stable in the long run
[01:57] <bradm> right, I can try that out now
[01:57] <wallyworld> bradm: agreed, this ws just a way of letting you get further
[01:57] <bradm> wallyworld: yup, perfect.
[01:58] <bradm> wallyworld: and this staging env is for exactly this.
[01:58] <wallyworld> \o/
[01:58] <bradm> although I wonder how we got the other env up
[01:58] <wallyworld> nfi :-)
[01:58] <bradm> it is 1.18 I think
[01:58] <wallyworld> ah
[01:58] <wallyworld> explains it
[01:59] <wallyworld> a lot of new network stuff has been done since then
[01:59] <bradm> ev'll get upset if I break it ;)
[01:59] <wallyworld> yep :-)
[02:01] <wallyworld> menn0: waigani: where's Tum (sic) today?
[02:01] <waigani> wallyworld: being an 'entrepreneurial innovator'
[02:02] <wallyworld> oh, sounds serious
[02:02] <waigani> wallyworld: some workshop thing that he took the day off for
[02:02] <wallyworld> and didn't mark the calendar
[02:02] <waigani> haha
[02:02] <wallyworld> or reschedule his 1:1 with me
[02:02] <waigani> oh, that sucks
[02:03] <wallyworld> not really, i didn't want to talk to him anyway
[02:03] <wallyworld> don't need him
[02:03] <waigani> haha
[02:09] <bradm> wallyworld: I can't imagine there'd be any bad side effects if I upgrade to 1.21, do a test deploy and then destroy and redeploy to 1.20.8 when its out, right?
[02:10] <wallyworld> bradm: that should work
[02:10] <bradm> wallyworld: sounds like I know what I'm doing after lunch then.
[02:11] <bradm> wallyworld: thanks for the help
[02:11] <wallyworld> np :-)
[02:45] <davecheney> bradm: hang on, id you say downgrade ?
[02:45] <davecheney> i'm not sure what you mean when you say redeploy to $OLDER VERSION
[03:01] <huwshimi> Hey, does anyone know if there is a max character length for machine names?
[03:04] <bradm> davecheney: juju destroy-environment ; downgrade to 1.20.8 ; juju bootstrap
[03:08] <davecheney> bradm: ok, that is fine
[03:09] <bradm> davecheney: currently this is all about refining the process, and its staging, so its not the end of the world to redeploy - wouldn't want to do it all the time though.
[03:24] <bradm> wallyworld: fwiw, the juju bootstrap just worked with 1.21-alpha1 and the tweaks to the environment.
[03:27] <wallyworld> bradm: awesome, great
[03:27] <wallyworld> huwshimi: juju doesn't impose one explicitly
[03:28] <huwshimi> wallyworld: OK, thanks
[03:36] <davecheney> wallyworld: juju lets you choose machine names ?
[03:36] <wallyworld> no
[03:37] <davecheney> wallyworld: then you didn't really answer huwshimi 's question :)
[03:37] <wallyworld> i just meant that juju has no length limit anywhere
[03:37] <wallyworld> what the providers do is up to them
[03:37] <davecheney> wallyworld: the machine names will always be integers
[03:37] <davecheney> yes ?
[03:37] <davecheney> the instance id's are opaque blobs
[03:38] <wallyworld> well, we print out the int id now, but don't have to
[03:38] <wallyworld> the point is there's no char length  encoded anywhere
[03:38] <davecheney> nope, that is true
[03:38] <wallyworld> which was the point of the question, presumably from a ui perspective
[03:39] <davecheney> ok
[05:19] <menn0> an update on the CI blocker (bug 1370635)
[05:19] <mup> Bug #1370635: Unable to connect to environment after local upgrade on precise <ci> <precise> <regression> <upgrade-juju> <juju-core:In Progress by waigani> <https://launchpad.net/bugs/1370635>
[05:20] <menn0> I have the cause figured out but the solution isn't clear yet
[05:20] <menn0> details on the bug
[06:06] <axw> wallyworld_: can you please review https://github.com/juju/juju/pull/784 for me? I've refactored state.Storage, which should make the other branch a bit tidier
[06:06] <wallyworld_> sure
[06:21] <wallyworld_> axw: +1 with a suggestion, i gotta do scholl pickup, bbiab
[06:23] <axw> wallyworld_: thanks, cya
[06:37] <bradm> what the?  there's .epm files and .conf files in /var/log/juju with juju 1.21-alpha1 ?
[06:37] <bradm> er, .pem even.
[06:39] <dimitern> davecheney, hey, still around?
[06:39] <axw> wallyworld_: can't update RB #51 for some reason, I get an internal server error when trying to publish
[06:39] <axw> I've fixed the issues though
[06:43] <bradm> filed LP#1370896
[06:46] <wallyworld_> axw: except landing is blocked \o/
[06:46] <axw> yeah :|
[06:46] <wallyworld_> bradm: well that kinda sucks, that should be fixed. btw if you type bug 1370896 a magic fairy will print some extra info
[06:47] <mup> Bug #1370896: juju 1.21-alpha1 has conf files in /var/log/juju on instances <juju-core:New> <https://launchpad.net/bugs/1370896>
[06:48] <axw> bradm: those .pem files have been there for ages; logrotate.conf is new
[06:48] <wallyworld_> but why in the log dir?
[06:48]  * axw shrugs
[06:48] <axw> the .pem file is for rsyslogd
[06:48] <axw> for SSL
[06:48]  * wallyworld_ thinks it needs fixing anyway
[06:49] <bradm> axw: just because its been there for ages doesn't make it right.
[06:49] <axw> bradm: right, sorry, I thought you thought it was new
[06:49] <bradm> I just mentioned them both in the bug for completeness
[06:49] <axw> okey dokey
[06:49] <bradm> anyway, not a big deal, just throwing out bugs for issues as I find them.
[06:54] <wallyworld_> axw: i may have old code, but i noticed there's a test called TestFindToolsInControlBucket, which is now obsolete. it uses a test helper UploadToStorage(c, s.env.Storage()...). these can go away
[06:54] <axw> wallyworld_: sure, I'll take a look...
[06:54] <wallyworld_> ta, or i can delete them as a drive by
[06:55] <wallyworld_> in the tools-stream branch
[06:55] <axw> wallyworld_: nah can't go yet, not till we have the upgrade-step
[06:55] <axw> wallyworld_: I've yet to write an upgrade step that moves everything from provider to environment storage
[06:55] <wallyworld_> maybe i delete the Find test
[06:56] <wallyworld_> cause i don't want to spend time making it work with tools-stream
[06:56] <axw> okay
[07:05] <menn0> axw, wallyworld_: in case anyone asks, I'm stopping for a bit but will pick up with CI blocker later tonight
[07:05] <menn0> I haven't done enough hours today due to Real Life stuff
[07:22] <axw> menn0: no worries, thanks
[07:23] <dimitern> axw, ericsnow, http://reviews.vapour.ws/r/33/ please take a look, I really need to land this already :)
[07:23] <axw> dimitern: looking
[07:23] <dimitern> axw, thanks
[07:27] <mattyw> morning all
[07:33] <dimitern> is launchpad down of anyone else?
[07:33] <dimitern> for*
[08:05] <voidspace> morning all
[08:08] <voidspace> morning all
[08:13] <jam> morning voidspace
[08:13] <jam> dimitern: did you see https://bugs.launchpad.net/juju-core/+bug/1308146
[08:13] <mup> Bug #1308146: not okForStorage error when deploying local charm <charms> <deploy> <juju-core:Triaged> <https://launchpad.net/bugs/1308146>
[08:13] <jam> I'm wondering if this has to do with something we're writing to the DB to cache information about local changes
[08:13] <jam> cmarms
[08:13] <jam> charms
[08:13] <jam> vs, what we do for cs: charms
[08:14] <dimitern> morning voidspace
[08:14] <dimitern> jam, not sure, I have to look
[08:14] <jam> dimitern: you did the stuff for PutCharm to support local charms, and for the GUI to be able to get its stuff, right?
[08:14] <dimitern> jam, that's right
[08:15] <dimitern> but it's been a while
[08:17] <jam> dimitern: sure. Just the thought comes to might that it is probably the only thing that is directly different between local and cs charms
[08:17] <jam> and involves possibly writing charm config keys to the db
[08:18] <dimitern> jam, what I didn't get from the bug is whether the problematic charm was deployed from a local repo or from cs:
[08:21] <jam> dimitern: from local:, from "cs:" doesn't have the problem
[08:21] <jam> hence why I think it is the caching logic
[08:22] <jam> "It's not exactly clear from the bug log when this regression occured,
[08:22] <jam> and the bug suggests it may only affect local charms."
[08:24] <dimitern> jam, right, I saw that later, sorry
[08:24] <dimitern> jam, I'm looking through the code, it seems this happens in the last step - state.UpdateUploadedCharm()
[08:25] <dimitern> jam, I see the problem
[08:26] <dimitern> jam, we do replace . and $ in service settings when saving to state, but we don't do the same for the charms collection (and its config field)
[08:31] <dimitern> jam, and it seems we never did
[08:39] <dimitern> jam, yep, i'm afraid it looks like a "my bad" case :) I'll assign it to myself and propose a fix
[08:39] <jam> dimitern: it sounds like it is just "need to escape", yeah
[08:39] <jam> dimitern: great
[08:47] <voidspace> axw: ping
[08:48] <axw> voidspace: pong
[08:48] <voidspace> axw: thanks for your review of my PR
[08:48] <axw> you're welcome
[08:48] <voidspace> axw: you commented that the "cmd" variable isn't needed any more in applyReplSetconfig
[08:48] <voidspace> axw: it's used twice (for logging) - and is passed into applyReplSetConfig
[08:49] <axw> ah, it's input
[08:49] <axw> my bad
[08:49] <axw> sorry, glanced over that
[08:49] <voidspace> yeah, it looks kinda like that
[08:49] <voidspace> resetting it in the loop was always pointless
[08:49] <voidspace> that loop just didn't do what it looked like it was doing
[08:50] <voidspace> which is why I fixed it
[08:50] <voidspace> axw: anyway, cool - just checking you didn't have some other reason I missed
[08:50] <axw> nope, thanks though
[08:50] <voidspace> axw: so I'll add those doc comments and merge
[08:50] <voidspace> thanks!
[08:52] <axw> wallyworld_: I think we were meant to discuss charmstores and placement and things today - probably a bit late now
[09:02] <jam> dimitern: escaping sounds like something we could backport to 1.20
[09:02] <jam> and since local charms never worked there anyway, we don't have to worry about compat for upgrade
[09:04] <TheMue> morning
[09:04] <jam> morning TheMue
[09:05] <TheMue> dimitern, jam: I think I got a good approach for testing now. take a look at http://paste.ubuntu.com/8370850/
[09:05] <TheMue> the upper files simulate the different versions of an agent here
[09:06] <TheMue> and then there are files for testing each version
[09:07] <TheMue> instead of embedding a type I'm working with a simple struct for needed infos and versioned non-public test funcs containing the tests on anonymous facades
[09:08] <TheMue> so if tests are added or changed in later versions the according test helper funcs can be added in those files too (and used until they are changed in future again)
[09:08] <TheMue> the examples contain adding, changing and dropping a facade function
[09:08] <dimitern> jam, sgtm
[09:09] <dimitern> TheMue, will look shortly, thanks
[09:10] <TheMue> dimitern: thanks, it's mostly based on your approach :D
[09:19] <jam> TheMue: so that still makes it fairly easy to accidentally leave off TestSecondFuncOK (like you did in agent_v2_test.go)
[09:19] <jam> now given your change to SecondFunc() it may be that you intended for it t odie
[09:19] <jam> to die
[09:19] <jam> using the "embed the earlier version but make it an invalid signature" rule
[09:19] <TheMue> jam: this risk still exists, yes
[09:20] <jam> Which I think fwereade and I thought was a bit too magical
[09:21] <TheMue> jam: it is, because the public name still exists. did I missed a better idea for hiding it?
[09:23] <TheMue> jam: surely we could do it in a similar way like I've done for the tests here: private versioned implementations which are only called in each new facade
[09:23] <jam> TheMue: so in our API docs discussion, the idea was if you wanted something to disappear you have to factor out a common base and embed
[09:23] <TheMue> jam: so a V2 dropping a function simply doesn't have it
[09:25] <TheMue> jam: I've got my problem with the embedding, or, at least even here the methods have to be versioned.
[09:25] <TheMue> jam: because we could have a doThisV0 valid until V3, but need a doThisV3 in V3 and higher
[09:27] <TheMue> jam: implementing it as functions using one shared type would make it simpler (or at least more logical) to implement the v0 login in the v0 file, reusing it until v2 and add a new implementation of v3 in the v3 file
[09:28] <TheMue> jam: so the implementation is more where it is expected than in one large file containing the base with all versioned changes
[09:29] <TheMue> dimitern: btw, your idea of using a facade with only the interesting function is cool
[09:30] <dimitern> TheMue, yeah? It could be written a bit more concise, if we define the interface before the test case, like type lifer interface { Life() params.Life } .. testLife(c *gc.C, facade lifer)
[09:36] <jam> wwitzel3: a simpler patch for you: http://reviews.vapour.ws/r/54/
[09:36] <jam> I didn't see how to do the dependent-diff with Review Board and make my change depend on yours
[09:39] <jam> wwitzel3: well, I guess I did find something, but reviewboard tells me: The file "utils/syslog/config.go" (revision e1eaf4a) was not found in the repository
[09:40] <TheMue> dimitern: yes, the only problem then would be to be creative enough for the name *lol*
[09:42] <TheMue> dimitern: but I now like your approach more than my first one. it's only important that the tests themself are external and versioned, so that they can be reused and changed over time
[09:44] <dimitern> TheMue, yeah, that was my idea as well
[09:44] <dimitern> jam, thanks for the review - one of the issues is already fixed earlier (the NewFacadeCaller calling NewFacadeCallerForVersion internally)
[09:50] <jam> dimitern: yeah, I had written that up yesterday, but I keep hitting "Save" instead of "Publish" when doing reviews.
[09:51] <dimitern> jam, axw, ericsnow, http://reviews.vapour.ws/r/55/ - fixes bug 1308146
[09:51] <mup> Bug #1308146: not okForStorage error when deploying local charm <charms> <deploy> <juju-core:In Progress by dimitern> <juju-core 1.20:Triaged by dimitern> <https://launchpad.net/bugs/1308146>
[09:52] <jam> just a reminder, whole team meeting in 8min
[09:52] <jam> dimitern: I haven't looked yet, but does it seem feasible to backport to 1.20?
[09:55] <dimitern> jam, yes, changes are minimal
[09:58] <menn0> phew! I have a fix for the CI blocker
[09:58] <jam> https://plus.google.com/hangouts/_/canonical.com/juju-core-team?authuser=1
[09:58] <jam> nice menn0
[09:58] <menn0> it might not be the final fix we end up going with but it solves the issue for now
[09:58] <menn0> I will take it up with thumper tomorrow (it's his work that caused it)
[09:59] <menn0> but I don't blame him
[09:59] <menn0> it was head-hurtingly hard to figure this out
[09:59] <menn0> PR soon
[10:00] <jam> menn0: dimitern: TheMue: voidspace: team meeting
[10:00] <menn0> jam: did you mean me?
[10:01] <jam> menn0: well, it is the "entire juju team weekly meeting" , so yeah
[10:01] <jam> menn0: you might not usually come to it on this week
[10:01] <axw> dimitern: I was afk, will review after the meeting
[10:02] <dimitern> axw, cheers
[10:04] <voidspace> jam: omw
[10:05] <voidspace> hmmm... currently failing to join
[10:34] <perrito666> jam: that is unfair, I could do sleep even though my timezone says work
[10:34] <axw> jam: did you set the parent branch in rbt after the fact?
[10:34] <jam> perrito666: I'll let you pick whichever one you want
[10:34] <axw> or can you only do it on first post
[10:34] <voidspace> dimitern: are you there?
[10:34] <jam> axw: yeah, I was trying to play around it
[10:34] <jam> with it
[10:35] <jam> rbt post -r --parent eventually worked
[10:35] <voidspace> dimitern: we could do a quick standup now
[10:35] <dimitern> voidspace, yep
[10:35] <axw> jam: ah, thanks
[10:35] <jam> once I rebased everything because git couldn't handle what I wanted
[10:35] <dimitern> voidspace, ah, yes actually, brt
[10:35] <axw> ah I was doing -u, that's why it wasn't working
[10:36] <jam> axw: interesting, because it was trying to match up based on the summary?
[10:36] <jam> but your summary is different because you're including different revs (presumably)
[10:36] <jam> axw: I think my problem is that I was trying to merge master, but rbt post can't handle that
[10:36] <axw> jam: actually no, I'm just a twit: I did -u <rev>
[10:36] <jam> you have to have master in your parent branch
[10:36] <jam> ah
[10:36] <axw> :)
[10:49] <menn0> axw or wallyworld_: http://reviews.vapour.ws/r/56/
[10:50] <wallyworld_> looking
[10:53] <mattyw> folks, how can I use mongo shell to connect to mongo on a live state server?
[10:53] <wallyworld_> menn0: +1 with a suggestion, thanks for fixing
[10:53] <menn0> mattyw: local provider?
[10:53] <mattyw> ^^ specifiacally looks like I need to login somehow
[10:53] <wallyworld_> menn0: you managed to test it?
[10:53] <menn0> wallyworld_: yep
[10:53] <wallyworld_> \o/
[10:53] <mattyw> menn0, aws - but I suppose I could use local provider which might make things easier
[10:53] <menn0> I created a script to repro
[10:54] <menn0> and used git bisect to automatically find the problem reb
[10:54] <wallyworld_> mattyw: there's a plug from kapil
[10:54] <menn0> rev
[10:54] <wallyworld_> juju-db
[10:54] <menn0> mattyw: I just asked because the answer is slightly different depending on the provider
[10:54]  * menn0 looks up the command line
[10:54] <wallyworld_> mattyw: https://github.com/kapilt/juju-dbinspect
[10:54] <wallyworld_> works on any provider afaik
[10:55] <menn0> mattyw: mongo 127.0.0.1:37017/admin --ssl --username "admin" --password "`sudo grep oldpassword /var/lib/juju/agents/machine-*/agent.conf  | cut -d' ' -f2`"
[10:55] <mattyw> wallyworld_, menn0 thanks very much - I'll try everything until I get what I want :)
[10:55] <wallyworld_> mattyw: i've used the db-inspec tool - very niiiice
[10:55] <mattyw> menn0, that's a command worth hanging on to
[10:56] <wallyworld_> it essentially automates what menn0  typed
[10:56] <wallyworld_> plus gives some standard commands
[10:56] <menn0> :)
[10:56] <menn0> mattyw: you'll need to sudo apt-get install mongodb-clients first
[10:56] <menn0> mattyw: the path to the agent.conf is different for the local provider, hence the difference
[10:56] <menn0> or use the plugin :)
[10:57] <mattyw> menn0, thanks for your help - I've found what I was looking for
[10:57] <mattyw> menn0, metrics have arrived from a deployed unit \o/
[10:57] <menn0> \o/
[11:01] <menn0> wallyworld_: is this ok?
[11:01] <menn0> logger.Warningf("state servers info has no environment UUID so retrieving it from environment state")
[11:01] <wallyworld_> menn0: +1 thank you
[11:01] <voidspace> TheMue: sorry frank, I cut you off!
[11:01] <voidspace> TheMue: I will enjoy it all I hope
[11:02] <voidspace> TheMue: except maybe giving the talk - still practising
[11:05] <menn0> right, the CI blocker fix is testing now but I really need to go to bed
[11:06] <menn0> can someone please keep an eye on the merge and if it's successful mark bug 1370635 as "Fix Committed"?
[11:06] <mup> Bug #1370635: Unable to connect to environment after local upgrade on precise <ci> <regression> <upgrade-juju> <juju-core:In Progress by menno.smits> <https://launchpad.net/bugs/1370635>
[11:08] <TheMue> voidspace: my talks in India in 2008 have been my first public ones too. man, I've been nervous
[11:08] <TheMue> voidspace: but now it's something I really enjoy
[11:08] <menn0> jam, natefinch :?
[11:09] <natefinch> menn0: yep, will do
[11:09] <menn0> natefinch: thanks
[11:09] <TheMue> voidspace: in India I liked all those impressions, the food, and the traffic with all those different vehicles on multiple lanes and honking all the time
[11:09] <jam> menn0: can you link the PR
[11:09] <jam> ?
[11:10] <menn0> https://github.com/juju/juju/pull/787
[11:11] <menn0> and the merge run is here: http://juju-ci.vapour.ws:8080/job/github-merge-juju/673/
[11:11] <voidspace> TheMue: I have friends in Chennai, not far from Bangalore, so I'll be going there after the conference
[11:11] <menn0> goodnight
[11:11] <voidspace> TheMue: I've spoken at conferences many times, I still find it hard
[11:11] <voidspace> menn0: goodnight - see you in Brussels!
[11:11] <menn0> indeed! looking forward to it.
[11:27] <perrito666> what is the process to post an update to rb?
[11:31] <perrito666> ok I definitely dont understand rb mails
[11:31] <jam> perrito666: "rbt push -r EXISTINGREV"
[11:31] <jam> so to update "54" you do "rbt post -r 54"
[11:31] <perrito666> jam: tx
[11:31] <jam> sorry for the typo
[11:32] <perrito666> jam: I saw push and post used mixed so many times in the emails that I already read post when you say push
[11:32] <jam> yeah
[11:39] <mattyw> folks, very trivial http://reviews.vapour.ws/r/57/
[11:43] <dimitern> jam, trivial review of the 1.20 backport fix? https://github.com/juju/juju/pull/790
[11:44] <jam> dimitern: LGTM
[11:44] <wallyworld_> mgz: looks like CI has an issue? see http://juju-ci.vapour.ws:8080/job/github-merge-juju/675/console
[11:44] <wallyworld_> /var/lib/jenkins/juju-release-tools/make-release-tarball.bash: line 115: ./check_dependencies.py: No such file or directory
[11:47] <dimitern> jam, thanks
[11:52] <perrito666> aghh something went wrong when updating the patch
[11:53] <perrito666> strange
[11:53] <perrito666> dimitern: around?
[11:54] <perrito666> apparently when I re-merged with master I dragged some changes from dimitern
[11:55] <perrito666> http://cdn.meme.li/instances/500x/54445816.jpg
[11:56] <dimitern> perrito666, is that why it fails with check_dependencies.py: No such file or directory ?
[11:57] <perrito666> dimitern: ?
[11:58] <voidspace> is CI unblocked again?
[11:58] <perrito666> dimitern: I just updated master from upstream and then mmm, I believe Ill need to drop the pr
[11:58] <mgz> wallyworld_: that's me, I'll fix it
[11:59] <wallyworld_> mgz: thanks, it's blocking a critical bug fix
[11:59] <dimitern> perrito666, ah, ok :), thanks mgz
[11:59] <wallyworld_> to unblock landings
[11:59] <mgz> must remember not to land things just before lunch...
[12:02] <mgz> okay, fix tried, I'll resend the landing
[12:02]  * perrito666 turns on his git fu
[12:04] <jam> wallyworld_: It looks like I did get the  bot to work: http://juju-ci.vapour.ws:8080/job/github-merge-juju/678/
[12:04] <jam> ah, maybe not.
[12:04] <jam> :(
[12:04] <wallyworld_> :-(
[12:05] <jam> I misread it.... so yeah, still broken mgz
[12:05] <mgz> jam: I have hope for the current run
[12:05] <mgz> just made a change to the bash
[12:05] <jam> natefinch: can you follow up with https://github.com/juju/juju/pull/787 or possibly mgz
[12:05] <jam> It is one of the critical blockers, and I'm not going to be around to shepherd it
[12:05] <mgz> jam: I'll make sure that lands
[12:06] <jam> thanks
[12:06] <mgz> there was a test failure on the first run earlier...
[12:10] <mgz> dimitern: good and bad news
[12:11] <dimitern> mgz, hit me
[12:11] <mgz> good news is my change did what it was meant to... bad part is trunk *is* actually failing the check
[12:11] <mgz> so, I'll just pull out the code for now, resend yours and menno's fixes, then put it back in again and fix trunk
[12:12] <dimitern> mgz, did I break it perhaps? or
[12:12] <mgz> no, I think it was an earlier change, as it was on 1.20 as well (but got fixed there)
[12:12] <mgz> so, resending yours now
[12:33] <mgz> dimitern: yours is in
[12:36] <dimitern> mgz, cheers!
[13:04] <perrito666> wallyworld_: axw I know its quite late but if any of you could give a second pass over eric's http://reviews.vapour.ws/r/34/ It would be greatly appreciated, I need this up to land restore
[13:05] <dimitern> jam, would you mind terribly if you review the 1.18 backport MP on LP, I'm having issues with lbox and rietveld: https://code.launchpad.net/~dimitern/juju-core/lp-1308146-1.18-backport/+merge/235116
[13:07] <hazmat> wrt to openstack, do we know which custom extensions we require.. afaics primarily we require nova network security groups extension
[13:08] <dimitern> mgz, perrito666, wallyworld_, or somebody else free to take a look? ^^
[13:08] <hazmat> do we have an option to disable the firewaller so we don't need that extension?
[13:08] <mgz> dimitern: looking
[13:08] <dimitern> hazmat, not right now
[13:08] <dimitern> hazmat, we need os-security-groups to exist
[13:09] <hazmat> dimitern, any idea how much work it would be to disable that?
[13:10] <mgz> dimitern: lgtm, have you also run the full test suite locally? we don't have gating on 1.18 any more I think
[13:10] <dimitern> mgz, you mean go build ./... && go test ./... ?
[13:11] <dimitern> hazmat, to disable the firewaller altogether ?
[13:11] <mgz> dimitern: yup
[13:11] <dimitern> mgz, running now
[13:11] <hazmat> dimitern, yeah
[13:12] <dimitern> mgz, and then, if you can be so kind to remind me, how to manually merge it?
[13:12] <hazmat> dimitern, do we use os-networks extension as well?
[13:12] <mgz> dimitern: just checking if the old bot is actually alive still
[13:13] <mgz> dimitern: if not, merge to the 1.18 branch locally
[13:13] <dimitern> hazmat, it's not much work to introduce "firewall-mode": "disabled" (in addition to "instance", "global") in the env config and then when "disabled" just not start the firewaller
[13:14] <hazmat> dimitern, cool, thanks
[13:14] <dimitern> mgz, ah, so bzr merge ~/src/juju-core/1.18 while on my branch in GOPATH ? and then push?
[13:15] <dimitern> hazmat, np, if it's important, I'd file a bug and possibly ping alexis for scheduling
[13:16] <hazmat> dimitern, k, thanks just feeling it out atm
[13:17] <mgz> then push as-the-bot, `bzr push bzr+ssh://IFORGOTTHEBOTNAME@bazaar.launchpad.net/+branch/juju-core/1.18`
[13:18] <mgz> dimitern: wait a sec on that though
[13:19] <mgz> dimitern: the old bot seems to be handling it
[13:19] <mgz> dimitern: I'll ping you if you need to do anything else
[13:20] <dimitern> mgz, so 1. set commit message on the MP and then mark it as approved?
[13:20] <dimitern> mgz, ok, cheers
[13:20] <wallyworld_> perrito666: review done
[13:20] <axw> me too, practically at the same time :p
[13:20] <mgz> he's double-lucky
[13:21] <perrito666> wallyworld_: tx man
[13:22]  * perrito666 gets spam from one of the top competitors for presidency... quoting Dr. Seuss as his core platform driver
[13:23] <hazmat> dimitern, mgz also looks like we may also depend on os-availability-zones.. not clear if its entirely optional
[13:23] <mgz> hazmat: pretty sure that fails neatly when it's not available
[13:24] <mgz> axw: ^
[13:25] <hazmat> mgz, yeah.. there's two call paths to it afaics.. one with explicit zone placement specified (and explicit provisioning error), and one with the zone balance using collected zones of an instance. it looks like it should fail neatly
[13:30] <mgz> dimitern: landed on 1.18
[13:30] <dimitern> mgz, sweet! tyvm
[13:47] <perrito666> ericsnow: ping
[13:54] <mgz> ocr, can I get a stamp on https://github.com/juju/charm/pull/48 please?
[13:57] <wwitzel3> natefinch, ericsnow, perrito666: I'll be a couple minutes late to standup (5 max), dealing with some house paperwork.
[13:58] <perrito666> wwitzel3: np
[13:59] <mgz> perrito666: ^review plz? super easy :)
[13:59] <perrito666> mgz: remember that my review bears the weight of a feather
[13:59] <mgz> the best kind
[14:01] <perrito666> mgz: lgtm
[14:01] <mgz> perrito666: ta ta
[14:11] <dimitern> TheMue, I've looked at http://paste.ubuntu.com/8370850/ - LGTM
[14:15] <TheMue> dimitern: thanks, currently changing my code an feels fine there too
[14:37] <hatch> If I have a multi core instance on ec2 and a few single core service units. Is there a way I can specify that each unit should get a single core?
[14:41] <mgz> perrito666: next trivial bit <https://github.com/juju/juju/pull/791> :)
[14:42] <mattyw> shouldn't landing be unblocked now that https://github.com/juju/juju/pull/787 has landed?
[14:42] <mgz> mattyw: it is, sorry, should have announced in here
[14:43] <mgz> everyone: landing unblocked, go wild
[14:43] <perrito666> mgz: lgtm, I actually checked the hash just in case
[14:43] <mattyw> mgz, I had something rejected 2 minutes ago
[14:43] <mattyw> mgz, should I just try again?
[14:43] <mgz> hm, let me look
[14:43] <mgz> perrito666: thanks!
[14:43] <mattyw> mgz, have you fixed world hunger yet?
[14:43] <mgz> mattyw: 789?
[14:44] <mgz> mattyw: on it :)
[14:44] <jcw4> mattyw, mgz looks like bug 1370365 still blocks ci
[14:44] <mup> Bug #1370365: After the last `apt-get update` the screen backlight is turned off. <amd64> <apport-bug> <bios-outdated-a09> <kernel-da-key> <performing-bisect> <regression-update> <screen> <trusty> <linux (Ubuntu):Incomplete> <https://launchpad.net/bugs/1370365>
[14:44] <mattyw> mgz, nice one
[14:44] <jcw4> sorry bug 1370635
[14:44] <mup> Bug #1370635: Unable to connect to environment after local upgrade on precise <ci> <regression> <upgrade-juju> <juju-core:In Progress by menno.smits> <https://launchpad.net/bugs/1370635>
[14:45] <mgz> mattyw: marked the bug, resubmitted yours
[14:45] <mgz> bug 1370635
[14:45] <mup> Bug #1370635: Unable to connect to environment after local upgrade on precise <ci> <regression> <upgrade-juju> <juju-core:Fix Committed by menno.smits> <https://launchpad.net/bugs/1370635>
[14:46] <mattyw> mgz, thanks very much, let me know when you've put an end to war and I'll review it
[14:47] <mgz> mattyw: I suspect there's some lag in picking up the launchpad bug status
[14:49] <mgz> it's returning clean for me locally now
[14:50] <mgz> greh, must be caching related
[14:51] <mgz> locally: $ python check_blockers.py master 789
[14:51] <mgz> No blocking bugs
[14:51] <mgz> on the build slave: jenkins@juju-core-slave:~/juju-ci-tools$ python check_blockers.py master 789
[14:51] <mgz> Does not match ['fixes-1370635']
[14:51] <mgz> >_<
[14:51] <mgz> will have to throw some cache busting in there, this is annoying
[15:00] <TheMue> dimitern: changed it, currently testing it before reproposal, but it looks and feels real cool
[15:00] <mgz> okay, this is annoying, cache-busting isn't helping
[15:01] <mgz> who's holding on to old junk here... an aws proxy? launchpad?
[15:01] <dimitern> TheMue, great!
[15:03] <sinzui> natefinch, per the cross-team call, can you ask someone to look into bug 1370781 . I hope this is a trivial fix because the adding of the archive and the calling of upgrade are easy to reverse.
[15:03] <mup> Bug #1370781: cloud-archive on precise not pinned when juju calls apt-get upgrade <cloud-installer> <landscape> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1370781>
[15:12] <mgz> mattyw: I've hacked in a fix, landing your branch now
[15:18] <mgz> everyone: trunk not open for landing quite yet
[15:18] <mgz> we want a clean CI run with menno's fix from this morning
[15:51] <wwitzel3> ericsnow: https://github.com/juju/utils/pull/35 when you have a chance
[15:52] <ericsnow> wwitzel3: k
[15:52] <wwitzel3> ericsnow: http://reviews.vapour.ws/r/58/
[16:24] <mattyw> mgz, looks like it's not been accepted by the bot
[16:24] <mattyw> mgz, but not hurry
[16:34] <mgz> mattyw: yeah, sinzui pointed out we should actually wait for a clean run of those upgrade jobs with menno's change, which is happening now
[16:34] <mattyw> mgz, sounds sensible
[16:34] <mgz> sinzui: can I ask you to flip the bug to fix released when that happens, and tell people in here?
[16:34] <mgz> I'm migrating home from cow-orking now
[16:41] <sinzui> mgz: I will update the bug when CI is satisfied
[16:45] <sinzui> mgz, mattyw I see 1804 tested master and passed http://juju-ci.vapour.ws:8080/job/local-upgrade-precise-amd64/
[16:45] <sinzui> I am marking the bug fix released
[16:45] <mattyw> sinzui, cool thanks very much
[16:47] <perrito666> hint: apparently we can access all of our repositories as if they where svn...
[16:47] <perrito666> https://github.com/features
[16:48] <mattyw> perrito666, but they still don't suppor prereq branches
[16:49] <perrito666> mattyw: now, aren't you a party p****r? :p
[16:49] <mattyw> perrito666, yes
[16:49] <mattyw> :)
[16:50] <perrito666> mattyw: I would also want all reviews in one mail
[16:50] <mattyw> perrito666, I read that as "want all reviews in the mail"
[16:50] <perrito666> heh I want to be able to do a full review and then commit and have that send ONE summary email
[17:13] <ericsnow> wwitzel3: that should get you started
[17:13] <ericsnow> wwitzel3: I *may* have gone a little overboard :)
[17:21] <wwitzel3> ericsnow: I can't figure out in which use case values would be nil?
[17:21] <ericsnow> wwitzel3: var mytags Tags
[17:22] <ericsnow> wwitzel3: (before calling mytags.Add(value) for the first time)
[17:23] <ericsnow> wwitzel3: maybe that's a use case we don't care about, but the future has a way of making us pay for those kind of assumptions
[17:23] <wwitzel3> ericsnow: I see now, I forgot to commit the unitialized test that I added .. it is for exactly that scenario and it works fine
[17:25] <ericsnow> wwitzel3: cool.  If that's covered then that takes care of most of my review comments :)
[17:44] <perrito666> sorry sinzui hadn't you marked 1370635 as fixed?
[17:45] <sinzui> perrito666, yes, I marked it fix released within the last 20 minutes I think
[17:45] <perrito666> mm  merge bot does not seem to ack that
[17:58] <perrito666> ok seems that it is finally accepting merge requests
[18:07] <ericsnow> perrito666: that backups PR just merged :)
[18:08] <perrito666> I know I am the one that dollar dollar-ed the pr last :p
[18:08] <ericsnow> wwitzel3: thanks for putting up with my exuberance...hopefully it was helpful and didn't add much extra work
[18:08] <ericsnow> perrito666: thanks
[18:14] <mattyw> night all
[18:17] <wwitzel3> ericsnow: appreciate the review :) .. I like all comments, they make me think about the code differently. Even if the result is, I'm not going to take action, it is still good to look at things with different persepctives.
[18:17] <ericsnow> wwitzel3: okay, good.  The last thing I want is to waste your time on trivialities. :)
[18:18] <wwitzel3> ericsnow: no worries, I will just ignore those :P
[18:19] <ericsnow> wwitzel3:  :)
[18:34] <voidspace> g'night all
[19:56]  * perrito666 does diff -u of 2 diff files and his head explodes
[20:02] <jcw4> perrito666: lol
[20:04] <perrito666> times are changing, my wife complains that osx is less user friendly than ubuntu
[20:05] <natefinch> nice
[20:35] <perrito666> well, ubuntu seems to be more responsive on slower machines
[20:40] <wallyworld_> sinzui: is bug 1370781 really critical, blocking 1.20.8?
[20:40] <mup> Bug #1370781: cloud-archive on precise not pinned when juju calls apt-get upgrade <cloud-installer> <landscape> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1370781>
[20:41] <sinzui> wallyworld_, no. It is not a regression
[20:41] <wallyworld_> happy to fix it, but i'm not sure if we should delay 1.20.8 because of it
[20:42] <sinzui> wallyworld_, I asked earlier today if it was trivial to fix. I had a lot of prep work for 1.20.8 so I was happy to hope for a fix while I updated the copy rules for proposed
[20:42] <wallyworld_> sinzui: ok, let me see what i can do this morning
[20:42] <sinzui> wallyworld_, I will release tomorrow regardless of the state of that bug
[20:43] <wallyworld_> sinzui: fwiw, i have scheduled about 6 apt related bugs to be looked at over the next 2 weeks
[20:43] <sinzui> fab
[20:57] <perrito666> nothing like having the second reviewer answering the questions from the first before you get the chance to
[20:57] <perrito666> :p
[21:10] <perrito666> ericsnow: tx, --pull is a much better word
[21:10] <ericsnow> perrito666: oh good :)
[21:11] <ericsnow> perrito666: at least there's one useful thing for you in that review then :)
[21:11] <perrito666> ericsnow: also, its charm-sync because otherwise we would be stepping on charmtools toes
[21:11] <perrito666> ericsnow: I have found many interesting things on your review
[21:12] <perrito666> ericsnow: re s/unit/remote unit/ unit can only be remote
[21:12] <ericsnow> perrito666: oh yeah lol
[21:21] <perrito666> is there a way to set up rb to show a couple of context lines on the issues?
[21:21] <perrito666> like a comment on "return err" even if it has the line number says absolutely nothing
[21:21] <perrito666> and I cannot always look up in my local copy of the code bc the line might have moved a lot
[21:21] <ericsnow> perrito666: it will show only the lines that were highlighted by the reviewer when the made the comment
[21:22] <ericsnow> perrito666: you can click on the link right there to pull up that spot in your browser
[21:22] <perrito666> ericsnow: I am trying to avoid jumping around
[21:22] <ericsnow> perrito666: I don't think that is adjustable
[21:55] <thumper> well the answer to how stuffed is my shoulder, is very.
[21:57] <perrito666> thumper: I am pretty sure there is some meaning to stuffed I dont know or you are a teddy bear
[21:57] <thumper> stuffed as in buggered, screwed
[21:57] <perrito666> thumper: ouch, I hope the other guy is worse
[22:25] <ericsnow> wallyworld_: when can I expect to find Andrew?
[22:25] <wallyworld_> ericsnow: about 2.5 hours
[22:25] <thumper> o/ wallyworld_
[22:25] <ericsnow> wallyworld_: k
[22:26] <wallyworld_> hi thumper, where did you get to yesterday?
[22:26] <thumper> wallyworld_: I had a day off
[22:26] <thumper> wallyworld_: for a local seminar
[22:26] <wallyworld_> we didn't miss you :-P
[22:26] <thumper> on design thinking, and business stuff
[22:26] <thumper> yeah, chatted to menn0
[22:26] <thumper> pleased he fixed my bad shit
[22:27] <ericsnow> FYI, we've updated .reviewboardrc to include the TRACKING_BRANCH setting
[22:27] <thumper> o/
[23:31] <bradm> so, when can I get my hands on juju 1.20.8? :)
[23:54] <thumper> davecheney: around?
[23:54] <thumper> davecheney: I have a language question
[23:58] <davecheney> thumper: yup
[23:58] <thumper> davecheney: take a look in agent/bootstrap.go
[23:58] <thumper> davecheney: the InitializeState method
[23:59] <thumper> function
[23:59] <davecheney> mmm
[23:59] <thumper> the named error return value is only used in a defer to close the connection if an error is returned
[23:59] <thumper> does this actually work?
[23:59] <davecheney> oh
[23:59] <davecheney> fuck i always miss that
[23:59] <thumper> no assignments are made to resultErr explicitly