[00:43] <lazyPower> jose: you need to put it behind a proxy service, is the proper way to do it
[00:43] <lazyPower> eg: setup nginx to forward to the socket or localhost:port
[00:43] <lazyPower> whichever way you choose to setup the daemon
[00:44] <jose> cak
[00:44] <lazyPower> https://github.com/groovyobject/Ansible-Playbooks/blob/master/templates/nginx_site_proxy.j2
[00:44] <jose> ack*
[00:44] <jose> hmm
[00:44] <lazyPower> theres an nginx vhost that would reverse proxy to a port configured daemon. in this case, a node.js app for ghost
[00:44] <lazyPower> otherwise, you specify the proxy-pass to the full path of the socket file
[01:05] <lazyPower> jose: also since i didn't specify, thats in a jinja2 template format
[01:05] <lazyPower> the {{ }} is for variable substitution. You dont want to leave those behind. I bet you gathered that - but just in case.
[01:07] <jose> tahnk you :)
[01:07] <jose> I'm looking into that tomorrow, for sure
[01:07] <jose> lazyPower: did you get the tests to pass? because I got some weird clock
[02:39] <lazyPower> jose: that means it skipped
[02:39] <lazyPower> are you still running on free tier of AWS? you'll probably need to kick up the deployment wait time
[02:39] <lazyPower> if you're running on smalls, the 900 it waits by default should be plenty, and one of the tests failed. run it with the -v flag and you'll get more output to tell you why it gav eyou a skip
[02:43] <jose> lazyPower: I'm running on the free tier, under micros
[02:43] <lazyPower> yeah, you'll want to tune the timeout setting to something more reasonable
[02:43] <jose> 1200 is default
[02:44] <lazyPower> it was 900 last i checked. that my be set th 1200 and it still may not be long enough
[02:44] <lazyPower> if you dont get a response messag elike "Unable to connect to MySQL" then chances are it timed out during the d.deploy phase
[02:44] <lazyPower> you can test with the local provider to keep your cloud costs down if you comment out the NFS tests. and unit. thats the only one in the bunch that doesnt play well with LXC
[02:48] <jose> well, I don't use local as it takes forever to deploy :P
[02:48] <jose> my internet connection is still slow
[02:48] <jose> I can keep up with cloud, it's good for me
[13:51] <sebas_> Juju and the Drupal charm was just presented here at FISL 15, in Brasil :)
[14:10] <frankban> rbasak: ping re new quickstart release
[14:10] <rbasak> frankban: hi! I have looked at it, but haven't finished testing it yet. Had some issues with my test environment.
[14:11] <rbasak> frankban: I'm at a sprint this week, so I'm quite time limited. Sorry for the delay.
[14:12] <rbasak> One of the issues I have, BTW, is that on a loaded box, juju times out creating an lxc container template, even though it will finish in the end anyway
[14:12] <frankban> rbasak: no worries and thanks! so, as I mentioned yesterday, the revisions which should be included are revno 65, 66 and 67. Please feel free to ping me if you need any help
[14:13] <frankban> rbasak: uhm, timeout while creating the template never experienced that :-/
[14:15] <rbasak> I think it's an assumption that juju (not quickstart) is making about how long it should take to build the template container
[14:18] <alexpilotti> natefinch: hi!
[14:19] <natefinch> alexpilotti: howdy!
[14:19] <frankban> rbasak: OIC
[14:19] <alexpilotti> natefinch: good tx, frantically getting ready for Atlanta :-)
[14:19] <frankban> rbasak: so on slower machines it can timeout
[14:19] <frankban> rbasak: or on slower connections I guess
[14:20] <rbasak> frankban: right. WHere I'm testing, IO performance is poor because it's on a VM where the metal is shared by other tenants.
[14:20] <frankban> yeah
[14:32] <mhall119> marcoceppi: one of these days I'll remember how to fix this,until then I need your help again
[14:32] <mhall119> mhall@mhall-thinkpad:~$ juju status
[14:32] <mhall119> ERROR state/api: websocket.Dial wss://10.0.3.1:17070/: dial tcp 10.0.3.1:17070: connection refused
[14:32] <mhall119> after having to reboot
[14:33]  * mhall119 has a tomboy note open now to record the fix
[14:33] <jcastro> we really need to fix that
[14:33] <marcoceppi> mhall119: it's okay, if you remember how to fix this I'll not be needed anymore
[14:33] <marcoceppi> mhall119: initctl list | grep juju
[14:34] <mhall119> nothing listed
[14:34] <marcoceppi> mhall119: sorry
[14:34] <marcoceppi> mhall119: sudo initctl list | grep juju
[14:34] <mhall119> mhall@mhall-thinkpad:~$ sudo initctl list |grep juju
[14:34] <mhall119> juju-db-mhall-local stop/waiting
[14:34] <mhall119> juju-agent-mhall-local start/running, process 1064
[14:34] <marcoceppi> mhall119: sudo start juju-db-mhall-local
[14:35] <mhall119> mhall@mhall-thinkpad:~$ sudo start juju-db-mhall-local
[14:35] <mhall119> juju-db-mhall-local start/running, process 11371
[14:35] <mhall119> mhall@mhall-thinkpad:~$ sudo initctl list |grep juju
[14:35] <mhall119> juju-db-mhall-local stop/waiting
[14:35] <marcoceppi> mhall119: sudo service monogdb stop
[14:36] <marcoceppi> then start juju-db-mhall-local
[14:36] <mhall119> still goes back to stop/waiting
[14:36] <marcoceppi> mhall119: pastebin /var/log/upstart/juju-db-mhall-local.log
[14:37] <mhall119> marcoceppi: http://paste.ubuntu.com/7410772/
[14:38] <marcoceppi> mhall119: this was more than a reboot I'm guessing
[14:39] <mhall119> at 10am today I manually rebooted after updating my system, because hangouts weren't working
[14:39] <mhall119> a couple days ago my laptop powered itself off for no reason, I haven't tried accessing my juju env since then, so it may have been broken for a while
[14:41] <marcoceppi> mhall119: so there's a --repair flag for mongo (really just need to remove a lock file but I don't know where it is)
[14:41] <marcoceppi> mhall119: can you pastebin /etc/init/juju-db-mhall-local.conf
[14:42] <mhall119> http://paste.ubuntu.com/7410785/
[14:44] <mhall119> it was ~/.juju/local/db/mongod.lock
[14:44] <mhall119> removed that, re-ran sudo start juju-db-mhall-local and now I can `juju status`
[14:47] <marcoceppi> mhall119: awesome, good to know
[14:47] <marcoceppi> mhall119: thumper is working on a new `juju local` plugin that will make managing local environments way easier in the future
[14:47] <mhall119> I look forward to breaking it :)
[15:38] <whit> wwitzel3, you put up your pyramid charm somewhere yet?
[16:09] <jcastro> http://askubuntu.com/questions/462391/juju-bootstrap-node-cant-access-ubuntu-archives-via-maas
[16:09] <jcastro> anyone see this problem before?
[16:31] <tedg> lazyPower, So I got the ownCloud charm setup on docean. It works well.
[16:31] <tedg> lazyPower, How is the SSL bit going?
[16:31] <lazyPower> tedg: thats awesome!
[16:32] <lazyPower> tests are blocking the merge, but its incoming. Jose and I were having a bit of back and forth about it lastnight.
[16:32] <lazyPower> I expect it to land in the next couple of days
[16:32] <tedg> Cool, I didn't want to take it beyond playing with if there was no encryption.
[16:32] <lazyPower> Yeah - another thing to note
[16:33] <lazyPower> there's a server side encryption plugin - i *highly* recommend it
[16:33] <tedg> Oh, that's interesting.
[16:33] <tedg> BTW, I used DAVdroid on Android.
[16:33] <lazyPower> that way anything you put on your DO instance is encrypted as well. its more of a safeguard in case someone goes spelunking on your instance.
[16:33] <tedg> You still have to pay, but it's OSS>
[16:33] <lazyPower> nice! There's a disqus on my blog, would you mind dropping that int eh comment feed for future users that sumble across the post?
[16:34] <lazyPower> stupid template has a bug where disquss doesn't always load, you may have to reload the article to get it to show :(  I'll eventually get around to fixing that...
[16:34] <tedg> Ah, k
[16:35] <lazyPower> thanks for the feedback though tedg - Glad to hear it's helping someone.
[16:36] <tedg> Hmm, seems you can't post to Disqus with OpenID?
[17:06] <cory_fu> I'm trying to install cobzr from launchpad, and the instructions on http://labix.org/cobzr just say to do `go install launchpad.net/cobzr` but I get a "cannot find package" error.
[17:06] <cory_fu> I'm assuming there's a missing step in there (e.g., go get)?
[17:08] <cory_fu> Why do so many instructions involving go seem to be missing steps?  (`go get launchpad.net/cobzr ; go install launchpad.net/cobzr` worked)
[17:24] <themonk> how to restart a unit?
[17:30] <dpb1> hi marcoceppi: any chance we could kick #1259630 a bit now?  I think we would like it to move forward.
[17:30] <_mup_> Bug #1259630: add storage subordinate charm <landscape> <Juju Charms Collection:Fix Committed by davidpbritton> <https://launchpad.net/bugs/1259630>
[17:30] <marcoceppi> dpb1: it's on the list for this week
[17:31] <dpb1> marcoceppi: great, thanks!
[17:31] <marcoceppi> expect a proper review/response either tonight or tomorrow
[17:31] <dpb1> look forward it it. :0
[17:31] <dpb1> :)
[17:44] <themonk> marcoceppi: how do i restart a pending unit?
[17:46] <marcoceppi> themonk: what version of juju?
[17:57] <cory_fu> Man.  Adding bzr-pager, bzrtools (for cdiff), aliasing bzr diff -> bzr cdiff, and creating a ~/.colordiffrc makes bzr much nicer to work with
[18:01] <themonk> marcoceppi: juju version is 1.18.2-precise-amd64
[18:04] <themonk> marcoceppi: and why lxc local container deployment is too slow?
[18:09] <marcoceppi> themonk: odds are something is stuck during deployment
[18:09] <marcoceppi> themonk: which is why you see it in pending
[18:10] <marcoceppi> themonk: can you run `sudo lxc-ls --fancy` and report back what is listed?
[18:13] <themonk> marcoceppi: output is themonk-local-machine-1  RUNNING  10.0.3.113  -     YES
[18:17] <marcoceppi> themonk: no other machines listed?
[18:19] <themonk> marcoceppi: no
[19:07] <cory_fu> jose: You around?
[19:07] <jose> cory_fu: I am always around ;)
[19:07] <cory_fu> :)
[19:08] <cory_fu> I was wondering if you got my message last night regarding the tracks charm?  My IRC client sometimes tells me I'm connected when I'm not
[19:08] <jose> oh, the permissions one
[19:08] <jose> yeah, I did
[19:08] <jose> and ports <=1024 are root only, that one too
[19:09] <cory_fu> Yeah, so I don't think it will be feasible to use setcap, so I think our only choice is to just run it as root
[19:09] <cory_fu> :-/
[19:10] <jose> hey, what we can do is if the port is <1025, then run it as root
[19:10] <jose> and if port is >1023, run as tracks user
[19:11] <jose> adding a note to the README, of course
[19:11] <cory_fu> Yeah, that's a possibility, though it complicates the hooks.  Keep in mind that we need to handle the case of the user changing the port (i.e., we'll have to update the tracksapp.conf file in the config-changed hook)
[19:11] <jose> it actually does
[19:12] <jose> I think I can write this up while these owncloud tests are running
[19:12] <cory_fu> Well, it changes the port in the conf file, but we'd also have to add / remove the setuid line
[19:13] <cory_fu> Just another sed line, I suppose.  :)
[19:13] <jose> yep!
[19:13] <cory_fu> Awesome.  Well, I have to step away for a few minutes, but if there's anything I can do to help, let me know.
[19:14] <jose> sure thing
[19:14] <jose> I'll work on this and let you know when I have any results
[19:15] <cory_fu> Thanks!  :)
[19:20] <lazyPower> cory_fu: jose - please dont run the service as root
[19:20] <lazyPower> a) its against CS guidelines, and b) its a huge security hole
[19:20] <jose> lazyPower: then the quick workaround for me would be to only run it if port is >1024
[19:20] <jose> will do that
[19:21] <lazyPower> that's a far better option.
[19:22] <lazyPower> jose: i'd also mark that in the readme - that the service is intended to be run at scale - so if you want port 80, deploy it behind a reverse proxy.
[19:22] <jose> mhm, will do
[19:22] <lazyPower> you can co-locate the service, if the end user is concerned about machine consumption
[19:22] <jose> at this point the readme is *pretty* lightweight
[19:43] <astark> Hello.  I am trying to get around the fact that Maas / Juju do not seem to work well with i386 hardware.  I tried 'juju bootstrap --constraints arch=i386', but I get a response that suggests the only valid value is amd64.  Does anyone have any ideas?  Thanks.
[19:45] <jose> hey guys, has anyone seen this error while testing before? http://paste.ubuntu.com/7412268/
[19:46] <lazyPower> astark: i'm assuming this is in realtion to ensuring you're getting a 32bit machine?
[19:46] <lazyPower> *relation
[19:47] <lazyPower> jose: your test timed out during the deployment
[19:47] <jose> and I gave it 25 minutes!
[19:47] <lazyPower> well thats fun
[19:48] <lazyPower> maybe that's not what happened, but thats what it leads me to believe
[19:48] <lazyPower> marcoceppi: ^ amulet's being finicky it looks like. Any idea? 25 minutes is long enough to setup pretty much anything....
[19:49] <jose> I'm running it again just in case
[19:51] <astark> lazyPower:  I have about 9 boxes.  4 are amd64, the others are i386.  Maas knows the difference.  When I goto do a normal bootstrap, if it targets a 32 bit machine the bootstrap fails (due to always downloading amd64 juju tools), but if it picks a 64 bit machine bootstrapping happens successfully.  I then goto deploy openstack, and when deploying the services only the 64 machines ever move from 'pending' to 'started'.  I was trying initially with
[19:51] <astark>  1.18 and have been trying 1.19.1 with no success either.
[20:05] <jose> this time it showed the same signs after 2014-05-07 15:03:36  Adding relation relation-sentry:provides-owncloud_shared-fs-nfs_nfs <-> nfs:nfs
[20:07] <jose> oh and just gave the same errors I thinik
[20:14] <marcoceppi> jose: use --set-e and when it's done run juju status
[20:14] <jose> marcoceppi: like 'charm test -e ec2 tests/100-deploy --set-e'?
[20:15] <marcoceppi> that looks good
[20:15] <jose> ok
[20:16] <jose> running again
[20:29] <jose> it's been stuck in 2014-05-07 15:21:16 Config specifies num units for subordinate: owncloud-sentry for around 8m
[20:39] <marcoceppi> jose: it's going to time out
[20:39] <marcoceppi> jose: I think that one or more of your aws machines aren't being turned on
[20:39] <marcoceppi> provisioning errors, etc
[20:39] <jose> it did timeout
[20:40] <jose> oh, oh, deployment did complete
[20:40] <jose> but I have another error, let me pastebin
[20:40] <jose> http://paste.ubuntu.com/7412525/
[20:41] <jose> for some weird reason it's not able to connect to the machine
[20:55] <lazyPower> jose: is the service exposed?
[20:55] <jose> yes, it exposes both owncloud and haproxy
[20:56] <lazyPower> hmmm
[21:00] <lazyPower> I'm not sure man :(
[21:00] <lazyPower> it looks like its attempting to connect over ssl though
[21:00] <lazyPower> is port 443 active? run it with a --set-e flag so it doesn't tear down the env and you can poke around in it
[21:01] <lazyPower> also, ensure open-port 443 happens in the hook code when you enable ssl, otehrwise it wont open the port in the AWS security group.
[21:01] <lazyPower> which would explain why it cannot connect...
[21:03] <jose> oh, I did run it with that
[21:03] <jose> port 443 *should* be active
[21:03] <jose> yes, owncloud has 443 and 80 open
[21:03] <jose> haproxy, though, only has 80
[21:04] <jose> which *may* explain the error
[21:04] <jose> nope, it isn't that, because it's trying to connect to the owncloud address with a failure
[21:08] <lazyPower> Do you have a d.sentry.wait?
[21:10]  * jose checks
[21:11] <jose> I do not
[21:11] <jose> added; destroying env and rerunning
[21:34] <mhall119> jcastro: marcoceppi: ok guys, I have a charm that I want to submit to the charm store....what do I do?
[21:34] <marcoceppi> mhall119:
[21:35] <jcastro> https://juju.ubuntu.com/docs/authors-charm-store.html#submitting-a-new-charm
[21:35] <marcoceppi> https://juju.ubuntu.com/docs/authors-charm-store.html#submitting-a-new-charm
[21:35] <marcoceppi> dangit
[21:35] <jcastro> :)
[21:35] <mhall119> hah, jcastro wins
[21:35] <thumper> mhall119: oh hai
[21:35] <mhall119> hey thumper
[21:35] <thumper> mhall119: wanted to talk to you about deploying django apps with juju
[21:35] <thumper> mhall119: marcoceppi said you were the person to talk to
[21:35] <thumper> mhall119: my app is not open source (personal startup project)
[21:36] <thumper> mhall119: how do I get the app payload into the charm?
[21:37] <mhall119> marcoceppi: I've become "the person to talk to" about deploying django?
[21:37] <mhall119> that's not a good sign :)
[21:37] <mhall119> thumper: my django charms pull from bzr on launchpad
[21:37] <marcoceppi> mhall119: you're the only person I could think that does django stuff :)
[21:37] <thumper> mhall119: it is a great sign
[21:37] <mhall119> thumper: alternately you can put the files (or a tarball of the files) into your charm's ./files/ directory
[21:37]  * thumper sighs...
[21:38] <thumper> mhall119: this whole tarball thing is one thing I'm fixing this cycle
[21:38] <mhall119> alternately, you can put your files into cloud storage and configure your charm to pull from there
[21:38] <thumper> luckily text compresses well, right?
[21:38] <mhall119> I suppose
[21:38] <mhall119> thumper: easiest thing to do is to stop hating freedom so much and open source your code :-P
[21:39] <thumper> mhall119: haha
[21:39] <thumper> I don't hate freedom
[21:39] <thumper> I'm free to try and make some money :)
[21:39] <mhall119> thumper: I can help you with gunicorn, swift and a CDN though ;)
[21:40] <mhall119> thumper: http://paste.ubuntu.com/7412775/ is my current test deployment
[21:41] <thumper> mhall119: what is go-pronto?
[21:41] <marcoceppi> thumper: maybe a subordainte charm that you don't release that has your ssh keys for pulling the source of your app that can plop it in the right place on the django charm/service?
[21:41] <mhall119> thumper: a new swift-backed CDN from bigkevmcd
[21:42] <mhall119> marcoceppi: is it possible to make a subordinate charm our of a django app?
[21:42] <thumper> marcoceppi: yeah, I've been thinking about the subordinate option
[21:42] <thumper> mhall119: why not?
[21:42] <thumper> I may poke around
[21:42] <mhall119> thumper: because I don't know enough juju
[21:42] <thumper> might need to make a config option in the main charm
[21:42] <thumper> so it doesn't try to deploy without the subordinate
[21:43] <mhall119> right now summit-website's charm is coded to setup swiftstorage, but having it a subordinate that you can add or not would make it more flexible
[21:43] <marcoceppi> mhall119: subordinates are like the glue and string that turn deployments from piles of rocks, to a mcguyver helicopter
[21:43] <thumper> marcoceppi: haha, classic
[21:44] <mhall119> so...maybe I'll wait on making that subordinate
[21:44] <thumper> marcoceppi: do we have docs on deploying local charms?
[21:44] <mhall119> charm proof tells me that my charm isn't ready to submit yet :(
[21:44] <mhall119> back to work I go
[21:44] <marcoceppi> thumper: we shure as hell should
[21:45] <marcoceppi> https://juju.ubuntu.com/docs/charms-deploying.html#deploying-from-a-local-repository
[21:45] <thumper> ta
[21:46] <marcoceppi> haha shure, it's that time of the day when I need to just log off
[21:46] <thumper> marcoceppi: hmm... that doesn't actually tell the user what the local directory structure should look like
[21:46] <mhall119> marcoceppi: what category should a CDN service fall under?
[21:46] <marcoceppi> thumper: pull requests welcome, we cover it somewhere else in the doc now that I think about
[21:46] <marcoceppi> it
[21:46] <marcoceppi> mhall119: eh, we only have like 6
[21:46] <mhall119> marcoceppi: I have file-servers currently, but I don't konw if that's right
[21:47] <marcoceppi> misc or applications probably
[21:47] <marcoceppi> mhall119: that works
[21:47] <mhall119> does it?
[21:47] <marcoceppi> doesn't it?
[21:47] <marcoceppi> question aside, categories are arbitrary
[21:47] <marcoceppi> you could put it in both
[21:47] <marcoceppi> misc and file-servers
[21:47] <mhall119> ok
[21:49] <thumper> evilnickveitch: ping
[21:50] <thumper> evilnickveitch: docs on local repository structure?
[21:50] <jose> marcoceppi: I have got exceptions while running the tests but no results yet, that is normal and I should wait, right?
[21:51] <jose> I got the exception of a exception of a exception
[21:58] <thumper> rick_h_: help
[21:59] <thumper> rick_h_: can you deploy a local charm from the gui?
[21:59] <mhall119> submitted my first charm! https://bugs.launchpad.net/charms/+bug/1317281
[21:59] <_mup_> Bug #1317281: New Charm: go-pronto <Juju Charms Collection:New> <https://launchpad.net/bugs/1317281>
[22:04] <jose> wohoo, congratulations mhall119!
[22:04] <marcoceppi> thumper: you can drag and drop a tarbal
[22:04] <marcoceppi> of a charm
[22:04] <jose> mhall119: I think that for a charm to be on trusty it needs to have tests... not 100% sure though
[22:05] <thumper> marcoceppi: oh.. ok...
[22:10] <jose> mhall119: and as I mentioned earlier, the details with the README:
[22:10] <rick_h_> thumper: huh?
[22:10] <rick_h_> thumper: drag/drop it on the canvas
[22:10] <thumper> rick_h_: does it handle zip files?
[22:10] <thumper> or just tarballs
[22:10] <jose> README has to be in Markdown and Contact Information is for the charm *and* upstream
[22:10] <rick_h_> thumper: just zips
[22:11] <thumper> oh, so just zip files
[22:11] <thumper> hmm..
[22:11] <rick_h_> thumper: yep, it's what juju upload supports. Does juju take tarballs?
[22:12] <mhall119> jose: what details were those again?
[22:12] <mhall119> also, how do you write tests for a charm?
[22:12] <jose> mhall119: <jose> README has to be in Markdown and Contact Information is for the charm *and* upstream
[22:12] <jose> `charm add tests` provides an autogenerated test suite
[22:12] <jose> they're written in python3 with the help of amulet
[22:12] <jose> https://juju.ubuntu.com/docs/tools-amulet.html has more info
[22:13] <mhall119> man, this is what happens, you let jcastro on your team and suddently *everything* has to be in Markdown
[22:13] <jose> haha
[22:14] <mhall119> jose: $ charm add tests
[22:14] <mhall119> Error: add is not a valid subcommand
[22:14] <marcoceppi> jose: mhall119 readme doesn't HAVE to be in Markdown, it just renders better when it is
[22:14] <marcoceppi> also, tests are still optional and may be changing in the future
[22:14] <marcoceppi> mhall119: install charm-tools from ppa:juju/stable
[22:14] <mhall119> why wasn't the README created for me in Markdown?
[22:14] <marcoceppi> the one in trusty is super outdated
[22:14] <mhall119> marcoceppi: trusty is 2 weeks old!
[22:14] <marcoceppi> mhall119: you're using anchinent version of charm-tools
[22:15] <marcoceppi> mhall119: it hasn't been sync'd since precise
[22:15] <mhall119> 2 weeks!
[22:15] <marcoceppi> mhall119: I missed the update window
[22:15] <mhall119> why not?
[22:15]  * jose proposes 100 charms for trusty
[22:15] <marcoceppi> jose: we don't have 100 charms with tests
[22:16] <jose> didn't you say tests are still optional?
[22:16] <mhall119> he said Markdown was optional
[22:16] <mhall119> oh, tests too
[22:16] <mhall119> missed that
[22:16] <marcoceppi> jose: not for trusty
[22:16] <jose> he was proposing for trusty, that's why I mentioned tests
[22:16] <marcoceppi> jose: but we're reworking what it means to be a charm test
[22:16] <jose> cool
[22:16] <marcoceppi> mhall119: so if you have unit tets for your charm, you're golden
[22:17] <mhall119> not much to test....
[22:17] <jose> on the other hand, azure is not behaving correctly and my test is stuck
[22:17]  * marcoceppi looks at the charm
[22:17] <marcoceppi> ooooo a bash charm
[22:17]  * jose loves bash charms
[22:18] <marcoceppi> heh, mhall119, I see what you mean
[22:19] <mhall119> marcoceppi: my summit charm will have more
[22:19] <marcoceppi> So, I'll review the charm, but there's a potential problem with it, it's going to be impossible to test with amulet because not all clouds provide swift, etc
[22:19] <marcoceppi> mhall119: sweet, I eagerly await that one
[22:19] <marcoceppi> don't ge me wrong, this is awesome
[22:20] <mhall119> ah, is that what amulet is used for? testing on different clouds?
[22:21] <mhall119> marcoceppi: you can *technically* run it in a cloud that doesn't use swift....as long as you point it to a cloud that does :)
[22:21] <mhall119> I'm running it on LXC, pointing to canonistack's swift
[22:22] <marcoceppi> mhall119: /sure/ but that means hard coding swift creds in to a test
[22:22] <mhall119> I'm guessing that's frowned upon
[22:22] <marcoceppi> mhall119: yeah, amulet and "charm tests" as they stand today are designed to do integration testing on charms and we run those across all our providers
[22:22] <marcoceppi> mhall119: typically
[22:22] <mhall119> ok, so do I need tests or will they just be pointless for this?
[22:22] <marcoceppi> it's not a blocker for the store, we'll do the review like normal and give you feedback
[22:23] <marcoceppi> we've never formalized charm tests being required, we've strongly recommended them for trusty but like I mentioned earlier the concept of what is a charm test may change int he near future
[22:23] <mhall119> I guess I should make swiftstorage a subordinate then, so I can submit summit-website charm to the store
[22:24] <marcoceppi> mhall119: is swiftstorage different than go-pronto?
[22:24] <evilnickveitch> thumper, it is covered in https://juju.ubuntu.com/docs/authors-charm-writing.html, but it would be good to add to the deploy page too. I am thinking of adding a whole page about local charms actually, to cover fetching them too
[22:26] <mhall119> marcoceppi: yes
[22:26] <mhall119> swiftstorage is a Django app that makes it use swift for static files and uploaded media, rather that local files
[22:29] <marcoceppi> mhall119: ah, gotchya
[22:33] <jose> whoops, just on the 7th day of the month and already exceeded my free 2mil I/O requests for ec2 :P