=== 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 === BradCrittenden is now known as bac === wedgwood_away is now known as wedgwood === teknico__ is now known as teknico === defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz === defunctzombie_zz is now known as defunctzombie [14:47] m_3: hey so, review grouping/breakup/whatever we call it [14:48] jcastro: ack, should be easy to create a couple... just wanna minimize interruption of charm urls [14:48] * jcastro nods [14:54] SpamapS: I see m_3's comment on the puppet/puppetmaster mergre request, but then I see yours about " it may not be as cut and dry as usual" [14:54] SpamapS: ... so what do I do? :) [15:13] arosales: any changes you want to do to the survey? or just roll as is? [15:16] jcastro: which survey are you using, the general one? [15:17] Hi all -- what could be happening here: /var/lib/juju/units/lds-quickstart-0/charm/hooks/install: line 322: open-port: command not found [15:17] (command not found?) [15:18] dpb_: have you tried the `juju debug-hooks` command? [15:18] arosales: http://www.surveymonkey.com/s/ubuntu-juju [15:18] I believe you had me point it to a redirect thing [15:18] that you could swap in and out [15:18] dpb_: https://juju.ubuntu.com/docs/hook-debugging.html and/or https://juju.ubuntu.com/docs/write-charm.html [15:19] jcastro: yup, thats the correct one. [15:19] dpb_: it'll crack open a shell during the different hooks and you can interactively see whats going on [15:19] jcastro: I think that has the initial questions we want. [15:19] okey [15:19] chrischris: good idea [15:19] mramm: do you see any questions you may want to add to http://www.surveymonkey.com/s/ubuntu-juju [15:20] jcastro: I'll confirm with mramm real quick to see if any other questions may need to be added. [15:20] sure, no worries [15:27] chrischris: the problem is that open-port and all the other juju commands were installed in /usr/local, not /ust [15:27] chrischris: because environments had juju-origin: lp:juju [15:27] chrischris: probably some "make && make install" is used in that case, and it defaults to /usr/local [16:39] Anyone know the status of logstash-agent? === teknico_ is now known as teknico [16:42] It's listed on the charm store but when I try to deploy I see: 2013-03-19 11:35:32,569 ERROR Error processing 'cs:precise/logstash-agent': entry not found [17:01] robmoore: hmmm... lemme look [17:10] robmoore: grrrr.. it looks like the branch stacking is broken for that branch in launchpad [17:11] robmoore: lemme see if I can fix it === deryck is now known as deryck[lunch] === defunctzombie is now known as defunctzombie_zz === salgado is now known as salgado-lunch === defunctzombie_zz is now known as defunctzombie === deryck[lunch] is now known as deryck === salgado-lunch is now known as salgado === defunctzombie is now known as defunctzombie_zz [19:11] m_3: ok, new stacked branch created [19:13] stacked... :(... lemme think [19:14] ok, scratch that... so go to the lp page for that branch [19:14] and delete that branch [19:15] once it's deleted, start over [19:15] wipe your local repo [19:15] bzr branch lp:charms/alice-irc [19:15] ok sec [19:15] cd alice-irc [19:15] bzr init lp:~irc-charmers/charms/precise/alice-irc/trunk [19:15] bzr push lp:~irc-charmers/charms/precise/alice-irc/trunk [19:16] should be unstacked then [19:16] Using default stacking branch /+branch-id/589819 at bzr+ssh://bazaar.launchpad.net/~irc-charmers/charms/precise/alice-irc/ [19:16] Created a standalone branch (format: unnamed) [19:16] after the first command [19:16] so I think you're right? [19:16] push the second and we can see [19:17] I did [19:17] one sec [19:17] awesome... `triton:~ $ bzr info lp:~irc-charmers/charms/precise/alice-irc/trunk [19:17] sory, paste error [19:17] bzr info [19:17] standlone branch. \o/ [19:17] ok, lemme see if I can promulgate that one [19:18] hey so if we're redoing this and renaming promulgate to "promotion", I won't complain [19:18] haha [19:19] noooo [19:19] I knew that would get your attention [19:21] Hi === defunctzombie_zz is now known as defunctzombie === clong is now known as clong_brb [19:30] jcastro: ok, so everything looks good [19:30] jcastro: next up... [19:31] jcastro: wipe your local branch [19:31] jcastro: bzr branch lp:charms/alice-irc [19:31] jcastro: make a change [19:31] jcastro: and push it back up to lp:charms/alice-irc [19:31] change the readme as we'll keep that history [19:33] bzr push lp:~irc-charmers/charms/precise/alice-irc/trunk [19:33] as the push command? [19:33] nope [19:33] bzr push lp:charms/alice-irc [19:33] then we do forensics :) [19:34] done [19:35] ok, one sec [19:36] jcastro: sweet [19:37] jcastro: so you're not a charmer, but you made a change to a store-based charm by being in the group that owns the official branch [19:37] that's what we wanted right? [19:37] jcastro: yup [19:38] jcastro: so we can now make whatever "xxx-charmers" groups we want... [19:38] rock [19:38] so off the bat, the gui guys right? [19:38] jcastro: we'll consider making them the owners of the official branch... [19:38] under what conditions? [19:39] ~charmers is added to the group [19:39] what else? [19:39] +2 by charmers or something? [19:39] yeah [19:39] +2 seems to be fine [19:39] we give a lot of quality control over to the group [19:39] +2 is like our default policy for everything [19:39] SpamapS: marcoceppi: negronjl jamespage ^^^ [19:39] thoughts? [19:40] then reviews of group branches have to be reviewed by _either_ a group member or a member of charmers [19:40] So charmers needs to +2 anyone to be in that specific xxx-charmer group? [19:41] no [19:41] marcoceppi, that's my understanding ... [19:41] charmers needs to +2 any admins to that team [19:41] jcastro: care to explain ? [19:41] SpamapS: ah, just for the admins [19:41] SpamapS, thx [19:42] because admins can add anybody they want [19:42] I don't think charmers wants to be in charge of every team like that [19:42] negronjl: ok so tldr, we want to enable teams to take over a charm [19:42] jcastro: i got that [19:42] jcastro: just trying to be clear on the +2 part [19:42] it would be good to include, in policy, an admonition to charmers to educate admins of those teams how important the membership is [19:43] +2 from existing charmers to make a team and put people in it? [19:43] also those teams *must* stay closed.. no autojoining :) [19:44] jcastro: I think this is worth a mailing list discussion, but IMO, charmers should be able to create a team, own it, be the admins of it, and add non-admins, without any charmers +2's [19:44] agree with mailing list [19:44] think DM-Upload for Debian [19:44] ok so make up your mind, for the first 6 months you were like "don't make it debian" [19:44] now you're like "make it debian" [19:44] if a DD thinks you're good, and your key is in the DM keyring.. they can just let you upload [19:45] jcastro: Don't make it Debian. Don't throw out the GOOD parts of Debian either. [19:45] ok time to get on plane [19:45] just want to let you all know, good luck, we're all counting on you [19:46] heh [19:46] jcastro: I tend to agree that ~charmers create and own the groups [19:46] jcastro: no on openstack-charmers... that group already exists, but they want it isolated for development [19:47] jcastro: It seems to be simpler ( at least for now ) [19:47] ok [19:47] I will put that as the proposal on the list [19:47] and you guys ack/nack [19:47] jcastro: ok [19:48] * m_3 reading backchannel [19:50] jcastro: thanks... yeah, we can decide policy from the list [19:50] nod [19:51] jcastro: it takes a little bit to create the group and switch the branch ownerships around [19:51] jcastro: might be harder for larger existing sets of charms (i.e., take longer and be more interruptive of development) [19:52] so the only non-charmers branches we have promulgated atm is alice-irc (I think) [19:52] I'll leave that this way for a bit for more testing [19:53] but plan to revert that one charm to charmers-owned in the future and deleting the irc-charmers team [19:53] upstream has abandoned alice anyway, we should just blow it away when we're done [19:54] jcastro: ack [19:54] we'll have to see how that effects github migration plans [19:55] to be clear... nothing's been done with groups but testing so far... wanted to see it work [19:58] m_3 How does this change the namespacing? I'm assuming the lp:charms/... alias just points to lp:~xxx-charmers/... instead of lp:~charmers, right? [19:59] marcoceppi: xactly [19:59] Cool [19:59] marcoceppi: so there's a `charm promulgate --owner-branch ` [20:00] that doesn't require it to be lp:~charmers [20:00] otherwise it barfs [20:00] i.e., without the option [20:00] marcoceppi: btw, charm-tools help is pretty much borked as far as I can tell [20:01] marcoceppi: I think the fix to that is to make the top-level help stupider... and ust pass everything to the subcommand [20:01] m_3 As in "marco wtf did you do" or "fyi while you're poking around" [20:01] but I think we bounced back and forth on that one [20:01] ha! [20:01] marcoceppi: no... just while you're messing with it [20:01] Oh whew nothing I broke [20:01] Yeah, I've found it to be annoying too [20:01] right [20:02] totally [20:02] Everything should be handled by the subcommands, imo [20:02] agree, but really up to the person who takes the time to go fix it :) [20:02] The only help "charm" should have is listing the available subcommands [20:02] ;) === BradCrittenden is now known as bac [20:05] yup [21:03] jcastro, that's awesome re surge Edicts.. http://pastebin.ubuntu.com/5629367/ [21:09] that is cool [21:53] ok, so for pyju and goju to live together on the same machine... [21:54] update-alternatives... no biggie [21:54] here's the question: [21:54] should we have versioned binaries.... i.e., /usr/bin/juju points to /usr/bin/juju-0.7 or /usr/bin/juju-2.0 [21:55] and so open-port would be [21:55] /usr/bin/open-port-0.7 and /usr/bin/open-port-2.0 [21:55] --or-- [21:55] versioned directories? [21:55] /usr/bin/juju points to /var/lib/juju/0.7/juju [21:55] and /usr/bin/open-port points to /var/lib/juju/0.7/open-port [21:56] any opinions? [22:00] I feel like, versioned directories is better? The only thing I've used update-alternatives for is java and that uses versioned dirs [22:01] I think Python does it via versioned binaries though [22:02] I think that versioned directories is better as well. [22:02] I see a small amount of users trying to do juju-0.7 vs using update alternatives, whereas I think versioned binaries makes more sense for something like Python [22:28] cool... thanks y'all [22:37] SpamapS, you mentioned another oasis standard around the orchestration topic i think.. do you remember the name? [22:48] hazmat: OASIS/CAMP [22:50] SpamapS, thanks [22:50] that looks pretty paas focused [22:50] but i can see the cf lineage now [22:53] hazmat: versus juju which only looks like a paas when you read the charms.. ;) === wedgwood is now known as wedgwood_away