/srv/irclogs.ubuntu.com/2013/05/13/#juju.txt

=== hloeung_ is now known as hloeung
stubI'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 that12:23
stubmarcoceppi_: 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
drj11i have a question, about SSL certs and https servers and juju14:12
=== gary_poster is now known as gary_poster|away
=== gary_poster|away is now known as gary_poster
marcoceppi_drj11: fire away14:26
drj11where 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
drj11let's say i am making a charm to run our web-app on https. which i am.14:27
m_3drj11: a common practice for this has been to a.) freeze the charm locally, then b.) embed large sensitive payloads just-in-time when deploying14:33
m_3drj11: we're still working to consolidate libraries and offer a standard best practice for this14:34
drj11m_3: okay, that's cool that your working on it14:34
m_3drj11: keep an eye on https://launchpad.net/charm-helpers14:35
drj11m_3: does juju have any facilities yet for the "just-in-time" thing?14:35
drj11ooh14:35
m_3drj11: no, that's all tooling around juju atm14:35
=== drrk_ is now known as drrk
m_3drj11: and it's one way people are solving that problem14:36
m_3drj11: we'll probably have a session on this at virtual uds this week14:36
drj11m_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_3drj11: yes, that's another approach14:37
drj11oh i thought you were saying that's what charm-helpers was, just a standard way of doing that wrapping.14:38
m_3drj11: 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 charm14:38
m_3drj11: charm-helpers is mostly a set of tools to call from within a charm14:39
m_3drj11: juju plugins will be the place to put together all our wrapper scripts like the one you just described14:40
m_3hasn't landed yet14:40
* m_3 can't wait!14:40
drj11m_3 okay. that all sounds good. really just checking i hadn't missed anything obvious.14:40
drj11now i can't wait either.14:40
m_3drj11: :)14:40
m_3marcoceppi_: 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 so14:42
m_3marcoceppi_: then we need to decide what to do with lp:juju-jitsu14:42
marcoceppi_m_3: firey death?14:42
m_3ha!14:42
marcoceppi_m_3: juju-plugins project probably ;)14:42
m_3there're still some scripts we'll wanna salvage as plugins in juju-1.914:43
m_3juju-contrib14:43
marcoceppi_Take the things we liked form it and format it to plugins14:43
m_3yeah, juju-plugins14:43
marcoceppi_something like that, but yeah the import export stuff for sure off the top of my head14:43
m_3so we'll make those each separate packages...14:43
m_3charm-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 repo14:44
marcoceppi_m_3: sounds good to me for now14:44
m_3do we still need to package charm-helpers-{sh,py,etc..}?14:44
m_3oh, yeah... probably language deps that'd be annoying14: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 language14:45
m_3ok, so juju-plugins, charm-tools, charm-helpers-sh, charm-helpers-py14:45
marcoceppi_so charm-helpers-core (for example) would give you the py/bash installations14:45
m_3maybe s/charm-helpers-py/python-charm-helpers/ ?14:45
marcoceppi_m_3: probably, again I'm not sure how best to package those semantics wise14:45
m_3marcoceppi_: wait, so where's "-core" come in14:45
marcoceppi_m_3: that was a poor example14:46
m_3well helpers will be a bitch to package14:46
m_3b/c of the alternative installs that people want14:46
m_3hmmm.... well, maybe not... if we offer both a `pip install` as well as a real package... that might make mew et al happy enough14: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_3marcoceppi_: yeah, good point14:47
m_3ok, 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 requirement14:47
m_3marcoceppi_: we need to figure out how to maintain a little backwards compat14:47
m_3or grep around in the current store charms to see who's using what14: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 infrastructure14:48
m_3figure out a migration strategy for non-store charms14:48
* m_3 sad14:48
m_3wanted to tear packaging from charm-tools with a vengence14: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_3well... bits of it14:49
m_3no need for charm-tools to be packaged there14:50
m_3i.e., charm promulgate and friends14:50
marcoceppi_Right, I mean the helpers packaging could be moved14:50
marcoceppi_though, that would be tedious14:50
wedgwoodm_3: marcoceppi_: the new lp:charm-helpers is already set up for both deb and pip packaging14:50
m_3we should go through the juju packaging sometime too14:50
m_3wedgwood: awesome14:51
wedgwoodI still need to set up a PPA, but it should build14:51
m_3wedgwood: ack... we can tack a ppa onto charm-helpers14:51
m_3marcoceppi_: s/tedious/randomly explosive/ :)14:52
marcoceppi_m_3: very much so14:53
hazmatsidnei, new deployer version released w/ your flush fix fwiw15:01
=== SpamapS_ is now known as SpamapS
=== scuttlemonkey_ is now known as scuttlemonkey
zodiakI don't suppose anyone has a 'devstack style' juju charm for openstack on a single machine ?16:20
sarnoldzodiak: does this do what you want? http://jujucharms.com/~virtual-maasers/precise/virtual-maas16:36
zodiaksarnold, very cool.. certainly looks like the ticket16:38
zodiakI am finding the documentation on ubuntu 13.04, grizzly and juju interplay.. urm.. sorta.. "lacking" (no offense meant)16:39
zodiakdo 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 Ubuntu16: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 lts16:51
sarnoldmarcoceppi_: 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 though16:53
sarnoldmarcoceppi_: 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
sarnoldmarcoceppi_: .. while still mkaing it clear that production users probably shouldn't be _those_ users.. :)16:54
zodiakwell, dare I even ask, is the suggested "plan of attack" to stick with folsom or does the openstack juju's use grizzly ?17:05
zodiakcause, speaking as an openstack-developer, folsom and horizon was jst a disaster17:05
zodiak(specifically the quantum integration or lack thereof, and nova-network was.. ugh)17:06
zodiakI believe the juju's still use 2012.xx rather than 2013.xx .. but I am more than open to being wrong :D17:07
=== marlinc_ is now known as Marlinc
hazmatzodiak, 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
b1tbktanyway to deploy ceph-mds through ceph juju charm? default deployment doesn't seem to include an mds which prevents cephfs from working19:06
=== fo0bar_ is now known as fo0bar
=== defunctzombie_zz is now known as defunctzombie
=== defunctzombie is now known as defunctzombie_zz
chilicuilhi 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
chilicuilok, got it, it seems I need to write "" instead, I've updated the report22: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
hazmatchilicuil, commented on bug23:40
hazmatb1tbkt_, doesn't look like it, i'd suggest a separate charm like ceph-osd23:40

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!