[00:16] <bradm> anyone know how to create an icon.svg for a charm?
[00:16] <rick_h> bradm: check out https://juju.ubuntu.com/docs/authors-charm-icon.html
[00:17] <rick_h> bradm: be aware that only icons for reviewed charms show up. Otherwise the category icon will be displayed if it has one.
[00:17] <bradm> rick_h: huh, I have to draw something?  that's not going to go well :)
[00:18] <rick_h> bradm: hah, yea time to take some designer'y type out for a drink
[00:19] <marcoceppi> bradm: A template is provided, if a luddite like me can do I think anyone can :)
[00:19] <bradm> rick_h: I wonder if there's a way to convert the logo from upstream to a svg file
[00:19] <marcoceppi> bradm: you can embed a bitmap instead of trying to convert it to SVG
[00:19] <rick_h> bradm: yea, best thing is if you can find an svg of the upstream logo, check license on it and all that.
[00:20] <rick_h> marcoceppi: how does that work for the bitmap? We take the icons from 27ishpx to 160px. So pretty wide range for non-vector
[00:20] <marcoceppi> rick_h: get the largest size bitmap you can find, hope for the best
[00:20] <rick_h> marcoceppi: sorry, was more a 'how well does that work' question
[00:20] <rick_h> lol
[00:20] <marcoceppi> rick_h: liferay and a few others have embeded bitmaps
[00:20] <rick_h> "paste and pray" method? :)
[00:21] <rick_h> cool, liferay shows up pretty well
[00:21] <bradm> ok, I might try doing something less than optimal for my first revision, and try and get a better looking logo later
[00:22] <rick_h> marcoceppi: autocomplete in comingsoon :) it's purdy stuff for you and jcastro
[00:23] <bradm> not that my charm is anything major, just a bip client
[00:23] <rick_h> bradm: hey, never know when someone else finds it useful
[00:24] <bradm> rick_h: yeah, plus it was more for me to learn how charm helpers works, etc
[00:32] <marcoceppi> rick_h: <3333333333
[01:07] <ahasenack> adam_g: like     @nose.plugins.attrib.attr('slow') ?
[01:13] <ahasenack> adam_g: done
[02:36] <Skepchurn> http://mrkinnikumike.blogspot.com/
[06:04] <melmoth_> with 1.12.0-raring-amd64  "juju debug-hooks" tells me there is no such command.. I dont see debug-hooks neither in "juju help commands"
[06:04] <jam1> melmoth_: it is new in 1.13.1
[06:05] <melmoth_> ahh.
[06:05] <melmoth_> i ll just watch the demo and not try it myself then :) thanks
[06:06] <jam> melmoth_: I can point you to where you can get 1.13.1, but if you want to stick with a stable version, its up to you
[06:06] <melmoth_> jam i m just playing with it so yep, a 1.13.1 version woul dbe  handy
[06:07] <jam> melmoth_: ppa:juju/devel
[06:07] <melmoth_> ahhhhh... right, i was using ppa:juju/stable. Thanks !
[06:07] <jam> I think we still need to copy the 1.12 and 1.13.1 tools to canonistack let me check
[06:09] <melmoth_> i m using local provider right now, as i m having issue deploying charm on canonistack (with juju-core)
[06:09] <jam> melmoth_: np, I'm copying the tools now anyway. Also, I think you need 1.13+ to get local provider
[06:09] <jam> thumper would know better, but he won't be around for a couple days (still traveling back from Isle of Man)
[06:09] <melmoth_> worked with 1.12 (untill i try debug-hooks)
[06:16] <melmoth_> jam btw im the guy you replyed to on cloud-list about juju-core on canonistack.I m wondering, if default-image-id is obsolete, how does juju knows wich image to pick when you bootstrap or deploy stuff ?
[06:17] <jam> melmoth_: you want the long or short answer?
[06:17] <melmoth_> short please :)
[06:17] <melmoth_> just enough to understand what i m doing and not ending up firing up an image i dont want
[06:17] <jam> there is a catalog, we look it up. We have a keystone entry in canonistack that tells us where the catalog lives.
[06:18] <jam> we map from "precise-amd64" to an instance-id on the cloud.
[06:20] <melmoth_> oh, i guess it s the product-streams endpoint
[06:24] <melmoth_> jam thanks a lot, i dot know if it s the 1.13 version or the fatc i commented out the obsolete settings, but now i can deploy stuff on canonistack
[06:24] <jam> melmoth_: I think it could as easily be canonistack got some more resources freed.
[06:24] <jam> our experience has shown that occassionaly canonistack is a bit overloaded
[10:13] <vila> hi there, trying to setup a local juju provider with lxc, 'juju get-environment'  fails with:
[10:14] <vila> error: error parsing environment "local": no public ssh keys found
[10:14] <vila> where can I find the juju config documentation ?
[10:20] <vila> mgz: ping, may be you know ^
[10:34] <jam> vila: juju currently requires you to have ~/.ssh/id_rsa.pub available, so it can set up authorized-keys on the target machines.
[10:34] <jam> It should optionally let you get by without them, but probably just warn that you won't have ssh access.
[10:35] <vila> jam: thanks, found authorized-keys-path dusting off my memory, I'm all set on that
[10:35] <vila> jam: now, juju get-environment says: error: file "provider-state" not found
[10:36] <vila> ... which juju bootstrap created ;)
[10:36] <jam> vila: I just set up a local env here, and it seems to be working. You did 'juju bootstrap" and it succeeded, right?
[10:36] <vila> jam: a bit surprising to not be able to use get-env before bootstrap but I can imagine why
[10:36] <vila> jam: well bootstrap ended up with 'error: no reachable servers' :-/
[10:37] <jam> vila: get-env is 'read the environment from the server' not from your local configuration.
[10:37] <vila> jam: ha ! makes sense then ;)
[10:37] <jam> local config sets up the initial env, but the source-of-truth is the remote location
[10:42] <vila> jam: running saucy, using ppas juju/devel and juju/pkgs, I add to manually install mongodb-server to make bootstrap happy
[10:42] <jam> vila: 'apt-get install juju-local' if you want all the things we need for the local provider. In the stable ppa, not sure about devel.
[10:42] <jam> ppa:juju/stable
[10:43] <jam> adds mongodb-server and lxc
[10:43] <jam> vila: you don't need them to run juju-the-client, so we didn't want to make them required on the juju-core package itself.
[10:44] <vila> jam: that's it !
[10:44] <mgz> hm, we still don't have a better error message with the packages missing?
[10:45] <jam> mgz: looking here: https://launchpad.net/~juju/+archive/stable/+packages it looks like the 'juju-local' package is built from the juju-core package. So there isn't a way to just copy it into ppa:juju/devel, right?
[10:45] <jam> We have to fix up our packaging for devel?
[10:45] <mgz> yeah, we can
[10:45] <jam> mgz: we had one
[10:45] <jam> I don't know if it landed in 1.13.1
[10:46] <jam> mgz: https://code.launchpad.net/~axwalk/juju-core/lp1204094-verify-local-prereqs/+merge/178496
[11:48] <Elvo> Hi, can I have few question regarding juju?
[11:49] <Elvo> 1) Is it opensource or not?
[11:49] <Elvo> 2) is it offering stuff like autoscaling and auto-healing in the cloud?
[11:49] <Elvo> 3) Is it working with Rackspace?
[11:55] <marcoceppi> Elvo juju is opensource, it doesn't directly offer autoscaling or auto-healing but it is on the roadmap to be addressed (it does do scaling though), it doesn't work with rackspace yet because Rackspace hasn't updated their openstack install. It does however work with Amazon, HPCloud, OpenStack, MAAS, and LXC (local) with more providers coming online soon
[11:56] <marcoceppi> Elvo: Juju also has a restful API which can be used to implement autoscaling and auto-healing yourself using a tool of your choice
[12:04] <Elvo> Thanks for answers. Question more - is there or it will be later - Windows client for juju?
[12:15] <hazmat> jam, does it only search id_rsa.pub ? any others.. like id_dsa.pub  or other default keys?
[12:16] <hazmat> Elvo, yes, there will be
[12:16] <jam> hazmat: I'm not positive what it needs, just that it needs something, and if you have nothing it complains.
[12:17] <hazmat> from the src looks like it will accept any of "id_dsa.pub", "id_rsa.pub", "identity.pub"
[12:17] <jam> hazmat: I believe you can set it in the environ config directly if you like
[12:17] <jam> (set the string)
[12:17] <jam> d
[12:17] <hazmat> jam, yup, just wanted to double check re other default keys for inspection
[12:18] <jam> hazmat: I'm a bit surprised it picks dsa before rsa, TBH. I thought dsa was deprecated.
[12:20] <hazmat> jam, what's your criteria for triage importance levels?
[12:20] <jam> I guess it is just alphabetical
[12:22] <jam> hazmat: so it should be: Critical: block the next release until fixed, High: On the priority queue for the next X months, Everything Else.
[12:22] <jam> I may not always get those right
[12:28] <hazmat> jam fair enough, was just curious cause its always clear re criteria ie openstack_s3 (high) before provider constraints (ec2-zone, maas-tags ) (low)
[12:28] <hazmat> er.. not always
[12:31] <jcastro> Elvo: Juju is written in golang so running on windows is just a matter of compiling it
[12:31] <jcastro> we have not yet done that
[12:31] <jcastro> but we are in progress, you should see Windows and OSX clients fully supported quite soon
[12:44] <marcoceppi> jamespage: what's the login information for openstack-dashboard once deployed?
[12:45] <jamespage> marcoceppi, it gets it from keystone
[12:45] <jamespage> marcoceppi, and the admin username and password is configured using config in keystone
[12:45] <marcoceppi> jamespage: So. I just deployed openstack and I have no idea how to log in
[12:45] <marcoceppi> jamespage: thanks!
[12:46] <jamespage> marcoceppi, you need todo a "juju set keystone admin-password=XXX"
[12:46] <jamespage> otherwise is randomly generated :-)
[12:46] <jamespage> usname is admin
[12:47] <jam> jamespage: it can be hard to guess a randomly generated password :)
[12:47] <jam> jamespage: could you "juju get keystone" ? (is there a reason to force it to something new)
[12:47] <jamespage> jam: indeed - and as juju was no way of sharing something back to the user ....
[12:48] <jamespage> jam: there is no 'config-set' from within a deployed charm
[12:49] <marcoceppi> jamespage: does the admin-password need to be set prior to deployment?
[12:49] <marcoceppi> jamespage: because setting it causes config-changed to barf
[12:49] <jamespage> marcoceppi, juju-core?
[12:50] <marcoceppi> jamespage: yes :( http://paste.ubuntu.com/5981025/
[12:50] <jamespage> marcoceppi, ohyes
[12:50]  * jamespage scrabbles for the patch
[12:50] <marcoceppi> jamespage: you've got 8 hours before demo :)
[12:51] <jamespage> marcoceppi, http://paste.ubuntu.com/5981028/
[12:52] <jam> jamespage: how would you "juju set" on a service you haven't deployed yet? Just run "juju set" before the instance actually starts?
[12:53] <jamespage> jam: nope - 'juju deploy --config config.yaml keystone'
[12:53] <jamespage> that injects the configuration at deploy time
[12:54] <marcoceppi> jamespage: if you want to propose merge, I'll ack and land it
[12:55] <jamespage> marcoceppi, doing so now
[12:55] <marcoceppi> jamespage: logging in now produces "Unable to retrieve authorized projects."
[12:56] <jamespage> marcoceppi, hmm
[12:57] <jamespage> marcoceppi, https://code.launchpad.net/~james-page/charms/precise/keystone/juju-core-fixes/+merge/179920
[12:57] <jamespage> marcoceppi, it logged you in though right?
[12:57] <jamespage> marcoceppi, and which openstack-origin are you using?
[12:57] <jamespage> (more config)
[12:58] <marcoceppi> jamespage: no, I get that error on the login screen, cloud:precise-grizzly, here's a URL!
[12:58] <marcoceppi> http://15.185.188.159/horizon/auth/login/
[12:58] <marcoceppi> admin123 for the password
[12:58]  * marcoceppi fears no lurkers
[12:58] <jamespage> marcoceppi, hmm - well thats annoying
[12:59] <marcoceppi> slightly :)
[12:59] <marcoceppi> let me know what I can do to get you any additional information
[12:59] <marcoceppi> other than this is openstack on openstack
[13:03] <jamespage> marcoceppi, can you pastebi /etc/openstack-dashboard/local_settings.py please
[13:04] <marcoceppi> jamespage: http://paste.ubuntu.com/5981086/
[13:05] <jamespage> marcoceppi, can you access your deployment using command line tools?
[13:06] <marcoceppi> jamespage: let me try (using the keystone admin data?)
[13:06] <jamespage> marcoceppi, yes
[13:07] <jamespage> marcoceppi, http://paste.ubuntu.com/5981092/
[13:07] <jamespage> source that as a file and then do 'keystone catalog' and see if it works
[19:56] <Beret> ?
[21:31] <marcoceppi> Beret: Hi, did you have a question?
[21:34] <Beret> marcoceppi, sorry, typed in the wrong window :)
[21:34] <Beret> I'm good thanks
[21:38] <marcoceppi> o/
[23:02] <adam_g> wedgwood, am i on crack or did this change / this bug is valid? i keep hitting older code that was looking for Nones. https://bugs.launchpad.net/charm-helpers/+bug/1203241
[23:02] <_mup_> Bug #1203241: relation_get() on a non-set relation setting does not return None <Charm Helpers:New> <https://launchpad.net/bugs/1203241>
[23:03] <wedgwood> adam_g: I don't remember seeing anything that would have changed that
[23:04] <wedgwood> adam_g: Could be that it's always been that way?
[23:04] <adam_g> wedgwood, the helper itself looks like it should be returning None for unset relations
[23:04] <adam_g> at least, IIRC
[23:05] <adam_g> but if the the difference in output of relation-get vs config-get is new..
[23:05] <wedgwood> Could be. I'm not sure if that's right though. Does relation-set give a non-zero exit value for un-set keys?
[23:05] <wedgwood> If not, there's no difference between no value and an empty one
[23:05] <wedgwood> And that may be the reason for the inconsistency
[23:07] <adam_g> wedgwood, IIRC relation-set will exit non-zero if its arguments are not key=value
[23:08] <wedgwood> that makes sense. but I mean if I run "relation-get relationname somethinginvalid", do I get an empty string and a 0 exit?
[23:09] <wedgwood> what I'm saying is that both config-get and relation-get probably do the same thing. if there's no difference in output between unset and empty, then the implementations may just be inconsistent because it wasn't clear which was correct.
[23:09] <wedgwood> I'm leaning toward an empty string until we can tell the difference.