[00:00] <SpamapS> RichardRaseley: its possible MaaS can be coaxed to own nodes w/o PXE... but it definitely requires its own pre-seeded install to be in charge of the machine.
[00:01] <RichardRaseley> Can you create classes of machines in MaaS, for example I might configure hardware in such a way that it is specifically for swift-storage
[00:01] <RichardRaseley> or swift-proxy
[00:01] <RichardRaseley> or nova, etc.
[00:02] <SpamapS> RichardRaseley: that is the plan, but IIRC, not in the current release. Right now the only constraint juju+maas suppors is (don't hit me) server name. :)
[00:02] <RichardRaseley> Ha
[00:02] <RichardRaseley> OK
[00:02] <SpamapS> which, btw, I think is a huge mistake ;)
[00:02] <SpamapS> should have been class, not name
[00:02] <RichardRaseley> Again, it is dissapointing because it takes Juju off the table for us in the foreseeable future. =[
[00:02] <SpamapS> but, I think time ran short on dev and they wanted to get something out for Ubuntu 12.04
[00:02] <RichardRaseley> Anyways - I have to go - time got away from me.
[00:02] <RichardRaseley> thanks for the conversation.
[00:03] <SpamapS> RichardRaseley: :) thanks for your interest!
[00:04] <xmltok> do the juju charms for openstack build openstack quickly and easily on maas already? i have a few POC investigations into openstack and maas right now, juju was going to come later
[00:04] <xmltok> perhaps it should be maas, juju, then openstack.
[00:05] <SpamapS> xmltok: yes, there's a bit of polling/sequencing that needs to be refactored (juju grew some new things recently that alleviate the need to order the deployment) so it should get even better/faster soon.
[00:06] <SpamapS> xmltok: we had the deploy/destroy on a loop at ODS ... it would just bring up all 8 nodes w/ openstack, then tear them back down, over and over. I think it takes < 10 minutes on crap hardwware.
[00:06] <SpamapS> xmltok: (assuming a fast mirror :)
[00:06] <xmltok> nice
[00:06] <xmltok> encouraging
[00:07] <SpamapS> xmltok: I think the instructions to do it are hiding somewhere on wiki.ubuntu.com
[00:07] <xmltok> i have high hopes for juju. i would like to replace the lion's share of our app deployment with it
[00:07] <SpamapS> xmltok: https://wiki.ubuntu.com/ServerTeam/MAAS/Juju
[00:07] <SpamapS> xmltok: \o/
[00:08] <xmltok> yep, seen that guy. are you very familiar with maas? I was wondering how it triggers builds, i didnt see ipmi hooks or anything like that
[00:09] <SpamapS> xmltok: it uses cobbler on the backend
[00:09] <SpamapS> xmltok: so, any power control that cobbler supports
[00:09] <xmltok> got it
[00:09] <SpamapS> xmltok: though I think there is a strong desire to take cobbler out of the loop
[00:09] <SpamapS> since it kind of complicates things
[00:09] <SpamapS> xmltok: so, IPMI is supported, WoL, a few other things
[00:10] <SpamapS> alright, I have to run
[00:10] <xmltok> we have rackable/sgi blades, and none of them have ipmi or wol. garbage.. but we do have scripts to locate nodes and control the power
[00:10] <xmltok> thanks for clearing some things up
[00:10] <SpamapS> xmltok: good luck.. we're all counting on you. ;-)
[02:52] <hazmat> jimbaker, that jitsu do thing needs a serious warning
[02:53] <hazmat> that its executing locally without any access to the charm or remote unit
[02:53] <hazmat> ie. its a remote hook context on a local script
[07:08] <bkerensa> imbrandon: let me know what day is going to work best for the Cloudflare tour so I can set it up with their CEO
[07:10] <imbrandon> bkerensa: kk will do , i'm thinking probably monday late afternoon OR wed lunchish , but let me confirm that first and think a bit more
[07:11] <imbrandon> just wakin up so not fully aware of my brain yet
[07:11] <bkerensa> yeah just ping the others and see what works best and I will make it happen :P
[07:20] <imbrandon> kk, not 100% whom all besides me, gonna TRY and drag jcastro and marcoceppi at minimum maybe SpamapS if he wants to he would love it too but not sure what their schedules are gonna be like i know clints is booked and i bet jcastro;s is tooo
[07:21] <imbrandon> hell mine is for that matter
[07:21] <imbrandon> lol
[07:21] <imbrandon> but i'll make time
[07:21] <imbrandon> ill try to find out from them sometime today if i can tho
[12:57] <gmb> Hi all. A quick question: I'm working on something for UDS and what I really need is a way of having Juju start up all the nodes for a particular charm using a specific AMI. Obviously I can't use default-image-id or default-ami in environments.yaml any more to do this. Is there a way I can do it with juju set-constraints, or when passing --constraints to juju deploy?
[12:57] <gmb> I can't find any reference to it in the constraints documentation.
[14:20] <SpamapS> gmb: default-image-id still works, its just not recommended since you lose the ability to specify most of the other constraints since your image id might not boot on all instance types.
[14:21] <SpamapS> gmb: what exactly do you want on this image id though? As a potential judge for the charm contest, I'd dock points for needing a specific image.
[14:27] <jcastro> SpamapS: group hug bro
[14:28] <gmb> SpamapS, Here's the scenario:
[14:28] <gmb> We're running Launchpad clinics at UDS
[14:28] <gmb> It takes a long time to set up LP on you machine
[14:28] <SpamapS> jcastro: :)
[14:28] <gmb> Instead of requiring it for everyone who wants to take part we'll sping up EC2 instances with LP already set up (add keys and bzr whoami and Bob's your Auntie's live in lover)
[14:29] <gmb> It's be lovely if I could just type juju delpoy ... and pass it some config options rather than having to spent time faffing around. Of course, I can script it myself, but Juju is nicer :).
[14:29] <SpamapS> gmb: there's an enormous advantage to using the charm's install hook rather than an image id.. mainly that you don't have to then duplicate your image id in ever region and architecture you want to use.
[14:30] <SpamapS> every region, rather
[14:30] <gmb> SpamapS, In this instance, I'll take the advantage of not having the install hook take 40 minutes.
[14:30] <SpamapS> gmb: wtf!
[14:30] <SpamapS> 40 minutes?!
[14:30] <gmb> I told you: LP takes a long time to set up.
[14:31] <SpamapS> gmb: I've thought long and hard about having juju take a system snapshot right after the 'install' hook runs, and then using that for subsequent add-unit's
[14:32] <gmb> SpamapS, So would I if I'd known that was an option... tell me more!
[14:32] <SpamapS> gmb: well its not
[14:32] <SpamapS> but it might be doable with very little coding.
[14:32] <SpamapS> :)
[14:33] <SpamapS> gmb: 40 minutes is indeed totally unacceptible for an install hook.
[14:33] <SpamapS> gmb: what in blazes is it doing for 40 minutes?
[14:35] <gmb> SpamapS, Installing builddeps, getting the source, building the source... 40 minutes is, I'll grant you, on the far edge of normal. On a good day, though, it's still in the tens of minutes.
[14:35] <gmb> You could file this under "buildout is a bugger"
[14:35] <gmb> BUt that might be unfair.
[14:36] <gmb> SpamapS,  Anyway, my point is that I want to be able to spin up a new instance quickly, and Juju would let me do that. But I accept that I might not be doing things the right way (and I wouldn't do things this way for general usage).
[14:37] <gmb> Also, default-image-id makes Juju shout at me and exit. How can I make it not?
[14:38] <SpamapS> gmb: there's still a way to use image ids, I just forget it now
[14:39] <gmb> SpamapS, Hum. Okay. If you remember it let me know. I'll investigate alternatives anyway, since I acknowledge that this way of doing things is a bit mucky.
[14:40]  * gmb -> otp
[14:41] <SpamapS> is juju.ubuntu.com down?
It works!</h1></body></html>
[14:41] <SpamapS> Oh, I didn't give a Host: header
[14:43] <SpamapS> not down, but very slow
[14:44] <SpamapS> probably related to the www.ubuntu.com problems -P
[14:44] <SpamapS> http://www.ubuntu.com/ ... wtf? Why are there 18 miles of whitespace on each side of that page?
[14:45] <marcoceppi> SpamapS: I don't see much white space
[14:46] <SpamapS> marcoceppi: how wide is your window?
[14:46] <SpamapS> mine is about 1440 pixels wide.. ;)
[14:47] <marcoceppi> 1920
[14:47] <marcoceppi> well 1920 x 2
[14:48] <SpamapS> maybe its a chrome thing..
[14:48]  * marcoceppi is using chrome
[14:48] <SpamapS> ah Ok for whatever reason I was zoomed out a bit
[14:49] <SpamapS> but its still *a lot*
[14:49] <marcoceppi> yeah, the default ubuntu template has a bit of white space :)
[14:50] <marcoceppi> since it's only 980px wide
[14:51] <SpamapS> http://imgur.com/9bRxv
[14:51] <SpamapS> hideous
[14:52] <marcoceppi> wow
[14:52] <marcoceppi> that is a lot
[14:52] <marcoceppi> http://i.imgur.com/BfKhe.png
[14:53] <marcoceppi> I feel like yours is more zoomed than mine
[14:55] <SpamapS> I went to Actual size
[14:55] <SpamapS> but, yeah, I get that a lot
[15:04] <gary_poster> SpamapS, some installations take a long time--40 minutes or more might represent an outlier, but not a "wtf" outlier in my guess (just a guess).  examples include many packages needing to be installed (think fresh lxc download/configuration), many packages needing to be built/compiled (LP uses sdists and has a lot of them, and mailman takes a long time to build for some reason I don't know, and we build WADL and docs and...).
[15:35] <gary_poster> bac, mars posted something to cloud I thought you'd be able to reply to...looking for subject line...
[15:36] <gary_poster> bac, "Juju Charms: How Do I..."
[15:36] <gary_poster> you've experimented with sending private information
[15:37] <gary_poster> not sure if you think it is worth sharing, but if so, wanted to call it out
[15:37] <bac> gary_poster: i'll look
[15:37] <gary_poster> thanks
[15:56] <RichardRaseley> So Juju currently supports deployment against MaaS and EC2, but not Nova, correct?
[16:08] <jamespage> RichardRaseley, its possible to use with OpenStack using the ec2 provider - but you openstack deployment must support both the ec2 API and the s3 API
[16:21] <RichardRaseley> jamespage: Thank you for that information. Is "native" OpenStack support on the roadmap?
[16:22] <jamespage> RichardRaseley, I don't think it is at the moment - this was discussed at the Openstack Design Summit last week - http://www.ubuntu.com/cloud/private-cloud/awsome
[16:23] <SpamapS> RichardRaseley: native OpenStack isn't really all that necessary. The needs that juju has from ec2 and s3 are very tiny, and openstack's compatibility layer supports them fully
[16:24] <SpamapS> RichardRaseley: That said, I'd like to see native support so that we can use OpenStack's ability to enumerate instance types to match the generic 'mem' and 'cpu' constraints.
[16:24] <jamespage> but like SpamapS says thats prob overkill for juju requirements (unless the cloud you are trying to use does not expose the ec2 API).
[16:24] <jamespage> SpamapS, that would be nice.
[16:25] <SpamapS> Seems like a gaping hole in EC2's API that you can't programattically say "how much RAM does an m1.small have"
[16:25] <SpamapS> but, it makes sense that they wouldn't focus on that, since its *always* the same number
[16:26] <RichardRaseley> Is the EC2 & S3 compatibility layer built into OpenStack or is that something that has to be installed seperately.
[16:27] <SpamapS> built in
[16:28] <SpamapS> RichardRaseley: its built in now. Note that it may be moved to a separate proxy, as some openstack based clouds don't want EC2 compatibility for political or even possibly technical reasons.
[16:28] <SpamapS> RichardRaseley: Canonical developed said proxy, its called AWSome
[16:29] <RichardRaseley> OK, I can see the political or pride aspect. "OpenStack is awesome, and we are fully behind it, but you have to use this compatibility layer built to support a competing platform to use our automation software."
[16:29] <RichardRaseley> Seems a little weird from an outside perspective.
[16:38] <imbrandon> RichardRaseley: well its a stopgap, we dont want to keeop using it for openstackm maybe others but os will be fully native *sometime* its some man hrs etc etc
[16:38] <RichardRaseley> I understand that.
[16:39] <RichardRaseley> And am sympathetic.
[16:39] <imbrandon> and really its the storage bits on os
[16:39] <imbrandon> not the compute
[16:39] <imbrandon> and SpamapS has a great idea to rid that need anyhow
[16:39] <imbrandon> and just store the nneded info on the bootstrap node
[16:40] <imbrandon> then it woulent be needed for OS at all then, others yea
[16:55] <SpamapS> RichardRaseley: think of it another way. "AWS only does these 8 things. OpenStack intends to do 100 things that AWS will never do."
[16:55] <SpamapS> RichardRaseley: for that reason, separating the EC2 bits out into a separate proxy makes a lot of sense.
[16:56] <RichardRaseley> SpamapS: I was referring to "native" support for Nova, Swift, etc.
[16:56] <RichardRaseley> I am not opposed to seeing the proxy functionality seperated out.
[16:57] <RichardRaseley> I mean, that makes sense.
[16:57] <SpamapS> RichardRaseley: well I guess my point is, juju is intended to use *both*
[16:58] <SpamapS> So if we wrote a native OpenStack provider, we'd not gain much, because all the clouds that juju supports need to support the same functionality (which is a very tiny footprint btw... start/stop/list machines is the krux of it)
[16:58] <SpamapS> We only just now added the constraint ability.. which is where native support becomes more attractive because it enhances capabilities without needing anything fundamentally different.
[16:59] <RichardRaseley> I suppose that is true from a technical point of view - but there is something that just seems "off" about having to proxy requests to OpenStack from Juju through an ec2, s3 proxy. :: shrugs ::
[16:59] <RichardRaseley> Right
[16:59] <SpamapS> RichardRaseley: to be clear, right now, there is no proxy needed.
[17:00] <SpamapS> OpenStack's EC2 capabilities are built in
[17:00] <RichardRaseley> It is a compatibility layer though, correct?
[17:00] <SpamapS> Sort of
[17:00] <SpamapS> EC2 is done at the same level as OSAPI
[17:00] <RichardRaseley> So JuJu makes ec2 calls, that layer translates those to nova?
[17:00] <SpamapS> Nova-API supports both EC2 and OSAPI
[17:01] <SpamapS> so.. the same thing that translates OSAPI to nova :)
[17:01] <RichardRaseley> I am not familiar with OSAPI - I am just dipping my toes into OpenStack
[17:01] <SpamapS> Its just possible that the EC2 will be moved out of Nova API as OSAPI grows as the dominant use case.
[17:01] <SpamapS> OSAPI == Native OpenStack API
[17:02] <RichardRaseley> Ah
[17:11] <hazmat> RichardRaseley, the ec2 calls that juju makes to openstack are implemented at the same layer/level as the native openstack calls
[17:12] <hazmat> but in the context of public clouds built on openstack, not all choose to expose those implementations
[17:13] <hazmat> the proxy offers compatibility usage in that context, and going forward maybe adopted as a preferred mechanism by ostack for ec2 compat
[17:13] <hazmat> that's tbd though
[17:16] <bkerensa> jcastro: Why you offer XPS laptops at UDS?
[17:17] <bkerensa> >.< now you know I must write more charms
[17:17] <jcastro> bkerensa: why not?
[17:17] <jcastro> SpamapS: hah, nice hack (the subordinate ssh thing)
[17:17] <jcastro> you know, why not have an "auth" subordinate that does just that?
[17:19]  * SpamapS is good with the hatchet :)
[17:19] <SpamapS> jcastro: I am working on a pam-mysql subordinate actually :)
[17:20] <SpamapS> I'm telling you.. once subordinates are fully understood.. everybody's heads will explode with good ideas
[17:20] <bkerensa> jcastro: So if we are attending UDS and we start pushing Charms this week will those count or do we actually have to write them at UDS?
[17:20] <hazmat> bcsaller, please do an ml announce of subs
[17:21] <SpamapS> Yeah it would go well with the 12.04 release
[17:21] <bcsaller> hazmat: writing something up
[17:21] <hazmat> bcsaller, awesome
[17:21] <SpamapS> I think we have to accept any charm from now until judging.. otherwise people will cheat and bring pre-baked charms anyway. ;)
[17:23] <bkerensa> SpamapS: I cannot bring anything pre-baked because I need you to roll out my dough first before I put it in the oven
[17:23] <bkerensa> :D
[17:26] <RichardRaseley> So - this is a question from a non-developer and someone with no experience using charms - are most charms written in a specific language such as Python?
[17:29] <hazmat> RichardRaseley, no.. they can be written in any language and with any tooling.. that said.. most of the 'official' charms (ie been through a review process) are written in shell/bash with a handful in python.
[17:30] <RichardRaseley> hazmat: Thanks for that information.
[18:23] <jml> hi
[18:24] <jml> I'm getting lots of log-spam in /tmp/juju-local/jml-local/machine-agent.log
[18:24] <jml> 2012-04-26 19:23:25,336:1064(0x7f845c6e3700):ZOO_WARN@zookeeper_interest@1461: Exceeded deadline by 486569ms
[18:24] <jml> 2012-04-26 19:23:25,337:1064(0x7f845c6e3700):ZOO_WARN@zookeeper_interest@1461: Exceeded deadline by 486569ms
[18:24] <jml> 2012-04-26 19:23:25,337:1064(0x7f845c6e3700):ZOO_ERROR@handle_socket_error_msg@1528: Socket [192.168.122.1:50887] zk retcode=-7, errno=110(Connection timed out): connection timed out (exceeded timeout by 0ms)
[18:24] <jml> I suspect that it crashed my computer earlier (when it ran out of disk space)
[18:24] <SpamapS> jml: doh!
[18:24] <SpamapS> jml: more recent versions don't seem to do that as much
[18:24] <jml> yeah.
[18:24] <jml> well, this is whatever is in precise today
[18:24] <SpamapS> jml: there was a change in txzookeeper that made the client more robust
[18:24] <SpamapS> ah ok
[18:25] <SpamapS> hazmat: ^^
[18:25] <SpamapS> jml: the deadline stuff... makes me wonder if there was a time skew of some kind?
[18:25] <jml> I guess there should probably also be a circuit breaker in the logging code to prevent killing computers
[18:25] <jml> although maybe in the cloud it doesn't matter if computers die :\
[18:26] <hazmat> we need to disable the log verbosity on zk log
[18:26] <hazmat> its bad
[18:26] <jml> what do I do to stop the problem?
[18:26] <jml> it's also chewing cpu
[18:26] <hazmat> jml, ? cpu logging is chewing up cpu?
[18:26] <hazmat> er. logging is
[18:27] <jml> hazmat: the process doing the logging is
[18:27] <jml> that's how I identified the issue
[18:27] <jml> fwiw, it's spammed 3G+ while I've been talking here.
[18:28] <hazmat> jml this is the bug https://bugs.launchpad.net/juju/+bug/958312
[18:28] <_mup_> Bug #958312: Change zk logging configuration <juju:New> < https://launchpad.net/bugs/958312 >
[18:28] <hazmat> the short answer is we can just disable the zk log
[18:28] <hazmat> on the clients
[18:28] <hazmat> the long answer is a an os.pipe that filters the output of the log to just relay relevant things
[18:29] <hazmat> eta 10m on the disable fix
[18:30] <jml> sorry, what I meant was how can I save my computer? just kill the rogue process?
[18:30] <jml> actually,  screw it, I just did that.
[18:30] <hazmat> jml, just delete the logs.. or data-dir
[18:31] <jml> hazmat: I tried that first, still left me with something using approx 100% cpu
[18:31] <hazmat> jml, that sounds very odd, unless that's a cascading problem
[18:31] <hazmat> ie. disk full triggers something else bad
[18:32] <jml> hazmat: well, the earlier disk full was on a previous boot
[18:32] <jml> but I did have to hard kill
[18:32] <_mup_> juju/zk-log-client-disable r532 committed by kapil.thangavelu@canonical.com
[18:32] <_mup_> disable zk client log on agents
[18:32] <jml> because it's running as root, it uses *all* the disk space
[18:32] <jml> not just almost all
[18:32] <jml> so 'sudo reboot' wouldn't work
[18:35] <hazmat> jml, i've always just removed the offending log file first.. but yeah.. that's ugly
[18:35] <hazmat> the one line fix  is https://code.launchpad.net/~hazmat/juju/zk-log-client-disable/+merge/103753
[18:36] <jml> hazmat: cool.
[18:37] <jml> hazmat: although I have to confess I'm not in a huge rush to switch away from using the package
[18:37] <hazmat> SpamapS, the zk server isn't up on local provider on reboot...
[18:37] <hazmat> ie not upstartified
[18:37] <SpamapS> ahhhh
[18:38] <SpamapS> hazmat: so perhaps we should back off logging/retries?
[18:38] <hazmat> SpamapS, its the c library logging, we have to do some magic to get it to do things sanely
[18:39] <hazmat> like pass it an os.pipe we have a reader on that does something like a  ring buffer before it flushes to the log file
[18:39] <SpamapS> hazmat: REST API to the rescue? ;)
[18:39] <jml> anyway, I'm off. thanks guys.
[18:39] <hazmat> SpamapS, not really.. this an agent problem.
[18:39] <jml> REST :(
[18:39] <hazmat> SpamapS, oh you mean rest EVERYWHERE ;-)
[18:39] <hazmat> rip ;-)
[18:39] <SpamapS> hazmat: Yeah I think eventually that will happen
[18:40] <hazmat> that one liner does the safe/simple thing of just disabling the c library logging.
[18:40] <hazmat> it does occassionally have useful info, but not at the cost/risk it has
[20:38] <jimbaker> hazmat, +1 on that trivial re zk log, i think you made the right case
[20:38] <hazmat> jimbaker, thanks.. committing
[21:33] <cyberplop> Alguien habla espa;ol?????
[21:46]  * hazmat hits the road enroute to an openstack meetup
[22:14] <jcastro> SpamapS: all you bro: http://askubuntu.com/q/125640/235
[22:54] <bobweaver> Yes there is a juju channel
[22:56] <bobweaver> how do charms work in-comparison to .debs ? are there control files rules ect where can I find tutorials ? besides the ones in the topic. thanks for your time.
[23:00] <bobweaver> sorry if I missed anything  router geeked out
[23:04] <SpamapS> doh
[23:04] <SpamapS> 7 minutes from "how does that work" to /part .. doh
[23:08] <bobweaver> dang sorry if I missed anything my router stoped working for a little bit.
[23:09] <mars> SpamapS, ^
[23:13] <SpamapS> bobweaver: welcome back :)
[23:14] <bobweaver> I am reading a bunch like the tutorials juju.ubuntu.com/docs/ I am also going to join the mailing list
[23:14] <bobweaver> Thanks SpamapS
[23:14] <SpamapS> bobweaver: Charms define services, where as .debs define local, single machine program installations.
[23:14] <bobweaver> sorry about the break in the tunnel
[23:16] <SpamapS> bobweaver: there is a metadata file, not unlike debian/control in a debian source package.. and hooks are somewhat like maintainer scripts (preinst, postrm, etc), though their purpose is quite different.
[23:16] <bobweaver> The real reason that I would like to see more about juju is becasue I watched the keynote for last years UDS and there was something in there like getting away from packaging the way that it is. So I thought that now is the time as I was learing making .debs
[23:17] <bobweaver> I am going to fire up the virtual machine and install drupel and have a play
[23:17] <bobweaver> thanks for them tips.
[23:18] <bobweaver> Is it true that ubuntu is going to try to start usingt juju more and more ? like a re-placemesnt for apt? if too harsh sorry :)
[23:22] <SpamapS> bobweaver: Its not a replacement for apt at all.
[23:22] <SpamapS> bobweaver: packaging makes juju charms more robust and easier to write.
[23:22] <SpamapS> bobweaver: there are some things, however, that are really hard to package in a way that is generically useful.
[23:24] <SpamapS> bobweaver: for instance, if you have a web app that is changing rapidly, it may be better to deploy with juju and have users always get the latest release, rather than some frozen app from the archive 2 years ago.
[23:26] <bobweaver> I see so it is mainly for lamp and other fast pace stuff
[23:27] <SpamapS> not really
[23:27] <bobweaver> I have been fighting packing this up https://launchpad.net/zpanelcp   may juju would be good ?
[23:27] <SpamapS> its for integrating that stuff, with the slow moving rock solid stuff
[23:28] <SpamapS> bobweaver: is it useful in a multi-node deployment?
[23:28] <bobweaver> yeah
[23:29] <SpamapS> bobweaver: it looks like a great candidate for juju integration actually
[23:29] <bobweaver> I am going to give it a shot but we will see. I like to play around with stuff
[23:31] <SpamapS> bobweaver: documentation is severely lacking on that project
[23:31] <SpamapS> or well hidden
[23:31] <bobweaver> I might be able to help I see that there is a juju charm school
[23:33] <bkerensa> jcastro: You around
[23:34]  * bkerensa wonders if Canonical (Juju) would like to sponsor the next shirt http://i.imgur.com/ZIzUO.png and get the Juju logo on the sleeve
[23:34] <bkerensa> :) Eucalyptus sponsored our last edition
[23:35] <SpamapS> bkerensa: that would be cool
[23:41] <bobweaver> bkerensa:1st wow & cool. do you know how there are the green love oregon stickers ? maybe make the ubuntu circle into heart. but I think that I would like one of them shirts. they look great.
[23:41] <bkerensa> bobweaver: :D
[23:42] <bkerensa> SpamapS: It cost about $497 for us to have 30-40 shirts printed they come out real nice... I wear the Ubuntu Oregon/Eucalyptus shirts often
[23:42] <bkerensa> :P
[23:42] <bkerensa> Is kind of sad we have to go to other companies to have them sponsor CD's/Banners etc for us though :P
[23:44] <SpamapS> bkerensa: if Canonical sponsored every Ubuntu user group we wouldn't have any money to make *Ubuntu*
[23:44] <SpamapS> In a way, Canonical sponsors anything and everything that has the Ubuntu logo on it. :)
[23:46] <bkerensa> SpamapS: They give CD's, Banner and Table Cloth to all approved LoCo's
[23:47] <bkerensa> :P but we continue to be denied approval even though we exceed the criteria :)
[23:50] <SpamapS> bkerensa: oh, whats up with that?
[23:50] <SpamapS> bkerensa: IIRC, thats also how you get approval to use the Ubuntu Trademark.. so.. be careful about those t-shirts w/ Ubuntu logo :P
[23:51] <bkerensa> SpamapS: To be honest? I have no idea and our entire loco is pretty disappointed at it.... We escalated the issue to the CC because we felt we were treated unfairly.... If you look at loco.u.c. see how many U.S. approved LoCo's are having release parties? not many but we are and for three cycles in a row we have the largest release party in the U.S. :) also 20% of our members had commits in 12.04
[23:51] <bkerensa> so idk
[23:52] <bkerensa> We have people who work for Canonical in the LoCo who were like "Why did we get declined?"
[23:52] <bkerensa> idk its a hot mess :P
[23:52] <SpamapS> bkerensa: but there must be a reason
[23:53] <bkerensa> SpamapS: I think it was because the LC did not throughly examine our application and had new members...
[23:53] <bkerensa> they ended up changing the approval criteria right after we were declined because they tried to make up criteria on the fly
[23:54] <bkerensa> They didnt even bother creating minutes for the meeting
[23:54] <bkerensa> https://wiki.ubuntu.com/LoCoCouncil/Minutes/20120117
[23:54] <bkerensa> I had to add them myself
[23:54] <SpamapS> bkerensa: ouch
[23:54] <bkerensa> yeah
[23:54] <SpamapS> so, churn + ineptitude
[23:54] <SpamapS> bkerensa: perhaps things are better now then?
[23:54] <bkerensa> yeah and someone from the LC actually told me later flat out we should have been approved
[23:55] <bkerensa> SpamapS: perhaps but we still have to wait a cycle I guess or response from the CC.... Either way it impacts us getting CD's into the hands of potential users
[23:55] <bkerensa> and everytime people ask us for printed CD's I have to explain why we don't have them
[23:57] <SpamapS> bkerensa: you guys going to put a booth up at OSCON?
[23:57] <SpamapS> Thats been one of my favorite conferences for years
[23:57] <SpamapS> and its right there in Portland
[23:57] <bkerensa> SpamapS: yes of course.. We have had one every year
[23:57] <bkerensa> :D
[23:58] <bkerensa> and we will be at OSBridge
[23:58] <bkerensa> and PuppetConf and pretty much everything in our region :)
[23:58] <SpamapS> bkerensa: if you can't get t-shirts w/ juju logos for your loco.. let us know.. we'll make sure you have a mountain of juju shwag
[23:58] <SpamapS> jcastro: ^^