[09:01] <teleyinex> hi there
[09:01] <teleyinex> I'm trying to learn juju and to connect it to my rackspace cloud
[09:01] <teleyinex> I'm generating the environments.yaml
[09:02] <teleyinex> and I think I've everything fine, but I'm getting this error:
[09:02] <teleyinex> ERROR required environment variable not set for credentials attribute: Secrets
[09:03] <teleyinex> the Secrets variable is not even in the environments.yaml file
[09:03] <teleyinex> so I don't know how to fix it
[09:03] <teleyinex> any idea why is asking for that variable=
[09:03] <teleyinex> any idea why is asking for that variable?
[09:27] <aquarius> I'm told by jcastro that I can set a backup dir with the postgres charm using some of the backup variables at https://jujucharms.com/fullscreen/search/precise/postgresql-52/?text=postgresql#bws-configuration. How do I set them?
[09:51] <ashipika> ERROR juju.state.open.go:92 TLS handshake failed: x509 certificate has expired or is not yet valid
[09:52] <ashipika> any clues where to start looking?
[10:02] <ashipika> anybody?
[10:05] <mgz> ashipika: are you using a self signed cert?
[10:06] <ashipika> this is what i get when i run juju bootstrap..
[10:06] <mgz> sure, but against *what*
[10:06] <ashipika> but i see now that it might be a "user" problem.. since it appears that juju bootstrap was ran as another user
[10:06] <mgz> juju has multiple providers, and we know that say, ec2, has a valid cert
[10:06] <ashipika> null environemnt
[10:06] <ashipika> environment
[10:08] <mgz> ashipika: and can you say, curl something from bootstrap-host without it complaining about the cert?
[10:09] <ashipika> curl to boostrap-host from another host?
[10:14] <mgz> ashipika: or ssh, probably more appropriate
[10:14] <mgz> check the host you're actually conecting to at any rate
[12:45] <marcoceppi> aquarius: It'll automatically backup to /var/lib/postgresql/backups, but you can `juju set postgresql backup_dir=/path/` to change configuration
[12:46] <aquarius> marcoceppi, oh, that's already happening? sweet!
[12:46] <aquarius> so I don't need to change anything
[12:46] <marcoceppi> aquarius: nope! Charms should always do the right thing(tm) by default
[12:46] <aquarius> that's excellent.
[12:46] <marcoceppi> aquarius: in this case it'll have the last 5 days of backups in that directory
[12:47] <aquarius> I should probably have a separate thing to send the backups elsewhere, mind :)
[12:47] <marcoceppi> aquarius: a great case for a suborindate charm
[12:47] <aquarius> not sure that's a charm; it's a one-liner in my crontab ;)
[12:48] <marcoceppi> aquarius: sure, I was just trying to slyly convince you to write a subordinate charm for backups ;)
[12:48] <aquarius> yeah, that's not happening ;)
[12:48] <aquarius> I barely understand how to do it myself
[12:49] <aquarius> trying to write a thing which keeps every sysadmin in the world happy is nowhere near my priority list :P
[12:49] <marcoceppi> eh, worth a shot
[12:57] <aquarius> :)
[14:40] <X-warrior> How does a subordinate charm works? I have an logstash-agent charm, then I deployed it... later I add a relation logstash-agent service2, now logstash is subordinated to service2. If I add a relation to logstash-agent (let's say redis). Will it update de service2 logstash-agent?
[14:46] <marcoceppi> X-warrior: yes, it will
[15:47] <X-warrior> marcoceppi: ty still trying to get this logstash to work
[15:47] <X-warrior> :D
[15:47] <X-warrior> btw, why when I use upgrade-charm I get an "already running latest charm", but I just updated one of the files...
[15:51] <X-warrior> oh forgot, just found my error
[15:52] <sinzui> bac, gary_poster staging.jujucharms.com is sending connection refused messages about mongo. I am going to investigate
[15:52] <bac> thanks sinzui.  let me know if i can help
[15:53] <gary_poster> ty sinzui
[16:02] <sinzui> bac, gary_poster mongodb filled the disk with logs. I deleted some and restarted mongo. I see staging is happy
[16:03] <bac> yay
[16:03] <bac> sinzui: can we turn down the log level?  logrotate?
[16:04] <sinzui> bac, I think we need to update the charm to handle rotation. Te log-level also seem to be permanently on spew
[16:05] <bac> sinzui: ok, i'll make a card for us
[17:29] <mxc> good morning
[17:29] <mxc> getting this error on Azure when bootstrapping:
[17:29] <mxc> 2013-12-07 04:23:00 ERROR juju supercommand.go:282 POST request failed: BadRequest - The affinity group name is empty or was not specified. (http code 400: Bad Request)
[17:29] <mxc> juju bootstrap --show-log --upload-tools  6.01s user 5.05s system 12% cpu 1:28.15 total
[17:29] <mxc> i'm running everything out of west us but trying to run the juju command from a non-azure machine.
[17:58] <mxc> back
[18:06] <sarnold> hey mxc, sorry, no responses while you were away
[18:06] <mxc> sarnold: thanks for the heads up
[20:00] <mxc> http://askubuntu.com/questions/388419/juju-bootstrap-fails-in-azure-badrequest-the-affinity-group-name-is-empty-or  <- would appreciate if anyone could take a look
[22:51] <jcastro> mxc, natefinch is who you should keep an eye out, he's the azure guy afaict
[22:52] <mxc> jcastro: thanks!
[22:56] <arosales> mxc,  did you have the mail to the list on juju bootstrap failing?
[22:58] <jcastro> http://askubuntu.com/questions/388419/juju-bootstrap-fails-in-azure-badrequest-the-affinity-group-name-is-empty-or
[22:59] <arosales> mxc if you run "apt-get update && apt-get install juju-core" on your stand along machines does that give you 1.16.4?
[23:00] <mxc> was that a bad use of the list?
[23:00] <mxc> if so, apologies
[23:01] <arosales> mxc, no it was a great use
[23:01] <mxc> arosales: 1.16.4-saucy-amd64
[23:01] <arosales> mxc, just wante to confirm mxc and the list  mail was the same subject
[23:01] <mxc> oh, yeah, that was me
[23:02] <arosales> cool, so an apt-get update gets you the latest juju
[23:02] <arosales> mxc which reagion is your ubuntu stand alone instance?
[23:02] <mxc> all west us
[23:02] <arosales> mxc sounds like you are using an azure instance as the juju client (ie to issues juju deploys from)
[23:03] <mxc> but also trying to get this working from a non-azure, plain old windows machine
[23:04] <mxc> arosales: so, yes, that would be ok
[23:07] <arosales> mxc, I was able to bootstrap from my ubuntu client outside of azure
[23:07] <mxc> does the machine that I am running juju bootstrap from need to have certain ports open?
[23:07] <arosales> I will see if I can reproduce your environment but bootstraping from within azure.
[23:07] <mxc> i get this from inside and outside of azure
[23:08] <mxc> is it possible to get even more debug output than just --show-log?
[23:08] <arosales> --debug
[23:09] <mxc> ty
[23:09] <mxc> doesn't help much in this case
[23:10] <mxc> ooh, a bit more
[23:10] <mxc> }: mirror data for "com.ubuntu.juju:released:tools" not found
[23:11] <arosales> mxc, can you pastebin your full --debug output?
[23:12] <arosales> mxc, it should retry if a local mirror isn't found.
[23:13] <arosales> mxc, hmm . . .  I don't know what port juju client
[23:13] <mxc> http://pastebin.ubuntu.com/6548362/
[23:13] <arosales> mxc, can you drop the --upload-tools
[23:14] <mxc> sec
[23:15] <arosales> mxc, it also looks like jujustorewestdocmunch may not be fully configured
[23:15] <arosales> 2013-12-09 19:45:38 ERROR juju supercommand.go:282 cannot obtain storage account keys: GET request failed: ResourceNotFound - The storage account 'jujustorewestdocmunch' was not found. (http code 404: Not Found)
[23:17] <mxc> oops, i accidentally copied way too much
[23:17] <mxc> sorry
[23:17] <arosales> ah I see you last attempt is at the bottom
[23:18] <mxc> http://pastebin.ubuntu.com/6548391/
[23:18] <mxc> sorry, here's the fixed on
[23:20] <arosales> mxc, also be interesting to see what "juju bootstrap  --debug" returns
[23:24] <mxc> same
[23:24] <winael> Hi every one
[23:25] <winael> utlemming: I just tried your tuto about quick start with Juju and I found a little "bug"
[23:25] <utlemming> winael: k....
[23:26] <arosales> winael, hello
[23:26] <winael> hi arosales
[23:26] <arosales> mxc, what metadata index does it read prior to the affinity error
[23:27] <mxc> https://jujustorewestusdocmunch.blob.core.windows.net/juju-azure-private/tools%2Fstreams%2Fv1%2Findex.json?se=2023-12-09T23%3A25%3A35Z&sig=AYXhLWBbLAfaigM%2B%2BHq2OueWOCi7SU6o56l1JnOgejg%3D&sp=r&sr=b&sv=2012-02-12
[23:28] <winael> utlemming: let's me explain, as i read your post, I undestand that it is a way to easly test Juju... but in the practice, ip forwarding doesn't work. So when you expose a service like Mediawiki, you can't access to it out of the vagrant box, unlike the Juju GUI
[23:29] <utlemming> winael: that is correct....you need to follow the SSHuttle instructions
[23:29] <winael> I think it could be a little confusing for people who want just give it a try but don't know linux very well and specially iptables rules
[23:29] <arosales> mxc, can you paste bin this attempt (ie without --upload-tools).  I want to see if you are trying to hit "http://cloud-images.ubuntu.com/releases/streams/v1/index.sjson"
[23:29] <utlemming> winael: I wouldn't do IP tables. Just use SShuttle, which forwards everything for you.
[23:31] <winael> Oh ok... that's not clear in fact. I think about none Ubuntu user, it a little bit confusing
[23:33] <utlemming> winael: the big problem here is that every OS has some convoluted method of forwarding ports, and looking at it made my head nearly explode for Windows.
[23:33] <winael> but the idea to use a vagrant image to easly deploy a Juju server I love it
[23:35] <winael> yeah I can understand that. In fact, I think it will be more easly to just add a note into your post (if you want to test a charm you've just deployed, use sshuttle)
[23:35] <winael> and make the sshuttle part non optional
[23:36] <mxc> arosales: http://pastebin.com/AQArivJz
[23:36] <mxc> ubuntu paste bin is super slow at the moment
[23:36] <utlemming> winael: I'll take a look.
[23:36] <utlemming> winael: thanks for the feedback
[23:36] <winael> I said that because I talk about this at work, but if they tried and fail for that, they just think Juju doesn't work
[23:36] <winael> And I imagine lot's of people can think the same
[23:36] <winael> you're welcome :)
[23:38] <mxc> is there a way to turn on HTTP request logging so that I can see every http request going out?
[23:40] <utlemming> winael: updated, hopefully that helps
[23:40] <winael> In fact this project inspire me. I am thinking about how I can try to bring Juju for my client which use VM on ESX, and I said to my self, wooooooooooh if I can have a QuickStart MaaS+Juju vagrant image as master, it'll fixe all my problems (it's just a fantasy, but...)
[23:42] <arosales> mxc, taking a look
[23:42] <arosales> mxc, thanks for the info
[23:42] <mxc> ty
[23:49] <mxc> oh, i've been using an ubuntu 13.10 machine to run juju from.  could that be part of the problem?
[23:49] <jcastro> winael, the vagrant images are more for supporting local development, not so much for serving things in an environment
[23:50] <jcastro> for your idea you're going to just use manual provisioning, which will be finished in january
[23:57] <arosales> mxc, no running the juju client from 13.10 should be fine
[23:57] <arosales> mxc I am still working on reproducing your error
[23:57] <arosales> mxc I did confirm that if storage and instance were in different regions you would get a different error along the lines of
[23:57] <arosales> The source image must reside in a storage account that has the same affinity group or location as the cloud service East US. (http code 400: Bad Request)
[23:58] <winael> jcastro: I have to take a look on the Manuel Provisioning doc in deed
[23:58] <arosales> and in those cases you should still hit cloud-images.ubuntu.com
[23:59] <winael> I try very hard to push Ubuntu/Juju in my company but it's not easy
[23:59] <winael> they prefere to try to re invent the wheel