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