[04:52] <_mup_> juju/purge-queued-hooks r463 committed by jim.baker@canonical.com
[04:52] <_mup_> Locking test for UnitRelationLifecycle.purge
[14:34] <_mup_> juju/deploy-invalid-conf r449 committed by kapil.thangavelu@canonical.com
[14:34] <_mup_> merge trunk
[15:07] <jcastro> niemeyer: it isn't clear to me in the CS spec, but is there a flag for pulling unofficial charms from the store?
[15:07] <niemeyer> jcastro: No flags, it's just a different url
[15:08] <niemeyer> jcastro: cs:~jcastro/oneiric/hadoop
[15:08] <jcastro> ah perfect, thanks.
[15:08] <niemeyer> jcastro: np
[15:08]  * jcastro expects some cs:~upstream-project-that-isnt-in-the-repository/oneiric/projects
[15:08] <jcastro> good to know we covered that use case
[15:17] <bac> hi m_3
[16:04] <bac> hazmat, m_3:  i finally found the root of the problem i've been trying to resolve with the ubuntu user not being setup properly in the container.  the lxc update from last friday (https://launchpad.net/ubuntu/+source/lxc/0.7.5-3ubuntu24) includes a change to the ubuntu template to create the ubuntu user.  this causes setup_users to skip populating /home/ubuntu/.ssh.  i have a patch that makes setup_users more robust:  http://pastebin.ubuntu.com/843134/
[16:05] <m_3> bac: cool... thanks!
[16:06] <hazmat> bac thanks for looking into it, the patch lgtm..  bcsaller, jimbaker ^
[16:06] <hazmat> i'll apply it as a trivial
[16:06] <bac> great, thanks hazmat
[16:07] <bcsaller> hazmat: yeah, looks fine
[16:16] <jimbaker>  cool
[16:22] <_mup_> juju/trunk r455 committed by kapil.thangavelu@canonical.com
[16:22] <_mup_> merge deploy-invalid-conf. services won't deploy without valid config. [r=jimbaker, bcsaller][f=914610]
[16:27] <hazmat> bac the first bit looks a little strange, its basically saying if the user exists, then add the user
[16:29] <bac> hazmat: not my intent.  yeah, that part is bogus
[16:29] <bac> hazmat: the condition is backward
[17:51] <_mup_> juju/trunk r456 committed by kapil.thangavelu@canonical.com
[17:51] <_mup_> [trivial] lxc creation script copes with existing ubuntu user [a=bac][r=hazmat,bcsaller,jimbaker]
[18:37] <gary_poster> hazmat, fwiw, gmb just sent the feedback email I mentioned earlier to the juju list.
[18:38] <gary_poster> Also, m_3 or SpamapS or other ~charmers, we just submitted our charms for review https://bugs.launchpad.net/charms/+bug/932974 and eagerly await feedback.  Thanks!
[18:38] <_mup_> Bug #932974: Buildbot charms <Juju Charms Collection:Fix Committed> < https://launchpad.net/bugs/932974 >
[18:38] <gary_poster> thanks mup, like I said. :-)
[18:57] <_mup_> juju/unit-stop r424 committed by kapil.thangavelu@canonical.com
[18:57] <_mup_> minor tweaks
[18:59] <jimbaker> hazmat, are you working on bug 872264 ?
[18:59] <_mup_> Bug #872264: stop hook does not fire when units removed from service <juju:In Progress by jimbaker> < https://launchpad.net/bugs/872264 >
[19:01] <jimbaker> ok, i see this is a doc branch in lp:~hazmat/juju/unit-stop
[19:07] <hazmat> jimbaker, i'd had a discussion with niemeyer about when i was writing that spec, its going to need some state modifications
[19:08] <hazmat> gary_poster, noted, thanks.
[19:08] <hazmat> gmb, relation-get  can also retrieve local (non remote unit) values
[19:08] <jimbaker> hazmat, it sounds like it may be too earlier then to start dev on then
[19:08] <niemeyer> hazmat: Maybe even implement the ideas we discussed at Budapest
[19:08] <hazmat> jimbaker, have you thought about a solution ?
[19:09] <jimbaker> like to see some consensus before i tackle it
[19:09] <niemeyer> But we need a proper spec first
[19:09] <hazmat> agreed
[19:09] <jimbaker> hazmat, no, just trying to work on the most important bugs first. i will unassign myself
[19:09] <hazmat> niemeyer, the solution i got to was recording intent in the topology, which felt a little odd, and creates a garbage collection activity
[19:09] <niemeyer> hazmat: Ugh
[19:10] <hazmat> niemeyer, we record user intent in the topology, the coordination around stop happens, and then.. the topology needs cleanup
[19:10] <niemeyer> hazmat: Well.. that sounds ok..
[19:11] <hazmat> niemeyer, if we modify the topology to directly enact the user action, we effectively remove the identity.. if we record elsewhere we're violating the encapsulation of user intent in the topology.
[19:11] <niemeyer> hazmat: We just need to think through since logic has to be aware of the fact there is now ghost information int he topology
[19:11] <hazmat> niemeyer, yeah.. it seemed like the best option
[19:11] <hazmat> even if we record elsewhere the topology needs cleanup
[19:12] <niemeyer> hazmat: RIght.. I recall that conversation now.. tear down follows the inverse process of setup to preserve the grand concept
[19:12] <niemeyer> hazmat: Maybe.. but I wouldn't classify that as garbage collection
[19:13] <hazmat> ghost recon ;-)
[19:13] <gary_poster> hazmat, relation-get: cool, we would love to know how.  We don't see it in the docs even after searches, but I would not be at all surprised to have you show it to us in there. :-)  response to the email would be best: those questions/comments are from all of us collectively in the squad
[19:13] <hazmat> gary_poster, relation-get -h ?
[19:14] <hazmat> fair enough
[19:14] <niemeyer> hazmat: The key distinction is that it's not unimportant information.. it's there for a reason, and the way it is disposed off must be well defined and considered
[19:18] <gary_poster> hazmat, -h gives me an idea on how to do it, at least.  (`relation-get key $JUJU_UNIT_NAME` afaict?)
[19:18] <gary_poster> non-obvious imo :-)
[19:20] <hazmat> gary_poster, fair enough, it needs  documentation
[19:21] <hazmat> and it looks like it should be a switch so a key doesn't need to be specified
[19:22] <gary_poster> yeah +1
[19:27] <SpamapS> Hey guys, any code going to land in the next 8 hours that I should hold off uploading to precise for feature freeze?
[19:27]  * SpamapS re-posts in #juju-dev as well
[19:28] <m_3> SpamapS: we really should test the precise lxc stuff before uploading
[19:29] <SpamapS> m_3: did something change?
[19:31] <m_3> SpamapS: yup... this morning... just kicked off another ppa build to test it out
[19:31] <m_3> 456 should go in if it tests out
[19:31]  * m_3 looking to see what 455 is as that'll get pushed too
[19:33] <m_3> yeah, 454 and 456 are critical to precise
[19:36] <SpamapS> m_3: bug #'s?
[19:37] <m_3> both 454 and 456 relate to Bug #914392
[19:37] <_mup_> Bug #914392: LXC local provider does not respect 'series' (only installs oneiric) <local> <juju:Fix Released by hazmat> <juju (Ubuntu):Triaged by clint-fewbar> < https://launchpad.net/bugs/914392 >
[19:40] <hazmat> SpamapS, should be good afaics
[19:41] <m_3> ok, new ppa is out... please test precise running precise lxc containers
[19:41] <m_3> bac: ^^
[19:41] <m_3> I'll do the same
[19:41] <bac> cool, thanks m_3.  i had trouble getting mine to build due to test failures.
[19:45] <m_3> for peeps who haven't done that yet, you've gotta edit your environment to change 'default-series: precise' and make sure 'juju-origin: ppa'
[19:51] <bac> m_3: have you been able to install 0.5+bzr456-1juju2~precise1 ?
[19:52] <dendrobates> I haven;t tried in precise yet
[19:52] <m_3> bac: it's still downloading stuff
[19:53] <bac> m_3: it appears on the lp page but i don't know if it is published yet
[19:55] <m_3> bac: crap, yeah... it's still showing 454... we'll have to wait on lp
[20:06] <m_3> bummer... ok, the build failed on precise
[20:06] <danwee> anybody can help with juju
[20:07] <m_3> hazmat: the failing test doesn't look to have anything to do with the code changes
[20:07] <m_3> https://launchpadlibrarian.net/92996257/buildlog_ubuntu-precise-i386.juju_0.5%2Bbzr456-1juju2~precise1_FAILEDTOBUILD.txt.gz
[20:09]  * hazmat pokes
[20:10] <hazmat> m_3, nothing obvious
[20:10] <hazmat> danwee, sure
[20:11] <danwee> at last , thanks hamzat
[20:11] <danwee> ok , i m trying to cennect juju to a zookeeper, but i keep getting invalid ssh key
[20:12] <danwee> that is on orchestra server
[20:12] <danwee> i did RSA exchange keys with no luck to solve the problem, when i juju status
[20:13] <danwee> any ideas?
[20:16] <danwee> https://help.ubuntu.com/community/UbuntuCloudInfrastructure
[20:17] <danwee> reached juju status step, >> invalid ssh key
[20:18] <danwee> are u still there ?
[20:30] <hazmat> danwee, so you did bootstrap, the machine comes up, but status can't connect because of an invalid ssh key
[20:31] <hazmat> danwee, do you have a key specified in environments.yaml or is it doing the default and picking it up from the host/user that the cli is running on
[20:43] <danwee> mmm no i didnt specify  a key on yaml, u think that will solve the problem ?
[20:44] <danwee> u mean i can specify an RSA key in yaml ?
[20:47] <danwee> hazmat can u explain more please
[20:48] <hazmat> danwee, yes.. you can specify the key, else the key is sniffed from the environment.. if its sniffed from the environment, its important that the same user executes juju subsequently as its their key thats being setup on the newly launched machine
[20:49] <hazmat> danwee, the bottom of this has some details on specifying keys explicitly instead of implicitly https://juju.ubuntu.com/docs/provider-configuration-ec2.html
[20:49] <hazmat> hopefully that helps
[20:50] <danwee> you are great :)
[20:54] <jianghaitao> hi, just joined. Anyone who can help me on running LXC unit tests?
[20:55] <jianghaitao> it is complaining about resolvconf package
[21:00] <m_3> jianghaitao: hi... first make sure you're set up like https://juju.ubuntu.com/CharmSchool
[21:01] <m_3> jianghaitao: with one addition... your environments.yaml should have 'juju-origin: ppa'
[21:03]  * SpamapS is starting to think more and more that juju should push itself into the bootstrap node and deploy itself from the bootstrap node rather than trying to direct users to the right place to fetch it
[21:03] <jianghaitao> well, I downloaded the juju source and would like to run the LXC unit tests
[21:04] <jianghaitao> but it did not work, just wondering why?
[21:05] <koolhead17|afk> jianghaitao: http://askubuntu.com/questions/65359/how-do-i-configure-juju-for-local-usage/65360#65360
[21:05] <_mup_> Bug #65360: [UNMETDEPS] libbonobouimm1.3 has unmet dependencies <libbonobouimm1.3 (Ubuntu):Fix Released by geser> < https://launchpad.net/bugs/65360 >
[21:05] <koolhead17|afk> did you checked this link
[21:05] <SpamapS> actually jianghaitao brings up an important point.. I don't believe we run those unit tests in an automated fashion *ever*
[21:05] <SpamapS> and further.. I don't know why
[21:06] <jianghaitao> Thanks, but that is not what I was asking
[21:06] <jianghaitao> I knew how to run juju locally
[21:06] <SpamapS> well except that buildd's run lucid which has a very old lxc in the kernel.
[21:06] <SpamapS> jianghaitao: we don't run those tests very often.. we probably should.
[21:07] <jianghaitao> just that I want to run the unit tests that comes with the source code...seems I did not state clearly from the beginning?
[21:07] <m_3> jianghaitao: the lxc tests require a lot of lxc local environment setup
[21:07] <SpamapS> jianghaitao: those specific tests are usually skipped because they require extra functionality on your system
[21:08] <m_3> jianghaitao: lxc setup assumes things like apt-cacher-ng bound to 192.168.122.1:3124(?), etc
[21:08] <jianghaitao> That is ok, I just want to know how to set it up so I can run it
[21:08] <m_3> jianghaitao: so I recommend that before you try any lxc unit tests, you get your lxc env set up
[21:09] <m_3> jianghaitao: cool... so that's the link I sent above juju.ubuntu.com/CharmSchool
[21:09] <m_3> spells out the packages you'll need and the basic environment you'll need
[21:09] <jianghaitao> how do I know my lxc is set up? I think I set it up already
[21:10] <jianghaitao> Do I need to install juju before running unit tests? probably not, right...I will double check again
[21:10] <m_3> jianghaitao: it's set up when a service (choose a charm) reaches a 'started' state
[21:12] <m_3> jianghaitao: yes, you'll need to install everything on that list to get lxc working
[21:13] <jianghaitao> humm....actually I had more problem running juju unit tests on a VM that I have set up the juju and was able to start services...but anyhow, I appreciate all your help and will work on it more
[21:14] <m_3> jianghaitao: cool
[21:25] <danwee> i specified the key in enviroment.yaml, but still invalid ssh key >> hamzat , any ideas ?
[21:26] <danwee> something is missing, but i think this the right path
[21:36] <hazmat> danwee, hmm.. there's a few variables to play out, the machine appears to be up per orchestra and that the ssh connection attempt is happening at all. debugging further would require getting into the machine to understand why the key hasn't been put in place correctly. we put the key in place via cloud-init
[21:37] <hazmat> m_3, SpamapS is there any good way to get debugging info out of orchestra, like what the KSMETA is for a machine
[21:41]  * m_3 clueless
[21:41] <danwee> hamzat, from the machine side, all there is the authorized_keys, should i install cloud-init on the machine inorder for juju to autheticate it somehow ?
[21:42] <m_3> danwee: yes, that should be part of the orchestra preseed iirc
[22:01] <SpamapS> hazmat: cobbler has a commandline tool
[22:01] <SpamapS> hazmat: you can use dumpvars to get all of the variables for a system
[22:01] <hazmat> danwee, it should be part of the base clolud image
[22:01] <hazmat> cloud init that is
[22:02] <hazmat> jianghaitao, could you verify if the libvirt bridge is running it should be virbr0 in ifconfig output
[22:03] <danwee> yes, i m viewing the kickstart for the machine
[22:08] <danwee> thanks alot for your help , i m gonna delve more into the subject, but thanks for pointing me out the directions
[22:08] <danwee> you take care and i find out something interesting, i ll share it as well
[22:14] <hazmat> danwee, if you have the kickstart metadata for the machine could you post it to pastebin.ubuntu.com and send the link here.
[22:15] <hazmat> so cloud-init isn't putting the keys on the machine, either the base image is off somehow (ie. cloud-init not installed), or cloud-init's data is misconfigured
[22:56] <jamesmitchell> can I get a pointer for attaching and mounting and EBS volume for a service? I am deploying an nfs charm and want to put the data on a seperate ebs volume
[23:01] <m_3> jamesmitchell: the default juju images are ebs-rooted
[23:01] <m_3> jamesmitchell: unfortunately, that's all we do now to handle data
[23:03] <m_3> jamesmitchell: at least you can snapshot that, but otherwise it's manual attachment/mounting
[23:04] <jamesmitchell> I'm fine with it being ebs-rooted. I want to add an extra ebs volume as part of the install
[23:04] <jamesmitchell> and I'm not sure what I can do inside the instance to attach and mount
[23:04] <m_3> jamesmitchell: you can ssh in and do anything you'd like
[23:05] <jamesmitchell> :)
[23:05] <m_3> jamesmitchell: juju ssh takes args and supports forwarding iirc... and 'juju scp' exists
[23:05] <jamesmitchell> I was thinking more automated juju install
[23:05] <m_3> right ;)
[23:06] <jamesmitchell> everything I google wants me to attach the volume using console or ec2-tools
[23:07] <jamesmitchell> so I ask whether there is a way for the instance to attach the volume itself - provided I send a volume id as a config value
[23:08] <m_3> hmmmm... dunno, I've always done it using ec2 tools from _outside_ the instance
[23:09] <m_3> excellent question though... I don't think there's anything preventing you from sending creds up to the instance and using ec2 tools from there
[23:10] <jamesmitchell> fair enough - I'll go that route
[23:10] <m_3> it's stupid, I know, but one way to do exactly what you're trying is two different nfs services
[23:10] <m_3> just make the first one do nightly transfers from it's shared out directory to the backup mount
[23:11] <m_3> they're both running ebs volumes
[23:11] <m_3> but really you don't gain anything over just running a single ebs-rooted nfs server and taking snapshots of that ebs volume
[23:12] <m_3> jamesmitchell: one thing I want to do is provide a 'backup to s3' charm
[23:12] <m_3> that'll be subordinate to something like nfs server
[23:12] <jamesmitchell> actually my use case is for the setup of a new site. I have 2Gb tar file of initial image data (paired with an initial db load)
[23:13] <jamesmitchell> the tar file is on S3, and I can currently copy it down and untar
[23:13] <m_3> ah, that's it then
[23:13] <jamesmitchell> but it seems really slow - so I thought about creating the ebs ahead of time, and using snapshots to preload other sites
[23:13] <m_3> you'll have to add some config to the charm that takes s3 creds and an 'initial seed data' url
[23:13] <jamesmitchell> yep - got that working now
[23:13] <m_3> nice
[23:14] <m_3> yeah, so it's worth playing with calling ec2 tools from the instance to see if you can attach a volume from within the instance
[23:14] <m_3> that should be pretty easy to test out manually
[23:14] <m_3> then add it to the charm config if that works out
[23:14] <m_3> (please let me know!)
[23:15] <jamesmitchell> ok - I will. Thanks for that
[23:15] <m_3> jamesmitchell: please consider pushing your changes (pulling seed data from s3) back to the community charms
[23:16] <jamesmitchell> funny you should say that... I have not been able to get the charm-tools to work on my Lucid system. Keep getting an m2 error
[23:16] <m_3> SpamapS: lucid charm-tools?
[23:16] <jamesmitchell> during checkout
[23:17] <jamesmitchell> yes
[23:18] <SpamapS> m_3: if they exist.. they're not well tested ;)
[23:18] <m_3> jamesmitchell: that's not surprising
[23:18] <m_3> unfortunately
[23:18] <SpamapS> jamesmitchell: I think you mean mr right?
[23:18] <m_3> jamesmitchell: just do `bzr branch lp:charms/nfs`
[23:18] <SpamapS> jamesmitchell: mr changed drastically some time after lucid
[23:19] <jamesmitchell> yes, sorry I meant mr
[23:19] <SpamapS> jamesmitchell: We should probably have some kind of version detection so that doesn't break
[23:19] <jamesmitchell> m_3: that is how I seeded my versions - direct to source :)
[23:19] <m_3> mr's just a multi-repository checkout thingy... not much different than bzr branch
[23:20] <SpamapS> jamesmitchell: part of the reason we haven't worried about that is that charm-tools is mostly a stop-gap until juju's backend store is setup.
[23:20] <m_3> or `git bzr clone` :)
[23:20] <SpamapS> m_3: shush, gitboi
[23:23]  * m_3 making traction into the _second_ pot of coffee for the day
[23:25] <SpamapS> m_3: once I drain #1, I always just run across the street and get a red bull ;)
[23:25]  * SpamapS would be very sad if he didn't have a 7-11 45 steps away
[23:25] <m_3> zul would be jealous
[23:26] <zul> you know when im at home i dont drink redbull, you guys just drive me to insanity :P
[23:28] <SpamapS> zul: s/drive me to insanity/get me to act like my true self/
[23:29] <zul> heh im quite quiet without it
[23:30] <m_3> gary_poster: ping
[23:32] <_mup_> juju/env-from-env r457 committed by kapil.thangavelu@canonical.com
[23:32] <_mup_> pickup juju env from environment
[23:34] <_mup_> Bug #933165 was filed: Juju environment can be specified via environment variable. <juju:In Progress by hazmat> < https://launchpad.net/bugs/933165 >
[23:35] <m_3> hazmat: whoohoo thanks! perfect precedence ordering too
[23:37] <m_3> I'm totally gonna get the yellow team to propose cli plugins
[23:37]  * m_3 see's how it is... :)
[23:37] <SpamapS> ;)
[23:48] <m_3> gary_poster: please ping me tomorrow when you get a chance, I've got some questions on the buildbot charm
[23:56] <gary_poster> m_3, will do, thanks