[06:58] <imbrandon_> you could probably draw some pretty successful conclusions on what info would be useful by mimicking the info found in say the Druapl plugin browser or the Wordpress Plugins Codex or the NPM Web registry for NodeJS modules , they have all successfully solved it and i'm sure what we should be adding is very similar I'm guessing. Just my 0.2c
[08:36] <m_3> jamespage: when you get a chance, can you see if http://paste.ubuntu.com/5697795/ has any hope of working wrt manpages?
[08:36] <m_3> followed up by the corresponding update-alternatives slaves in postinst
[08:37] <m_3> just don't know the best way to get the manpages built into /usr/lib/juju-xxx/man during install
[08:38]  * m_3 pbuilding it to test now
[08:38] <jamespage> m_3: that looks like what openjdk does
[08:38] <jamespage> so its prob OK!
[08:39] <m_3> ack... thanks!
[10:15] <m_3> mgz: got a sec?
[10:20] <m_3> nm... I see you're involved in other stuff
[10:20] <mgz> m_3: I do
[10:22] <m_3> just having a hell of a time moving forward with the alternatives for the manpages and wanted a sanity check
[10:22] <m_3> every time I go to test, the _versioned_ manpages were never installed
[10:25] <m_3> mgz: I'm trying for something like http://paste.ubuntu.com/5698017/ (also updated in my lp:~mark-mims/ubuntu/raring/juju/0.7 branch
[10:26] <m_3> I want them installed as _files_ and then I'll update-alternatives to install the actual man pages in postinst
[10:26] <mgz> hm...
[10:26] <m_3> but /usr/lib/juju-0.7/man is never created
[10:26]  * m_3 being thick
[10:31] <m_3> mgz: oh, wait... it just worked
[10:32] <mgz> woho :)
[10:32] <m_3> yeah, nice /usr/lib/juju-0.7/man/man1/xxx.1
[10:32] <m_3> now I'll just add more slaves
[10:32] <m_3> mgz: ok, thanks... mp shortly
[10:35] <m_3> I guess it's only appropriate that the packaging for "juju" be black magic
[10:57] <m_3> mgz: ok, that latest branch seems to work with manpages... I just noticed we should do alternatives for bash completion too... but shhhhhhh
[10:57] <m_3> I'll get on that one after I update my juju-2.0 packaging branch to reflect the changes we just made here
[10:58] <m_3> I think we've covered all of james' comments
[10:58]  * m_3 biab... more coffee
[12:17] <m_3> awesome, the purge is even clean now... no cruft left in /usr/lib/python2.7/dist-pacakges/juju
[12:49] <m_3> mgz: hey, ok... so bash_completion is versioned in my latest branch
[12:50] <m_3> testing upgrades from 0.6 -> 0.7 and then also installing 2.0
[12:53] <m_3> mgz: also updated lp:~mark-mims/juju-core/packaging-with-alternatives/ to use juju-core.{postinst,prerm}.in
[12:55] <mgz> excellent, I'm just doing ffe bugs now...
[13:15] <m_3> dang... I wish we could take this opportunity to change the control file
[13:15] <m_3> change some recommends stuff to suggests
[13:15]  * m_3 really hates accidentally install mesa and shit in test containers
[13:34] <jcastro> hey guys
[13:34] <jcastro> so thumper sent me a mail last night
[13:34] <jcastro> and says he can implement one of my ides
[13:34] <jcastro> and I told him to bring it up to the list
[13:34] <jcastro> but basically
[13:34] <jcastro> I wanted a `juju switch $environment` command
[13:34] <jcastro> so like
[13:34] <jcastro> juju switch production
[13:34] <jcastro> juju switch local-dev-laptop
[13:34] <jcastro> juju switch testing
[13:35] <jcastro> and so on
[13:35] <jcastro> and juju status would spit back an environment name too
[13:35] <jcastro> so you could do stuff and switch environments without dealing with environment variables or juan's epic dotfile collection
[13:37] <m_3> mgz: ok, so tips of lp:~mark-mims/juju-core/packaging-with-alternatives/ and lp:~mark-mims/ubuntu/raring/juju/0.7/ play really nicely together...
[13:37] <m_3> mgz: I testing upgrading 0.6 -> 0.7 and then also installing 2.0.... that worked beautifully
[13:38] <m_3> not sure what'll happen with going straight from 0.6 -> 2.0.... probably breakage
[13:38]  * m_3 trying that now
[13:39] <m_3> jcastro: sure, sounds good
[13:40]  * m_3 fantasizes about `jujush [env] > `
[13:41] <m_3> maybe just `jush[env]>`
[13:41] <m_3> shorter
[13:46] <m_3> mgz: can we change the control files so that juju-core-1.9+ can live with juju-0.7+, but _conflicts_ with juju-0.6 and lower?
[13:46] <mgz> hm...
[13:47] <m_3> I'd like to force an upgrade to 0.7 before folks try to co-install juju and juju-core
[13:47] <marcoceppi> jcastro: I like the idea
[13:47] <marcoceppi> I feel like it could be dangerous with juju destroy-environment (I know it warns, but still)
[13:47] <m_3> mgz: that kinda makes sense
[13:47] <mgz> yeah, we can do this
[13:48] <mgz> can do a conflicts on juju < 0.7... have the new juju0.7 package, and a juju metapackage with a higher version...
[13:48] <mgz> or something along those lines, bugging jamespage now
[13:48] <m_3> I think if you add juju-core to juju-0.6 and lower, then goju will just have its way with it... testing this now
[13:49] <mgz> apparently we want breaks and replaces instead
[13:50] <m_3> mgz: yeah, addnign 2.0 on top of 0.6 is not good... ends with a mix of the two
[13:52] <m_3> mgz: anyways... both of those branches are ready for another round of review
[13:54]  * m_3 back to scale testing
[13:56] <mgz> ace, will bring in, and push up
[13:57] <m_3> jcastro: btw... that's a perfect example (just like `juju publish`) for a command line plugin
[13:58] <m_3> i.e., stick a 'juju-switch' somewhere in your path (like $HOME/bin) and juju will catch it as a subcommand `juju switch`
[13:58]  * m_3 still wants that... bad
[13:59] <jcastro> m_3: yeah
[13:59] <jcastro> hey
[13:59] <jcastro> epic topic?
[13:59] <m_3> yup
[13:59] <jcastro> add it!
[13:59] <m_3> ack
[14:00] <m_3> there're _sooo_ many things we use that are natural plugins
[14:12] <jcastro> mgz: heya, http://www.rackspace.com/blog/ramping-up-our-openstack-investment-involvement/
[14:12] <m_3> mgz: btw, '--force' can safely be removed from 1.9.13's postinst, but has to be there in 0.7 to get a clean upgrade from 0.6->0.7
[14:12] <jcastro> "While  we believe some variation in implementations will be inevitable, we do want to eliminate as many of these as possible to provide as much of a common OpenStack experience as we can."
[14:13] <jcastro> this should make supporting rackspace easier I hope?
[14:19] <mgz> jcastro: that sounds like a big improvement
[14:19] <mgz> ...horrible debian packaging hack I'm not committing... http://paste.ubuntu.com/5698591/
[14:21] <mgz> jcastro: I don't see a mention of security groups, but for go juju at least there's a... sort of workaround (just don't use them)
[14:22] <mgz> console log and keypairs I'll personally welcome though, the undebuggability was what made me give up when I tried hacking something in
[14:22] <jcastro> mgz: I'm more inferring the desire to not be different
[14:22] <jcastro> like as an overalll goal
[14:23] <mgz> yeah, it's a good thing
[14:26] <m_3> mgz: nice... I've been hoping someone would pipe up with standards
[14:26] <m_3> just don't know them
[15:12] <SpamapS> mgz: what has been the challenge with supporting rackspace btw?
[15:13] <SpamapS> IIRC, they listed multiple endpoints for things in the catalog that confused our client libs?
[15:15] <SpamapS> m_3: there are standards.. but there are also LOTS of extensions (fully compliant w/ said standards) ;)
[15:17] <mgz> SpamapS: what I wrote down from when I poked it: <http://paste.ubuntu.com/5698755/>
[15:18] <SpamapS> mgz: for the security groups, seems like you can just bypass that in juju (as in, if exists(securitygroupsextension)...)
[15:18] <SpamapS> mgz: the other bits... WTF
[15:21] <mgz> right, I was prepared to hack around security groups somehow, but... got stuck on everything else when none of my normal debug tooling was working :)
[15:45] <m_3> sonne: yeah, no joke... that's been the hardest part... soooo many ways to do it all
[15:46] <m_3> sonne: sorry... wrong completion
[15:46] <m_3> SpamapS: ^
[16:21] <m_3> mgz: you need anything updated for the morning?  I'm gonna turn into a pumpkin in a sec
[16:22] <mgz> m_3: I think we're good, but if you could follow up on anything tomorrow while I'm travelling that would be great
[16:22] <mgz> I'll send and email with the current state of things tonight so everyone knows where we're at
[16:23] <m_3> mgz: ack...  I'm flying tomorrow afternoon UTC too
[16:23] <m_3> mgz: thanks!
[18:27] <marcoceppi> jcastro: is that juju_icons_source.svg anywhere?
[18:28] <jcastro> that is an excellent question?
[18:28] <jcastro> can you reply on list? I have jovan following along
[18:28] <marcoceppi> It would be great once this becomes policy to have the templated dropped in the charm root during charm create
[18:28] <jcastro> indeed
[18:28] <jcastro> that is quite clever
[18:28] <jcastro> <-- lunch
[18:47]  * koolhead17 looking for other Juju guy from Portland other than adam_g 
[18:49] <mgz> koolhead17: you will not be disappointed
[18:49] <mgz> at least next week only :)
[18:49] <koolhead17> mgz, hehe
[18:50] <koolhead17> adam_g, hola there. looking forward to see you sir :)
[22:46] <ahasenack> hi guys, I'm wondering if there is a way to inject a proxy configuration into juju-deployed units, even for the bits that juju itself needs to install before handing over to my install hook
[23:01] <SpamapS> ahasenack: https://bugs.launchpad.net/juju/+bug/897645
[23:01] <_mup_> Bug #897645: juju should support an apt proxy or alternate mirror for private clouds <cloud-init:Fix Released> <The Eilt project:New> <juju:Confirmed> <juju-core:Confirmed> < https://launchpad.net/bugs/897645 >
[23:01] <ahasenack> SpamapS: yeah, just found it
[23:01] <ahasenack> SpamapS: so no dice?
[23:02] <ahasenack> hazmat: around? Is there no way to inject a proxy configuration into the juju environment with pyjuju? Something that juju would use even before the install hook is called?
[23:08] <SpamapS> ahasenack: custom image.. :)
[23:08] <ahasenack> heh