[06:44] <AskUbuntu> openstack infrastructure help | http://askubuntu.com/q/320538
[08:31] <negronjl> jcastro:  I may not able to finish it ... in London sprinting :/
[08:46] <melmoth> hmmm, my charm.log says opened 123/udp, but i do not see any change in my vm security rules
[08:48] <melmoth> hmm, probably because it s a subordinate charm.
[12:29] <jcastro> negronjl: we'll handle it here.
[12:44] <marcoceppi> melmoth: what provider?
[12:45] <melmoth> marcoceppi, openstack.
[12:45] <melmoth> turned out it was related to the fact the charm is a subordinate
[12:45] <melmoth> once i exposed the container charm, i saw the security rules change
[13:08] <marcoceppi> melmoth: interesting
[13:08] <melmoth> not sure if it s a bug or a feature :)
[13:09] <marcoceppi> melmoth: probably a bug
[13:18] <jcastro> marcoceppi: liferay if you have time today
[13:19] <jcastro> marcoceppi: also if you do promulgate, rate it.
[13:19] <jcastro> *cough*
[13:19] <marcoceppi> jcastro: I've carved out some time around lunch
[13:19] <jcastro> EXCELLENT.
[14:16] <jamespage> marcoceppi, do we have an agreed location for charm unit test?
[14:17] <jamespage> I think I'm correct in saying that the tests top-level directory is more charm integration testing type stuff right?
[14:23] <marcoceppi> jamespage: Yes, so test(s)? directory in CHARM_DIR is functional testing, unit tests should live near the code of the file it's testing
[14:23] <marcoceppi> jamespage: we've tossed a few ideas, but haven't agreed on anything yet, the idea was lib/<LIB_NAME>/tests
[14:23] <jamespage> aack
[14:29] <pavel> how I can specify array type in config.yaml?
[14:31] <marcoceppi> pavel: There are no array types in juju config
[14:31] <pavel> marcoceppi, thanks
[14:31] <marcoceppi> Typically it's just string and you specify delimiter (, ; |) etc
[14:31] <pavel> yep
[15:15] <stokachu> is it possible to have multiple subordinates related to one service
[15:16] <stokachu> for example i would like to expose my django app over gunicorn and have another webserver like monkey to serve the static files
[15:16] <stokachu> and all be on the same machine
[15:23] <marcoceppi> stokachu: There is no limit to subordinates on a single machine, however becareful not to have them stomp on each other
[15:25] <stokachu> marcoceppi: yea i just ran into that and shutdown the whole unit
[15:27] <stokachu> does it make sense to have a django application a subordinate to apache? reason I ask is im trying to figure out the best way to serve static files
[15:27] <stokachu> currently apache is one instance, and django+gunicorn is another which is also where the static content is
[15:29] <marcoceppi> stokachu: There's really no right or wrong answer, what works best for you and your charm/application is the right answer. Charms are designed to be opinionated reflections of how you/the serivces community does workloads
[15:29] <stokachu> i gotcha
[15:30] <marcoceppi> Personally, I'm not a fan of apache as a subordinate. It's too difficult to guess every possible workflow. When I need to be opinionated about web service to use in a charm I add it as a config option (many of my charms has an "engine" config option with apache2 and nginx being valid values)
[15:30] <stokachu> marcoceppi: with your setup do you install apache/nginx on the same system as the charm you are deploying?
[15:31] <marcoceppi> stokachu: I will install either depending on the option provided by the user on the unit itself. That way I know what configuration files to place where, etc
[15:31] <stokachu> marcoceppi: ok cool that makes sense to me
[15:31] <stokachu> that'll reduce my instance count too
[15:32] <marcoceppi> stokachu: however, you don't even have to provide the option, if apache2 is the answer for you then use that. If someone else wants another web service they can add teh configuration option and submit a patch ;)
[15:32] <marcoceppi> If you have a desire to use different engines, then I'd look for configuration options over subordinates
[15:32] <stokachu> marcoceppi: ok cool, i think ill look into that
[15:32] <stokachu> makes more sense to me than the subordinate does
[15:33] <marcoceppi> Again, personally, I like to look at suborindates as a way to extend a service in to other unrelated services without the use of a relation. Like monitoring, shared file systems, etc
[15:33] <jcastro> yeah to me subordinates is "I need to tack on another service like backup"
[15:33] <stokachu> ah so totally separate from the intention of the charm itself
[15:33] <stokachu> that clears up a lot now
[15:34] <marcoceppi> stokachu: gunicorn is of course the exception to my opinion, as it works quite well the way it's designed
[15:34] <stokachu> marcoceppi: agreed, ill just make note of it as being a 'special case'
[15:35] <stokachu> thanks guys you have just cleared up the rest of my confusion with the subordinates and relations
[15:35] <marcoceppi> juju's flexible to do most whatever you want, you just need to note of what makes sense for you and then shape that in to charms. We really don't have many conventions of what each type of charm should look like. It's very very lose and opinionated
[15:35] <marcoceppi> cheers o/
[15:35] <stokachu> marcoceppi: yea i love the flexibility :D
[16:47] <_mup_> Bug #1201879 was filed: Juju LXC deployment fails with abort error <juju:New> <https://launchpad.net/bugs/1201879>
[17:58] <jcastro> hey adam_g
[17:58] <jcastro> did you get my messages wrt. rating those 2 openstack charms?
[18:18] <adam_g> jcastro, dont think so. sorry, been out since thursday. still going thru inbox
[18:20] <adam_g> jcastro, not seeing it, when did you send
[18:20] <jcastro> IRC 2 days ago
[18:20] <jcastro> TLDR I need you to rate glance and cinder
[18:20] <adam_g> jcastro, oh, ok
[18:20] <jcastro> you can either do that through manage.jujucharms.com
[18:21] <jcastro> or mail me the results for each one based on: https://juju.ubuntu.com/docs/authors-charm-quality.html
[18:21] <jcastro> and I'll rate them for you
[18:21] <jcastro> you can basically just copy and paste to criteria into an email and then change the ones the charm doesn't do to +0
[18:21] <jcastro> and I'll do the rest
[18:21] <jcastro> but I need it by Friday EOD
[18:21] <adam_g> jcastro, email you the qualtiy assessment?
[18:22] <jcastro> yeah
[18:22] <adam_g> ok
[18:22] <jcastro> I only need cinder and glance by Friday
[18:22] <adam_g> note glance + cinder (and the other bash openstack charms) will have python rewrites proposed to charm store sooooon
[18:22] <jcastro> will they be rewritten by OSCON?
[18:23] <jcastro> if no then I need the ratings before then. It should only take you like ~5min per charm to rate
[18:23] <adam_g> jcastro, we are targeting to have *most* of them at least done and ready for testing + review by this week EOW
[18:23] <jcastro> adam_g: ok then if you want to rate the new ones instead that's fine
[18:23] <jcastro> As long as we have ratings for them for OSCON
[18:24] <adam_g> jcastro, i'll rate them as-is. the rewrites are functionally the same. the're just much cleaner and an improvement in terms of maintainability
[18:24] <adam_g> oh, and not bas
[18:24] <jcastro> if you want to rate what they will support that's fine too
[18:24] <adam_g> *bash
[18:24] <jcastro> a few day discrepancy isn't a big deal
[18:25] <marcoceppi> hazmat: is python-jujuclient packaged?
[18:25] <marcoceppi> "somewhere"
[18:26] <adam_g> marcoceppi, https://launchpad.net/~ahasenack/+archive/python-jujuclient i think kapil mentioned this as a source last week
[18:26] <marcoceppi> adam_g: cool, thanks
[19:34]  * rick_h still watches over here...
[19:34] <arosales> jcastro, I don't see @ https://juju.ubuntu.com/docs/authors-charm-policy.html
[19:34] <arosales> where it states a charm will be ack'ed if upstream is still not fully GA
[19:34] <arosales> if the charm itself looks good why block it from the charm store?
[19:35] <marcoceppi> arosales: Well, with tests I don't see why we wouldn't let alpha services in
[19:36] <arosales> sorry I meant t say "where it states a charm will be _nacked" if upstream is still not full GA."
[19:36] <marcoceppi> it doesn't, but I dont' think it's a policy more an ethical thing
[19:36] <jcastro> that's just a choice we decided
[19:36] <arosales> marcoceppi, if the charm itself looks good and follows the charm store guildlines then . .  .
[19:37] <marcoceppi> I don't want to say "DEPLOY DISCOURSE WITH THIS CHARM" then because of a change upstream (and there are a lot of changes) it doesn't deploy
[19:37] <jcastro> the charm pulls from github, there's no guarantee it'll even deploy at any given point
[19:37] <marcoceppi> it makes juju look bad
[19:37] <jcastro> so we left it in ~marcoceppi
[19:37] <marcoceppi> Since the store is supposed to be golden
[19:37] <jcastro> when they hit 1.0 I think we should totally Feature it though
[19:37] <marcoceppi> So, when testing gets better, I'd feel more confident saying "put it in the store"
[19:38] <marcoceppi> because I'll know exactly when it starts failing to deploy
[19:38] <marcoceppi> Of if I can get sam & co to take over the charm upstream
[19:38] <arosales> jcastro, marcoceppi what about the charm maintainer keeping a known good working version
[19:38] <arosales> and the config option to pull from trunk
[19:38] <marcoceppi> arosales: it pulls "latest-stable" but that changes every week
[19:38] <arosales> any charms that pulls directly from tip is at risk for a non-deploy
[19:39] <marcoceppi> so if it's pinned to a version that becomes out of date in a matter of days
[19:39] <arosales> marcoceppi, sure, but it deploys and I config change to get the latest
[19:39] <marcoceppi> they're seriously averaging 30+ commits to tip a day
[19:39]  * arosales thinking about scenerio aside from discourse
[19:40] <arosales> ie when should the charm store not accept charms when upstram is moving to fast
[19:40] <marcoceppi> it's up to the maintainer at htat point
[19:40] <marcoceppi> I wouldn't halt a review because someone did that, I just don't have the time atm to keep up as a maintainer and truly offer a compelling charm experience with discourse + juju
[19:40] <arosales> and thats fair
[19:41] <arosales> it just sounded like jcastro was saying it was policy
[19:41] <jcastro> no, that was charm specific
[19:41] <jcastro> sorry, I didn't mean to imply that
[19:41] <jcastro> I mean, we could do the known-good-deploy thing, as soon as upstream does a release
[19:41] <jcastro> they don't even really roll tarballs yet
[19:42] <arosales> jcastro, gotcha. Thanks for clarifying.
[19:43] <jcastro> we could do known-good github snapshops but I am pretty sure upstream wouldn't like that
[19:43] <marcoceppi> about to roll out 0.4.0 of amulet with initial deployer support. Should have the rest of deployer integration ready by Thursday in time for next week
[19:43] <jcastro> they want you on tip right now, so that's why we kept it out of the store for now
[19:44] <arosales> marcoceppi, made it good point of it being up to the maintainer wanting a good juju story.  Specifically, marcoceppi could push discourse into the charm store but would have to heavily maintain it am.
[19:44] <arosales> s/am/atm
[19:46] <jcastro> marcoceppi: hey I think I found a problem in your ninja CSS thing for the docs
[19:46] <jcastro> go to http://juju.ubuntu.com/docs
[19:47] <jcastro> and check out the installation instructions
[19:47] <marcoceppi> I am checking them out
[19:47] <jcastro> then click on "getting started" to get to the actual page then the proper instructions show up
[19:47] <marcoceppi> wat.
[19:47] <marcoceppi> jcastro: OH
[19:47] <jcastro> yeah weird
[19:47] <marcoceppi> that's because there is two pages right now, index.html and getting-started.html
[19:47] <marcoceppi> I thought I commited a fix for that
[19:47]  * marcoceppi checks
[19:47] <jcastro> also did you see how I butchered the instructions
[19:47] <jcastro> 2 lines.
[19:48] <marcoceppi> jcastro: </3
[19:48] <arosales> jcastro, +1
[19:48] <marcoceppi> I hope you moved the update-alternatives somewhere else
[19:48] <jcastro> to where?
[19:48] <marcoceppi> people will ask, maybe a caveats section
[19:49] <jcastro> IS and m_3 know how to do it
[19:50] <jcastro> that covers everyone right?
[19:50] <marcoceppi> ROFL
[19:50] <jcastro> at this point if someone is like "I want local" we can say "wait a week"
[19:50] <marcoceppi> jcastro: pushed index.html fix, will be out next doc build
[19:50] <marcoceppi> "I was using 0.7 and installed juju-core NOW EVERYTHING IS BROKEN"
[19:51] <marcoceppi> maybe it'll be a better question to link in the install page from Ask Ubuntu
[19:51] <jcastro> I can add a link but to what?
[19:51] <marcoceppi> jcastro: put a link to AU in the docs
[19:51] <jcastro> If you used Juju .7 and install 1.x it doesn't change the update-alternatives anyway
[19:51] <jcastro> yeah to which question?
[19:51] <marcoceppi> jcastro: pretty sure it does?
[19:51] <marcoceppi> jcastro: make one?
[19:52] <marcoceppi> Oh, wait
[19:52] <marcoceppi> it's the other way around
[19:52] <marcoceppi> installing juju-core then installing juju pushes alternatives to 0.7 I think
[19:52] <marcoceppi> nvm
[19:52] <marcoceppi> w/e mims knows
[19:52] <jcastro> yep
[19:52]  * marcoceppi goes back to work
[19:52] <jcastro> and alternatives doesn't really work anyway
[19:52] <jcastro> either way you need different environments.yaml
[19:52] <jcastro> so I don't think people are like just flipping it back and forth
[19:53] <marcoceppi> jcastro: I've been flipping, but I have a different JUJU_HOME for juju-core, but yeah it's a much more advanced thing
[19:53] <marcoceppi> that will hopefully just go away soon
[19:53] <jcastro> yeah
[19:54] <jcastro> ok so how about I point to this
[19:54] <jcastro> http://askubuntu.com/questions/65359/how-do-i-configure-juju-for-local-usage
[19:56] <marcoceppi> jcastro: naw, I just wouldn't worry about it
[19:56] <marcoceppi> when local lands we'll just document it as a provider
[19:56] <jcastro> fixed it, a link won't hurt anybody