| SpamapS | negronjl: you ready for tomorrow? | 04:31 |
|---|---|---|
| === asavu_ is now known as asavu | ||
| === Leseb_ is now known as Leseb | ||
| === asavu_ is now known as asavu | ||
| antono | hi all. testing juju with local provider | 10:51 |
| antono | for some reason no success. it cannot start all lxc containers for very long time | 10:52 |
| 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 | 10:53 |
| === 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 | ||
| 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 | 14:31 |
| james_w | how's the charm store coming along? | 15:14 |
| bbcmicrocomputer | hi, a quick Q.. when writing Charms, is it by design that Juju executes hooks with a umask of 0077? | 15:20 |
| === al-maisan is now known as almaisan-away | ||
| jcastro | bbcmicrocomputer, out of curiosity, what are you looking to charm? | 16:34 |
| jamespage | jcastro, I hoping to persuade him to charm hive :-) | 16:36 |
| jcastro | heh | 16:36 |
| 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:39 |
| bbcmicrocomputer | jcastro: yeah, I'd like to do a Hive charm | 16:43 |
| jcastro | oh nice | 16:43 |
| bbcmicrocomputer | jcastro: atm, I'm just playing with jamespage's existing Hadoop ones | 16:44 |
| 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:46 |
| 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:47 |
| 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:48 |
| bbcmicrocomputer | jcastro: ah cool, well would love to have a go at tackling them, schedule permitting | 16:49 |
| jcastro | awesome | 16:49 |
| 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:50 |
| jcastro | not sure | 16:52 |
| bbcmicrocomputer | jcastro: ah ok | 16:52 |
| jcastro | I can however ping bcsaller, fwereade_, hazmat, and niemeyer for you. :) | 16:53 |
| bbcmicrocomputer | jcastro: sure, thanks | 16:53 |
| 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:57 |
| bbcmicrocomputer | fwereade_: ok, thanks | 16:58 |
| === JanC_ is now known as JanC | ||
| andrewsmedina | hi | 17:12 |
| andrewsmedina | there's a way to define a custom image in a deploy? | 17:13 |
| jcastro | like an AMI? | 17:14 |
| 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:16 |
| fwereade_ | andrewsmedina, what's your use case? | 17:17 |
| 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:18 |
| jcastro | i've always wanted to do that too | 17:20 |
| andrewsmedina | fwereade_: I want to use juju with golden images | 17:20 |
| andrewsmedina | This would be possible with "--contraints" | 17:23 |
| andrewsmedina | like | 17:23 |
| andrewsmedina | juju deploy local:mysql --constraints 'image-id: ami-0000002d' | 17:23 |
| 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:24 |
| 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:27 |
| 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:28 |
| andrewsmedina | fwereade_: use golden image is a very common amazon workflow | 17:30 |
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| 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:30 |
| 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:31 |
| andrewsmedina | fwereade_: I know | 17:32 |
| fwereade_ | andrewsmedina, is it ramp-up time you're mainly worried about? | 17:37 |
| andrewsmedina | fwereade_: yes | 17:38 |
| 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:39 |
| andrewsmedina | fwereade_: in every deploy, juju install juju, zookeeper agent... | 17:40 |
| andrewsmedina | fwereade_: update and upgrade the ubuntu | 17:41 |
| 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:43 |
| niemeyer | bbcmicrocomputer: Are you getting such a umask? (/cc jcastro) | 17:44 |
| niemeyer | bbcmicrocomputer: What's the 0077 reflecting, more precisely? | 17:45 |
| andrewsmedina | fwereade_: I think skipping this installation every time | 17:45 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| fwereade_ | niemeyer, I haven't verified, so yeah, we definitely want that bug ;) | 17:55 |
| 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:56 |
| 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 | 17:57 |
| _mup_ | Bug #953258 was filed: juju executing hooks with umask of 0077 <juju:New> < https://launchpad.net/bugs/953258 > | 18:25 |
| _mup_ | Bug #953339 was filed: juju remove-relation usage/help typo <juju:New> < https://launchpad.net/bugs/953339 > | 19:45 |
| robbiew | jcastro: SpamapS: http://www.zazzle.com/run_lxc_tshirt-235168775723259384 | 21:25 |
| robbiew | we should make hallyn wear it | 21:25 |
| 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:35 |
| jcastro | that is pretty awesome though | 21:36 |
| 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:37 |
| 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:38 |
| m_3 | arosales: done | 21:48 |
| arosales | m_3: Thank you | 21:48 |
| m_3 | np | 21:50 |
| === Furao_ is now known as Furao | ||
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:20 |
| m_3 | marcoceppi: links? | 23:21 |
| m_3 | marcoceppi: you still working from lp:~marcoceppi/charms/oneiric/steam/trunk? | 23:21 |
| 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:22 |
| m_3 | marcoceppi: awesome... I'll take a look | 23:23 |
| 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:25 |
| m_3 | yaml can take a yaml file as a field | 23:26 |
| marcoceppi | Interesting | 23:26 |
| 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:27 |
| m_3 | marcoceppi: we'd have to watch _re_configuration... treat that more as a full upgrade... but it should work | 23:29 |
| marcoceppi | Right, this looks promising, I'm going to give it a shot | 23:30 |
| 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 | 23:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!