| === hloeung_ is now known as hloeung | ||
| stub | I'm writing a test. Any ideas how to pause until a relation has been completely setup? I think I need to block until all hooks have finished running, but I can't get that information out of juju status. | 07:58 |
|---|---|---|
| === huats_ is now known as huats | ||
| === gary_poster|away is now known as gary_poster | ||
| === stevanr_ is now known as stevanr | ||
| marcoceppi_ | stub: I saw your merge proposal. We're writing a light weight testing framework to help provide functions like that | 12:23 |
| stub | marcoceppi_: lovely. | 12:27 |
| === wedgwood_away is now known as wedgwood | ||
| === marlinc_ is now known as Marlinc | ||
| === ppetraki_ is now known as ppetraki | ||
| === eschnou is now known as 18WADHHH7 | ||
| drj11 | i have a question, about SSL certs and https servers and juju | 14:12 |
| === gary_poster is now known as gary_poster|away | ||
| === gary_poster|away is now known as gary_poster | ||
| marcoceppi_ | drj11: fire away | 14:26 |
| drj11 | where do people generally put their SSL certs? | 14:27 |
| drj11 | (or any other private config that's a bit too big to fit in a yaml key,value pair) | 14:27 |
| drj11 | let's say i am making a charm to run our web-app on https. which i am. | 14:27 |
| m_3 | drj11: a common practice for this has been to a.) freeze the charm locally, then b.) embed large sensitive payloads just-in-time when deploying | 14:33 |
| m_3 | drj11: we're still working to consolidate libraries and offer a standard best practice for this | 14:34 |
| drj11 | m_3: okay, that's cool that your working on it | 14:34 |
| m_3 | drj11: keep an eye on https://launchpad.net/charm-helpers | 14:35 |
| drj11 | m_3: does juju have any facilities yet for the "just-in-time" thing? | 14:35 |
| drj11 | ooh | 14:35 |
| m_3 | drj11: no, that's all tooling around juju atm | 14:35 |
| === drrk_ is now known as drrk | ||
| m_3 | drj11: and it's one way people are solving that problem | 14:36 |
| m_3 | drj11: we'll probably have a session on this at virtual uds this week | 14:36 |
| drj11 | m_3: right. so for now I could deploy the charm, then have a script that copied the SSL cert to the right server. and if i wanted i could wrap that. | 14:37 |
| m_3 | drj11: yes, that's another approach | 14:37 |
| drj11 | oh i thought you were saying that's what charm-helpers was, just a standard way of doing that wrapping. | 14:38 |
| m_3 | drj11: another common problem is when you've gotta have a "private" key out on the server in order to pull from private repos... that's really best when you grab the payload _first_ and then deploy a fatter charm | 14:38 |
| m_3 | drj11: charm-helpers is mostly a set of tools to call from within a charm | 14:39 |
| m_3 | drj11: juju plugins will be the place to put together all our wrapper scripts like the one you just described | 14:40 |
| m_3 | hasn't landed yet | 14:40 |
| * m_3 can't wait! | 14:40 | |
| drj11 | m_3 okay. that all sounds good. really just checking i hadn't missed anything obvious. | 14:40 |
| drj11 | now i can't wait either. | 14:40 |
| m_3 | drj11: :) | 14:40 |
| m_3 | marcoceppi_: hey project question... shall we keep lp:charm-tools for charm tools? lp:charm-helpers for charm helpers? | 14:42 |
| marcoceppi_ | m_3: I think so | 14:42 |
| m_3 | marcoceppi_: then we need to decide what to do with lp:juju-jitsu | 14:42 |
| marcoceppi_ | m_3: firey death? | 14:42 |
| m_3 | ha! | 14:42 |
| marcoceppi_ | m_3: juju-plugins project probably ;) | 14:42 |
| m_3 | there're still some scripts we'll wanna salvage as plugins in juju-1.9 | 14:43 |
| m_3 | juju-contrib | 14:43 |
| marcoceppi_ | Take the things we liked form it and format it to plugins | 14:43 |
| m_3 | yeah, juju-plugins | 14:43 |
| marcoceppi_ | something like that, but yeah the import export stuff for sure off the top of my head | 14:43 |
| m_3 | so we'll make those each separate packages... | 14:43 |
| m_3 | charm-tools, juju-plugins, and charm-helpers? | 14:43 |
| marcoceppi_ | m_3: I'm not sure how to best structure the repo. I figured they should, for the most part, live in the same repo | 14:44 |
| marcoceppi_ | m_3: sounds good to me for now | 14:44 |
| m_3 | do we still need to package charm-helpers-{sh,py,etc..}? | 14:44 |
| m_3 | oh, yeah... probably language deps that'd be annoying | 14:44 |
| marcoceppi_ | m_3: once charm-helpers project takes shape, we'll need to package those (in addition to figuring out other distribution methods) but helpers would likely be packaged by context and not by language | 14:45 |
| m_3 | ok, so juju-plugins, charm-tools, charm-helpers-sh, charm-helpers-py | 14:45 |
| marcoceppi_ | so charm-helpers-core (for example) would give you the py/bash installations | 14:45 |
| m_3 | maybe s/charm-helpers-py/python-charm-helpers/ ? | 14:45 |
| marcoceppi_ | m_3: probably, again I'm not sure how best to package those semantics wise | 14:45 |
| m_3 | marcoceppi_: wait, so where's "-core" come in | 14:45 |
| marcoceppi_ | m_3: that was a poor example | 14:46 |
| m_3 | well helpers will be a bitch to package | 14:46 |
| m_3 | b/c of the alternative installs that people want | 14:46 |
| m_3 | hmmm.... well, maybe not... if we offer both a `pip install` as well as a real package... that might make mew et al happy enough | 14:47 |
| marcoceppi_ | m_3: I think we're going to be splitting helpers up based on subject matter and not by core lanaguage. So having a set of helpers that deal with openstack for instance which would include all the ways to talk to those helpers (ie bash and python starting out) | 14:47 |
| m_3 | marcoceppi_: yeah, good point | 14:47 |
| m_3 | ok, we can put off packaging helpers (well, or changing helper packaging) | 14:47 |
| marcoceppi_ | m_3: package, pip, and branch + install for sure. I know that's a high requirement | 14:47 |
| m_3 | marcoceppi_: we need to figure out how to maintain a little backwards compat | 14:47 |
| m_3 | or grep around in the current store charms to see who's using what | 14:48 |
| marcoceppi_ | m_3: right, the current packaing is good for now, as the new helpers is still early work atm but we will need to find a way to gracefully switch over to the new infrastructure | 14:48 |
| m_3 | figure out a migration strategy for non-store charms | 14:48 |
| * m_3 sad | 14:48 | |
| m_3 | wanted to tear packaging from charm-tools with a vengence | 14:48 |
| m_3 | :) | 14:48 |
| marcoceppi_ | :D in due time sir. Though we could move the packaing over to the new helpers project as mirror the way it works now. | 14:49 |
| m_3 | well... bits of it | 14:49 |
| m_3 | no need for charm-tools to be packaged there | 14:50 |
| m_3 | i.e., charm promulgate and friends | 14:50 |
| marcoceppi_ | Right, I mean the helpers packaging could be moved | 14:50 |
| marcoceppi_ | though, that would be tedious | 14:50 |
| wedgwood | m_3: marcoceppi_: the new lp:charm-helpers is already set up for both deb and pip packaging | 14:50 |
| m_3 | we should go through the juju packaging sometime too | 14:50 |
| m_3 | wedgwood: awesome | 14:51 |
| wedgwood | I still need to set up a PPA, but it should build | 14:51 |
| m_3 | wedgwood: ack... we can tack a ppa onto charm-helpers | 14:51 |
| m_3 | marcoceppi_: s/tedious/randomly explosive/ :) | 14:52 |
| marcoceppi_ | m_3: very much so | 14:53 |
| hazmat | sidnei, new deployer version released w/ your flush fix fwiw | 15:01 |
| === SpamapS_ is now known as SpamapS | ||
| === scuttlemonkey_ is now known as scuttlemonkey | ||
| zodiak | I don't suppose anyone has a 'devstack style' juju charm for openstack on a single machine ? | 16:20 |
| sarnold | zodiak: does this do what you want? http://jujucharms.com/~virtual-maasers/precise/virtual-maas | 16:36 |
| zodiak | sarnold, very cool.. certainly looks like the ticket | 16:38 |
| zodiak | I am finding the documentation on ubuntu 13.04, grizzly and juju interplay.. urm.. sorta.. "lacking" (no offense meant) | 16:39 |
| zodiak | do the juju charms for precise work on raring without troubles ? | 16:39 |
| marcoceppi_ | zodiak: I can't speak for their compatibility 100%, but ideally the precise charms should work on 13.04 - that being said we recommend deployments (and charms) be run and written against the LTS release of Ubuntu | 16:51 |
| marcoceppi_ | Which is why you find the majority of charms are written for precise and not raring. As for the client side, you can run juju on 13.04 without issues, just deployments tend to be on the lts | 16:51 |
| sarnold | marcoceppi_: it feels to me like it'd be useful to have a juju.ubuntu.com page providing guidance on the versions... something like, "if you're here to just use juju, stick to LTS releases and juju from <source>" and "if you want to make sure you're ready to use juju in the _next_ LTS, use <distro series> and juju from <source>" ... | 16:52 |
| marcoceppi_ | sarnold: Yeah, that's going to be an interesting problem come 14.04 - the "new docs" should help clarify the whole client series vs deployed series though | 16:53 |
| sarnold | marcoceppi_: but I think it'd be nice to have feedback from _some_ users on 13.10 and how well things work out with different charms... | 16:54 |
| marcoceppi_ | sarnold: how so? | 16:54 |
| sarnold | marcoceppi_: .. while still mkaing it clear that production users probably shouldn't be _those_ users.. :) | 16:54 |
| zodiak | well, dare I even ask, is the suggested "plan of attack" to stick with folsom or does the openstack juju's use grizzly ? | 17:05 |
| zodiak | cause, speaking as an openstack-developer, folsom and horizon was jst a disaster | 17:05 |
| zodiak | (specifically the quantum integration or lack thereof, and nova-network was.. ugh) | 17:06 |
| zodiak | I believe the juju's still use 2012.xx rather than 2013.xx .. but I am more than open to being wrong :D | 17:07 |
| === marlinc_ is now known as Marlinc | ||
| hazmat | zodiak, we have a set of openstack testing charms for later releases of ubuntu, the precise charms can pull from preferred ostack release in cloud archive. | 17:31 |
| === SpamapS_ is now known as SpamapS | ||
| === gary_poster|away is now known as gary_poster | ||
| === drrk_ is now known as drrk | ||
| b1tbkt | anyway to deploy ceph-mds through ceph juju charm? default deployment doesn't seem to include an mds which prevents cephfs from working | 19:06 |
| === fo0bar_ is now known as fo0bar | ||
| === defunctzombie_zz is now known as defunctzombie | ||
| === defunctzombie is now known as defunctzombie_zz | ||
| chilicuil | hi there, I'm trying to pass 'null' to a string var in a charm and juju outputs: "Invalid options specification: options.config_file.default: expected string, got None", bug #1101607, do you know any workaround? | 22:09 |
| _mup_ | Bug #1101607: juju default config string value of 'null' produces an error <juju:New> <https://launchpad.net/bugs/1101607> | 22:10 |
| === wedgwood is now known as wedgwood_away | ||
| === adam_g_ is now known as adam_g | ||
| chilicuil | ok, got it, it seems I need to write "" instead, I've updated the report | 22:24 |
| === defunctzombie_zz is now known as defunctzombie | ||
| === defunctzombie is now known as defunctzombie_zz | ||
| === defunctzombie_zz is now known as defunctzombie | ||
| === defunctzombie is now known as defunctzombie_zz | ||
| === defunctzombie_zz is now known as defunctzombie | ||
| === defunctzombie is now known as defunctzombie_zz | ||
| hazmat | chilicuil, commented on bug | 23:40 |
| hazmat | b1tbkt_, doesn't look like it, i'd suggest a separate charm like ceph-osd | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!