[00:08] zirpu: awesome [03:32] <_mup_> Bug #1017792 was filed: running relation-get with no client id gives misleading error < https://launchpad.net/bugs/1017792 > [03:48] is this expected? : charm proof . [03:48] E: could not find metadata file for . [03:48] E: revision file in root of charm is required [03:48] but [03:48] charm proof $(pwd) [03:48] works fine [04:20] <_mup_> Bug #1017801 was filed: juju tries to delete in-use security groups < https://launchpad.net/bugs/1017801 > [04:21] Hi guys [04:21] I have a question [04:21] Where do I get layman definition of what juju does for me? [04:22] it deploys software for you, into cloud environments like amazon ec2, rackspace, and so on. [04:22] so, applications from my dev environment into EC2, cloudfoundry etc? [04:22] juju manages all the connections between different services, like getting your webserver behind haproxy, or setting up new hbase cluster nodes. [04:22] yes, that sort of thing [04:23] there is in fact a charm to deploy cloudfoundry itself. [04:23] define charm? Sorry, I am a noob [04:25] a charm is the rules for deploying a specific piece of software [04:25] imbrandon, pingy [04:25] foine. [04:56] MarkDude: heya man [04:56] * MarkDude needs those links again [04:56] about to crash :) cool one sec [04:56] making the Fedora juju page now [04:57] Have some folks willing to test [04:57] btw i plan on making some new ones in the next day or so ( juju is about to do a minor release ) [04:57] and i'll refresh them at the same time [04:57] kk links, brb [04:57] we have a few Fedora Ambaassadors that are also Ubuntu Memebers [04:57] nice [04:57] let em know they are more than willing to hang out [04:58] and if we get tooo off topic we'll make a #juju-fedora chan [04:58] :) [04:58] or #juju-ports , actually not a bad idea [04:58] hrm [04:58] ok [04:58] http://jujutools.github.com/rpm-juju [04:59] btw i made a page about them for the offical docs [04:59] but the docs have a build issue atm, soon as thats worked out ( today hopes ) then there will be links to it in the official docs too [04:59] etc [04:59] MarkDude: ^^ [05:00] docs are linked at http://juju.ubuntu.com btw, pretty sure that was obvious tho [05:00] but just in case [05:00] but yea, sometime in the next 24hrs i'd say maybe 48 tops there will be a minor version refresh [05:01] so it will be perfect timing for their feedback and i might be able to slip stuff in if its not a core bug [05:01] etc [05:01] right away in those cases [05:02] Sorry, but the page you were trying to view does not exist. [05:02] oh and you saw my "Download for Ubuntu" JS/CSS button thing ? I made one for Fedora and OSX too, might for SuSE as well if i get bored [05:02] i'll link ya up [05:02] bah [05:03] let me go look [05:03] i did that from memory [05:03] heh [05:03] https://github.com/jujutools/rpm-juju [05:03] there we go [05:03] sorry bout that [05:04] anyhow like i said i got a little bit of docs and such creeping in tho todayish so that will help them too [05:09] okies man, i'm about to crash, been a long day, hit me up anytime at imbrandon@ubuntu.com too if you dont catch me on IRC [05:10] MarkDude: and there is a bug tracker on linked on that RPM page too "Issues" if anyone ways to report something [05:11] Cool- I will include your email on the page to [05:11] thx imbrandon [05:11] i'll do the leg work and figure out if its a rpm specific issue or core one and file them in LP on their behalf if its core so they wont have a escuse not to report it :) [05:12] cool cool, where ya posting this btw ? [05:14] https://fedoraproject.org/wiki/Juju [05:19] rockin, ok i'm off to bed man, take it easy [05:19] sorry to run on ya :) === nijaba_ is now known as nijaba === smoser` is now known as smoser === almaisan-away is now known as al-maisan [11:04] I'm working on my charm again. Getting rid of the sqlite kludge so I can aim it at postgresql. Exciting times. [11:27] jml: enjoyed your blog posts BTW [11:27] jamespage: thanks :) [11:27] agree that its quiet here in the mornings.... [11:28] yeah [11:29] juju is the first command-line tool I've used in a long time that makes me think "this should have a GUI" [11:36] uhh, how do you get the port from the postgres charm? === al-maisan is now known as almaisan-away [11:39] is it correct to just assume the standard port? [11:52] I'm writing a script to call juju for my users. Is there a way to get the public address of the only deployed unit? (Would prefer the exposed service URL, tbh.) [11:59] why are stacks any more difficult than, say, a .dot file? [12:05] what I want is something that looks at my local charm, detects whether there are any changes between it and the last deployed charm, and if there is, add --upgrade to my deploy call. [12:05] what I want is something that looks at my local charm, detects whether there are any changes between it and the last deployed charm, and if there is, add --upgrade to my deploy call. [12:05] i.e. I want 'make' [12:05] (sorry for double entry. keyboard error.) === zyga is now known as zyga-afk [12:40] jml, hmm [12:40] jml, the postgresql does assume default port [12:40] charm that is [12:41] jml, the only way I know to get it to automatically update charms is to bump the version number in the revision file manually before doing a deploy [12:41] but I often forget todo that - and have to use --upgrade anyway [12:42] well, the real question is how do I detect that the version number needs bumping [12:43] the environment has a copy of the charm stored somewhere, presumably [12:44] if I could get that, it would be easy to ask "do your copy and my copy differ? if so, bump my version. if not, great." === zyga-afk is now known as zyga [12:45] jml, it does === zyga is now known as zyga-food === benji___ is now known as benji === zyga-food is now known as zyga [13:57] Quick question, one of my web sites uses a node.js server. It is suppossed to open port 8080 which does not happen. What is the best way to open this port, including it in the charm? [14:11] surgemcgee: You can include it in the charm if the charm requires the node.js server etc. If you need to just ad-hoc open it you can do that with juju-jitsu [14:11] Ideally if the charm users it/needs it it should expose it [14:23] Im trying to debug some problems I am having with the swift charms. anyone else working on these, or using them? [14:47] adam_g: ^^ jaustinpage needs help w/ swift [14:47] jaustinpage: adam_g wrote them === zirpu_ is now known as zirpu [15:21] SpamapS: thanks for the info === jaustinpage is now known as japage2 [15:38] japage: curious, what issues are you having w/ swift? [15:43] japage: I'm working with the swift charms, what are you seeing? [15:47] juju folks; I've got 11 nodes in my MaaS cluster, and 11 machines created, with 11 total services on them. When I attempt to add a unit to one of the services, it adds a 12th machine in state pending, assigns the unit to that machine, and nothing ever happens. Is there a way to make juju use an existing machine to host the unit, or what? [15:48] So far the behavior seems to be one service unit per machine. [15:52] cheez0r - I seem to be seeing some sort of error when i try to create the connection between swift-storage and swift-proxy [15:53] It is like the swift-relation-changed function is not able to add the storage nodes for some reason [15:54] cheezor: i dont think you can push more than 1 service out to a node [15:55] that's awfully strange. [15:55] I should be able to, for instance, run nova-compute and swift-storage on the same node. [15:55] cheez0r: I agree [15:56] cheez0r: have you been able to deploy swift to 4 or more machines, and get the relationship between swift-proxy and swift-storage working/ [15:56] no. [15:56] *? [15:56] I have not pursued the relationship at all [15:56] hmm, ok [15:57] I'm right now working on getting swift-storage on multiple nodes- but I'm out of nodes [15:57] im cheating, im using vm's to test, so I can create more nodes as needed..... [15:57] nice. [15:57] I've been trying to deploy a whole MaaS/Juju/OpenStack cluster on HP Blade hardware. [15:58] for about a month. [15:58] cheez0r: everybody has asked for the ability to run two things on one machine [15:58] a month? the rest of the openstack charms seem to be working well, at least for me. [15:58] cheez0r: but as yet, that feature is not implemented in juju [15:59] cheez0r: part of the reason being that juju was envisioned first as "apt-get for the cloud" not "openstack deployment tool" [15:59] japage: I've had many issues that have roadblocked me [16:00] cheez0r: so, with the cloud, you just size your VMs right [16:00] SpamapS: yeah, si comprende [16:00] The more I work with juju + openstack the less I think they're a good pairing [16:00] cheez0r: but w/ real hardware, you get what you get [16:00] but perhaps that's going to improve as juju evolves [16:00] cheez0r: Its the #1 feature request [16:01] cheez0r: I think it will land as the first feature after the go port is done. [16:01] I've been "accidently" using juju/maas exactly as intended... === japage is now known as japage_afk [16:03] SpamapS, hey - you appear to be chair for our team meeting today! [16:03] still OK for that or do you want to slide to me? [16:04] SpamapS: thanks for the info man, very helpful. [16:14] 'morning all === jamespage is now known as hazmat_mk2 === hazmat_mk2 is now known as jamespage [16:36] negronjl: are you stalking the halls of Velocity as well? [16:44] SpamapS: I may go back there tomorrow but, not today [16:44] SpamapS: Did enough stalking yesterday :) [16:49] SpamapS, trying to upload a branch for co-location, but network here is choppy, going to hit up the speaker lounge and hardline it post plenaries [16:49] re jitsu [17:02] hazmat: sweet === EvilBill_ is now known as EvilBill [17:06] hello all === japage_afk is now known as japage === zyga is now known as zyga-afk [18:39] morning y'all [18:41] lifeless: howdy [18:43] SpamapS: o/ [18:43] hey, so did you see my query about proof? [18:43] 15:48 < lifeless> is this expected? : charm proof . [18:43] 15:48 < lifeless> E: could not find metadata file for . [18:43] 15:48 < lifeless> E: revision file in root of charm is required [18:43] 15:48 < lifeless> but [18:43] 15:48 < lifeless> charm proof $(pwd) [18:43] 15:48 < lifeless> works fine [18:44] lifeless: that does not make much sense. [18:44] <_mup_> Bug #1018059 was filed: Disable fsync on zk to speed tests. < https://launchpad.net/bugs/1018059 > [18:44] indeed. [18:45] <_mup_> Bug #1018061 was filed: Disable fsync on zk to speed tests. < https://launchpad.net/bugs/1018061 > [18:45] would you like a bug, and if so where [18:45] lifeless: if args.charm_name: charm_name = args.charm_name [18:45] else: charm_name = os.getcwd() [18:45] <_mup_> Bug #1018062 was filed: teminate-machine should provide and option to '--force' < https://launchpad.net/bugs/1018062 > [18:46] charm proof [18:46] usage: proof [ charm_name | path/to/charm ] [18:46] lifeless: charm proof . works for me in all my charms [18:47] as does no argument, which assumes . [18:47] http://paste.ubuntu.com/1061284/ [18:47] SpamapS: I'm running precise. [18:47] SpamapS: does that make a difference? [18:47] no, I am too [18:48] tho I might have a more current charm-tools [18:48] the one in precise is pretty old by now [18:56] lifeless: I think that bug is fixed in trunk basically. [18:57] hokay [18:57] * lifeless suggests more SRU is in order [18:58] lifeless, http://paste.ubuntu.com/1061301/ [18:58] should fix it [18:59] * hazmat submits a branch [18:59] actually this easier to cowboy ... SpamapS, m_3, jimbaker` any objections to the one liner above [19:02] hazmat, +1 [19:02] hazmat: if you think that corrects the problem (a problem I don't have or see) then yes, just commit and push [19:02] hazmat: please run 'make check' too [19:02] hazmat: charm-tools has tests [19:02] hazmat: consider maybe adding a test for this :) [19:04] hey juju guys, I just want to confirm that I understand this: Juju does not support specifying which node a charm is to be deployed to, right? It just pulls a node from what's available? [19:04] All of the reading I've done on this topic has left me with that understanding; I'm just trying to confirm I'm right. [19:04] cheez0r: yes thats correct [19:04] Thanks SpamapS! [19:04] cheez0r, yes at the moment, re jitsu extensions that capability is coming soon [19:04] hazmat, my only objection to this code is that charm_name and charm_path are rather conflated here [19:04] but that's the existing case [19:04] jimbaker`, that's the entire script [19:05] indeed [19:05] jimbaker`, feel free to rewrite [19:05] hazmat, i'm sure there will be some opportunity :) [19:06] I believe we have a lot of refactoring to do in charm proof [19:07] I'd even be open to changing the name to something else, since proof was a play on 'principia mathematica' [19:13] SpamapS, is trunk open? [19:16] hazmat: tonight [19:17] SpamapS, ack, i just closed out the galapagos milestone [19:17] hazmat: actually, screw that [19:17] closed? [19:17] SpamapS, if you have a separate branch, why are we gating trunk [19:17] I mean to creat an actual release [19:17] I have no branch [19:17] Its a psychological freeze [19:17] SpamapS, the distro branch? [19:17] meant to get you guys to *test* it [19:17] hazmat: right, the distro package is a quilt stream. ;) [19:17] hazmat: anyway, lets just open trunk, I'm going to tag 0.5.1 as trunk [19:18] SpamapS, ack [19:18] hazmat: I meant to create a release from the galapagos milestone [19:18] err, I'm going to tag r544 as trunk [19:18] SpamapS, i just did, its just a label though no tarball attached [19:18] https://launchpad.net/juju/+milestone/galapagos [19:18] I'll do tarballs if somebody requests it [19:18] but I don't really see a need [19:19] tag is fine [19:19] hazmat: I was going to bump the version in setup.py too [19:19] SpamapS, sounds good [19:19] hmm wait, natty and oneiric still FTBFS [19:21] hazmat: can you hold just a bit longer on lp:juju ? I want to make sure natty/oneiric build [19:21] pretty sure this is buildds being slow, not a real problem [19:21] hazmat: heh, tho your fsync change might be a solution for that [19:22] SpamapS, sure, just want to greenlight the sub port change and the fsync stuff in [19:22] SpamapS, perhaps.. some of the status setup tests need exorcism [19:22] they setup the world and examine a fraction [19:22] and worse they get used by other tests as a base [19:22] hazmat: I'm tempted to just make a branch for 0.5, and do any fixes in there [19:23] SpamapS, hmm [19:23] which is probably what we should do, but I liked the idea of taking a week to actually use/test the release [19:23] SpamapS, branch for stable or branch for features, either sounds reasonable [19:23] SpamapS, afaik the next major incompatible feature is upgrade support [19:24] hazmat: I was thinking we should start honolulu by adding a feature which which makes arbitrary PPA selection possible so we can add PPA's and keep ppa:juju/pkgs stable [19:25] SpamapS, effectively the upgrade stuff has support for things ... like that [19:25] I was hoping you'd say that [19:25] ie. arbitrary release url support [19:25] you can point it to any directory of releases [19:26] https://code.launchpad.net/~juju/+archive/pkgs/+build/3600404 .. once that builds.. I'll commit the 0.5 -> 0.5.1 change and release that as 0.5.1... [19:26] Then I was thinking I'd alter the PPA build recipe to pull from a stable series, and create a new PPA for trunk [19:26] * hazmat needs an osd notify for website changes [19:26] SpamapS, +1 [19:27] hazmat: what would you say to shortening honolulu to just 3 weeks? Basically just merge everything that is approved already, and wrap up the zk acl work? [19:27] SpamapS, why? [19:27] hazmat: so we can get the zk acl work out faster. :) [19:27] SpamapS, your setting what feels like arbitrary deadlines [19:28] doesn't make anything go faster [19:28] hazmat: no, this would get us back on the 6 week cadence. [19:28] since we're 3+ weeks late [19:28] SpamapS, but why are we late? [19:28] Because nobody cares about releases except me [19:28] and I've been busy/distracted/etc. [19:29] SpamapS, i think its more about the num of developers assigned to py juju atm [19:29] well we didn't delay it for want of features/bug fixes [19:29] just.. time to organize the release [19:30] the whole point of having a cadence is to just ship what we have when the day arrives. [19:30] that way people don't feel rushed to push things that aren't ready, because they know they will see a release in 6 weeks [19:30] but yeah [19:30] w/o developers this is a bit moot :) [19:31] jimbaker`, hows the sec group rework coming? [19:32] https://launchpadlibrarian.net/108722045/buildlog_ubuntu-natty-i386.juju_0.5%2Bbzr544-1juju5~natty1_FAILEDTOBUILD.txt.gz [19:33] jimbaker`, ^ [19:33] new format bug [19:33] that has failed 3 times in a row [19:33] works fine on precise and quantal [19:36] hazmat: I'm tempted to just merge in your no fsync change and see if that solves it [19:53] hazmat, i'm currently sick, so not so much progress yet [20:01] m_3, your in au? [20:01] jimbaker`, ack, thanks for the update [20:04] SpamapS, that failure is odd if its rel specific, its the same py version, and same major libyaml [20:04] SpamapS, do we even care about pre oneiric? [20:04] hazmat: not much no, but oneiric fails too [20:05] hazmat: its more that I want to know why, not that I want to care about oneiric/natty [20:07] ok appt time [20:07] hazmat: bbiab.. I'd be fine w/ pushing the fsync change into trunk.. if that solves it, we'll ship it with 0.5.1. :) [20:16] bcsaller, do you have time to debug ^ [20:18] hazmat: you mean the libzk deadlock thing still? [20:18] I have looked at it but didn't finish it yet, I can poke at it again today [20:18] bcsaller, no the test failure on oneiric [20:19] looks like natty [20:19] bcsaller, the libzk deadlock with security isn't critical, the test failure (see build failure link above ) is the problem [20:20] bcsaller, SpamapS mentioned it also exhibits under oneiric [20:33] hazmat: it looks like the default json module would have to fail for this to break, but I'm spinning up an instance [21:12] what I think of when I think of juju & puppet: http://tinyurl.com/yfn5wn9 [21:31] jml, why? === salgado is now known as salgado-afk [21:55] sidnei: puppet. juju. think about it. (I guess it might not translate well.) [22:06] jml: bad man :P [22:32] jml: Hahahah thats fantastic [23:21] ahhh finally .... it lives !! http://bholtsclaw.github.com/showdown/ [23:23] imbrandon: ping, question, do you have a mailman charm? [23:23] i do not, there MIGHT be one [23:23] but i would need to look hadent seen one around yet [23:23] that was what I was asking, not you, in general :P [23:23] if you see one, let me know [23:24] you can check on the store [23:24] it shows all of them [23:24] and the ones in-porogresss [23:24] as well [23:24] progress* [23:24] one sec i'll get you the exact link [23:24] it's not there, so I assume there's no mailman charm [23:25] yea if there isnt one there and you dont see it in the ~queue the other place to look is a bug against juju charms [23:25] but i think those show in the in comming queue [23:25] ( maybe not without a branch , not sure ) [23:25] but yea [23:26] if its not there then nope and its fair game, if it is there but no one worked on it in 30 days [23:26] then it is also fair game but still probably nice to ping the other party if its practial to do so [23:26] but thats just "best" really [23:27] SpamapS: i guess no word from RT ? unfortunate :( [23:28] I'll see, I may write one if I have time [23:29] even if your doing it shelfishly and then push what you have to your own branch on LP like ~lpip/charms/precise/mailman [23:29] then someone else has a start on it when they go to finish etc [23:29] great [23:29] mental note taken [23:29] so even partial charms are nice to keep on LP in your name too even if not ready for the store for whatever reason [23:30] and if you push to a branch named like that me or anyone can install your version of the charm too like [23:30] juju deploy cs:~lpid/precise/charmname [23:31] :) [23:31] that's great, JoseeAntonioR didn't know that [23:31] yup yup. thje docs are actually prettu good on the basics [23:32] some things and adv stuff a little dated [23:32] but for most projects i've been on ours are fantasic compared [23:32] even though we;re actually trying to make them even better still [23:32] :) [23:33] http://www.jujucharms.com/docs [23:34] anyone that is in charm-contributors can commit or do a merge preposal too so alot of ppl can help like a wiki but cleaner [23:34] and easier to manage :) [23:34] * imbrandon gets back to his charm for now, havent actually done any juju stuff at all today yet [23:36] :P [23:36] go for it [23:42] SpamapS / m_3 ( and everyone ) I almsot forgot to mention it since i've been not in #juju most of today, there is now a #juju-ports ( with pointers to here if all are afk ) for OSX and Fedora Peeps ( and others as more come ) to collab and get support and not clutter here if not needed [23:43] its on the irc teams radar too as part of the official juju- namespace etc, and Markdue put the word out over there and we already have a few ilders [23:43] ( like 3 ) [23:43] just kinda FYI