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