[02:40] <jose> guys, is it fine if a non-charmer reviews a charm pointing some errors? I'd like to do some review when I have some time
[02:41] <davecheney> jose: yes, absolutely
[02:41] <davecheney> many hands make light work
[02:41] <jose> cool, thanks! :)
[12:53] <cory_fu> Good morning, all.
[12:59] <tvansteenburgh> morning cory_fu
[13:37] <mbruzek> We have a system that juju status tells us that 2 system's agent state is "down"
[13:37] <mbruzek> Is there a way to restart the juju agents on a system?
[13:54] <lazyPower> mbruzek: upstart should handle restarting the juju-agent
[13:55] <lazyPower> I've brought several machines up and down this weekend that are manually provisioned. There is an upstart task for resuming operation -- i dont know if they fail out if the bootstrap node is unavailable... i didn't look that closely at it.
[13:55] <mbruzek> lazyPower, juju status shows 2 agents down, so presumably the upstart is not working.  Can we manually restart them?
[13:56] <lazyPower> should be able to just call the service back up. let me remote into a jujub ox and peek at /etc/init
[13:56] <lazyPower> mbruzek: jujud-machine-1.conf exists
[13:56] <lazyPower> that should be the agent. so service jujud-machine-# restart should fix it
[14:02] <tvansteenburgh> lazyPower: ever seen this error:
[14:02] <tvansteenburgh> ERROR state/api: websocket.Dial wss://10.0.3.1:17070/: x509: certificate signed by unknown authority...
[14:02] <tvansteenburgh> http://pastebin.ubuntu.com/7216718/
[14:02] <lazyPower> Yeah, it was bootstrapped by another workstation and your client is bugging out over the ssl signature
[14:03] <lazyPower> this is why we actively suggest jumpstations for working on remote systems as a team presently
[14:03] <tvansteenburgh> i don't see how that's possible, this is local
[14:04] <lazyPower> did you wipe your juju config between bootstrap and now?
[14:04] <lazyPower> those are the only 2 cases where i've seen that.
[14:04] <tvansteenburgh> you mean environments.yaml?
[14:04] <lazyPower> nah, i mean the jenv stuff
[14:04] <tvansteenburgh> i don't even know where that is
[14:05] <tvansteenburgh> so i don't think i deleted it
[14:05] <tvansteenburgh> any way to work around this?
[14:05] <marcoceppi> tvansteenburgh: it's in ~/.juju/environments
[14:05] <marcoceppi> tvansteenburgh: you have to tear down and start again
[14:05] <lazyPower> ^
[14:05] <tvansteenburgh> if i force destroy the env then rebootstrap, i get this error running juju status
[14:05] <marcoceppi> tvansteenburgh: that's, interesting
[14:06] <tvansteenburgh> i seem to do all sorts of interesting things
[14:06] <marcoceppi> tvansteenburgh: destroy again
[14:07] <marcoceppi> rm -f ~/.juju/environments/local.jenv
[14:07] <marcoceppi> try again
[14:08] <tvansteenburgh> after destroying, there's nothing in ~/.juju/environments
[14:10] <tvansteenburgh> the full error is:
[14:10] <tvansteenburgh> ERROR state/api: websocket.Dial wss://10.0.3.1:17070/: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "juju-generated CA for environment \"local\"")
[14:10] <tvansteenburgh> filed a bug on it this morning but i'm really just looking for a way to get passed it now
[14:11] <marcoceppi> tvansteenburgh: destroy, again, run bootstrap with --debug flag
[14:11] <marcoceppi> paste output
[14:13] <tvansteenburgh> marcoceppi: http://pastebin.ubuntu.com/7217166/
[14:13] <tvansteenburgh> uhhh
[14:13] <tvansteenburgh> and now juju status works fine
[14:13] <marcoceppi> you're welcome \o/
[14:13] <marcoceppi> ;)
[14:14] <tvansteenburgh> \o/
[14:15] <lazyPower> bonus
[14:16] <overm1nd> hi marcoceppi, do you have any plan to update the wordpress charm?
[14:17] <marcoceppi> overm1nd: I've had plans to update that charm for over a year
[14:17] <marcoceppi> overm1nd: it's the time I don't have, did you want something done?
[14:17] <overm1nd> ahaha I can feel the pain
[14:17] <overm1nd> I was interested in multisite support
[14:17] <marcoceppi> overm1nd: yeah, I have a plan for that, which would work nicely with juju
[14:18] <marcoceppi> overm1nd: I may try to attack it this weekend, unless you wanted to give it a go
[14:18] <overm1nd> I tried but it feels too complex for me
[14:19] <overm1nd> I also tried to start a new charm but I can get the sourse form charm get command
[14:19] <overm1nd> from*
[14:19] <overm1nd> I know I don't need it but something is vroken in my env I need to look at it
[14:19] <overm1nd> to tell the true I'm also evaluating puppets and ansible
[14:23] <webbrandon> any of you ever ran into these when mining: http://paste.ubuntu.com/7217201/ ?  I just started a priate network server and all my miners get that, trying to think of why?
[14:24] <webbrandon> oops wrong chat
[14:30] <smoser> hazmat, responding to a friday ping now. you still need anything?
[14:30] <hazmat> smoser, mr wolf was calling in reinforcements at the time, i think its all clear atm.
[14:31] <smoser> well, yeah.
[14:32] <hazmat> smoser, how was the game?
[14:39] <smoser> game was cold (very strong gusts of wind, ~40 degrees F and ~30F with windchill). and cubs lost. but i was at wrigley field for opening day, so that part was awesome.
[14:54] <nessita> hello everyone, I'm having an issue with juju deploy that is showing up since I updated juju-core to 1.18. Error is: "only charm store charm references are supported, with cs: schema" when deploying the solr-jetty charm
[14:54] <nessita> more debug output in https://pastebin.canonical.com/107885/
[14:54] <nessita> any ideas?
[14:55] <nessita> perrito666, would you know who can help me with that ^?
[15:32] <noodles775> mbruzek: Hi, if you've time, can you check this charm-helpers MP: https://code.launchpad.net/~michael.nelson/charm-helpers/fresh-ansible-relations/+merge/214203
[15:32] <noodles775> mbruzek: bloodearnest has already checked it and is +1 (hrm, bloodearnest, can you add your vote there when you get a chance)
[15:32] <mbruzek> Yes I will have a look
[15:32] <noodles775> mbruzek: he's the other ansible-support user besides me :-)
[15:32] <noodles775> Thanks.
[15:47] <bloodearnest> noodles775: done
[15:55] <tclarke> having trouble setting up juju to run disconnected from the internet on openstack. I did a juju sync-tools --all --local-dir=/tmp/juju   on a connected machine, moved the result to a web server accessible by the openstack system
[15:56] <tclarke> then I created an "images" diretory on the web server and grabbed releases/precise/*12.04*amd64*  (the only vesion I care about for this deployment)
[15:56] <tclarke> also grabbed cloud-images release/streams/v1/index.json and com.ubuntu.cloud:released:download.json
[15:56] <jcastro> sinzui, _THANK YOU_ for such finely detailed release notes
[15:56] <jcastro> that is an epic announcement
[15:57] <tclarke> removed all the entries which weren't 12.04 amd64
[15:57] <tclarke> added "tools-metadata-url: http://server/juju/tools" and "image-metadata-url: http://server/juju/images" to my environments.yaml
[15:58] <tclarke> juju -v bootstrap gives me "ERROR bootstrap failed: cannot start bootstrap instance: invalid URL "http://cloud-images.ubuntu.com/release/streams/v1/index.json" not found"
[15:58] <tclarke> what am I missing?
[15:59] <sinzui> tclarke, /release/ is missing a "s", /releases/
[16:00] <tclarke> thought of that...I have a symlink between "release" and "releases"
[16:00] <sinzui> tclarke, you may not need to set that since that is the default location to search
[16:00] <tclarke> so both exist
[16:01] <tclarke> here's the full directory listing served by the web server: http://www.pastebin.ca/index.php
[16:01] <tclarke> hang on, wrong link
[16:02] <tclarke> here, pastbin.ca doesn't want to work for me :)    http://pastebin.com/eVP12L8q
[16:03] <AskUbuntu> MAAS / nodes have limited internet access after install | http://askubuntu.com/q/444563
[16:05] <sinzui> tclarke, oh, yes, restricted networks must open access to that machine or mirror the images locally.
[16:06] <tclarke> sinzui: I release that...that's what I'm trying to do but juju is ignoring my image mirror config and is still trying cloud-images
[16:07] <sinzui> tclarke, right, and image-metadata-url is the right option to change :(
[16:07] <bloodearnest> hmm - it's only the MaaS provider that can place use --to lxc:n ?
[16:07] <tclarke> is there an equiv of "juju sync-tools" for the images?
[16:08] <sinzui> tclarke, I configure tools-metadata-url most of the time and it honoured. There is no effort to talk to streams.canonical.com when I change tools-metadata-url
[16:08] <tclarke> or a similar tool...I suspect I'm either missing something in the image repo or it's not properly setup but there seems to be no documentation on creating a mirror
[16:08] <sinzui> tclarke, maybe there is a jenv file present...juju is ignoring the yaml file.
[16:09] <sinzui> tclarke, you may need to delete $JUJU_HOME/environments/my-env.jenv
[16:09] <tclarke> I've attempted "rm -rf .juju/environments" a couple times...didn't seem to help
[16:09] <sinzui> tclarke, juju does not warn you that it found a cached config and is using it
[16:11] <sinzui> jamespage, do you have any experience with image-metadata-url being ignored with maas configs as tclarke reports?
[16:11] <tclarke> not maas tho, openstack
[16:30] <tclarke> progress....I seemed to have been missing a level in the directory tree..
[16:30] <tclarke> when I fix that, I get a different error about an invalid index.json.
[16:30] <tclarke> my index.json is: http://pastebin.com/vRc6USiS
[16:58] <Fishy_> My MAAS import boot images never finishes.. any idea how I can check the status of it?
[16:58] <Fishy_> something is broked
[16:58] <Fishy_> looking at /var/log/maas
[16:59] <Fishy_> nothing good there
[17:00] <Fishy_> well ok I get this
[17:01] <tvansteenburgh> who is the resident mysql charm expert?
[17:01] <tvansteenburgh> i have a master:slave setup, and the reads are going to master and writes to slave
[17:01] <Fishy_> http://paste.ubuntu.com/7217896/
[17:02] <Fishy_> does that error make sense to anyone
[17:02] <Fishy_> Invalid: The input field 'username' was not expected.
[17:38] <Fishy_> argh
[17:52] <lazyPower> tvansteenburgh: that would be marcoceppi
[19:24] <jcastro> jose, ping
[19:31] <jose> jcastro: pong
[19:31] <jcastro> hey if a charm doesn't have a logo
[19:31] <jcastro> you don't need to make an icon for it
[19:31] <jcastro> example: pictor
[19:31] <jose> oh, pictor, dustin made those
[19:32] <jose> I emailed him and asked and he replied with the logos
[19:32] <jcastro> oh well you can remove them
[19:33] <jose> huh?
[19:33] <jose> why's that?
[20:16] <jcastro> jose, it's better to just show a blank icon than a made up one with no branding
[20:16] <jose> oh, you meant for the ones that don't have an icon
[20:16] <jcastro> it's literally an orange box with text, it looks like it was made by a developer
[20:16] <jose> :P
[20:16] <jose> I'll make sure to fix that asap
[20:16] <jose> you know what, I'll do it now
[20:17] <jose> but pictor should be good to go, I think
[20:17] <jcastro> yeah, either a totally awesome icon that matches upstream's brand, or a template
[20:17] <jcastro> marco had some other feedback
[20:17] <jose> I'll wait for it, then
[20:51] <mhall119> jcastro: marcoceppi: I have a django charm that uses gunicorn, but I need something to service static files, what's the right path for this?
[20:52] <mhall119> I should also note that it currently uses multiple gunicorn nodes behind an haproxy
[20:52] <mhall119> and currently the static files are references with relative URLs like /static/css/site.css
[21:29] <lazyPower> mhall119: probably co-locate apache2 and gunicorn on the same machine, or nginx
[21:30] <lazyPower> and use the web daemon as a reverse proxy to the django app, and used for serving the static assets
[21:31] <lazyPower> i dont have much experience with gunicorn charm however - so this may be a bad suggestion... but thats my knee jerk reaction to the question.
[21:33] <mhall119> jcastro: can I use swift-dependent things when deploying to my local LXC for testing?
[21:40] <bloodearnest> mhall119: we have 2 approaches to servcing static resources:
[21:40] <bloodearnest> 1) a custom subordinate charm that builds/tars/deploys the assets on a service's units, then set the service's vhost config (apache in our case) to serve the static assets directly
[21:41] <bloodearnest> 2) a deploy to a swift bucket and then a proxy through apache to swift
[21:41] <bloodearnest> 2 is nicer, and less work
[22:21] <mhall119> bloodearnest: do you have an example config for 2?
[23:00] <marcoceppi> mhall119: apache2
[23:27] <bloodearnest> mhall119: I do't, we're just trying that approach now - but noodles775 can probably help
[23:27] <bloodearnest> *don't