[00:48] hello [00:49] are there juju charms that automatically deploy openstack for some common uses? [00:49] 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] i am having zero lucki finding them [03:58] hazmat: m_3: got a moment? [03:59] I'm writing up https://www.mediawiki.org/wiki/NOLA_Hackathon#Topics.2C_Goals.2C_.26_Outcomes [03:59] (nice photo: https://commons.wikimedia.org/wiki/File:NOLA_Hackathon_13.jpg ) :) [04:11] * sumanah emails you both [04:46] perlstein: the charms are at http://code.launchpad.net/charm [04:47] perlstein: there's some info on how to use them spread out on wikis.. we're working on consolidating it === _mup__ is now known as _mup_ [11:17] jamespage: hey, so, charm testing.. [11:18] SpamapS: hey [11:18] any thoughts on my email from last month? [11:18] 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] SpamapS, w00t [11:19] whats the thinking then? [11:19] 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] SpamapS, I agree [11:20] https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-juju-charm-testing [11:21] jamespage: the whiteboard details the way that we'll do it.. [11:21] 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] TBH this is really what I wanted to see [11:24] but I think that this is something a little different to the complex deployment testing objective we have [11:25] The idea behind this one is simply to ensure that testing happens automatically on all charms in the charm store. [11:25] which I agree is v. important and fulfills a clear objective for juju and the charm store [11:27] I don't think the test runner will actually be that complex to write. [11:27] it would be nice if this work could hook into the complex deployment testing stuff [11:27] 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] i.e. we could use the internal charm tests as part of testing an specific stack of charms [11:28] as well as testing it from the outside as well [11:28] openstack being a case in point [11:29] Indeed [11:30] 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] jamespage: hazmat sent out a proposal for a near term roadmap that included import/export [11:31] so with complex deployment testing the stuff I have today works around not having that [11:31] the internal charm testing is broadly equivalent to __install__ tests [11:31] jamespage: right [11:31] so I can probably bin that [11:32] and just provide a nice way to hook in a set of black box system tests once the environment is fully deployed [11:33] 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] an overall status is good - we can use that for acceptance into the charm store [11:33] but details of what went wrong are important as well [11:33] (sure that you already discussed this) [11:34] glossed over the details, but yes, the idea is to provide help for fixing whatever broke [11:34] this is so lining up to become a jenkins plugin :-) [11:34] I'm hoping its just a script that one runs in jenkins. :) [11:34] (have been holding off as I did not want to re-invent the wheel) [11:35] yeah - but think about this [11:35] an deployed juju environment is just a test fixture [11:35] 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] so having a nice way to manage (import/export) and environment setup would be sweet [11:36] 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] heck you can even write them in python these days [11:37] *experimental only [11:37] 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] so for the charm testing that is sufficient [11:37] I was more thinking about complex deployment testing TBH [11:38] i.e. set me up this environment [11:38] I'll then test/run/build in it [11:38] and then tear it down again [11:38] it needs more thinking about [11:39] It feels odd when I think about how a juju env relates to jenkins. [11:39] can we make sure that servercloud-p-juju-charm-testing happens before servercloud-p-complex-deployment-testing. [11:39] 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] jamespage: yeah good idea [11:40] jamespage: as of last night it was before [11:40] I'll add a deps [11:41] done [11:42] ahh very nice [11:42] I forget that deps exist ;) [11:43] hey guys, i'm off now for the afternoon. flight to UDS 6.30am tomorrow. looking fwd to seeing you there. [11:45] heh, I'm in Orlando airport waiting to fly home for the weekend. ;) [11:45] be back on Tuesday morning. :) [11:45] rog: see you here then. ;) [11:46] SpamapS: great, hope all went well this week [11:52] rog: indeed, very productive (stayed almost completely focused on the charm store) [12:34] hrm, why doesn't our bot tell us about trunk commits? :-P [14:58] SpamapS, yeah.. it would be nice if the commits weren't client side [14:58] 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.