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