[00:25] hey koolhead17|zzZZ [00:25] sorry [00:25] was in meetings all day [00:25] whats goin on? === lamont` is now known as lamont [12:13] Good morning! [12:21] ./1 [16:16] hi [16:17] In my try to use juju + openstack when I run "juju status" return this error [16:17] 2012-01-25 14:07:39,567:1419(0x7fdf04f58700):ZOO_ERROR@handle_socket_error_msg@1579: Socket [127.0.0.1:34932] zk retcode=-4, errno=111(Connection refused): server refused to accept the client === objectiveous_ is now known as objectiveous [16:29] <_mup_> juju/local-respect-series r448 committed by kapil.thangavelu@canonical.com [16:29] <_mup_> allow creating precise lxc containers [16:35] Hello [16:35] <_mup_> juju/local-respect-series r449 committed by kapil.thangavelu@canonical.com [16:35] <_mup_> lxc unit deployment parameterizes series [16:36] andrewsmedina, that's with juju status -v ? does it eventually connect? what version of juju and which provider are you using? === SpamapS_ is now known as SpamapS [16:37] hazmat: Im using -v and using ec2 provider with openstack [16:38] my juju version 0.5+bzr443-1juju2~oneiric1 [16:41] andrewsmedina, does it eventually complete? right after bootstrap it can take some time for the remote machine to finish installation and get zk setup.. the client will retry automatically, so some of the zk messages are noise in that regard.. but that should stop after the bootstrap instance is fully functional === james_w` is now known as james_w [16:43] hazmat: in vm log "cloud-init boot finished at Wed, 25 Jan 2012 16:15:56 +0000. Up 1290.47 seconds" [16:43] are juju status slowly with openstack? [16:44] andrewsmedina, should be the same, it sounds like a connectivity issue perhaps based on zk not running [16:44] this looks like a timeout problem [16:44] andrewsmedina, what version of openstack? are you able to login into the machine? [16:44] I can ping and access the vm via ssh [16:44] diablo [16:45] andrewsmedina, its able to setup the ssh tunnel, and cloud-init is finished.. so i would imagine zk should be running unless there's an error [16:45] andrewsmedina, if you can ssh into the machine can you check if zookeeper is running (should be only java process) [16:46] hazmat: it's in the log too "juju-admin: error: unrecognized arguments: 2007-01-19 2007-03-01 2007-08-29 2007-10-10 2007-12-15 2008-02-01 2008-09-01 2009-04-04" [16:48] andrewsmedina, could you pastebin the log [16:48] andrewsmedina: that looks like maybe the metadata service returned bad data [16:48] or userdata service more likely [16:49] http://dpaste.org/FpsiB/ [16:51] Hello, as it's "Office Hours", is there somebody aware of ical server charms being written for 12.04? [16:53] Tim__, none that i know of.. the apple caldav server would be nice .. http://trac.calendarserver.org/ [16:53] lots of others out there though [16:53] Yes, or Davical. [16:57] andrewsmedina, thanks, could you pastebin the contents of /var/lib/cloud/instance/user-data.txt [16:57] andrewsmedina, fwiw there's a handy cli tool for this pastebinit [16:59] Tim__: best place to look is https://bugs.launchpad.net/charms [17:00] Tim__: if its not there, file it, as 'Charm Needed: ical server' with a description of the software you want to work on. Then assign the bug to yourself. [17:01] Thanks SpamapS, I will see if somethig is there [17:02] I do not expect myself to start writing charms a.t.m. still evaluating the usefullness for our organisation. [17:04] No bugs with "ical", "calendar" or "agenda".. [17:06] Tim__: could be as easy as 'charm create calendarserver' :) [17:06] or davical [17:07] Interesting... [17:07] calendarserver depends on memcached.. thats a silly thing to do since memcached is a network daemon [17:07] looks like davical uses postgres [17:08] I just saw davical. :) [17:08] Yes, davical can only work with postgres as far as I know. [17:08] I hadn't filed the bug on it yet, it does sound pretty awesome [17:09] SpamapS: robbiew: When we go to the openstack summit, you guys can roll on my bus: http://www.openstack.org/conference/san-francisco-2012/ [17:09] OH SNAP [17:10] heh [17:10] Apple's calendarserver won't always work on Linux. It's not supported by Apple. :-) [17:11] It would be nice to have something even 1/10th as good as google calendar that could be deployed for personal use [17:11] Tim__: are you interested in working on davical? That would be great [17:12] We created a bash script for an older version a few years ago, never actualy put it into production.. [17:13] Let me ask. [17:17] It should be dead simple to do since it is in the archive already [17:17] My colleague here says that bash script is not finished. Was based on some tutorial on the internet, [17:18] if you get that working it shouldn't be too much work charming it [17:19] Is postgress "charmd"? [17:19] Tim__: it is, though it needs some improvement to be tuned properly. [17:19] yup [17:19] Here's a good intro: https://juju.ubuntu.com/docs/write-charm.html#have-a-plan [17:19] of the things to think about before charming [17:21] Oo, good t-shirt idea [17:21] Write Charm. Have a plan. [17:22] http://bit.ly/xey5cj [17:22] with that image on it [17:23] Let me ask my colleague, maybe he is likes to do it..? [17:23] jcastro: ^^ [17:23] robbiew: ^^ [17:23] Tim__: that would be great! [17:23] We'd be more than happy to answer questions, etc. [17:24] SpamapS: heh...well you're free to make any shirt you want to pay for ;) [17:27] hi all [17:27] robbiew: yes, but its so much easier to incite you to do my evil deeds for me. :) you know you want that shirt [17:27] lol..good luck with that ;) [17:29] SpamapS: usshurper [17:29] jcastro: been thinking about it all week. :) [17:31] T-Shirt === niemeyer_ is now known as niemeyer [17:34] <_mup_> juju/local-respect-series r450 committed by kapil.thangavelu@canonical.com [17:34] <_mup_> propogate release series to machine agent and unit deployments from local provider [17:38] Me and my colleague could look into it at some point but we do not expect to finish before the 12.04 release. Nor would we support anything that's not direcly related to our own organisation. [17:44] m_3: ping [17:51] Tim__: that's fine, mostly working would be great, we can find someone to finish it [17:52] Tim__: and we keep the charm store open past release, we don't hard freeze charms until way after [17:52] SpamapS: actually, for LTSes we should keep that branch open for longer than the typical 6 months we talked about right? [17:52] jcastro: its open forever, all of them are... [17:53] jcastro: just that the dev focus changes to the new release of Ubuntu [17:53] oh, so when you guys said open for development, we don't close the old ones, right. [17:53] * jcastro nods [17:53] jcastro: so people wills till be able to push new stuff int o lp:charms/precise/foo for a long time [17:53] The only rule we're going to make there is that interfaces *must not* change. [17:54] We may also get heavy handed and say that upstream versions shouldn't change either. [17:54] But.. I kind of want to stay out of that water. ;) [17:54] that's why I want that --upstream switch in each one. [17:55] Yeah, maybe the default upstream version can't change. [17:59] Hi, I would like to know if is there a way to send parameters to an instance when using juju? I have a openstack private cloud and I would like to test juju. But I have a proxy and when I run 'juju bootstrap' the instance try to install some packages from an apt mirror. So, I need to tell the instance to use a proxy, or use my mirror. Is it possible ? [18:00] In a common instance I can use -f with euca-run-instances and send cloud-config files or bash scripts. [18:00] Jorge: your best bet is to override archove.ubuntu.com with your local mirror's IP in your local DNS [18:00] I'm running Diablo, installed from repo (ubunut oneiric). [18:01] OK. [18:01] Jorge: there are two bugs open that discuss this.. bug 809634 and bug 897645 [18:01] <_mup_> Bug #809634: allow additional user-defined userdata/cloud-config < https://launchpad.net/bugs/809634 > [18:01] <_mup_> Bug #897645: juju should support an apt proxy for private clouds < https://launchpad.net/bugs/897645 > [18:02] Jorge: If either of those would be helpful to you, it would help us if you noted that you are affected by them, and/or commented on them. [18:02] I'm going to note that bugs so! They really affect me! [18:03] I'm testing with a ubuntu cloud image. If I configure juju to use a customized image and I configure that image with the proxy environment variables, will it work? [18:03] Or juju just works with ubuntu cloud images? [18:04] Jorge: yes that will work fine [18:04] Jorge: you can specify the image id to use in environments.yaml [18:07] Great, i'm going to change my image! Thanks! :) [18:11] About the iCal server, whatever happens, the first thing needed is to report a bug at https://bugs.launchpad.net/charms correct? [18:12] yep [18:13] something like "Charm Needed: davical" [18:13] and then have a link to the project [18:13] also having a direct link to the project's install instructions can be helpful. [18:13] Ok, I will report a bug about it then. [18:19] * SpamapS needs to finish his dbconfig-common charm helper so we can just automatically charm all the packages that depend on it. [18:42] koolhead17: your conference pack is on the way! [18:43] jcastro: thank you sir!! i have 2 conf in feb now!! :) [19:41] Alright, I wrote a bug report for a iCal sever charm. https://bugs.launchpad.net/charms/+bug/921772 [19:41] <_mup_> Bug #921772: Charm Needed: iCal server for calendar/agenda functionality < https://launchpad.net/bugs/921772 > [20:10] hazmat: let me know when you have sometime [20:59] jcastro still here? [21:00] yep [21:01] The CalendarServer Debian maintainer like to have version 3.1 uploaded in 12:04.. that would be really nice. Current version is 2.4 https://answers.launchpad.net/ubuntu/+source/calendarserver/+question/185654 [21:02] He posted that yesterday. [21:03] ah so we need to turn that into a sync request. [21:04] I guess so? [21:08] I posted [21:08] basically, when he's ready, he can file a bug [21:08] and then someone will sync it [21:11] m_3: have you done your travel for strata yet? [21:12] Thanks, 3.1 would be a good basis to do that charming thingy on top of. [21:20] me too :) [21:21] jcastro: err rather, I posted too [21:32] Hi. Given this install hook http://pastebin.ubuntu.com/817000/ and this config.yaml http://pastebin.ubuntu.com/816999/ (notice installdir's default of /tmp/buildbot at the top) I get a failure to install, apparently because `config-get installdir` does not return a value. bac said he came here with a similar problem yesterday (using the same files/charm) and using the juju from the ppa fixed it for him, but I'm running fro [21:32] m the ppa (0.5+bzr447-1juju2~precise1) and no luck. Could someone help me diagnose this? [21:36] A demo of why I think config-get installdir is not working is that the install has "BUILDBOT_DIR=`config-get installdir`" and "juju-log "Creating master in $BUILDBOT_DIR"", and running ./install in juju debug-hooks results in "juju-log "+ juju-log 'Creating master in '" (notice the empty string) [21:36] SpamapS, any chance you have a sec for this? [21:37] "a sec" -> "some indeterminate amount of time, constrained by the fact that I will be at EoD soon :-)" [21:47] gary_poster: sure [21:47] gary_poster: I'm going to run out to lunch in about 10 minutes tho [21:49] SpamapS, cool. Can try again tomorrow. What can I do now? [21:50] gary_poster: did you try 'juju set your-service-name installdir=/something/that/makes/sense' ? [21:51] gary_poster, can you push the charm to lp.. per https://juju.ubuntu.com/Charms Contributing Charms [21:51] gary_poster, i can take a look at it [21:51] gary_poster: just to be careful, try wrapping /tmp/buildbot in quotes.. though I think yaml will interpret it as a string.. [21:52] SpamapS, no. I'll try. hazmat, ok thanks will do. We have it on lp now but in random crazy place (lp:~yellow/launchpad/buildbot-master) [21:52] gary_poster, anywhere i can get to it should work, if its already published [21:53] hazmat, ok cool. Yeah, bac has been working on this. It's public [21:53] gary_poster, are you deploying the charm with the config? [21:54] gary_poster, if you use juju set .. to set the config values, it won't be picked up till after the install hook has already run [21:54] hazmat in this case the question is why the default value is not being picked up [21:55] perhaps there is a bug [21:55] we did change some code in that area recently IIRC [21:55] yeah.. that config looks fine [21:56] yeah.. i changed the config values to be pick up defaults dynamically, instead of serializing defaults as initial values. [21:56] revno 446 === negronjl` is now known as negronjl [21:59] <_mup_> juju/ssh-known_hosts r485 committed by jim.baker@canonical.com [21:59] <_mup_> Merged trunk [22:18] fwiw, SpamapS, putting quotes around it in the default did not work. I didn't try the "set" because of what hazmat said (install will already have been run). I futzed around and the only other thing I discovered is that juju get buildbot-master gives my back the value I expect for installdir. [22:18] gary_poster, so deploying that charm, and using debug-hooks i do see installdir set correctly [22:18] http://paste.ubuntu.com/817054/ [22:18] from the install hook [22:18] that's the output of config-get [22:19] hazmat, so you see Creating master in /tmp/buildbotin the log also? [22:19] Though I was using config-get too [22:19] in the lxc [22:20] (I need to leave in 5) [22:20] gary_poster, it looks like its working correctly to me, i see a buildbot running [22:21] * hazmat looks around for a unit log to pastebin [22:21] hazmat, ok. So...something is wrong in my environment... [22:21] hazmat, are you on precise or oneiric? [22:21] though it is working fine for bac today, and was not yesterday mand he is on precise [22:22] gary_poster, but to clarify what are you using for a provider? and what value for default-series [22:22] hazmat, default-series oneiric; provider I'm guessing you mean lxc (rather than ec2) [22:23] gary_poster, here's the log.. http://paste.ubuntu.com/817057/ [22:23] gary_poster, yup thanks [22:23] gary_poster, i ran it on oneiric [22:24] bzr revno 5 of the charm [22:24] yeah, that's what I'm using too (though I had the same problem with 4) [22:25] ok...hazmat, so maybe I'll reinstall juju...? Not sure what could explain this so I'm at the rattle-the-windows-and-see-if-the-engine-starts stage [22:26] That log looks happy enough [22:26] gary_poster, could you pastebin the environ of the machine agent (from /proc/pid/environ) [22:26] its possible it was pointing to 'distro' instead of 'ppa' you where getting an old version of juju deployed [22:27] gary_poster, an easy way to verify is to set juju-origin: ppa in local environment section of environments.yaml [22:27] and if it works that its.. the environment of the machine agent would be more definitive/quicker to verify though [22:27] the environments.yaml change needs a new bootstrap [22:28] hazmat: the proc of what? the lxc instance? [22:29] gary_poster, the juju machine agent ... $ ps aux | grep machine should show it [22:29] its on the host [22:30] not the container, but it configures the containers with a base juju environment [22:30] got it. [22:31] hmm.. actually .. even better would have be a pastebinit of the master-customize.log in $data-dir [22:31] hazmat, http://pastebin.ubuntu.com/817062/ [22:31] $data-dir/units/master-customize.log [22:31] thanks [22:31] gary_poster, the environ thing has null chars, can't be piped readily [22:31] ah sorry [22:32] gary_poster, no worries that master-customize.log has even more info [22:32] bcsaller, is that lxc debug ready to land? [22:32] hazmat: afaik, yes [22:32] bcsaller, would be helpful to have a single script we could just ask people to run [22:32] thats why I wrote it [22:33] I might not capture everything thats useful in there now, but we can add to it, its a good start [22:33] hazmat, http://pastebin.ubuntu.com/817066/ is proc [22:33] I have to run go get child now or big trouble :-P [22:34] will leave this around and check back later or tomorrow [22:34] thank you hazmat [22:34] Also will get that file and send [22:34] bye [22:37] gary_poster, cheers [22:37] aha that was the problem [22:37] JUJU_ORIGIN=distro [22:39] ah.. i wonder.. if its a precise machine deploying an oneiric container, then distro represents two entirely different versions [23:38] hazmat: good example of why we shouldn't infer what the user intends just because they're deploying *from* a particular release of Ubuntu. :)