| perlstein | hello | 00:48 |
|---|---|---|
| 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 | 00:49 |
| sumanah | hazmat: m_3: got a moment? | 03:58 |
| 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 ) :) | 03:59 |
| * sumanah emails you both | 04:11 | |
| SpamapS | perlstein: the charms are at http://code.launchpad.net/charm | 04:46 |
| SpamapS | perlstein: there's some info on how to use them spread out on wikis.. we're working on consolidating it | 04:47 |
| === _mup__ is now known as _mup_ | ||
| SpamapS | jamespage: hey, so, charm testing.. | 11:17 |
| 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:18 |
| 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:19 |
| jamespage | SpamapS, I agree | 11:20 |
| SpamapS | https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-juju-charm-testing | 11:20 |
| 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:21 |
| jamespage | TBH this is really what I wanted to see | 11:23 |
| jamespage | but I think that this is something a little different to the complex deployment testing objective we have | 11:24 |
| 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:25 |
| 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:27 |
| 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:28 |
| SpamapS | Indeed | 11:29 |
| 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:30 |
| 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:31 |
| jamespage | and just provide a nice way to hook in a set of black box system tests once the environment is fully deployed | 11:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| jamespage | done | 11:41 |
| SpamapS | ahh very nice | 11:42 |
| SpamapS | I forget that deps exist ;) | 11:42 |
| rog | hey guys, i'm off now for the afternoon. flight to UDS 6.30am tomorrow. looking fwd to seeing you there. | 11:43 |
| 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:45 |
| rog | SpamapS: great, hope all went well this week | 11:46 |
| SpamapS | rog: indeed, very productive (stayed almost completely focused on the charm store) | 11:52 |
| SpamapS | hrm, why doesn't our bot tell us about trunk commits? :-P | 12:34 |
| hazmat | SpamapS, yeah.. it would be nice if the commits weren't client side | 14:58 |
| hazmat | er. messages about them | 14:58 |
| _mup_ | juju/expose-refactor r414 committed by jim.baker@canonical.com | 15:31 |
| _mup_ | Fix interaction of watch setup and retry test | 15:31 |
| * SpamapS awaits flight attendant rebuke and continues deleting... err.. reading email | 17:02 | |
| _mup_ | juju/expose-refactor r415 committed by jim.baker@canonical.com | 17:47 |
| _mup_ | Docstrings, cleanup | 17:47 |
| _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 | 19:57 |
| _mup_ | txzookeeper/session-and-conn-fail r61 committed by kapil.foss@gmail.com | 20:13 |
| _mup_ | refactor core tests for less exposed surface. | 20:13 |
| _mup_ | juju/unlocalize-network r409 committed by kapil.thangavelu@canonical.com | 21:17 |
| _mup_ | merge trunk | 21:17 |
| _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:21 |
| _mup_ | juju/trunk-merge r277 committed by kapil.thangavelu@canonical.com | 21:23 |
| _mup_ | merge trunk | 21:23 |
| _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. | 21:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
