=== nath_will is now known as nathwill [04:24] btw I definately like the idea of a dedicated mpich2 charm, and then just setup an alternate charm for jtr === zyga-afk is now known as zyga === TheRealMue is now known as TheMue === almaisan-away is now known as al-maisan [11:44] am now getting this error on local deploy, bootstrap and destroy-environment: [11:44] Unable to create file storage for environment [11:44] 2012-06-20 12:43:47,632 ERROR Unable to create file storage for environment [11:45] hmm. IRC logs that google found indicate reboot might do the trick. [11:46] Usually if you del /tmp/juju-local or run using sudo it will go through [11:47] Yeah, I just deleted juju-local [11:47] I wonder why it has that error. [11:47] * jml wishes he had a blocking deploy [11:49] Ha! May the juju gods help us. Seems to go back and forth depending on the version you're using. [11:50] Well, I don't think it's a good idea all the time [11:52] What's the deal with all of the blank lines in debug-log during hook.output? [11:53] also, I'm guessing debug-log flags stderr output as ERROR. Is that right? [11:56] yea [12:00] is there any way to look at debug-log retrospectively? i.e. is it stored anywhere on disk? [12:00] * jml deploys again, this time w/ tee [12:19] hazmat: ping ( when you get in this morning ) need a bit of help debuggin a build issue, should be trivial i hope [12:20] jml: yes it should be stored on disk, i think /var/lib/juju or something, i totaly forget, but i konw it is [12:20] imbrandon, pong [12:21] heya [12:21] i did a docs push a hour or so ago and it should look like http://www.assets-online.com/docs/juju/index.html [12:21] but no go :( [12:21] is there a build log or anything ? [12:22] e.g i put the tree nav back, and added some responsive goodies like we talked about :) [12:24] imbrandon, looks quite nice [12:24] ty [12:25] imbrandon, i don't have any insight into j.u.c/docs runs.. i did just update the one at jc.com/docs and it worked fine [12:25] imbrandon, it might be a daily cron job [12:25] hrm kk, was 15 min before [12:26] no biggie tho i can just keep an eye out tomarrow worst case [12:26] thought there might be some logs etc , not a huge deal tho :) [12:27] imbrandon: thanks. [12:27] should look good on tablet and phone too now, i only checked on my ipad tho [12:31] hazmat: btw i fully married the "traditional" canonical core css and bootstrap css with this push too, so like it would be easy to update jc.com to use the web-teams header but still get all the bootstrap/bootswatch goodies [12:31] sweet [12:40] 'charm help' gives me '/usr/share/charm-tools/scripts/help: 11: /usr/share/charm-tools/scripts/help: /usr/share/charm-tools/scripts/: Permission denied' [12:41] Version: 0.3+bzr148-2~precise1 [12:41] hrm how can i charm-upgrade to just a portion of the service ? e.g. a rolling upgrade [12:43] jml: thats an un helpful error but what it really means is help expects an argument [12:43] charm help [12:43] oh. the irony. [12:43] heh [12:45] imbrandon: ~charmers now has edit rights to the wiki [12:48] jcastro: ROCK! [12:48] see my latest push ? all prettyfied [12:48] jcastro: http://www.assets-online.com/docs/juju/index.html [12:49] so whenever /docs builds next thats what it will look like [12:50] INFO: Setting up initscripts (2.88dsf-13.10ubuntu11) ... [12:50] ERROR: mount: block device /dev/shm is write-protected, mounting read-only [12:50] mount: cannot mount block device /dev/shm read-only [12:50] Am getting that now when I try running dist-upgrade in my install hook (lxc environment) [12:50] should I be filing bugs about all of these things? [12:52] likely, sorry i cant be much help, not used the local provider much === TheRealMue is now known as TheMue [13:03] jcastro: no workie http://cl.ly/HVxl [13:04] imbrandon: docs merge this morning... I'm charmpilot today [13:06] imbrandon: can you send a mail to rt@ubuntu.com with that screenshot? [13:06] jcastro: sure thing [13:06] m_3: E:parse [13:21] is there a standard thing that hooks do to silence debconf warnings about backends? === benji is now known as Guest14462 [13:33] I have to bump revision every time I make a change to a charm, even while under development, right? === benji___ is now known as benji [13:34] jml, upgrade-charm will bump the number in the revision file for you [13:35] mars: thanks. [13:36] (although changing '1' to '2' is probably the least of the things I want automated :)) [13:36] hehe [13:38] debconf :( upgrade questions :( [13:39] jml: maybe you mean DEBIAN_FRONTEND='noninteractive'? [13:39] where do I mean it? [13:39] jml: asking about how hooks silence debconf warning [13:40] so just export that at the start? [13:40] juju sets up the hook exec environment with that set already [13:41] jml: you can use deploy --upgrade [13:41] oh, now I think I understand your question... sorry. you can do something like `apt-get update || true` [13:41] doesn't _silence_ them, but it doesn't barf on them either [13:42] SpamapS: thanks. [13:43] http://paste.ubuntu.com/1050895/ – that's where my install hook blocks at the moment. [13:44] SpamapS: should I destroy between deploy --upgrade? [13:44] jml: I encourage everyone to make the upgrade-charm hook call 'stop;install;start;config-changed' so it basically redeploys [13:45] SpamapS: oh right. there's a hook. :) [13:46] SpamapS: if you encourage everyone to do that, why doesn't the charm created by 'charm create' do that? [13:46] Its also not a bad idea to "refresh" all your relations by calling them all over again but that requires careful refactoring. [13:46] jml: so it looks like you might need to echo some config params to debconf-set-selections for that [13:46] jml: *GOOD IDEA* [13:46] honestly.. IMO juju core should do it [13:46] SpamapS: I abstain from that category of discussion :) [13:46] SpamapS: jitsu-core does though :) [13:46] should just call upgrade-charm; ... all of that [13:47] m_3: huh? :) [13:47] juju-do will refire a relation right? [13:47] I'm working up my first serious charm. Will probably just have to grep my logs here for r'.*\?' [13:47] m_3: jitsu do was renamed 'jitsu run-as-hook', because no, it does not do that [13:48] first tip: wait until the US is awake [13:48] ok, what's jitsu? [13:48] jml: juju-jitsu [13:48] jml: its in the PPA.. little helpers [13:48] SpamapS: ah, nevermind... that hasn't been merged in yet [13:48] SpamapS: I'll take a look. [13:53] jitsu has no way of discovering subcommands? [13:54] Hi, how do we know which we should used, db-relation-joined vs db-relation-changed? [13:54] jml: oops, regression.. that used to happen on bare 'jitsu' [13:54] The tutorial (demoing drupal) uses db-relation-changed but we're not getting the user/pw/db details there, but they do seem to show in relation-joined [13:55] jml: hey, so `debconf-get-selections | grep console-setup` shows lots of options... perhaps you can echo one of these to debconf-set-selections for that package? not sure the option from your pastebin, but start there [13:56] I find it surprising that console-setup is prompting [13:56] newz2000: joined is fired once, changed is continuously fired on both sides until no more relation-sets are called [13:56] I would have thought it would already be set up in the container [13:56] james_w: yes, me too [13:56] m_3: if we're configuring our app to talk to the db, which is best? [13:57] as in, I haven't seen it, but maybe jml is installing some obscure packages in the install hook [13:57] at this stage, I'm just dist-upgrading precise. [13:58] tbh, am a little surprised that there's not a standard recipe for doing so. [13:58] newz2000: often best in changed [13:58] newz2000: make sure you `exit 0` if the other side (db) isn't up yet [13:58] m_3: ok. We're having a prob where our script is firing one time and has no login credentials [13:58] m_3: ok. We're still trying to wrap our heads around that part. [13:58] newz2000, you don't always get all the credentials the first time it is called [13:59] SpamapS, hi there again :) conceptual question about subordinate charms... would it make sense to write an apache-wsgi-app subordinate charm that you can configure with options (wsgi file, apache config, etc) (so that it can be reused by any "web appserver" charm without having to rewrite the apache config stuff? [13:59] pindonga, it would [13:59] newz2000: it's up to the particular interface, but the usual story is the db gets the other side's hostname, then creates databases and creds, then does a relation-set on that [13:59] SpamapS, basically what I'm looking for is something similar to the chef recipes concept [13:59] or james_w ^ :) [13:59] newz2000: so the first time the app gets a relation-get from the db is in changed [13:59] james_w, m_3, interesting. We seem to only be running one time. Maybe that's because we're not doing exit 0 right [13:59] https://bugs.launchpad.net/charm-tools/+bug/1015575 filed also [13:59] <_mup_> Bug #1015575: Error running 'charm help' without arguments < https://launchpad.net/bugs/1015575 > [13:59] newz2000: gets a _non-empty_ relation-get :) [14:00] pindonga, I don't think there's all that much benefit to it if it is apache-specific though [14:00] grr. 'nother meeting. [14:00] m_3: ok. We don't understand it yet but we may be about there. Thanks, will pester you again in a bit [14:00] newz2000: not sure... have to see the code [14:00] newz2000: sure [14:01] pindonga, but it's certainly a valid use of subordinates IMO [14:02] james_w, well, the benefit would be write once read many [14:02] :) [14:02] don't see how you can do this in a webserver agnostic way [14:02] pindonga: wsgi is pretty webserver agnostic isn't it? [14:03] james_w: I've thought of this the other way around... the django app being subordinate to an apache-wsgi app... but it's probably the same diff [14:03] m_3, right, that's what I thought pindonga meant, but either way would work [14:04] another reason it would still be useful if it is apache specific is that many of them can be written, and then as apache improves, the users see those improvements [14:05] james_w, wsgi is, but you still need an apache-modwsgi one [14:05] pindonga, i tend to think things like wsgi containers are best left to the charm not a subordinate.. the charm has to pick one to be functional anyways. [14:05] so apache-modwsgi is probably the right combination for a subordinate [14:05] hazmat, the idea was to avoid repeating commonly performed stuff [14:06] pindonga, you could have a "wsgi" interface, which your app would provide, and then the apache charm could require that interface to serve your app via wsgi [14:06] every app server that you deploy using apache+modwsgi follows the same steps [14:06] pindonga, anyways.. that's my op.. there's also a gunicorn subordinate [14:06] except for the config itself [14:06] james_w: like that [14:06] or nginx could require the interface [14:06] james_w, interesting [14:06] pindonga, http://jujucharms.com/~patrick-hetu/precise/gunicorn [14:07] hazmat: but without inheritance, we have no way to improve general apache+wsgi charms other than subordinate/primary relationships [14:07] similarly for a 'rack' interface [14:07] james_w, so apache would be a subordinate charm to my app, in that case right? [14:07] pindonga, other way around [14:07] as I need it to be deployed in the same container [14:07] I think we will eventually see charm inheritance, and thats how this will work [14:07] james_w, if it's the other way, would I then juju deploy apache? (/me is at a loss) [14:08] SpamapS,+1 [14:08] you'll just write 'my-sexy-django-app' which extends: django-app which extends: apache-wsgi-app [14:08] the basics would be "wsgi script, working dir, user, processes, threads" [14:08] can't wait for that [14:08] funny juju might be the first language ti implement interfaces *before* inheritance [14:08] which is pretty webserver-agnostic, any any extras would require something else [14:08] * SpamapS hits the rimshot button [14:08] SpamapS, inheritance doesn't quite feel write either, ie. i don't want anything using apache mod wsgi, so perhaps subordinates give the choice.. [14:09] s/right [14:09] at least for my personal env deploys [14:09] pindonga, yeah, juju deploy apache, then juju deploy your app as a subordinate of apache, related using the wsgi interface [14:09] hazmat: we need to *end* this idea that personal preference is a good idea in ops [14:10] hazmat: there's a best way. Thats the way the charm works. [14:10] Measure it [14:10] pindonga: it'd be `juju deploy --config=wsgi.yaml apache; juju deploy --config=myapp.yaml django; juju add-relation apache:wsgi django` [14:10] implement it [14:10] and stop this nonsense that op A and op B can both be "right" [14:10] SpamapS, and patch security ;-) [14:10] ie maintain it [14:11] I'm just saying.. the idea with the charm store is that we all can actually agree on the best way to do WSGI apps [14:11] SpamapS, i agree, but unfortunately my best way is not the same as everyone elses ;-) === zyga is now known as zyga-food [14:11] SpamapS, gunicorn + nginx [14:11] or gunicorn + varnish [14:12] right, the charm should just pick one [14:12] what matter is it how my wsgi app works.. somebody else who cares more about that figured it out. :) [14:12] * SpamapS said pantomiming a hypothetical wsgi app developer [14:12] with a beret [14:13] * SpamapS cues the bass and snare [14:13] m_3: (or anyone) we could use some help with this /cc fugue88 [14:13] http://paste.ubuntu.com/1050957/ [14:13] * hazmat turns up the django [14:14] it's not successfully running syncdb, (line 45) [14:14] and it's also not re-running [14:14] newz2000, I'd check -n $password too [14:14] newz2000: so that's `db-relation-changed` right? [14:14] m_3: yes [14:15] and we did actually get it working so that it gets to line 46 [14:15] 45 [14:15] newz2000, are you installing django via packages or virtualenv? [14:15] and then it stops and doesn't retry [14:15] m_3, hey now, leave berets out of it! [14:15] perhaps around line 6 you should bail if [14:15] :-) [14:15] haha [14:15] hazmat: package [14:15] Beret: sorry :) [14:15] :) [14:15] newz2000, do you know what it errors with? [14:15] james_w: yes... [14:15] newz2000, also, are you adding this to the existing graphite charm? [14:16] newz2000: perhaps around line 6 you should put an other-side's-not-up guard?... lemme finish reading [14:16] psycopg2.OperationalError: could not connect to server: Connection refused [14:16] Is the server running on host "192.168.122.75" and accepting [14:16] TCP/IP connections on port 5432? [14:16] m_3: What would we do in that guard? Busy-wait? [14:16] newz2000: nevermind [14:16] james_w: we're doing an exercise to learn charming (ISD team srpint) [14:16] we made this charm yesterday, now adding db relationship to it [14:17] (it works fine when using local sqlite) [14:17] I wouldn't have started with graphite :-) [14:17] james_w: +1 [14:17] newz2000, why are you writing the credentials to /local_settings.py too? [14:17] debugging [14:17] ok [14:18] Interestingly, if we do juju ssh … then run syncdb without changing anything, it works fine. [14:19] Under what circumstances, exactly, will juju retry a hook? One part of the docs seems to indicate that if the hook exits non-0, it will be retried. We don't see that. Another part states that updating relation settings and exiting 0 will cause a retry. We could do that, but we don't really have any settings we *need* to communicate to the other side of the relation. [14:19] btw, fugue88 and I are pair programming this [14:19] Also, the docs aren't clear about *what* will be retried. Only the *other* side, or both sides? [14:20] fugue88: the relation hooks keep re-firing as long as either side keeps relation-set'ing [14:20] m_3: If side A relation-set's, both A's hook and B's hook will be retried? [14:20] fugue88: any non-zero exit from a relation at any time will just error out the relation (I think) [14:21] fugue88, if they exit non-zero they won't be retried until a human intervenes [14:21] Good to know about the non-0. [14:21] fugue88, if a relation-set is done then any relation-changed hooks will be fired for any relations that aren't in an error state [14:21] Great! [14:21] fugue88, I don't believe anything just gets "retried" [14:21] fugue88: A relation-sets, then B fires and relation-gets... if B doesn't relation-set, then A will not be fired again [14:21] Oh. [14:21] Not great. [14:22] fugue88, as in, you exit 0 early if the data you need isn't there yet, on the assumption that the data will be set later [14:22] is thre a convention for a relation-set to happen that indicates I'm not connecting, tell me when to try again? [14:22] So, if the relation data is there, but the other side isn't actually ready, we'll need to busy-wait in the hook. [14:22] so if you relation-get user and it is "" then you exit 0 on the assumption that the other side hasn't done relation-set user yet [14:22] then when it does that relation-changed will be called again [14:23] fugue88, the other side shouldn't set all the data until is is up [14:23] if the other side takes an hour.. and _then_ relation-sets... you'll get run again [14:23] or it should make sure to do a relation-set when it is up [14:23] james_w: Okay, we might take have to take a look at the postgresql charm. [14:24] Thanks! [14:24] but there's nothing that will cope well if there is a network hiccup during relation-changed [14:24] this dance is different with different "interfaces"... pgsql creates the db and creds on the first join... then just hands it back [14:24] newz2000: one thing to look at is the pg_hba.conf on the pg side [14:24] m_3: we have no prob connecting after it fails [14:24] hba is fine in this case. [14:25] Or, I should say... [14:25] becomes fine. [14:25] * SpamapS wishes he could focus fully on this discussion right now [14:25] ok cool... we've had problems setting that correctly in the past [14:25] Maybe a delay where the pg charm sets the relation stuff before HUP'ing postgres has finished. [14:25] We'll look. [14:26] fugue88: you can do relation-set's and relation-get's for other unrelated relationships, you don't have to busy wait [14:27] fugue88: so if you're in a relationship that gets a change, and you don't have some other relationship established yet that you need to send that data down or use it for something.. you can just defer [14:27] fugue88: right now that deferring is manual.. but its fairly straight forward how to do it. In the future I think we'll have a way to tell juju "defer this hook" and it will just retry it again [14:28] fugue88 newz2000: the pg charm is basic... please help improve it! i.e., great project post-sprint would be to add in pg9 replication :) [14:28] m_3: you're speaking our language [14:28] we're testing now, if we get it working as we think it will then we'll look at that charm next [14:28] * SpamapS goes afk bbiab [14:29] please lets continue this discussion later though [14:29] killing me to go right now! [14:29] ok, we have it working [14:29] we put an until syncdb sleep 1 in there [14:30] and it works, so that implies the charm needs to be a bit smarter [14:30] hmmmm [14:31] newz2000: hey, so why do you exit 0 on syncdb fail? that seems like a real error condition and should fail the relation [14:31] m_3: that was a misunderstanding of the docs on our part. We thought exit 0 meant it would get tried again soon. [14:31] ah gotcha [14:32] we think that could be a bit clear. :-) [14:32] clearer [14:32] yup... merging docs today as a matter of fact [14:33] m_3: what is the best way to get the postgres charm in order to propose a patch (if we're able to improve it)? [14:33] newz2000 fugue88: btw, please take meta notes about stuff like that... how we can improve the learning process. [14:33] ok === zyga-food is now known as zyga [14:35] newz2000: just branch it to a personal branch... then propose for merging. the source is lp:charms/postgresql and your personal branch should be in the format of lp:~/charms/precise/postgresql/ [14:35] m_3: cool [14:46] newz2000: you might check to see if we did anything special for syncdb timing in lp:~mark-mims/charms/oneiric/summit/trunk ( derived from lp:~michael.nelson/charms/oneiric/apache-django-wsgi/trunk ). It might've just been that running other manage.py commands added the necessary delay accidentally [14:46] m_3: ok [14:46] we've found at least one potential optimization for this charm [14:47] newz2000: that's definitely a best practice... get it talking then iterate [14:48] m_3: if you could find time to review this today I can totally remove that wiki page: https://code.launchpad.net/~jorge/juju/add-charm-store/+merge/110854 [14:49] jcastro: sure thing... I'll bump that up to do it next [15:00] SpamapS: when you get a chance, let's talk about what to do with charms that could be both a primary or a sub... seems silly to fork if the only change is `subordinate: true` [15:02] or at least let's put it on the policy todo list === zyga is now known as zyga-afk [15:18] * imbrandon returns [15:18] wow leave for an hour and yall start a party :) [15:27] hazmat: ~juju/juju/docs is not right it should be lp:juju/docs [15:28] where you keep moving merge proposals, but that branch is very old and owned by ~juju-hackers and not what is built from [15:36] <_mup_> Bug #1015637 was filed: Allow one charm to be either a primary or a subordinate service < https://launchpad.net/bugs/1015637 > [15:40] m_3: improvement to the postgresql charm: https://code.launchpad.net/~dsowen/charms/precise/postgresql/reload/+merge/111247 [15:41] works for us [15:41] m_3: also, I think the reason you didn't experience our issue with the summit charm is because you're doing enough work in your hook to not notice the delay for postgresql to restart [15:42] mornin newz2000 [15:42] howdy imbrandon === al-maisan is now known as almaisan-away [15:43] imbrandon, those are the same [15:43] imbrandon, the former is the actual target , the later an alias to it [15:44] hazmat: nah [15:44] hazmat: Diff against target:3147 lines (+2411/-174) 48 files modified [15:44] is the former [15:44] and actually its a 1 file change with 100ish loc [15:45] it might should be , but its not [15:45] but if it should be then it needs to be owned by ~charm-contributors too not ~juju-hackers [15:51] newz2000: cool thanks! processing the queue today, so I should get it into the store version [15:52] hazmat: @see https://code.launchpad.net/~jorge/juju/add-charm-store/+merge/111250 [15:52] <_mup_> Bug #1015644 was filed: Users told when deploy actually completes < https://launchpad.net/bugs/1015644 > [15:52] <_mup_> Bug #1015645 was filed: juju set not firing config-changed when passed a yaml file < https://launchpad.net/bugs/1015645 > [15:52] m_3: cool [15:52] Diff against target:156 lines (+140/-0) 2 files modified [15:53] can somebody verify Bug #1015645 when you get a chance pls? [15:53] <_mup_> Bug #1015645: juju set not firing config-changed when passed a yaml file < https://launchpad.net/bugs/1015645 > [15:53] make sure I'm not going nuts [15:53] Sure am getting this alot --> [15:53] operation timeout 2012-06-20 11:53:01,900 ERROR operation timeout [15:53] juju debug-log [15:55] <_mup_> Bug #1015649 was filed: "Unable to create file storage for environment" on 'juju bootstrap' in LXC environment < https://launchpad.net/bugs/1015649 > [15:56] hazmat or jcastro can you delete the first merge proposals ? i dont have access to [15:58] imbrandon: are these for docs? [15:59] m_3: yea i was fixing a merge proposal for jorge and going over the target with hazmat [15:59] m_3: back [15:59] imbrandon: i.e., please let me know if any MPs in the queue need to be ignored [15:59] m_3: whats an example of a charm that is primary or sub? [15:59] SpamapS: juju for one [15:59] err? [15:59] SpamapS: mysql [16:00] imbrandon: that is a placement issue, not primary/sub [16:00] I use it all the time and've copied it out to juju and juju-standalone [16:00] m_3: can you be more clear? [16:00] SpamapS: juju is a lxc container installer [16:00] lp:charms/juju [16:00] sorry for the "who's on first" aspect of that :) [16:01] SpamapS: I test lxc by spinning up the 'juju' charm in ec2 [16:01] SpamapS: but I also do classrooms by subbing juju to byobu-classroom [16:02] SpamapS: and charmtesting is migrating to be just some jenkins stuff with a juju sub for testing [16:02] <_mup_> Bug #1015654 was filed: debug-log over-rates severity of stderr output < https://launchpad.net/bugs/1015654 > [16:02] m_3: what about juju on ubuntu [16:02] imbrandon: right [16:02] meta meta [16:03] heh , kinda funy to say but yea [16:03] * m_3 is thinking of "Duuuude"... "Sweeeet"... but what does it say? [16:03] heh [16:03] m_3: right, so I think the answer here is "runtime subordination" [16:03] m_3: we need to add a simple --subordinate to deploy [16:03] <_mup_> Bug #1015655 was filed: Repeated blank lines during debug-log output < https://launchpad.net/bugs/1015655 > [16:03] SpamapS: actually to be more precise, juju isn't an lxc container installer... it's a juju client.. env is a config param [16:04] SpamapS: yeah, I'd _love_ that [16:04] m_3: we can of course fake that w/ jitsu, but this seems simple and straight forward and worth discussing w/ the juju core dev team. [16:05] SpamapS: yeah, that's why I filed it as a real bug... it's really worth it for users going forward [16:05] m_3: re-ignoring one , 110854 [16:05] i just cant change the status , its superceeded [16:05] Of course.. the original --with and --in ideas would have handled this wonderfully. :-P [16:06] imbrandon: looking [16:06] SpamapS: true [16:06] <_mup_> Bug #1015657 was filed: write-charm doesn't mention the need to bump version numbers when iterating charms < https://launchpad.net/bugs/1015657 > [16:07] brb nephew showed up, but its superceeded by 111250 [16:07] m_3: ^^ [16:07] imbrandon: whoah... that's the one jorge was just asking me to fasttrack [16:07] yea it was targets wrong [16:07] 111250 is correct [16:07] and the same merge [16:08] see hows its 156loc , thats what it should be [16:08] :) [16:08] brb [16:08] oh hey, there's a bug announce bot. [16:08] just filed bugs based on my IRC backlog in case any of you wanted to keep track on what was causing me to stumble. [16:09] * jml has to go now [16:09] looking forward to getting this darn thing deploying soon. [16:09] imbrandon: ok, I see that one [16:09] imbrandon: thanks === fenris is now known as Guest34289 [16:09] damn [16:09] so I missed all the good stuff? [16:09] :( [16:10] SpamapS: sounds like newz2000 and fugue88 got django working... and have some updates for pgsql! [16:11] great! [16:11] * m_3 is hoping somebody who knows something about pgsql can be the maintainer at some point [16:11] SpamapS: yes, we've got graphite, a Django app running [16:11] I'm working on writing up the charm store policy in a .rst document today [16:11] pgsql obviously hasn't gotten the same level of love that mysql has [16:11] newz2000: heh, are you saying mysql looks a little.. used? ;) [16:12] well, it is on rev 121 vs 17 for pg. :-) [16:12] newz2000: yeah, I wrote it by default... never used pgsql except for playing around [16:12] we're moving to use juju more and more in ISD and we deploy with pg whever possible. [16:12] So I suspect it will mature [16:12] newz2000: I was always mysql (and sqlserver, but shhhhhh) [16:12] newz2000: I imagine the most important addition you guys can make would be a pgsql-shared interface so django apps can share a db instead of having the db named after the service [16:13] and then replication :) [16:13] that's huge and missing [16:13] ok, I'll keep that in mind. [16:14] Tomorrow is SSO charm writing and it will use pg as well. [16:14] then externalizing performance tweaks into the charm config [16:14] (that might be an easy change to start with) [16:14] isn't there a new scale-out pgsql that was published recently? [16:14] m_3: indeed, it needs similar tuning capabilities to the mysql charm [16:14] SpamapS: afaik there were several solutions in pg pre-9 but now a standard one in 9 [16:15] I really wish add-unit on the mysql charm did something useful... like throw up galera replication automatically [16:15] m_3: No, something better than even that [16:15] hazmat: whats the new pgsql cluster thing? [16:19] SpamapS, postgres-xc [16:19] SpamapS, its not ha though [16:19] its linear scaling [16:20] but since its shared nothing, you need backups of each member of the cluster [16:20] Postgres-XC (eXtensible Cluster) is a multi-master write-scalable PostgreSQL cluster based on shared-nothing architecture [16:20] sounds HA to me [16:20] SpamapS, shared nothing, no replication [16:20] so it doesn't do the HA.. [16:21]