[10:08] <Odd_Bloke> How do tests get run against charms; trying to understand how I can (a) include unit testing in test runs, and (b) replicate what is done elsewhere.
[11:32] <lazyPower> Odd_Bloke: there is a project called bundletester which is pip installable (in a venv) - and it sniffs out the tests in teh charm
[11:32] <lazyPower> Odd_Bloke: the unit test setup is different between charms, so bundletester evaluates a makefile to find the test targets
[11:33] <lazyPower> Additionally, if you have the package `charm-tools` installed - you can issue 'charm add tests' and it will setup a test scaffolding for integration tests using amulet.
[11:35] <Odd_Bloke> lazyPower: Thanks!
[11:37] <lazyPower> No problem
[12:11] <Odd_Bloke> I'm hitting a traceback with bundletester: https://gist.github.com/anonymous/389baade22b077abd190
[12:11] <Odd_Bloke> The tests are those generated by "juju charm create".
[12:13] <lazyPower> tvansteenburgh: are we tracking bundletester bugs on github or launchpad?
[12:13] <tvansteenburgh> lazyPower: let's use github
[12:14] <lazyPower> Odd_Bloke: can you file a bug against the project here: https://github.com/juju-solutions/bundletester
[12:16] <Odd_Bloke> https://github.com/juju-solutions/bundletester/issues/2
[12:17] <lazyPower> Thanks Odd_Bloke
[12:17] <tvansteenburgh> Odd_Bloke: for a workaround you might try downgrading juju-deployer to 3.8
[12:18] <tvansteenburgh> Odd_Bloke: i don't have time to test it right now but that's what i'd try first
[12:19] <Odd_Bloke> Trying that now.
[12:20] <Odd_Bloke> tvansteenburgh: lazyPower: Same traceback.
[12:21] <tvansteenburgh> Odd_Bloke: gimme a min, i'll give it a try
[12:22] <Odd_Bloke> tvansteenburgh: Thanks. :)
[13:06] <natefinch> man, digital ocean is so much faster than AWS
[13:06] <natefinch> deploying my discourse charm takes 21 minutes on AWS and 7 on DO
[13:09] <marcoceppi> natefinch: welcome to the world of SSDs
[13:09] <tvansteenburgh> Odd_Bloke: i haven't been able to repro that error. i have some other things i need to do atm but will circle back
[13:09] <marcoceppi> natefinch: also, congrats on the deployment
[13:09] <marcoceppi> natefinch: finally, haha at it taking forever with docker :P
[13:10] <natefinch> marcoceppi: right?  It looks like they do a crapload of stuff after the docker image is deployed... no idea why
[13:10] <marcoceppi> natefinch: because why bother using imaged based workflows ;)
[13:13] <natefinch> marcoceppi: "I: relation website has no hooks"  .... I don't actually know if I should have a hook for that relation or not?  is there something I would need to do with that?  Are there docs I can look at for what that should do?
[13:14] <marcoceppi> natefinch: no docs, just examples of charms that implement that relation at the moment. We;re working on a way to documentate relations
[13:14] <natefinch> marcoceppi: IIRC we talked about documenting relations a year ago ;)
[13:14]  * marcoceppi gets the long list of core features that were discussed a year ago and don't exist
[13:14] <marcoceppi> ;)
[13:15] <lazyPower> zing!
[13:15] <marcoceppi> natefinch: here's an example http://bazaar.launchpad.net/~charmers/charms/precise/wordpress/trunk/view/head:/hooks/website-relation-joined
[13:17] <natefinch> marcoceppi: ok, so it looks like I could just copy and paste that, right?
[13:17] <marcoceppi> natefinch: and replace the port with the right value
[13:17] <marcoceppi> typically it's 80, depends on the service
[13:17] <natefinch> marcoceppi: what's the right value?
[13:18] <marcoceppi> natefinch: whatever port the service runs on
[13:18] <natefinch> marcoceppi: so just the value the service is listening on?
[13:18] <natefinch> marcoceppi: ok
[13:45] <lazyPower> jcastro, mbruzek: https://github.com/juju/docs/pull/171
[13:46] <jcastro> I don't like the term "user space charms"
[13:46] <jcastro> Just say "charms in your personal namespace"
[13:46] <jcastro> otherwise that's like another new term people won't understand
[13:48] <lazyPower> jcastro: updated
[13:48] <rick_h_> jcastro: or even just your published charms?
[13:48] <jcastro> yeah
[13:49] <rick_h_> jcastro: lazyPower just to start to beat the drum on the publishing idea as we move that forward.
[13:49] <lazyPower> rick_h_: I'm going to bake you a cake when 'publish' lands.
[13:50] <lazyPower> and i'll send a print copy of the reworked doc page when that happens.
[13:50] <natefinch> space charms sound pretty cool though
[13:51]  * natefinch whistles the star trek theme
[14:27] <josepht> to boldly deploy where no charm has gone before
[14:44] <natefinch> jcastro: maybe I'm not understanding what you mean by version specific stuff in charms.  Actions won't ever work in 1.18, therefore it's a version specific feature in a charm, isn't it?
[14:44] <jcastro> right
[14:44] <jcastro> I think having version specific anything in charms is a bad idea
[14:45] <natefinch> but my point is, if there's ever a new feature we want to support in a charm, it'll be version specific
[14:45] <jcastro> right
[14:45] <jcastro> I think if you were to tell a charm author
[14:45] <natefinch> and we need new features, unless you want to tell Mark S we can't do actions :)
[14:45] <jcastro> "check out these new features, but 1.20 only"
[14:46] <jcastro> my answer would be "well I'm not going to add it to my charm until someone asks for it."
[14:46] <jcastro> I would tell people "upgrade to 1.20"
[14:46] <jcastro> I wouldn't make my charm more complex
[14:52] <natefinch> jcastro: I guess I look at it differently.  I'd see all the new functionality in 1.20 and say "hey, this could make my charm a lot more useful to people", so I'd update it and tell people to get off their butts and upgrade ;)
[14:53] <jcastro> sure
[14:53] <jcastro> until you realize that most people are and will remain on 1.18
[14:53] <jcastro> I would just be like "this charm requires 1.20"
[14:53] <natefinch> jcastro: that's what we're doing
[14:54] <jcastro> yeah but this lets you pick and choose afaict.
[14:54] <natefinch> jcastro: in implementation, yes, but in actuality... feature X and Y will require 1.20, and feature Z will require 1.21, so if you use all three, your charm effectively requires 1.21
[14:55] <jcastro> right, so why not just something simpler like "> 1.21"
[14:55] <jcastro> like how packages do it?
[14:55] <jcastro> I feel like the granularity will just end up with different permutations for everything
[14:56] <jcastro> in the worst place to have it, the store
[14:56] <natefinch> I think that's perfectly valid.  It wasn't my design.... I think it was William's... who is conveniently out today :)
[14:58] <natefinch> I can guess about why it was done this way - so that if you backport a feature, the charms that use that feature all of a sudden work in the old version, rather than having a hard-coded revision number
[14:59] <jcastro> well, I think of it this way
[14:59] <natefinch> but it is significantly less obvious to the end user what versions will support any particular charm... they have to go look up the documentation for each feature and see what version it supports
[14:59] <jcastro> we know X version of juju is in Ubuntu version Z
[14:59] <jcastro> those charms are series'ed
[14:59] <jcastro> so I know on precise I'll have Juju version X with charm version Z
[15:00] <jcastro> when I move to trusty, I'll have X+1 and Z+1
[15:00] <jcastro> the charm might or might not have new features based on what corresponding version of juju comes with that new version of ubuntu
[15:00] <jcastro> basically, charm series are already tied to juju core versions we ship
[15:01] <jcastro> so if I want to use juju actions I'll use utopic charms
[15:01] <jcastro> but I wouldn't update the precise charm to use actions
[15:01] <natefinch> that's a very interesting point
[15:01] <jcastro> and if you use a PPA on an older serioes
[15:01] <jcastro> blam, you use the newer series charm as well, even on the old distro
[15:02] <jcastro> then it's easier for us to say
[15:02] <natefinch> the only problem then, is that you're now requiring that charms with new features use a non-LTS host OS
[15:02] <jcastro> "if you want to use actions, you need to put them in charms utopic and newer"
[15:03] <jcastro> not really, we're only doing LTS series anyway
[15:04] <natefinch> wait, so are you saying you'd deploy the utopic charm to Trusty?
[15:04] <jcastro> well we don't have utopic charms, that was an example
[15:04] <jcastro> it'd be whatever the next LTS is
[15:05] <natefinch> ok, so no new features until 2016 then?
[15:05] <jcastro> land as many as you want
[15:05] <jcastro> but like the "trusty" and "precise" stores are pretty much locked to the published version of juju in them
[15:06] <jcastro> which is why in the mail I think moving to getting newer juju's backported to those is a nicer win
[15:06] <jcastro> because then you'd bring them up along with you instead of having them hold you back
[15:08] <jcastro> (I realize that's also another set of problems)
[15:08] <natefinch> yeah... believe me, we'd love to have 1.20 in precise and trusty
[15:09] <natefinch> I think we're working on getting it into trusty, actually
[15:09] <jcastro> I just really think having version fragmentation in the store will be bad
[15:10] <jcastro> I mean, the hard truth is our customers and users use LTSes, and don't want radical change
[15:10] <jcastro> shifting the change from juju to the store seems just as bad to me, if not worse
[15:10] <jcastro> "don't worry, juju itself won't change, now we'll just put all the churn in the charm instead!"
[15:12] <natefinch> the problem is really that we just can't force people to upgrade
[15:13] <natefinch> I'm sure there's people out there running merrilly long with a 1.14 juju server, and someday they're going to say "hey, you know what? I want X new charm" and do juju deploy foo ... and it'll not work, in some weird and non-obvious way
[15:13] <natefinch> the point of this code is to make it not work in an obvious and immediate way
[15:15] <marcoceppi> woo who! pprint lands in trunk https://github.com/juju/juju/pull/757
[15:16] <marcoceppi> juju status --format=oneline
[15:18] <natefinch> nice!
[15:39] <aisrael> lazyPower: are there test lab credentials re https://bugs.launchpad.net/charms/+bug/1325700 that you can share, or should I assign it to you to re-review?
[15:39] <mup> Bug #1325700: New Charm: Dell OpenManage Server Administrator (OMSA) <Juju Charms Collection:Fix Committed> <https://launchpad.net/bugs/1325700>
[18:37] <aisrael> Has relation-list been deprecated?
[18:47] <arosales> aisrael: not sure, but be a good question to pop into #juju-dev
[18:47] <aisrael> ack
[18:47] <arosales> got a DB questoin from the folks working on the Zend charm.
[18:47] <arosales> "When I add MySQL relation I need 2 seperate DBs. One for Zend Server cluster data and one for the application. When I ask for "db_db=`relation-get database`" I get a database name "zend-server". Is it possible to get another DB from the same MySQL unit for Magento?"
[18:48] <arosales> hints/tips/tricks on how to create two DBs from one relation?
[18:49] <fuzzy_> in SQL it's called views
[18:50] <fuzzy_> where you can build a view of a dataset
[18:50] <fuzzy_> But I think your question is more Zend related :)
[18:59] <arosales> fuzzy_: thanks for the comments. I may have to see how the zend folks are trying to use this in their charm.
[19:00] <fuzzy_> If you have sql questions, feel free to ask
[21:07]  * arosales taking a look at the review queue
[21:07]  * arosales reviwing nginx
[21:08] <arosales> filled https://github.com/marcoceppi/review-queue/issues/9  -- not auto charm testing comment
[21:12] <jcastro> if I have a directory in my charm
[21:12] <jcastro> say "files/"
[21:12] <jcastro> where I want to put like random config files I want on the units
[21:12] <jcastro> when calling it from say an install hook, what's the pwd?
[21:12] <jcastro> will "cp -f files/foo destination" work?
[21:32] <arosales> mbruzek: can I get you to kick off a tests for the items in the review queue?
[21:32] <arosales> s/a//
[21:32] <mbruzek> sure
[21:32] <arosales> mbruzek: specifically the ones that don't have a test stuat
[21:33] <mbruzek> arosales: when I tried this yesterday it did not work for me let me try again today.
[21:33] <arosales> ah ok, let me know if it still fails
[21:34] <mbruzek> arosales: I did the Review Queue with Jose yesterday and told him about the new feature.
[21:34] <mbruzek> But I was unable to kick new tests off
[21:34] <mbruzek> arosales: I was incorrect, it does seem to work today.
[21:34] <arosales> mbruzek: ah ok, good to hear
[21:34] <mbruzek> specifically which ones?
[21:35] <mbruzek> arosales: all of them in the queue?
[21:36] <mbruzek> kicked them all off.
[21:38] <arosales> yes, I think they all need a test before ack
[21:38] <arosales> mbruzek: thanks
[22:22] <ayr-ton> Two quick questions, maybe is good to have this on askubuntu later. In the future will be possible to add relations between environments? And a friend of mine asked about official support do centos deployments.
[22:26] <alexisb> ./join #docker-dev
[22:39] <ayr-ton> alexisb, docker-dev?
[22:41] <alexisb> ayr-ton, yeah I added the "." by mistake
[22:41] <ayr-ton> Ah, ok.
[22:54] <arosales> ayr-ton: re your question, it is on the road map to have juju have relations between environments.  Its been dubbed cross environment relaitons.
[22:54] <arosales> s/relaitons/relations
[22:54] <arosales> charmer needed to update https://code.launchpad.net/~jorge/charms/trusty/mysql/fix-proof/+merge/234020
[22:55] <ayr-ton> interesting.
[22:55] <arosales> its been superceded by https://code.launchpad.net/~a.rosales/charms/trusty/mysql/add-default-keys/+merge/235064
[23:05] <arosales> charmer also needed to update the MP status on https://code.launchpad.net/~tvansteenburgh/charms/precise/block-storage-broker/fix-tests/+merge/234168