[01:51] SpamapS: I approved your merge request (https://code.launchpad.net/~clint-fewbar/charms/oneiric/mediawiki/misc-fixes/+merge/89369) [02:02] negronjl: sweet thanks === bradm_ is now known as bradm === koolhead11 is now known as koolhead17 [08:01] lynxman: reg certificate transfer, I would recommend you to have a look at https://code.launchpad.net/~nijaba/charms/oneiric/drupal/nb (which is still waiting for a review - hint) as it is I think the best example. [08:50] nijaba: thanks :) [11:39] hello guys [11:39] niemeyer: are u there? [11:39] tyska: I am indeed [11:39] tyska: How're things? [11:40] niemeyer: evolving [11:40] tyska: That's good :) [11:41] niemeyer: if someday you come to RG, come here to visit us [11:41] tyska: Will do.. where are you located? [11:42] i am on FURG - campus carreiros [11:43] tyska: Ok, any department/subdepartment? [11:43] yeah, Centro de Ciências Computacionais - C3 [11:44] tyska: Nice name :) [11:44] <_markh_> I'm using juju to set up some local (LCX) services on a single system. When that sys reboots, none of the services restart and juju status says "ERROR could not connect before timeout". How can I restore to the previously running state? [11:45] <_markh_> LCX==LXC ... doh! [11:45] _markh_: Yeah, I could guess it :) [11:45] _markh_: There are two different angles to that question: [11:46] _markh_: The local LXC provider is really meant to be used for local experimentation [11:46] _markh_: Rather than for actual deployments [11:46] _markh_: So it won't survive a reboot [11:47] _markh_: The second angle is that the constraint of rebooting was inherited from the prototyping stages even for EC2 [11:47] _markh_: So the story isn't great with the trunk code [11:47] _markh_: On the bright side, though, the code fixing that is up for review already [11:48] <_markh_> That's OK - we're not looiking to deploy immediately with juju. As long as I know the contraints then all is well [11:49] <_markh_> Good to hear that there are improvements in the pipeline (12.04 ? ) [11:49] _markh_: Cool.. so yeah, definitely in good ground there. Don't use the local provider for real stuff. [11:49] _markh_: There's a _big_ pipeline :-) [11:49] <_markh_> :) [11:49] _markh_: There's code landing every week, and there will be for the foreseeable future [11:50] niemeyer: do you have some new about that juju + eucalyptus problem? [11:50] <_markh_> I'm really excited for juju. It could absolutely help with the deployment issues we struggle with. [11:50] <_markh_> Thx. [11:52] tyska: Hmm.. sorry, do you have a bug number? [11:52] niemeyer: yeah, wait a minute [11:52] _markh_: That's great to hear.. it's indeed the kind of problem we're aiming at helping people on [11:53] niemeyer: https://bugs.launchpad.net/juju/+bug/907450 [11:53] <_mup_> Bug #907450: juju does not work with Walrus when s3-uri has a suffix < https://launchpad.net/bugs/907450 > [11:56] tyska: Not much action there yet [11:57] tyska: I'll clarify the problem for the folks asking [12:01] niemeyer: great, thanks! ;) [12:03] tyska: np, sorry it wasn't fixed yet [12:04] np === stub1 is now known as stub [12:48] niemeyer: that carmack quote is brilliant :) [12:48] mpl: And true! :) [12:48] yep [15:29] I'm wondering about running juju in an openstack cloud - I know the juju docs currently say that only ec2 is supported as a cloud, but I'm guessing openstack support is coming. Is it something I can play with ahead of time if I run juju from, say, trunk? [17:01] question, when a new charm is deployed, after finishing install it'll always execute config-changed? [17:19] lynxman, more specifically.. it will always execute config-changed when starting the service before executing the start hook [17:20] Ng, openstack is supported [17:20] hazmat: yeah just realised :) silly me [17:20] hazmat: thanks [17:20] np [17:21] ah.. the faq needs updating [17:44] hazmat: To run on an openstack implementation is it just a case of updating the type in environments.yaml to openstack and adding the appropriate keys there? [17:48] mbarnett, the default-image-id also needs to be specified in addition to the ostack credentials.. on the openstack side we use the ec2 apis to talk to openstack so either s3server.py needs to be running or the swift s3 middleware. [17:48] hazmat: okay, thanks. [17:51] hazmat: it's possible I use openstack + s3? [17:53] andrewsmedina, no.. the ec2/aws provider assumes the same credentials are valid for storage and compute, the s3 server could be setup just for juju's minimal storage usage if their isn't any need for the object storage server in the deployment [17:54] hazmat: I'm having problem to have the same authentication in nova and swift [17:57] andrewsmedina, if your just looking to get started.. s3server.py is basically just a single module python s3 server (in nova), afaicr it doesn't even bother with verifying the signed url authentication. [17:57] andrewsmedina, are you using keystone for both nova and swift? [17:57] hazmat: im using tempauth for swift [18:05] hazmat: I will try s3server.py instead swift [18:40] hazmat: quick question for you sir, any easy way to know the zk instance address from a juju instance? [18:41] lynxman, its in the cloud-init data, and environ of the agents [18:42] hazmat: so how can I recover it from the environ? [18:43] lynxman, cat /proc//env [18:44] er. /environ [18:44] hazmat: thanks :) === wrtp is now known as rog [20:18] <_mup_> juju/twisted-precise-compat r444 committed by kapil.thangavelu@canonical.com [20:18] <_mup_> orchestra storage provider twisted 11.1 forward compatibility [20:23] jimbaker, how goes? [20:23] bcsaller, jimbaker would either of you mind looking at this trivial, it fixes the precise builds. https://code.launchpad.net/~hazmat/juju/twisted-precise-compat/+merge/89490 [20:24] hazmat, good. did you have a chance to talk w/ bcsaller about niemeyer's review of the subordinate spec? [20:24] hazmat, i'll take a look at the trivial [20:25] jimbaker, i didn't, i looked over the niemeyer's review though [20:25] imho, i don't really such much implementation difference between the two approaches [20:25] bcsaller, give me a ping when your up for a chat re spec [20:25] i'd still like to flush out the relation structure on disk [20:25] er. zk [20:25] hazmat: I can do it in 2 minutes if you'd like [20:26] hazmat, as far as i could see, that's the only real diff, but it doesn't really carry into the impl - either is fine [20:27] hey smoser what's cirros? [20:27] https://launchpad.net/cirros [20:28] in a nutshell, ttylinux-uec version 2.0 [20:28] hazmat, +1 on the trivial [20:28] i appreciate the good doc on rationale [20:28] jimbaker, thanks... took way to long to find that magic line [20:29] hazmat, definitely understand that! :) [20:32] hazmat: yeah, the trival looks fine, but the api around _completelyDone *sigh* [20:33] bcsaller, what api ? ;-) [20:33] yeah [20:33] and why the default it has? [20:33] bcsaller, because by default most http requests are request/response and done [20:34] I'd say most client code wants to follow redirects though [20:34] bcsaller, this one just signals that it might be multiple request/responses before the semantic request result is obtained [20:34] true [20:36] hazmat: want to have that talk now? shame gustavo isn't around [20:40] bcsaller, sounds good re talk [21:57] hrm... "lightning" talks that are 15 minutes long.. more like thunder talks. :p [22:30] <_mup_> juju/trunk r444 committed by kapil.thangavelu@canonical.com [22:30] <_mup_> [trivial/merge] fix orchestra storage provider compatibility with twisted 11.1 [r=jimbaker,bcsaller][f=917954] [22:46] <_mup_> juju/upgrade-config-defaults r432 committed by kapil.thangavelu@canonical.com [22:46] <_mup_> merge trunk [22:49] <_mup_> juju/upgrade-config-defaults r433 committed by kapil.thangavelu@canonical.com [22:49] <_mup_> address review comments === hspencer is now known as hspencer[afk] [23:41] <_mup_> juju/trunk r446 committed by kapil.thangavelu@canonical.com [23:41] <_mup_> merge upgrade-config-defaults, config values are lazily instantiated. [r=bcsaller,fwereade][f=900560] [23:41] <_mup_> Previously configuration values where prepopulated from defaults, now [23:41] <_mup_> values are lazily computed from explicitly set values, and defaults. [23:41] <_mup_> For charm upgrades config values not explicitly set will recieve now new [23:41] <_mup_> charm defaults.