[04:31] <SpamapS> negronjl: you ready for tomorrow?
[10:51] <antono> hi all. testing juju with local provider
[10:52] <antono> for some reason no success. it cannot start all lxc containers for very long time
[10:53] <antono> so basically machine     state: not-started during 10 minutes
[10:53] <antono>  
[10:53] <antono> yesterday i got it running somehow... but i was away for a long time
[14:31] <yolanda> hi, good afternoon
[14:31] <yolanda> i'm trying to create an openstack instance from juju, but the instance gives me error
[14:31] <yolanda> anyone can guide me on how correctly setup the environments.yaml for openstack? i should be missing something
[15:14] <james_w> how's the charm store coming along?
[15:20] <bbcmicrocomputer> hi, a quick Q.. when writing Charms, is it by design that Juju executes hooks with a umask of 0077?
[16:34] <jcastro> bbcmicrocomputer, out of curiosity, what are you looking to charm?
[16:36] <jamespage> jcastro, I hoping to persuade him to charm hive :-)
[16:36] <jcastro> heh
[16:39] <jamespage> jcastro, are you helping with the charm school today?
[16:39] <jcastro> no, that's Clint and Juan
[16:39] <jcastro> it's a meatspace one
[16:43] <bbcmicrocomputer> jcastro: yeah, I'd like to do a Hive charm
[16:43] <jcastro> oh nice
[16:44] <bbcmicrocomputer> jcastro: atm, I'm just playing with jamespage's existing Hadoop ones
[16:46] <bbcmicrocomputer> jcastro, jamespage: would love to also create a Solr charm, so we could have a search server coupled to a MySQL or PostgreSQL instance
[16:47] <bbcmicrocomputer> jcastro, jamespage: be quite cool if you could just have indexing automatically set-up via the relations
[16:47] <jcastro> https://bugs.launchpad.net/charms/+bug/828367
[16:47] <_mup_> Bug #828367: Charm Needed: SolrCloud <Juju Charms Collection:New> < https://launchpad.net/bugs/828367 >
[16:48] <jcastro> and https://bugs.launchpad.net/charms/+bug/808255
[16:48] <_mup_> Bug #808255: Charm Needed: Solandra <Juju Charms Collection:New> < https://launchpad.net/bugs/808255 >
[16:48] <jcastro> those would be quite cool to see
[16:49] <bbcmicrocomputer> jcastro: ah cool, well would love to have a go at tackling them, schedule permitting
[16:49] <jcastro> awesome
[16:50] <bbcmicrocomputer> jcastro: any answer to the previous Q about why juju executes hooks with a umask of 0077?  Is it just to be *safe*?
[16:52] <jcastro> not sure
[16:52] <bbcmicrocomputer> jcastro: ah ok
[16:53] <jcastro> I can however ping bcsaller, fwereade_, hazmat, and niemeyer for you. :)
[16:53] <bbcmicrocomputer> jcastro: sure, thanks
[16:57] <fwereade_> bbcmicrocomputer, I think that comes from twistd defaults; I don;t know that we made an explicit decision ourselves
[16:57] <fwereade_> bbcmicrocomputer, but perhaps someone who joined before me will be able to contradict that
[16:58] <bbcmicrocomputer> fwereade_: ok, thanks
[17:12] <andrewsmedina> hi
[17:13] <andrewsmedina> there's a way to define a custom image in a deploy?
[17:14] <jcastro> like an AMI?
[17:16] <andrewsmedina> jcastro: yes
[17:16] <jcastro> http://askubuntu.com/questions/84333/how-do-i-use-a-specific-ami-for-juju-instances
[17:16] <jcastro> you want default-image-id
[17:16] <fwereade_> andrewsmedina, I *think* that you can still change default-image-id in environments.yaml before you deploy; but I recommend you don't come to depend on that because it'll be going away soon
[17:17] <fwereade_> andrewsmedina, what's your use case?
[17:18] <andrewsmedina> fwereade_: I want in some cases to define a custom ami in a deploy
[17:18] <andrewsmedina> jcastro: I want define at a deploy time
[17:18] <fwereade_> andrewsmedina, what are the important characteristics of the different ami?
[17:20] <jcastro> i've always wanted to do that too
[17:20] <andrewsmedina> fwereade_: I want to use juju with golden images
[17:23] <andrewsmedina> This would be possible with "--contraints"
[17:23] <andrewsmedina> like
[17:23] <andrewsmedina> juju deploy local:mysql --constraints 'image-id: ami-0000002d'
[17:24] <fwereade_> andrewsmedina, as I recall it was agreed that allowing specific images with constraints was a bad idea
[17:24] <andrewsmedina> fwereade_: why?
[17:24] <fwereade_> andrewsmedina, in particular it's an end-run around our attempts to match the ubuntu series tothe charm that's being deployed
[17:27] <andrewsmedina> fwereade_: but with this juju only works on ubuntu
[17:27] <fwereade_> andrewsmedina, but that is clearly a sensible thing to want to do; can I suggest starting a discussion on the lists? I suspect it'll be the best way to get properly considered discussion
[17:28] <fwereade_> andrewsmedina, that is a restriction that I think we're... er... somewhere between "resigned to" and "comfortable with" for now
[17:28] <andrewsmedina> fwereade_: you can do it
[17:30] <andrewsmedina> fwereade_: use golden image is a very common amazon workflow
[17:30] <fwereade_> andrewsmedina, I think there's a general assumption in the codebase that we'll be deploying to ubuntu -- charms, in particular, are intended to be targeted to a particular ubuntu series -- and we'd need to think carefully about how to relax that
[17:31] <andrewsmedina> fwereade_: and with this is not need install the same thing every time
[17:31] <andrewsmedina> fwereade_: humm
[17:31] <fwereade_> andrewsmedina, indeed -- I can definitely see the utility of what you ask for
[17:31] <fwereade_> andrewsmedina, but as I say it involves a bit more complexity than one might hope for
[17:32] <andrewsmedina> fwereade_: I know
[17:37] <fwereade_> andrewsmedina, is it ramp-up time you're mainly worried about?
[17:38] <andrewsmedina> fwereade_: yes
[17:39] <fwereade_> andrewsmedina, hmm, I'm just thinking that I actually don't know what the usual distribution of time-spent-ramping-up actually is
[17:40] <andrewsmedina> fwereade_: in every deploy, juju install juju, zookeeper agent...
[17:41] <andrewsmedina> fwereade_: update and upgrade the ubuntu
[17:43] <fwereade_> andrewsmedina, quite -- there's a fair amount to be done -- but I'm wondering how to get a decent idea of where we can save the most time in the general case
[17:44] <niemeyer> bbcmicrocomputer: Are you getting such a umask? (/cc jcastro)
[17:45] <niemeyer> bbcmicrocomputer: What's the 0077 reflecting, more precisely?
[17:45] <andrewsmedina> fwereade_: I think skipping this installation every time
[17:49] <bbcmicrocomputer> niemeyer: I noticed a lot of the configuration files being copied as part of a charm install hook was ending up as private to root, which caused problems when running daemon processes as other users.  So I altered one of the hooks to output the umask to a temporary file and found that when juju called it, it was 0077.
[17:50] <niemeyer> bbcmicrocomputer: That certainly sounds bogus
[17:50] <niemeyer> hazmat: Does that ring any bells?
[17:50] <fwereade_> bbcmicrocomputer, btw, what version of juju are you using?
[17:51] <niemeyer> bbcmicrocomputer: I can't find anything about such a umask in the code base, FWIW
[17:51] <bbcmicrocomputer> niemeyer: 0.5+bzr457-0ubuntu1
[17:51] <bbcmicrocomputer> niemeyer: me neither :)
[17:52] <niemeyer> bbcmicrocomputer: Ah, found the source
[17:52] <bbcmicrocomputer> niemeyer: it's an EC2 deployment and the system umask is def not set to 0077, so have assumed it was juju
[17:52] <niemeyer> bbcmicrocomputer:        --umask <mask>
[17:52] <niemeyer>               The (octal) file creation mask to apply. (default: 0077 for daemons, no change otherwise).
[17:52] <niemeyer> bbcmicrocomputer: From twistd
[17:52] <niemeyer> bbcmicrocomputer: Would you mind to file a bug? We'll certainly fix that
[17:53] <bbcmicrocomputer> niemeyer: ah ok, so we def shouldn't be altering charms to switch umasks?
[17:53] <niemeyer> bbcmicrocomputer: No, juju should not execute charms with such a umask
[17:53] <fwereade_> niemeyer, I *think* it's already fixed accidentally, because the upstart agents run with --nodaemon
[17:53] <bbcmicrocomputer> niemeyer: ok, will file a bug
[17:53] <niemeyer> fwereade_: Oh, was that recent?
[17:53] <fwereade_> niemeyer, thatstarts at r460 :)
[17:53] <niemeyer> hah, ok :-)
[17:54] <m_3> bbcmicrocomputer: we usually either use explicit chmods (preferred) or set the umask as needed in hooks
[17:54] <niemeyer> bbcmicrocomputer: Thanks for filing the bug. It'll be good to have that tracked no matter what
[17:54] <bbcmicrocomputer> m_3: makes sense
[17:54] <m_3> bbcmicrocomputer: lots of charm helper fns have a mode arg... ch_template_file <owner> <mode> <source> <target>
[17:55] <fwereade_> niemeyer, I haven't verified, so yeah, we definitely want that bug ;)
[17:56] <m_3> bbcmicrocomputer: 600 isn't an unreasonable starting point... better for the charm author to screw up in a more secure way than not IMO
[17:57] <bbcmicrocomputer> m_3: yeah, it wouldn't surprise me if it was by design for this very reason
[17:57] <bbcmicrocomputer> m_3: at least then the author is thinking about it
[17:57] <m_3> bbcmicrocomputer: right
[18:25] <_mup_> Bug #953258 was filed: juju executing hooks with umask of 0077 <juju:New> < https://launchpad.net/bugs/953258 >
[19:45] <_mup_> Bug #953339 was filed: juju remove-relation usage/help typo <juju:New> < https://launchpad.net/bugs/953339 >
[21:25] <robbiew> jcastro: SpamapS: http://www.zazzle.com/run_lxc_tshirt-235168775723259384
[21:25] <robbiew> we should make hallyn wear it
[21:35] <jcastro> robbiew, can we put "but don't forget to remove the stuff in /var/lib every once in a while." on the back?
[21:36] <jcastro> that is pretty awesome though
[21:37] <arosales> jcastro, m_3: If you have a spare minute could you add http://charmschoolsv.eventbrite.com/ to juju.ubuntu.com/Events?
[21:37] <robbiew> lol
[21:37] <arosales> more for our tracking where and what we have done.
[21:38] <arosales> also what do you think about putting webinars/virtual sessions you have done there to?
[21:38] <arosales> for http://charmschoolsv.eventbrite.com/ Clint and Juan are running that one.
[21:48] <m_3> arosales: done
[21:48] <arosales> m_3: Thank you
[21:50] <m_3> np
[23:10] <marcoceppi> Hey everyone o/ So I've started back up on the Steam charm and I don't think it's being done properly
[23:11] <m_3> marcoceppi: cool man... don't be shy about making changes
[23:11] <marcoceppi> Right, This one is kind of drastic though. I'm thinking that each "steam game" should be a subordinate(sp?) charm of a main Steam charm. To be deployed with the "Constraints" flag
[23:11] <marcoceppi> Opinions?
[23:12] <marcoceppi> Basically "I want to do this thing even more weirder"
[23:12] <m_3> ha!
[23:12] <marcoceppi> Because more weirder is the only way to describe it
[23:12] <m_3> I kind of seems like a config option to me
[23:12] <m_3> but there's no reason not to do it that way
[23:12] <m_3> well... except those features haven't really landed yet
[23:13] <m_3> I'd say heck yeah... experiment
[23:13] <marcoceppi> That's what I've been hammering on; however, I've run into "How do I deploy custom maps", "How do I add plugins", "How do I manage config options that don't exist between games"
[23:13] <m_3> ah right
[23:13] <marcoceppi> There are maybe a handful of shared config options, the rest are just hog wild different
[23:13] <m_3> well perhaps they're all separate charms?  that have a steam plugin of sorts
[23:14] <m_3> which is exactly what you were saying ;)
[23:14] <marcoceppi> For maps I figured there could be a "maps" folder that users can extract maps to and that would be moved in to place for that game, but if you switch game types the maps won't be compatible
[23:14] <marcoceppi> m_3: Yeah ;)
[23:14] <marcoceppi> It's a weird use case
[23:14] <marcoceppi> I really don't _want_ to make 35 different charms for each different Steam game server
[23:15] <marcoceppi> but I'm running out of sane options for consolidating them in to one
[23:15] <m_3> marcoceppi: until the steam charm can be deployed separately, then I'd recommend just using a helper sort of library for those parts... then you can turn it into a separate charm once we can do subordinates
[23:16] <m_3> marcoceppi: wow.. that _is_ a lot
[23:16] <marcoceppi> yeah :\
[23:16] <m_3> perhaps it's just more complex configuration then
[23:16] <marcoceppi> Well, I currently do this for configuration. juju steam --set config_key="mp_timelimit" config_value="12"
[23:17] <marcoceppi> so you have wild card config keys
[23:17] <m_3> right
[23:17] <m_3> note you can pass entire json or yaml files as config options...
[23:18] <marcoceppi> Also, what's the policy on something like "map_url" as a config option that would fetch a remote ZIP file and extract it (not over HTTPS and most likely using any Cryptographic checking) but wouldn't be part of the actual charm setup, user invoked
[23:20] <m_3> marcoceppi: do you have example configuration files for deploying steam?
[23:20] <m_3> a couple of different games
[23:20] <marcoceppi> m_3: I've been doing that for each game
[23:20] <marcoceppi> so you could just point to a configuration file and it would use "sane" defaults for that game
[23:21] <m_3> marcoceppi: links?
[23:21] <m_3> marcoceppi: you still working from lp:~marcoceppi/charms/oneiric/steam/trunk?
[23:22] <marcoceppi> Yeah, there might not be all the updates there but not much work has been done since then
[23:22] <marcoceppi> http://bazaar.launchpad.net/~marcoceppi/charms/oneiric/steam/trunk/view/head:/opt/tf2.cfg
[23:22] <marcoceppi> So that's what a game config looks like
[23:23] <m_3> marcoceppi: awesome... I'll take a look
[23:25] <m_3> marcoceppi: perhaps some config options can be grouped into dedicated config files... then we can pass the entire config files in as charm config params
[23:26] <m_3> yaml can take a yaml file as a field
[23:26] <marcoceppi> Interesting
[23:27] <m_3> http://paste.ubuntu.com/881172/
[23:27] <m_3> that's a snippet from a config yaml file I'm passing in to a charm
[23:27] <m_3> the | and the indentation make the magic happen
[23:27] <m_3> I think that could be really useful here
[23:29] <m_3> marcoceppi: we'd have to watch _re_configuration... treat that more as a full upgrade... but it should work
[23:30] <marcoceppi> Right, this looks promising, I'm going to give it a shot
[23:31] <m_3> seems like it'd make it easier to have separate sets of config options for different games... this way you can pass in a whole config file for each game
[23:31] <m_3> common stuff you can keep in the main config.yaml
[23:31] <m_3> but then there's an option for... game_config:
[23:31] <m_3> that you write out and point the game to during spinup