[00:48] <perlstein> hello
[00:49] <perlstein> are there juju charms that automatically deploy openstack for some common uses?
[00:49] <perlstein> i'm going by the openstack guide, but others on my team are suggesting that there's some charms i can check out to make it easier?
[00:49] <perlstein> i am having zero lucki finding them
[03:58] <sumanah> hazmat: m_3: got a moment?
[03:59] <sumanah> I'm writing up https://www.mediawiki.org/wiki/NOLA_Hackathon#Topics.2C_Goals.2C_.26_Outcomes
[03:59] <sumanah> (nice photo: https://commons.wikimedia.org/wiki/File:NOLA_Hackathon_13.jpg ) :)
[04:11]  * sumanah emails you both
[04:46] <SpamapS> perlstein: the charms are at http://code.launchpad.net/charm
[04:47] <SpamapS> perlstein: there's some info on how to use them spread out on wikis.. we're working on consolidating it
[11:17] <SpamapS> jamespage: hey, so, charm testing..
[11:18] <jamespage> SpamapS: hey
[11:18] <jamespage> any thoughts on my email from last month?
[11:18] <SpamapS> jamespage: we had a fairly deep conversation about it yesterday.. and we came up with something not at all compatible with what you guys have done. :p
[11:18] <jamespage> SpamapS, w00t
[11:19] <jamespage> whats the thinking then?
[11:19] <SpamapS> jamespage: we can likely use any of the tests you've already written, but the relation to a testing service has problems for automation of testing the entire graph of combinations of charms, which we very much want to do.
[11:20] <jamespage> SpamapS, I agree
[11:20] <SpamapS> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-juju-charm-testing
[11:21] <SpamapS> jamespage: the whiteboard details the way that we'll do it..
[11:21] <SpamapS> jamespage: we'll have to blacklist any charms that have no sane defaults (like the recently submitted ELB charm that needs an AWS account #)
[11:23] <jamespage> TBH this is really what I wanted to see
[11:24] <jamespage> but I think that this is something a little different to the complex deployment testing objective we have
[11:25] <SpamapS> The idea behind this one is simply to ensure that testing happens automatically on all charms in the charm store.
[11:25] <jamespage> which I agree is v. important and fulfills a clear objective for juju and the charm store
[11:27] <SpamapS> I don't think the test runner will actually be that complex to write.
[11:27] <jamespage> it would be nice if this work could hook into the complex deployment testing stuff
[11:27] <SpamapS> The dependency resolution bits are actually already done in an older branch of juju.. so its just wrapping that around the right sequencing.
[11:28] <jamespage> i.e. we could use the internal charm tests as part of testing an specific stack of charms
[11:28] <jamespage> as well as testing it from the outside as well
[11:28] <jamespage> openstack being a case in point
[11:29] <SpamapS> Indeed
[11:30] <jamespage> SpamapS: are 'stacks' expected to be delivered soon i.e. the ability to specify which charms, how many units and relationships without scripts
[11:30] <SpamapS> jamespage: hazmat sent out a proposal for a near term roadmap that included import/export
[11:31] <jamespage> so with complex deployment testing the stuff I have today works around not having that
[11:31] <jamespage> the internal charm testing is broadly equivalent to __install__ tests
[11:31] <SpamapS> jamespage: right
[11:31] <jamespage> so I can probably bin that
[11:32] <jamespage> and just provide a nice way to hook in a set of black box system tests once the environment is fully deployed
[11:33] <jamespage> SpamapS: so with the charm testing I think we need a way to pull out test results and report on what passed and failed.
[11:33] <jamespage> an overall status is good - we can use that for acceptance into the charm store
[11:33] <jamespage> but details of what went wrong are important as well
[11:33] <jamespage> (sure that you already discussed this)
[11:34] <SpamapS> glossed over the details, but yes, the idea is to provide help for fixing whatever broke
[11:34] <jamespage> this is so lining up to become a jenkins plugin :-)
[11:34] <SpamapS> I'm hoping its just a script that one runs in jenkins. :)
[11:34] <jamespage> (have been holding off as I did not want to re-invent the wheel)
[11:35] <jamespage> yeah - but think about this
[11:35] <jamespage> an deployed juju environment is just a test fixture
[11:35] <SpamapS> I was thinking about it and really we can just have a thing that watches all branches for a commit, when it sees one, it merges that into a single bzr branch that is "the charms".. and then runs the test runner for the affected charm.
[11:36] <jamespage> so having a nice way to manage (import/export) and environment setup would be sweet
[11:36] <SpamapS> jamespage: right.. I could see it working as a jenkins plugin, but I couldn't see myself writing a jenkins plugin. ;)
[11:36]  * jamespage is up for that challenge
[11:36] <jamespage> heck you can even write them in python these days
[11:37] <jamespage> *experimental only
[11:37] <SpamapS> jamespage: I'm not sure I fully understand the value in making it a jenkins plugin vs. just running things in response to a bzr commit.
[11:37] <jamespage> so for the charm testing that is sufficient
[11:37] <jamespage> I was more thinking about complex deployment testing TBH
[11:38] <jamespage> i.e. set me up this environment
[11:38] <jamespage> I'll then test/run/build in it
[11:38] <jamespage> and then tear it down again
[11:38] <jamespage> it needs more thinking about
[11:39] <SpamapS> It feels odd when I think about how a juju env relates to jenkins.
[11:39] <jamespage> can we make sure that servercloud-p-juju-charm-testing happens before servercloud-p-complex-deployment-testing.
[11:39] <SpamapS> A general juju plugin would make a lot of sense.. since as you say, juju envs are just test fixtures. But how it would work.. I'm really not sure.
[11:40] <SpamapS> jamespage: yeah good idea
[11:40] <SpamapS> jamespage: as of last night it was before
[11:40] <jamespage> I'll add a deps
[11:41] <jamespage> done
[11:42] <SpamapS> ahh very nice
[11:42] <SpamapS> I forget that deps exist ;)
[11:43] <rog> hey guys, i'm off now for the afternoon. flight to UDS 6.30am tomorrow. looking fwd to seeing you there.
[11:45] <SpamapS> heh, I'm in Orlando airport waiting to fly home for the weekend. ;)
[11:45] <SpamapS> be back on Tuesday morning. :)
[11:45] <SpamapS> rog: see you here then. ;)
[11:46] <rog> SpamapS: great, hope all went well this week
[11:52] <SpamapS> rog: indeed, very productive (stayed almost completely focused on the charm store)
[12:34] <SpamapS> hrm, why doesn't our bot tell us about trunk commits? :-P
[14:58] <hazmat> SpamapS, yeah.. it would be nice if the commits weren't client side
[14:58] <hazmat> er. messages about them
[15:31] <_mup_> juju/expose-refactor r414 committed by jim.baker@canonical.com
[15:31] <_mup_> Fix interaction of watch setup and retry test
[17:02]  * SpamapS awaits flight attendant rebuke and continues deleting... err.. reading email
[17:47] <_mup_> juju/expose-refactor r415 committed by jim.baker@canonical.com
[17:47] <_mup_> Docstrings, cleanup
[19:57] <_mup_> txzookeeper/session-and-conn-fail r60 committed by kapil.foss@gmail.com
[19:57] <_mup_> 2nd refactor, simplify retry impl, remove magic instance rebinding, just simple delegator methods
[20:13] <_mup_> txzookeeper/session-and-conn-fail r61 committed by kapil.foss@gmail.com
[20:13] <_mup_> refactor core tests for less exposed surface.
[21:17] <_mup_> juju/unlocalize-network r409 committed by kapil.thangavelu@canonical.com
[21:17] <_mup_> merge trunk
[21:21] <_mup_> juju/security-agents-with-identity r315 committed by kapil.thangavelu@canonical.com
[21:21] <_mup_> exposed grant access api, exists check on acl
[21:23] <_mup_> juju/trunk-merge r277 committed by kapil.thangavelu@canonical.com
[21:23] <_mup_> merge trunk
[21:26] <_mup_> juju/trunk r411 committed by kapil.thangavelu@canonical.com
[21:26] <_mup_> merge unlocalize-network [r=bcsaller,jimbaker][f=873335]
[21:26] <_mup_> Force explicit "C" locale to normalize output parsing of the libvirt cli.