=== zz_CyberJacob is now known as CyberJacob === CyberJacob is now known as zz_CyberJacob === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [09:35] Spads: http://big-data-charm-helpers.readthedocs.org/en/latest/examples/framework.html === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === zz_CyberJacob is now known as CyberJacob === kadams54 is now known as kadams54-away [11:20] can juju bundle use "charm: 'local:....'"? Cause bundle proof does not recognize it [11:23] marcoceppi_: ^^ [11:24] apuimedo: not charm: local, but branch: will work, and I think local: may work as well [11:24] oh good [11:24] let me check [11:26] local: makes the proofer through an error (just like branch: does ) [11:26] I think the proofer supports charm: [11:27] since it fails with KeyError: 'charm' [11:30] can you post your whole bundle [11:30] you can't use local for charm-store bundles, just for local bundles [12:07] marcoceppi_: it's a local bundle atm [12:34] apuimedo: if this is just for testing/deployment, thats not an issue. When you go for charm store promulgation you'll want to refactor out the local: and plug in cs:series/service-revision [12:34] indeed ;-) [12:35] lazyPower: One thing that should be done is to find some way to document the protocols [12:35] for the openstack services it could be quite useful [12:35] when you say protocols you mean the relationship interfaces? [12:35] not when it's simple setting or getting [12:35] interface protocols, yes [12:35] We started doing that in our charm readmes/doc sites [12:36] but when it's two-or-more steps [12:36] http://chuckbutler.github.io/docker-charm/user/configuration.html [12:37] i've adopted the pattern of: sends variables (or data) / receives variables (or data) - i need to normalize that nomenclature, but its handy to have as a reference. [12:37] I was trying to think of something that could present the information of complicated services [12:37] but the best I could come up with was flow charts [12:37] you know, i did that with the DNS charm as well [12:37] specially when there are config variables involved [12:37] https://github.com/chuckbutler/DNS-Charm/tree/master/docs [12:38] but yeah - i understand what you're getting at. this is somethin gi've been noodling/experimenting with since i started [12:38] i feel our current "grep the source" model is for the birds. [12:38] we were talking about doing code analysis to scan the relationships and update a listing somewhere. I still might do this, and any charms that dont make it through the lexer are manually parsed [12:38] lazyPower: those are cool graphs :-) [12:39] draw.io - i can take no credit :) [12:39] :-) [12:40] that looks easier than my graphviz approach [13:05] nice work lazyPower :) [13:06] thanks schkovich === psivaa-afk is now known as psivaa [13:52] marcoceppi_, lazyPower, mbruzek: I won't be able to join you for the Juju Office Hours this time, I'll be in class [13:52] OK. [13:53] Study hard! [13:53] Or Pay attention! [13:53] :P [13:53] sure, sure... === bladernr_ is now known as bladernr-lex [14:47] Is it safe to assume that JUJU_ENV_NAME will be always set? === kadams54_ is now known as kadams54-away === scuttle|afk is now known as scuttlemonkey [15:04] cmars: http://big-data-charm-helpers.readthedocs.org/en/latest/ [15:04] cmars: lp:~bigdata-dev/charm-helpers/framework [15:30] schkovich: so long as you're in a hook context, yes [15:52] Juju - Can't access juju charm store | http://askubuntu.com/q/608792 === kadams54 is now known as kadams54-away === brandon is now known as Guest36694 [18:25] is there a good mail server charm? [18:25] There is a postfix charm Guest36694 [18:26] admittedly i have limited interaction with it [18:26] https://jujucharms.com/postfix/precise/2 [18:28] Hi [18:28] hmm. looked for it. jujucharms.com search doesn't return anything for 'postfix' or 'mail' [18:29] do we need to install juju as root? [18:29] using root login [18:30] Guest36694: that link should have shown the postfix charm in teh store [18:30] VijayT_: you do not, juju is happy running as a user. if it requiers elevated privs it will prompt you for a sudo password [18:30] I see it. just letting you know. [18:30] it will return if I separate 'post fix' [18:30] interesting, i searched for postfix. I think they are in the middle of a deployment [18:31] I'll follow up with our webops/ui engineering team however, thanks for the heads up Guest36694 [18:32] thanks lazypower === Guest36694 is now known as web [21:27] How does one prevent juju-deployer from giving identical iSCSI initiator names to hosts? [23:23] msbrown: thats a very specific question, and i'm not sure i have an answer. That might be worthwhile to ping the list [23:24] msbrown: juju@lists.ubuntu.com - there's a sprint going on with the juju teams so they are mostly in EU timezones right now [23:27] lazyPower: I don't suppose you got a chance to look at my questions about the quassel-core amulet tests? :-) [23:28] blahdeblah: i have not, but i can take a look [23:28] lazyPower: I don't think I put them in the MP; I pinged you a few days ago in canonical #juju [23:28] https://bugs.launchpad.net/charms/+bug/999439 > [23:28] Bug #999439: Need charm for quassel-core [23:28] oh [23:28] lazyPower: I can find them again if needed [23:28] that would be brilliant if you dont mind [23:30] lazyPower: The main question is why the deployment setup has to be a class method instead of an instance method, since this seems to prevent running of multiple deployments from the same test. [23:33] when issued through bundletester I was getting weird side effects from the deployment, and this is a byproduct of using instance methods. Converting it to a class kept the deployment on point in the test - but its a worthwhile discussion to bring up on the list to see if we can mod the testing tools to support both. [23:33] Now that I know how to access class methods & variables in python, this is less of a big deal than it was. ;-) [23:33] While it works in some cases, i've run into cases where it just flat out side-effects the test into working once, then failing on the next run :| [23:34] i wish i had a better answer, but i can describe the effect vs the fix - this was actually suggested by mbruzek to me about 3 weeks ago when i ran into the issue [23:34] OK [23:34] Next Q: is there a good way to tighten the test loop, preferably by running locally somehow? It's a bit frustrating having to wait for hours/days to see the test results, only to find it's some stupid by-product of my python inexperience. [23:35] surely, you can kick off the test against the local provider using bundletester. my preferred method is bundletester -F -l DEBUG -v -e local - you can use any substrate vs CI [23:36] standing up quassel + Mysql should be fairly quick on the local provider [23:36] Any doc on the setup required? [23:37] https://github.com/juju-solutions/bundletester [23:37] ta [23:38] np :) [23:38] if you need further clarification on the testing loop with charms, I have a session coming up this week with an ISV [23:38] and i see about adding you to it if they are OK with having a third party sit in [23:39] lazyPower: That would be great; I'm in UTC+10, though, so don't make it a big deal if timing is an issue. [23:39] Its friday 11-12pm EDT [23:39] thanks again, lazyPower [23:39] np blahdeblah, happy to help. [23:40] I'll ship an email over to the team and circle back if you're still interested @ the time difference. [23:40] s/@/with/ [23:40] thanks [23:40] what's the UTC offset of EDT? [23:41] 5 hours [23:41] UTC Offset: UTC -4:00 [23:42] forgot, UTC doesn't observe DST [23:42] That's kinda the whole point of UTC. ;-) [23:42] its been a long day :D [23:42] :-) [23:43] That time would probably work reasonable well for me [23:43] thanks [23:43] np, i'll ping once i've got confirmation