[09:35] <cory_fu> Spads: http://big-data-charm-helpers.readthedocs.org/en/latest/examples/framework.html
[11:20] <apuimedo> can juju bundle use "charm: 'local:....'"? Cause bundle proof does not recognize it
[11:23] <apuimedo> marcoceppi_: ^^
[11:24] <marcoceppi_> apuimedo: not charm: local, but branch: <bzr branch> will work, and I think local: may work as well
[11:24] <apuimedo> oh good
[11:24] <apuimedo> let me check
[11:26] <apuimedo> local: makes the proofer through an error (just like branch: does )
[11:26] <apuimedo> I think the proofer supports charm:
[11:27] <apuimedo> since it fails with KeyError: 'charm'
[11:30] <marcoceppi_> can you post your whole bundle
[11:30] <marcoceppi_> you can't use local for charm-store bundles, just for local bundles
[12:07] <apuimedo> marcoceppi_: it's a local bundle atm
[12:34] <lazyPower> 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] <apuimedo> indeed ;-)
[12:35] <apuimedo> lazyPower: One thing that should be done is to find some way to document the protocols
[12:35] <apuimedo> for the openstack services it could be quite useful
[12:35] <lazyPower> when you say protocols you mean the relationship interfaces?
[12:35] <apuimedo> not when it's simple setting or getting
[12:35] <apuimedo> interface protocols, yes
[12:35] <lazyPower> We started doing that in our charm readmes/doc sites
[12:36] <apuimedo> but when it's two-or-more steps
[12:36] <lazyPower> http://chuckbutler.github.io/docker-charm/user/configuration.html
[12:37] <lazyPower> 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] <apuimedo> I was trying to think of something that could present the information of complicated services
[12:37] <apuimedo> but the best I could come up with was flow charts
[12:37] <lazyPower> you know, i did that with the DNS charm as well
[12:37] <apuimedo> specially when there are config variables involved
[12:37] <lazyPower> https://github.com/chuckbutler/DNS-Charm/tree/master/docs
[12:38] <lazyPower> but yeah - i understand what you're getting at. this is somethin gi've been noodling/experimenting with since i started
[12:38] <lazyPower> i feel our current "grep the source" model is for the birds.
[12:38] <lazyPower> 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] <apuimedo> lazyPower: those are cool graphs :-)
[12:39] <lazyPower> draw.io - i can take no credit :)
[12:39] <apuimedo> :-)
[12:40] <apuimedo> that looks easier than my graphviz approach
[13:05] <schkovich> nice work lazyPower :)
[13:06] <lazyPower> thanks schkovich
[13:52] <jose> 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] <mbruzek> OK.
[13:53] <mbruzek> Study hard!
[13:53] <mbruzek> Or Pay attention!
[13:53] <jose> :P
[13:53] <jose> sure, sure...
[14:47] <schkovich> Is it safe to assume that JUJU_ENV_NAME will be always set?
[15:04] <cory_fu> cmars: http://big-data-charm-helpers.readthedocs.org/en/latest/
[15:04] <cory_fu> cmars: lp:~bigdata-dev/charm-helpers/framework
[15:30] <marcoceppi_> schkovich: so long as you're in a hook context, yes
[15:52] <AskUbuntu> Juju - Can't access juju charm store | http://askubuntu.com/q/608792
[18:25] <Guest36694> is there a good mail server charm?
[18:25] <lazyPower> There is a postfix charm Guest36694
[18:26] <lazyPower> admittedly i have limited interaction with it
[18:26] <lazyPower> https://jujucharms.com/postfix/precise/2
[18:28] <VijayT_> Hi
[18:28] <Guest36694> hmm. looked for it.  jujucharms.com search doesn't return anything for 'postfix' or 'mail'
[18:29] <VijayT_> do we need to install juju as root?
[18:29] <VijayT_> using root login
[18:30] <lazyPower> Guest36694: that link should have shown the postfix charm in teh store
[18:30] <lazyPower> 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] <Guest36694> I see it.  just letting you know.
[18:30] <Guest36694> it will return if I separate 'post fix'
[18:30] <lazyPower> interesting, i searched for postfix. I think they are in the middle of a deployment
[18:31] <lazyPower> I'll follow up with our webops/ui engineering team however, thanks for the heads up Guest36694
[18:32] <VijayT_> thanks lazypower
[21:27] <msbrown> How does one prevent juju-deployer from giving identical iSCSI initiator names to hosts?
[23:23] <lazyPower> 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] <lazyPower> 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] <blahdeblah> lazyPower: I don't suppose you got a chance to look at my questions about the quassel-core amulet tests? :-)
[23:28] <lazyPower> blahdeblah: i have not, but i can take a look
[23:28] <blahdeblah> lazyPower: I don't think I put them in the MP; I pinged you a few days ago in canonical #juju
[23:28] <lazyPower> https://bugs.launchpad.net/charms/+bug/999439 >
[23:28] <mup> Bug #999439: Need charm for quassel-core <new-charm> <Juju Charms Collection:Fix Committed by paulgear> <https://launchpad.net/bugs/999439>
[23:28] <lazyPower> oh
[23:28] <blahdeblah> lazyPower: I can find them again if needed
[23:28] <lazyPower> that would be brilliant if you dont mind
[23:30] <blahdeblah> 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] <lazyPower> 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] <blahdeblah> Now that I know how to access class methods & variables in python, this is less of a big deal than it was. ;-)
[23:33] <lazyPower> 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] <lazyPower> 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] <blahdeblah> OK
[23:34] <blahdeblah> 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] <lazyPower> 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] <lazyPower> standing up quassel + Mysql should be fairly quick on the local provider
[23:36] <blahdeblah> Any doc on the setup required?
[23:37] <lazyPower> https://github.com/juju-solutions/bundletester
[23:37] <blahdeblah> ta
[23:38] <lazyPower> np :)
[23:38] <lazyPower> if you need further clarification on the testing loop with charms, I have a session coming up this week with an ISV
[23:38] <lazyPower> and i see about adding you to it if they are OK with having a third party sit in
[23:39] <blahdeblah> 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] <lazyPower> Its friday 11-12pm EDT
[23:39] <blahdeblah> thanks again, lazyPower
[23:39] <lazyPower> np blahdeblah, happy to help.
[23:40] <lazyPower> I'll ship an email over to the team and circle back if you're still interested @ the time difference.
[23:40] <lazyPower> s/@/with/
[23:40] <blahdeblah> thanks
[23:40] <blahdeblah> what's the UTC offset of EDT?
[23:41] <lazyPower> 5 hours
[23:41] <lazyPower> UTC Offset: UTC -4:00
[23:42] <lazyPower> forgot, UTC doesn't observe DST
[23:42] <blahdeblah> That's kinda the whole point of UTC. ;-)
[23:42] <lazyPower> its been a long day :D
[23:42] <blahdeblah> :-)
[23:43] <blahdeblah> That time would probably work reasonable well for me
[23:43] <blahdeblah> thanks
[23:43] <lazyPower> np, i'll ping once i've got confirmation