[15:15] <nottrobin> is there a standard place to store information about relations?
[15:16] <nottrobin> inside juju instances?
[15:16] <nottrobin> I'm writing a charm that requires mongodb
[15:16] <nottrobin> and I have a hook called "mongodb-relation-joined"
[15:17] <nottrobin> inside that hook, I need to store the hostname of the joined environment so my application can retrieve it to connect to it
[15:17] <nottrobin> how should I do that?
[15:56] <Tug> nottrobin, I think what you are looking for are the `relation-set` and `relation-get` commands
[15:58] <nottrobin> Tug: I can use relation-set and relation-get in my hook to retrieve / store the details of the relation, but what about my application? It can't be expected to know it's running in a juju environment. But it still needs to know what hostname to look for mongodb on
[15:58] <Tug> nottrobin, I guess you either have to start your app from the charm or modify a config file
[15:59] <Tug> or set environment variables
[15:59] <nottrobin> Tug: right. I'm trying to make the charm as generic as possible - IE have very little knowledge of the app's structure
[15:59] <nottrobin> Tug: yeah I was thinking of setting environment variable
[15:59] <nottrobin> Tug: but that seems to be impossible using Python
[16:00] <Tug> nottrobin, you can do bash commands in Python
[16:00] <bodie_> does anyone know whether it's possible to use coreos fleet as a deploy target with juju somehow?  can I write an extension provider if that option doesn't yet exist?
[16:01] <nottrobin> Tug: but you can't set environment variables
[16:01] <nottrobin> Tug: http://stackoverflow.com/questions/1506010/how-to-use-export-with-python-on-linux
[16:02] <Tug> noodles775, https://docs.python.org/2/library/os.html#os.environ
[16:02] <Tug> srry
[16:02] <Tug> nottrobin, https://docs.python.org/2/library/os.html#os.environ
[16:02] <nottrobin> setting an environment vaiable would be my perfect solution but I can't work out how to do it
[16:02] <nottrobin> Tug: right, but os.putenv fails
[16:03] <nottrobin> you can happily set the local os.environ dictionary, but it won't actually update the environment
[16:03] <Tug> I personnaly don't like environment variables, it's not a clean way to pass information (imo)
[16:04] <nottrobin> it's perfect for information about the environment
[16:04] <Tug> yeah for a program
[16:04] <nottrobin> right
[16:04] <Tug> like DEBUG=true start_my_prog
[16:05] <Tug> out of curiosity, what type of application is it ?
[16:05] <nottrobin> wsgi
[16:06] <nottrobin> the one I'm testing it with is django, but it could be flask or werkzeug
[16:07] <Tug> mm I see, have you looked at the python-django charm to see how they did it ?
[16:08] <nottrobin> good idea, I'll have a look
[16:08] <Tug> look like they are modifying an upstart script
[16:08] <Tug> did look for long
[16:08] <Tug> * I did not look for long
[16:14] <nottrobin> Tug: where did you see that?
[16:15] <nottrobin> Tug: I can see it writes the DB settings to <app_dir>/juju_settings/20-engine-%(engine_name)s.py
[16:15] <nottrobin> Tug: but I can't see how that file then gets used
[16:20] <nottrobin> Tug: yeah the settings get read by some lines injected at the bottom of settings.py
[16:20] <nottrobin> Tug: a very django-specific solution
[16:21] <hazmat`> bodie_, not really re coreos.. not entirely sure how that would work, you could run full os ubuntu containers inside of a coreos machine, and then basically register them as machines for a juju deployment.. i've got some simple client side plugins that do api machine provisioning for digital ocean, etc. if your going down that road.. alternatively getting charms that directly do docker (for image based deploys) else its just the container as a machine.
[16:22] <hazmat`> nottrobin, reading backlog, but typicaly way to address this issue is to have a standard way to configure your application, that the hooks can inject/render the relation config into
[16:24] <hazmat`> Tug, just about every paas uses env variables to pass config in... (heroku, dotcloud, cloudfoundry, openshift) etc.
[16:24] <hazmat`> its effectively the lowest common denominator across language runtimes.. but agreed that it has caveats (runtime manipulation etc)
[16:25] <hazmat`> nottrobin, ie. your app reads config from file, and hooks write that file, and can either restart the process, or send signal if they change it.
[16:26] <hazmat`> nottrobin, which wsgi framework out of curiosity?  pyramid and django both make this easy... flask requires some mucking about to get the plumbing right (re config from file) imo.
[16:27] <nottrobin> hazmat`: the projects I want to use it with at the moment are flask and django
[16:27] <nottrobin> hazmat`: that's why environment variables are perfect
[16:27]  * hazmat` nods
[16:28] <nottrobin> hazmat`: if I can just say "the mongodb hostname will be in the environment variables "MONGODB_HOST"
[16:28] <nottrobin> hazmat`: than writing your app to make use of that is simple
[16:28] <nottrobin> *then
[16:28] <hazmat`> nottrobin, so i'd suggest an upstart file which sources an environment file for each then.. alot of packages do this.. ie source /etc/default/$package_name  in a pre-exec upstart script
[16:29] <hazmat`> though you might want a different location than that.. but then the hooks just write to the env variable file, and restart the service after modifying the config
[16:29] <nottrobin> hazmat`: right so charmhelpers has a helper method which saves "export ..." lines into a scriptrc file inside the charm directory
[16:29] <nottrobin> hazmat`: but I couldn't work out how that file then gets sourced
[16:30] <nottrobin> hazmat`: do you know of a link that could explain how to configure upstart scripts to me?
[16:30] <nottrobin> hazmat`: I'm relatively new to this charming stuff
[16:31] <lazyPower> nottrobin: upstart has some really complete documentation. http://upstart.ubuntu.com/cookbook/
[16:31] <hazmat`> nottrobin, so re upstart looking at the docs (cookbook) or extant ones in packages is pretty good. it might be easier to just have a wrapper script that execs  the actual startup after sourcing your env variable file.
[16:32] <lazyPower> dont let that page intimidate you, in practice you usually only  need ~ 5 or 6 lines to build an upstart job that will do what you want it to do.
[16:32] <lazyPower> o/ hazmat`
[16:33] <nottrobin> hazmat`, lazyPower: thanks I'll get reading
[16:33]  * hazmat` heads out to the airport
[16:34] <lazyPower> nottrobin: here's a good example upstart script for you: https://github.com/chuckbutler/starbound-charm/blob/master/contrib/starbound-universe.conf
[16:35] <lazyPower> the only thing i read in the feedback above it doesn't exhibit is the environment variables. which are set with an 'env' keyword.
[16:36] <nottrobin> lazyPower: presumably it could source a file which did the actual exporting of variables
[16:37] <lazyPower> right
[19:36] <cruisibesares> hey juju guys. I just joined your mailing list the other day as im trying out this technlolgy for a proof of concept. I see that there has been a substanital amount of work on the vagrant provider recently which is great. I personally would like to use maas with virutal box so it will mirror my final deploy as close a possible. I found this blog post http://marcoceppi.com/2012/05/juju-maas-virtualbox/ and got that all set up and run
[19:36] <cruisibesares> ning. I got annoyed about having to power up all the boxes by hand durning commissioning so i built a little listener in go that basically just listens for the wake on lan packet and then look through the virutalbox boxes on the virulization host and uses the command line to power the right box on. So far it works like a charm (no pun intended) the only thing that is still kinda annoying me is that i have to use the gui to set the p
[19:36] <cruisibesares> ower type for each of the servers to wol of each server. This is more of a maas issue but is there a way that i can configure maas so that it will always use the wol power type by default?
[19:37] <lazyPower> cruisibesares: you can use KVM in leu of VirtualBox with the virsh provider to achieve non-manual powerup/powerdown
[19:37] <lazyPower> I'm using that on a server i have here in my house with great success.
[19:38] <lazyPower> i'm not really familiar with Virtualbox's WOL capabilities, unfortunately
[19:47] <cruisibesares> yeah it doesn't have any by default
[19:48] <cruisibesares> i just built a service that listens on port 9 and then calls the api
[19:48] <cruisibesares> the wol protocol is easy enough and i wanted to keep it on my mac
[19:48] <cruisibesares> that all works now somehow haha
[19:50] <cruisibesares> only hichup that i have at this point is the fact that after i run this maas maas nodes accept-all
[19:50] <cruisibesares> they all have power type set to
[19:50] <cruisibesares> --------
[19:51] <cruisibesares> if this makes no sense at all i can write it up a little better provide some examples and push it up to the maling list
[19:52] <cruisibesares> oops sorry network dropped out for a second
[20:00] <lazyPower> cruisibesares: it's an interesting use case, and I think others would benefit from your experience. If you have the time to post to the list, i'd love to read up on your specific testing implementation.
[20:00] <cruisibesares> alright i
[20:01] <cruisibesares> will fix up the read me and post what i have soon
[20:09] <cruisibesares> i think that im going to need to tweak the enlist_userdata file but i would like to avoid messing around with files included in the package
[23:28] <jokoka> yt ythhrt q;pk g