| === nath_will is now known as nathwill | ||
| EvilMog | btw I definately like the idea of a dedicated mpich2 charm, and then just setup an alternate charm for jtr | 04:24 |
|---|---|---|
| === zyga-afk is now known as zyga | ||
| === TheRealMue is now known as TheMue | ||
| === almaisan-away is now known as al-maisan | ||
| jml | am now getting this error on local deploy, bootstrap and destroy-environment: | 11:44 |
| jml | Unable to create file storage for environment | 11:44 |
| jml | 2012-06-20 12:43:47,632 ERROR Unable to create file storage for environment | 11:44 |
| jml | hmm. IRC logs that google found indicate reboot might do the trick. | 11:45 |
| kaaloo | Usually if you del /tmp/juju-local or run using sudo it will go through | 11:46 |
| jml | Yeah, I just deleted juju-local | 11:47 |
| jml | I wonder why it has that error. | 11:47 |
| * jml wishes he had a blocking deploy | 11:47 | |
| kaaloo | Ha! May the juju gods help us. Seems to go back and forth depending on the version you're using. | 11:49 |
| jml | Well, I don't think it's a good idea all the time | 11:50 |
| jml | What's the deal with all of the blank lines in debug-log during hook.output? | 11:52 |
| jml | also, I'm guessing debug-log flags stderr output as ERROR. Is that right? | 11:53 |
| imbrandon | yea | 11:56 |
| jml | 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:00 | |
| imbrandon | hazmat: ping ( when you get in this morning ) need a bit of help debuggin a build issue, should be trivial i hope | 12:19 |
| imbrandon | 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 |
| hazmat | imbrandon, pong | 12:20 |
| imbrandon | heya | 12:21 |
| imbrandon | 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 |
| imbrandon | but no go :( | 12:21 |
| imbrandon | is there a build log or anything ? | 12:21 |
| imbrandon | e.g i put the tree nav back, and added some responsive goodies like we talked about :) | 12:22 |
| hazmat | imbrandon, looks quite nice | 12:24 |
| imbrandon | ty | 12:24 |
| hazmat | 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 |
| hazmat | imbrandon, it might be a daily cron job | 12:25 |
| imbrandon | hrm kk, was 15 min before | 12:25 |
| imbrandon | no biggie tho i can just keep an eye out tomarrow worst case | 12:26 |
| imbrandon | thought there might be some logs etc , not a huge deal tho :) | 12:26 |
| jml | imbrandon: thanks. | 12:27 |
| imbrandon | should look good on tablet and phone too now, i only checked on my ipad tho | 12:27 |
| imbrandon | 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 |
| hazmat | sweet | 12:31 |
| jml | '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:40 |
| jml | Version: 0.3+bzr148-2~precise1 | 12:41 |
| imbrandon | hrm how can i charm-upgrade to just a portion of the service ? e.g. a rolling upgrade | 12:41 |
| imbrandon | jml: thats an un helpful error but what it really means is help expects an argument | 12:43 |
| imbrandon | charm help <some_command> | 12:43 |
| jml | oh. the irony. | 12:43 |
| imbrandon | heh | 12:43 |
| jcastro | imbrandon: ~charmers now has edit rights to the wiki | 12:45 |
| imbrandon | jcastro: ROCK! | 12:48 |
| imbrandon | see my latest push ? all prettyfied | 12:48 |
| imbrandon | jcastro: http://www.assets-online.com/docs/juju/index.html | 12:48 |
| imbrandon | so whenever /docs builds next thats what it will look like | 12:49 |
| jml | INFO: Setting up initscripts (2.88dsf-13.10ubuntu11) ... | 12:50 |
| jml | ERROR: mount: block device /dev/shm is write-protected, mounting read-only | 12:50 |
| jml | mount: cannot mount block device /dev/shm read-only | 12:50 |
| jml | Am getting that now when I try running dist-upgrade in my install hook (lxc environment) | 12:50 |
| jml | should I be filing bugs about all of these things? | 12:50 |
| imbrandon | likely, sorry i cant be much help, not used the local provider much | 12:52 |
| === TheRealMue is now known as TheMue | ||
| imbrandon | jcastro: no workie http://cl.ly/HVxl | 13:03 |
| m_3 | imbrandon: docs merge this morning... I'm charmpilot today | 13:04 |
| jcastro | imbrandon: can you send a mail to rt@ubuntu.com with that screenshot? | 13:06 |
| imbrandon | jcastro: sure thing | 13:06 |
| imbrandon | m_3: E:parse | 13:06 |
| jml | is there a standard thing that hooks do to silence debconf warnings about backends? | 13:21 |
| === benji is now known as Guest14462 | ||
| jml | I have to bump revision every time I make a change to a charm, even while under development, right? | 13:33 |
| === benji___ is now known as benji | ||
| mars | jml, upgrade-charm will bump the number in the revision file for you | 13:34 |
| jml | mars: thanks. | 13:35 |
| jml | (although changing '1' to '2' is probably the least of the things I want automated :)) | 13:36 |
| mars | hehe | 13:36 |
| jml | debconf :( upgrade questions :( | 13:38 |
| m_3 | jml: maybe you mean DEBIAN_FRONTEND='noninteractive'? | 13:39 |
| jml | where do I mean it? | 13:39 |
| m_3 | jml: asking about how hooks silence debconf warning | 13:39 |
| jml | so just export that at the start? | 13:40 |
| m_3 | juju sets up the hook exec environment with that set already | 13:40 |
| SpamapS | jml: you can use deploy --upgrade | 13:41 |
| m_3 | oh, now I think I understand your question... sorry. you can do something like `apt-get update || true` | 13:41 |
| m_3 | doesn't _silence_ them, but it doesn't barf on them either | 13:41 |
| jml | SpamapS: thanks. | 13:42 |
| jml | http://paste.ubuntu.com/1050895/ – that's where my install hook blocks at the moment. | 13:43 |
| jml | SpamapS: should I destroy between deploy --upgrade? | 13:44 |
| SpamapS | jml: I encourage everyone to make the upgrade-charm hook call 'stop;install;start;config-changed' so it basically redeploys | 13:44 |
| jml | SpamapS: oh right. there's a hook. :) | 13:45 |
| jml | SpamapS: if you encourage everyone to do that, why doesn't the charm created by 'charm create' do that? | 13:46 |
| SpamapS | Its also not a bad idea to "refresh" all your relations by calling them all over again but that requires careful refactoring. | 13:46 |
| m_3 | jml: so it looks like you might need to echo some config params to debconf-set-selections for that | 13:46 |
| SpamapS | jml: *GOOD IDEA* | 13:46 |
| SpamapS | honestly.. IMO juju core should do it | 13:46 |
| jml | SpamapS: I abstain from that category of discussion :) | 13:46 |
| m_3 | SpamapS: jitsu-core does though :) | 13:46 |
| SpamapS | should just call upgrade-charm; ... all of that | 13:46 |
| SpamapS | m_3: huh? :) | 13:47 |
| m_3 | juju-do will refire a relation right? | 13:47 |
| jml | I'm working up my first serious charm. Will probably just have to grep my logs here for r'<jml>.*\?' | 13:47 |
| SpamapS | m_3: jitsu do was renamed 'jitsu run-as-hook', because no, it does not do that | 13:47 |
| jml | first tip: wait until the US is awake | 13:48 |
| jml | ok, what's jitsu? | 13:48 |
| SpamapS | jml: juju-jitsu | 13:48 |
| SpamapS | jml: its in the PPA.. little helpers | 13:48 |
| m_3 | SpamapS: ah, nevermind... that hasn't been merged in yet | 13:48 |
| jml | SpamapS: I'll take a look. | 13:48 |
| jml | jitsu has no way of discovering subcommands? | 13:53 |
| newz2000 | Hi, how do we know which we should used, db-relation-joined vs db-relation-changed? | 13:54 |
| SpamapS | jml: oops, regression.. that used to happen on bare 'jitsu' | 13:54 |
| newz2000 | 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:54 |
| m_3 | 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:55 |
| james_w | I find it surprising that console-setup is prompting | 13:56 |
| m_3 | newz2000: joined is fired once, changed is continuously fired on both sides until no more relation-sets are called | 13:56 |
| james_w | I would have thought it would already be set up in the container | 13:56 |
| m_3 | james_w: yes, me too | 13:56 |
| newz2000 | m_3: if we're configuring our app to talk to the db, which is best? | 13:56 |
| james_w | as in, I haven't seen it, but maybe jml is installing some obscure packages in the install hook | 13:57 |
| jml | at this stage, I'm just dist-upgrading precise. | 13:57 |
| jml | tbh, am a little surprised that there's not a standard recipe for doing so. | 13:58 |
| m_3 | newz2000: often best in changed | 13:58 |
| m_3 | newz2000: make sure you `exit 0` if the other side (db) isn't up yet | 13:58 |
| newz2000 | m_3: ok. We're having a prob where our script is firing one time and has no login credentials | 13:58 |
| newz2000 | m_3: ok. We're still trying to wrap our heads around that part. | 13:58 |
| james_w | newz2000, you don't always get all the credentials the first time it is called | 13:58 |
| pindonga | 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 |
| james_w | pindonga, it would | 13:59 |
| m_3 | 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 |
| pindonga | SpamapS, basically what I'm looking for is something similar to the chef recipes concept | 13:59 |
| pindonga | or james_w ^ :) | 13:59 |
| m_3 | newz2000: so the first time the app gets a relation-get from the db is in changed | 13:59 |
| newz2000 | 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 |
| jml | https://bugs.launchpad.net/charm-tools/+bug/1015575 filed also | 13:59 |
| _mup_ | Bug #1015575: Error running 'charm help' without arguments <Juju Charm Tools:New> < https://launchpad.net/bugs/1015575 > | 13:59 |
| m_3 | newz2000: gets a _non-empty_ relation-get :) | 13:59 |
| james_w | pindonga, I don't think there's all that much benefit to it if it is apache-specific though | 14:00 |
| jml | grr. 'nother meeting. | 14:00 |
| newz2000 | 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 |
| m_3 | newz2000: not sure... have to see the code | 14:00 |
| m_3 | newz2000: sure | 14:00 |
| james_w | pindonga, but it's certainly a valid use of subordinates IMO | 14:01 |
| pindonga | james_w, well, the benefit would be write once read many | 14:02 |
| pindonga | :) | 14:02 |
| pindonga | don't see how you can do this in a webserver agnostic way | 14:02 |
| SpamapS | pindonga: wsgi is pretty webserver agnostic isn't it? | 14:02 |
| m_3 | 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 |
| james_w | m_3, right, that's what I thought pindonga meant, but either way would work | 14:03 |
| SpamapS | 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:04 |
| pindonga | james_w, wsgi is, but you still need an apache-modwsgi one | 14:05 |
| hazmat | 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 |
| pindonga | so apache-modwsgi is probably the right combination for a subordinate | 14:05 |
| pindonga | hazmat, the idea was to avoid repeating commonly performed stuff | 14:05 |
| james_w | 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 |
| pindonga | every app server that you deploy using apache+modwsgi follows the same steps | 14:06 |
| hazmat | pindonga, anyways.. that's my op.. there's also a gunicorn subordinate | 14:06 |
| pindonga | except for the config itself | 14:06 |
| m_3 | james_w: like that | 14:06 |
| james_w | or nginx could require the interface | 14:06 |
| pindonga | james_w, interesting | 14:06 |
| hazmat | pindonga, http://jujucharms.com/~patrick-hetu/precise/gunicorn | 14:06 |
| SpamapS | hazmat: but without inheritance, we have no way to improve general apache+wsgi charms other than subordinate/primary relationships | 14:07 |
| m_3 | similarly for a 'rack' interface | 14:07 |
| pindonga | james_w, so apache would be a subordinate charm to my app, in that case right? | 14:07 |
| james_w | pindonga, other way around | 14:07 |
| pindonga | as I need it to be deployed in the same container | 14:07 |
| SpamapS | I think we will eventually see charm inheritance, and thats how this will work | 14:07 |
| pindonga | james_w, if it's the other way, would I then juju deploy apache? (/me is at a loss) | 14:07 |
| pindonga | SpamapS,+1 | 14:08 |
| SpamapS | you'll just write 'my-sexy-django-app' which extends: django-app which extends: apache-wsgi-app | 14:08 |
| james_w | the basics would be "wsgi script, working dir, user, processes, threads" | 14:08 |
| m_3 | can't wait for that | 14:08 |
| SpamapS | funny juju might be the first language ti implement interfaces *before* inheritance | 14:08 |
| james_w | which is pretty webserver-agnostic, any any extras would require something else | 14:08 |
| * SpamapS hits the rimshot button | 14:08 | |
| hazmat | 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:08 |
| hazmat | s/right | 14:09 |
| hazmat | at least for my personal env deploys | 14:09 |
| james_w | pindonga, yeah, juju deploy apache, then juju deploy your app as a subordinate of apache, related using the wsgi interface | 14:09 |
| SpamapS | hazmat: we need to *end* this idea that personal preference is a good idea in ops | 14:09 |
| SpamapS | hazmat: there's a best way. Thats the way the charm works. | 14:10 |
| SpamapS | Measure it | 14:10 |
| m_3 | pindonga: it'd be `juju deploy --config=wsgi.yaml apache; juju deploy --config=myapp.yaml django; juju add-relation apache:wsgi django` | 14:10 |
| SpamapS | implement it | 14:10 |
| SpamapS | and stop this nonsense that op A and op B can both be "right" | 14:10 |
| hazmat | SpamapS, and patch security ;-) | 14:10 |
| hazmat | ie maintain it | 14:10 |
| SpamapS | 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 |
| hazmat | SpamapS, i agree, but unfortunately my best way is not the same as everyone elses ;-) | 14:11 |
| === zyga is now known as zyga-food | ||
| hazmat | SpamapS, gunicorn + nginx | 14:11 |
| hazmat | or gunicorn + varnish | 14:11 |
| SpamapS | right, the charm should just pick one | 14:12 |
| SpamapS | 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 | |
| m_3 | with a beret | 14:12 |
| * SpamapS cues the bass and snare | 14:13 | |
| newz2000 | m_3: (or anyone) we could use some help with this /cc fugue88 | 14:13 |
| newz2000 | http://paste.ubuntu.com/1050957/ | 14:13 |
| * hazmat turns up the django | 14:13 | |
| newz2000 | it's not successfully running syncdb, (line 45) | 14:14 |
| newz2000 | and it's also not re-running | 14:14 |
| james_w | newz2000, I'd check -n $password too | 14:14 |
| m_3 | newz2000: so that's `db-relation-changed` right? | 14:14 |
| newz2000 | m_3: yes | 14:14 |
| newz2000 | and we did actually get it working so that it gets to line 46 | 14:15 |
| newz2000 | 45 | 14:15 |
| hazmat | newz2000, are you installing django via packages or virtualenv? | 14:15 |
| newz2000 | and then it stops and doesn't retry | 14:15 |
| Beret | m_3, hey now, leave berets out of it! | 14:15 |
| m_3 | perhaps around line 6 you should bail if | 14:15 |
| hazmat | :-) | 14:15 |
| m_3 | haha | 14:15 |
| newz2000 | hazmat: package | 14:15 |
| m_3 | Beret: sorry :) | 14:15 |
| Beret | :) | 14:15 |
| james_w | newz2000, do you know what it errors with? | 14:15 |
| newz2000 | james_w: yes... | 14:15 |
| james_w | newz2000, also, are you adding this to the existing graphite charm? | 14:15 |
| m_3 | newz2000: perhaps around line 6 you should put an other-side's-not-up guard?... lemme finish reading | 14:16 |
| newz2000 | psycopg2.OperationalError: could not connect to server: Connection refused | 14:16 |
| newz2000 | Is the server running on host "192.168.122.75" and accepting | 14:16 |
| newz2000 | TCP/IP connections on port 5432? | 14:16 |
| fugue88 | m_3: What would we do in that guard? Busy-wait? | 14:16 |
| m_3 | newz2000: nevermind | 14:16 |
| newz2000 | james_w: we're doing an exercise to learn charming (ISD team srpint) | 14:16 |
| newz2000 | we made this charm yesterday, now adding db relationship to it | 14:16 |
| newz2000 | (it works fine when using local sqlite) | 14:17 |
| james_w | I wouldn't have started with graphite :-) | 14:17 |
| newz2000 | james_w: +1 | 14:17 |
| james_w | newz2000, why are you writing the credentials to /local_settings.py too? | 14:17 |
| newz2000 | debugging | 14:17 |
| james_w | ok | 14:17 |
| newz2000 | Interestingly, if we do juju ssh … then run syncdb without changing anything, it works fine. | 14:18 |
| fugue88 | 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 |
| newz2000 | btw, fugue88 and I are pair programming this | 14:19 |
| fugue88 | Also, the docs aren't clear about *what* will be retried. Only the *other* side, or both sides? | 14:19 |
| m_3 | fugue88: the relation hooks keep re-firing as long as either side keeps relation-set'ing | 14:20 |
| fugue88 | m_3: If side A relation-set's, both A's hook and B's hook will be retried? | 14:20 |
| m_3 | fugue88: any non-zero exit from a relation at any time will just error out the relation (I think) | 14:20 |
| james_w | fugue88, if they exit non-zero they won't be retried until a human intervenes | 14:21 |
| fugue88 | Good to know about the non-0. | 14:21 |
| james_w | 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 |
| fugue88 | Great! | 14:21 |
| james_w | fugue88, I don't believe anything just gets "retried" | 14:21 |
| m_3 | 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 |
| fugue88 | Oh. | 14:21 |
| fugue88 | Not great. | 14:21 |
| james_w | 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 |
| newz2000 | is thre a convention for a relation-set to happen that indicates I'm not connecting, tell me when to try again? | 14:22 |
| fugue88 | 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 |
| james_w | 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 |
| james_w | then when it does that relation-changed will be called again | 14:22 |
| james_w | fugue88, the other side shouldn't set all the data until is is up | 14:23 |
| m_3 | if the other side takes an hour.. and _then_ relation-sets... you'll get run again | 14:23 |
| james_w | or it should make sure to do a relation-set when it is up | 14:23 |
| fugue88 | james_w: Okay, we might take have to take a look at the postgresql charm. | 14:23 |
| fugue88 | Thanks! | 14:24 |
| james_w | but there's nothing that will cope well if there is a network hiccup during relation-changed | 14:24 |
| m_3 | this dance is different with different "interfaces"... pgsql creates the db and creds on the first join... then just hands it back | 14:24 |
| m_3 | newz2000: one thing to look at is the pg_hba.conf on the pg side | 14:24 |
| newz2000 | m_3: we have no prob connecting after it fails | 14:24 |
| fugue88 | hba is fine in this case. | 14:24 |
| fugue88 | Or, I should say... | 14:25 |
| fugue88 | becomes fine. | 14:25 |
| * SpamapS wishes he could focus fully on this discussion right now | 14:25 | |
| m_3 | ok cool... we've had problems setting that correctly in the past | 14:25 |
| fugue88 | Maybe a delay where the pg charm sets the relation stuff before HUP'ing postgres has finished. | 14:25 |
| fugue88 | We'll look. | 14:25 |
| SpamapS | fugue88: you can do relation-set's and relation-get's for other unrelated relationships, you don't have to busy wait | 14:26 |
| SpamapS | 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 |
| SpamapS | 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:27 |
| m_3 | 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 |
| newz2000 | m_3: you're speaking our language | 14:28 |
| newz2000 | 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:28 | |
| SpamapS | please lets continue this discussion later though | 14:29 |
| SpamapS | killing me to go right now! | 14:29 |
| newz2000 | ok, we have it working | 14:29 |
| newz2000 | we put an until syncdb sleep 1 in there | 14:29 |
| newz2000 | and it works, so that implies the charm needs to be a bit smarter | 14:30 |
| m_3 | hmmmm | 14:30 |
| m_3 | 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 |
| newz2000 | 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 |
| m_3 | ah gotcha | 14:31 |
| newz2000 | we think that could be a bit clear. :-) | 14:32 |
| newz2000 | clearer | 14:32 |
| m_3 | yup... merging docs today as a matter of fact | 14:32 |
| newz2000 | 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 |
| m_3 | newz2000 fugue88: btw, please take meta notes about stuff like that... how we can improve the learning process. | 14:33 |
| newz2000 | ok | 14:33 |
| === zyga-food is now known as zyga | ||
| m_3 | 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:~<lp-id>/charms/precise/postgresql/<some-branch-name> | 14:35 |
| newz2000 | m_3: cool | 14:35 |
| m_3 | 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 |
| newz2000 | m_3: ok | 14:46 |
| newz2000 | we've found at least one potential optimization for this charm | 14:46 |
| m_3 | newz2000: that's definitely a best practice... get it talking then iterate | 14:47 |
| jcastro | 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:48 |
| m_3 | jcastro: sure thing... I'll bump that up to do it next | 14:49 |
| m_3 | 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:00 |
| m_3 | or at least let's put it on the policy todo list | 15:02 |
| === zyga is now known as zyga-afk | ||
| * imbrandon returns | 15:18 | |
| imbrandon | wow leave for an hour and yall start a party :) | 15:18 |
| imbrandon | hazmat: ~juju/juju/docs is not right it should be lp:juju/docs | 15:27 |
| imbrandon | where you keep moving merge proposals, but that branch is very old and owned by ~juju-hackers and not what is built from | 15:28 |
| _mup_ | Bug #1015637 was filed: Allow one charm to be either a primary or a subordinate service <juju:New> < https://launchpad.net/bugs/1015637 > | 15:36 |
| newz2000 | m_3: improvement to the postgresql charm: https://code.launchpad.net/~dsowen/charms/precise/postgresql/reload/+merge/111247 | 15:40 |
| newz2000 | works for us | 15:41 |
| newz2000 | 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:41 |
| imbrandon | mornin newz2000 | 15:42 |
| newz2000 | howdy imbrandon | 15:42 |
| === al-maisan is now known as almaisan-away | ||
| hazmat | imbrandon, those are the same | 15:43 |
| hazmat | imbrandon, the former is the actual target , the later an alias to it | 15:43 |
| imbrandon | hazmat: nah | 15:44 |
| imbrandon | hazmat: Diff against target:3147 lines (+2411/-174) 48 files modified | 15:44 |
| imbrandon | is the former | 15:44 |
| imbrandon | and actually its a 1 file change with 100ish loc | 15:44 |
| imbrandon | it might should be , but its not | 15:45 |
| imbrandon | but if it should be then it needs to be owned by ~charm-contributors too not ~juju-hackers | 15:45 |
| m_3 | newz2000: cool thanks! processing the queue today, so I should get it into the store version | 15:51 |
| imbrandon | 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 <juju:New> < https://launchpad.net/bugs/1015644 > | 15:52 |
| _mup_ | Bug #1015645 was filed: juju set not firing config-changed when passed a yaml file <juju:New> < https://launchpad.net/bugs/1015645 > | 15:52 |
| newz2000 | m_3: cool | 15:52 |
| imbrandon | Diff against target:156 lines (+140/-0) 2 files modified | 15:52 |
| m_3 | 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 <juju:New> < https://launchpad.net/bugs/1015645 > | 15:53 |
| m_3 | make sure I'm not going nuts | 15:53 |
| surgemcgee | Sure am getting this alot --> | 15:53 |
| surgemcgee | operation timeout 2012-06-20 11:53:01,900 ERROR operation timeout | 15:53 |
| surgemcgee | juju debug-log | 15:53 |
| _mup_ | Bug #1015649 was filed: "Unable to create file storage for environment" on 'juju bootstrap' in LXC environment <juju:New> < https://launchpad.net/bugs/1015649 > | 15:55 |
| imbrandon | hazmat or jcastro can you delete the first merge proposals ? i dont have access to | 15:56 |
| m_3 | imbrandon: are these for docs? | 15:58 |
| imbrandon | m_3: yea i was fixing a merge proposal for jorge and going over the target with hazmat | 15:59 |
| SpamapS | m_3: back | 15:59 |
| m_3 | imbrandon: i.e., please let me know if any MPs in the queue need to be ignored | 15:59 |
| SpamapS | m_3: whats an example of a charm that is primary or sub? | 15:59 |
| m_3 | SpamapS: juju for one | 15:59 |
| SpamapS | err? | 15:59 |
| imbrandon | SpamapS: mysql | 15:59 |
| SpamapS | imbrandon: that is a placement issue, not primary/sub | 16:00 |
| m_3 | I use it all the time and've copied it out to juju and juju-standalone | 16:00 |
| SpamapS | m_3: can you be more clear? | 16:00 |
| m_3 | SpamapS: juju is a lxc container installer | 16:00 |
| m_3 | lp:charms/juju | 16:00 |
| m_3 | sorry for the "who's on first" aspect of that :) | 16:00 |
| m_3 | SpamapS: I test lxc by spinning up the 'juju' charm in ec2 | 16:01 |
| m_3 | SpamapS: but I also do classrooms by subbing juju to byobu-classroom | 16:01 |
| m_3 | 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 <juju:New> < https://launchpad.net/bugs/1015654 > | 16:02 |
| imbrandon | m_3: what about juju on ubuntu | 16:02 |
| m_3 | imbrandon: right | 16:02 |
| m_3 | meta meta | 16:02 |
| imbrandon | heh , kinda funy to say but yea | 16:03 |
| * m_3 is thinking of "Duuuude"... "Sweeeet"... but what does it say? | 16:03 | |
| imbrandon | heh | 16:03 |
| SpamapS | m_3: right, so I think the answer here is "runtime subordination" | 16:03 |
| SpamapS | 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 <juju:New> < https://launchpad.net/bugs/1015655 > | 16:03 |
| m_3 | SpamapS: actually to be more precise, juju isn't an lxc container installer... it's a juju client.. env is a config param | 16:03 |
| m_3 | SpamapS: yeah, I'd _love_ that | 16:04 |
| SpamapS | 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:04 |
| m_3 | SpamapS: yeah, that's why I filed it as a real bug... it's really worth it for users going forward | 16:05 |
| imbrandon | m_3: re-ignoring one , 110854 | 16:05 |
| imbrandon | i just cant change the status , its superceeded | 16:05 |
| SpamapS | Of course.. the original --with and --in ideas would have handled this wonderfully. :-P | 16:05 |
| m_3 | imbrandon: looking | 16:06 |
| m_3 | SpamapS: true | 16:06 |
| _mup_ | Bug #1015657 was filed: write-charm doesn't mention the need to bump version numbers when iterating charms <juju:New> < https://launchpad.net/bugs/1015657 > | 16:06 |
| imbrandon | brb nephew showed up, but its superceeded by 111250 | 16:07 |
| imbrandon | m_3: ^^ | 16:07 |
| m_3 | imbrandon: whoah... that's the one jorge was just asking me to fasttrack | 16:07 |
| imbrandon | yea it was targets wrong | 16:07 |
| imbrandon | 111250 is correct | 16:07 |
| imbrandon | and the same merge | 16:07 |
| imbrandon | see hows its 156loc , thats what it should be | 16:08 |
| imbrandon | :) | 16:08 |
| imbrandon | brb | 16:08 |
| jml | oh hey, there's a bug announce bot. | 16:08 |
| jml | 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:08 |
| * jml has to go now | 16:09 | |
| jml | looking forward to getting this darn thing deploying soon. | 16:09 |
| m_3 | imbrandon: ok, I see that one | 16:09 |
| m_3 | imbrandon: thanks | 16:09 |
| === fenris is now known as Guest34289 | ||
| SpamapS | damn | 16:09 |
| SpamapS | so I missed all the good stuff? | 16:09 |
| SpamapS | :( | 16:09 |
| m_3 | SpamapS: sounds like newz2000 and fugue88 got django working... and have some updates for pgsql! | 16:10 |
| SpamapS | great! | 16:11 |
| * m_3 is hoping somebody who knows something about pgsql can be the maintainer at some point | 16:11 | |
| newz2000 | SpamapS: yes, we've got graphite, a Django app running | 16:11 |
| SpamapS | I'm working on writing up the charm store policy in a .rst document today | 16:11 |
| newz2000 | pgsql obviously hasn't gotten the same level of love that mysql has | 16:11 |
| SpamapS | newz2000: heh, are you saying mysql looks a little.. used? ;) | 16:11 |
| newz2000 | well, it is on rev 121 vs 17 for pg. :-) | 16:12 |
| m_3 | newz2000: yeah, I wrote it by default... never used pgsql except for playing around | 16:12 |
| newz2000 | we're moving to use juju more and more in ISD and we deploy with pg whever possible. | 16:12 |
| newz2000 | So I suspect it will mature | 16:12 |
| m_3 | newz2000: I was always mysql (and sqlserver, but shhhhhh) | 16:12 |
| SpamapS | 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:12 |
| m_3 | and then replication :) | 16:13 |
| m_3 | that's huge and missing | 16:13 |
| newz2000 | ok, I'll keep that in mind. | 16:13 |
| newz2000 | Tomorrow is SSO charm writing and it will use pg as well. | 16:14 |
| m_3 | then externalizing performance tweaks into the charm config | 16:14 |
| m_3 | (that might be an easy change to start with) | 16:14 |
| SpamapS | isn't there a new scale-out pgsql that was published recently? | 16:14 |
| SpamapS | m_3: indeed, it needs similar tuning capabilities to the mysql charm | 16:14 |
| m_3 | SpamapS: afaik there were several solutions in pg pre-9 but now a standard one in 9 | 16:14 |
| SpamapS | I really wish add-unit on the mysql charm did something useful... like throw up galera replication automatically | 16:15 |
| SpamapS | m_3: No, something better than even that | 16:15 |
| SpamapS | hazmat: whats the new pgsql cluster thing? | 16:15 |
| hazmat | SpamapS, postgres-xc | 16:19 |
| hazmat | SpamapS, its not ha though | 16:19 |
| hazmat | its linear scaling | 16:19 |
| hazmat | but since its shared nothing, you need backups of each member of the cluster | 16:20 |
| SpamapS | Postgres-XC (eXtensible Cluster) is a multi-master write-scalable PostgreSQL cluster based on shared-nothing architecture | 16:20 |
| SpamapS | sounds HA to me | 16:20 |
| hazmat | SpamapS, shared nothing, no replication | 16:20 |
| SpamapS | so it doesn't do the HA.. | 16:20 |
| SpamapS | but it would be trivial to make it HA | 16:21 |
| SpamapS | its RAID0 .. | 16:21 |
| SpamapS | replication is RAID1 | 16:21 |
| SpamapS | so.. we need a postgresql-raid10 :) | 16:21 |
| imbrandon | heh | 16:21 |
| hazmat | SpamapS, re pg we should focus on streaming replication options | 16:21 |
| hazmat | postgres-xc is a different beast | 16:21 |
| SpamapS | hazmat: I want both | 16:21 |
| SpamapS | We should be able to do XC as a peer relation, and streaming replication as a provides/requires | 16:21 |
| imbrandon | just use mysql and be done :) | 16:21 |
| hazmat | SpamapS, me too.. but since we have neither.. we should get pg doing something decent first.. since its actually used by many. | 16:22 |
| SpamapS | its used by nobody right now | 16:22 |
| SpamapS | in the context of juju :) | 16:22 |
| SpamapS | (unless people are adopting juju in secret) | 16:22 |
| hazmat | SpamapS, who uses that ? ;-) | 16:22 |
| imbrandon | heh actually there are, i see tweets about internal juju deployments all the time | 16:23 |
| hazmat | anyways.. i'd vote for spiffing up the pg charm with replication first. | 16:23 |
| hazmat | but the do-ers have vetoes | 16:23 |
| === salgado is now known as salgado-lunch | ||
| * hazmat lunches | 16:33 | |
| === Guest34289 is now known as ejat | ||
| imbrandon | hazmat: so how should we fix the docs targets, looking at the review queue, they are all targeted wrong | 16:39 |
| hazmat | imbrandon, i'm not clear that their broken | 16:40 |
| hazmat | imbrandon, this one is correct.. https://code.launchpad.net/~jorge/juju/add-charm-store/+merge/111250 | 16:41 |
| hazmat | but i guess you fixed it | 16:41 |
| hazmat | imbrandon, so in general on those we should repropose | 16:41 |
| imbrandon | yea thats thje only one | 16:41 |
| hazmat | that's what i've been doing in the past | 16:41 |
| imbrandon | ok cool, just wasent sure | 16:41 |
| imbrandon | i can do that for those in the que now | 16:42 |
| hazmat | it takes too long to ask the original sometimes to do so, just note in the merge proposal.. the review queue still shows the correct origin person/branch | 16:42 |
| hazmat | imbrandon, if its in the review queue it should be correct.. | 16:42 |
| imbrandon | yea | 16:42 |
| imbrandon | no | 16:42 |
| hazmat | hmm.. | 16:42 |
| hazmat | so this one https://code.launchpad.net/~jorge/juju/add-charm-store/+merge/110854 | 16:42 |
| imbrandon | there is alot un the queue wrong, infact the one you showed me that i fixed is the only right one | 16:42 |
| imbrandon | yea, see the huge diff | 16:43 |
| hazmat | imbrandon, but its correctly done | 16:43 |
| hazmat | imbrandon, its a branch of docs targeting docs | 16:43 |
| imbrandon | ~juju/juju/docs isnt a failed branch and needs removed | 16:43 |
| imbrandon | it dont point anywhere | 16:44 |
| hazmat | oh.. | 16:44 |
| * hazmat gets it now | 16:44 | |
| hazmat | imbrandon, right | 16:44 |
| imbrandon | yea :) | 16:44 |
| hazmat | the lp:juju/docs doesn't point there anymore it goes to ~charm-contributors/juju/docs | 16:44 |
| _mup_ | Bug #1015682 was filed: docs... 'make text' fails <juju:New> < https://launchpad.net/bugs/1015682 > | 16:44 |
| imbrandon | ahh ok, that makes sense | 16:44 |
| imbrandon | ok sooo ... | 16:45 |
| imbrandon | heh | 16:45 |
| hazmat | so we should correct ones that show up like that hopefully not too many.. they won't show up in the review queue unless they target 'docs'.. i need to grab my takeout, bbiab | 16:46 |
| imbrandon | kk | 16:46 |
| imbrandon | m_3: make text works here | 16:47 |
| imbrandon | toctree is part of sphinx, do you have a really old version ? | 16:47 |
| imbrandon | 1.1.3 i see , hrm | 16:48 |
| imbrandon | oh thast ~juju/juju/docs | 16:48 |
| imbrandon | m_3: wrong branch | 16:48 |
| m_3 | imbrandon: huh | 16:50 |
| m_3 | imbrandon: that bug was against trunk bzr10... before any merges | 16:50 |
| imbrandon | yea thats a really old bzr branch | 16:51 |
| imbrandon | we're on like bzr39 | 16:51 |
| imbrandon | or something | 16:51 |
| imbrandon | ~charm-contributors/juju/docs | 16:51 |
| imbrandon | m_3: all these merge proposals are targeting the wrong bzr branch by mistake, they should target ~charm-contributors/juju/docs or lp:juju/docs , not ~juju/juju/docs | 16:53 |
| m_3 | imbrandon: ah, ok... I was starting from the oldest MPs and going forward | 16:53 |
| m_3 | imbrandon: thanks | 16:53 |
| imbrandon | yea no matter what the MP says do it against lp:juju/docs | 16:53 |
| m_3 | gotcha | 16:53 |
| imbrandon | and it should be correct | 16:53 |
| * imbrandon is trying to get it all streight :) | 16:54 | |
| SpamapS | we should fix all the warnings on the juju docs | 17:18 |
| _mup_ | Bug #1015704 was filed: docs: empty the drafts folder on production <juju:New> < https://launchpad.net/bugs/1015704 > | 17:18 |
| SpamapS | :make html in vim has quite a lot to say ;) | 17:18 |
| imbrandon | never tried it in vim, but yea that was one of my goals SpamapS , over time :) | 17:22 |
| === koolhead17|afk is now known as koolhead17 | ||
| imbrandon | 146ish of them or something | 17:22 |
| SpamapS | imbrandon: hey, the new theme.. it doesn't have any way to navigate sections | 17:23 |
| SpamapS | imbrandon: thats pretty vital, you adding it back in? | 17:23 |
| imbrandon | i thought of that, and am looking at it | 17:23 |
| imbrandon | was actaully what i was doiing now | 17:24 |
| === salgado-lunch is now known as salgado | ||
| imbrandon | dident seem to be missing that much tho honestly, after looking it over more, but yea i'm testing diffrent ways now | 17:25 |
| imbrandon | SpamapS: you are talking about this http://www.assets-online.com/docs/juju/index.html | 17:25 |
| imbrandon | right ? | 17:26 |
| SpamapS | no | 17:26 |
| SpamapS | imbrandon: the thing thats being built right now in lp:juju/docs | 17:26 |
| imbrandon | oh then yea, i added the tree back in | 17:26 |
| SpamapS | unless thats been updated | 17:26 |
| imbrandon | its been updated | 17:26 |
| SpamapS | I haven't pulled in a day or two | 17:26 |
| SpamapS | well then YAY | 17:26 |
| imbrandon | check that link, thats what it will look like next build | 17:26 |
| SpamapS | imbrandon: awesome! | 17:27 |
| SpamapS | imbrandon: wait, still no sections | 17:27 |
| imbrandon | i thought it was building every 15 minutes but somethign is broken or it isnt | 17:27 |
| SpamapS | thats the toc | 17:27 |
| SpamapS | I need the sections of the document | 17:28 |
| imbrandon | yea and thats what i was refering to as i was working with right now to add in somehow | 17:28 |
| imbrandon | but reeally there is one or two toc items that really need it, and i'm wondering if they dont need broken up instread | 17:29 |
| m_3 | SpamapS: fixing some warnings now | 17:29 |
| imbrandon | but yea working on it now | 17:29 |
| m_3 | imbrandon: if you're playing with layout you probably should be doing that on a separate feature branch and not trunk | 17:30 |
| imbrandon | SpamapS: see https://juju.ubuntu.com/docs/faq.html sections there | 17:30 |
| SpamapS | imbrandon: yeah, thats pretty awful. ;) | 17:30 |
| SpamapS | and agreed | 17:31 |
| imbrandon | m_3: layout is done, just a one char change to add sections but yea | 17:31 |
| SpamapS | playing on trunk is a no-no | 17:31 |
| m_3 | so what do we do right now... I'm halfway through a stack of merges | 17:32 |
| m_3 | should I stop and let trunk settle? | 17:32 |
| imbrandon | no | 17:32 |
| imbrandon | i am no pushing anything | 17:32 |
| m_3 | or keep going and let imbrandon deal with conflicts | 17:32 |
| imbrandon | yea go go, i'm off in my world | 17:32 |
| m_3 | imbrandon: ok | 17:32 |
| imbrandon | i'll fix it if you step on my toes accidently | 17:32 |
| imbrandon | :) | 17:32 |
| imbrandon | but yea its just one char change to add sections back in, but i'm working localy etc etc thus the assets-online domain to visualize | 17:33 |
| imbrandon | etc | 17:33 |
| imbrandon | so yea dont pay me no mind m_3 go go | 17:34 |
| imbrandon | SpamapS: btw uploading nginx+spdy to ppa here in a few | 17:37 |
| imbrandon | have it all working | 17:37 |
| koolhead17 | bkerensa_, around | 17:37 |
| SpamapS | imbrandon: nice, so then we can just add an 'nginx-website' interface that lets subs drop a file in /etc/nginx/sites-enabled, and away we go? | 17:38 |
| imbrandon | yup basicly | 17:38 |
| SpamapS | imbrandon: I love that. That should make scaling *php* quite easy. :) | 17:39 |
| bkerensa_ | koolhead17: sup? | 17:39 |
| === bkerensa_ is now known as bkerensa | ||
| imbrandon | SpamapS: how do you squash a commit in bzr ? | 18:14 |
| SpamapS | imbrandon: bzr uncommit | 18:15 |
| SpamapS | imbrandon: though that will make your branch diverge | 18:15 |
| imbrandon | erm | 18:15 |
| imbrandon | not good | 18:15 |
| imbrandon | i just really want to append to the last commit | 18:16 |
| SpamapS | imbrandon: if you just want something like git revert, I believe you just do it like svn and reverse merge | 18:16 |
| lifeless | imbrandon: SpamapS: squash makes git branches fiverge too :) | 18:17 |
| lifeless | imbrandon: uncommit is the right thing, long as its a local branch vs e.g. trunk. | 18:17 |
| SpamapS | oh is squash something in git ?? | 18:17 |
| imbrandon | yea | 18:17 |
| SpamapS | Ok, never used it | 18:17 |
| lifeless | SpamapS: http://365git.tumblr.com/post/4364212086/git-merge-squash | 18:17 |
| SpamapS | still fighting tooth and nail to not have to learn git until the rest of the world sucks me in. :-P | 18:17 |
| imbrandon | heh, hey now i'm _trying_ with bzr :) | 18:18 |
| imbrandon | lol | 18:18 |
| imbrandon | ok so i want my working copy uncommited changes added to my last commit | 18:19 |
| imbrandon | uncommit is the right thing ? | 18:19 |
| hazmat | just add a new commit | 18:19 |
| imbrandon | heh yea, sounds like it | 18:20 |
| lifeless | imbrandon: yes, uncommit will pop off the commit and not change your working copy at all. | 18:20 |
| lifeless | imbrandon: then you can commit again, and everything gets saved | 18:20 |
| imbrandon | k | 18:20 |
| hazmat | bzr doesn't want to support the whole rewrite commit history workflow.. | 18:20 |
| lifeless | hazmat: well | 18:20 |
| hazmat | for good reason.. | 18:20 |
| hazmat | lifeless, i know.. it can. | 18:20 |
| lifeless | hazmat: thats not strictly true. | 18:20 |
| hazmat | but that's not the intended usage model | 18:21 |
| imbrandon | yea ... with great power ... bah , adding commit | 18:21 |
| imbrandon | ;) | 18:21 |
| hazmat | lifeless, are you saying it does want to support it.. or just noting that it can? | 18:21 |
| lifeless | hazmat: https://lists.ubuntu.com/archives/bazaar/2009q2/059263.html | 18:22 |
| hazmat | lifeless, incidentally do you know if the multi branch in single dir support in bzr work is basically on hold? | 18:23 |
| lifeless | hazmat: 3-mumble years ago I analysed the tasks users need to do with their VCS w.r.t. history management and came to the conclusion that editory editing is a core facility for a VCS | 18:23 |
| lifeless | hazmat: the team are currently holding the fort for maintenance across the LP portfolio, so yes. Patches would be loved - it works but needs some UI polish basically. | 18:24 |
| lifeless | hazmat: I would, if doing the analysis now, create and reference some personas, to make it more concrete. | 18:25 |
| lifeless | but I think the conclusions owuld have been the same. I wish I'd pushed harder subsequent to that doc, now. | 18:25 |
| hazmat | lifeless, thanks for the link, digesting | 18:26 |
| SpamapS | http://spamaps.org/files/charm-store-policy/policy.html | 18:31 |
| SpamapS | A rough draft, for your reading pleasure | 18:31 |
| hazmat | ideally we expand the toc tree out on the current section | 18:32 |
| hazmat | and that goes under charms | 18:32 |
| imbrandon | hazmat: just poposed that merge | 18:32 |
| imbrandon | https://code.launchpad.net/~imbrandon/juju/docs/+merge/111281 | 18:32 |
| imbrandon | :) | 18:32 |
| hazmat | imbrandon, nice! | 18:32 |
| SpamapS | imbrandon: hah, that charm-store.rst ... I just took all the 'musts' from that and put them in the policy.rst that I'm working on | 18:32 |
| imbrandon | heh | 18:33 |
| imbrandon | and infact m_3 just merged it, he's on it :) | 18:33 |
| SpamapS | Yeah thats fine, I'll pull them out of it before I commit to trunk | 18:33 |
| hazmat | doh.. here i was bothering to approve it ;-) | 18:33 |
| * SpamapS grabs lunch | 18:34 | |
| imbrandon | :) | 18:34 |
| imbrandon | SpamapS: thats still i good idea i think | 18:34 |
| * imbrandon gets food as well | 18:35 | |
| * m_3 too | 18:35 | |
| jcastro | m_3: I didn't even notice the drafts folder, heh | 18:39 |
| lifeless | hazmat: checking you got my reply; maybe I'm not signed in to freenode or something | 18:46 |
| hazmat | lifeless, just saw it now | 18:47 |
| lifeless | cool | 18:49 |
| m_3 | bcsaller: yo | 18:57 |
| bcsaller | m_3: hey | 18:58 |
| m_3 | bcsaller: hey, so in lp:juju/docs | 18:58 |
| m_3 | there's a drafts/subordinate-internals.rst | 18:58 |
| m_3 | that's referencing a relative path subordinate-services.rst | 18:59 |
| m_3 | but the latter got moved to toplevel | 18:59 |
| m_3 | can you please tell me what should go where? and/or give me a branch? | 18:59 |
| m_3 | happy to file a bug if you'd rather... just trying to clean docs up today | 19:00 |
| bcsaller | m_3: internals are just impl details, the other sub-serv is the user facing doc | 19:00 |
| m_3 | should the draft/sub-internals be moved to internals/? | 19:00 |
| bcsaller | m_3: yeah, now that its in trunk it should | 19:00 |
| m_3 | i.e., is any of that still WIP or is it all released? | 19:00 |
| m_3 | ok cool | 19:00 |
| m_3 | gracias! | 19:01 |
| bcsaller | :) | 19:01 |
| robbiew | jcastro: yo...dumb/out-of-touch question...where are we hosting the juju client rpms? Is the plan still to leverage the OpenSUSE Build Service? | 19:05 |
| jcastro | https://github.com/jujutools/rpm-juju | 19:05 |
| imbrandon | robbiew: github atm , on the same group as osx forumula , and yes | 19:05 |
| imbrandon | :) | 19:05 |
| robbiew | imbrandon: heh...thanks jcastro2.0 | 19:07 |
| imbrandon | i'm happy to shift things arround if a better spot is deemed , just figured i'd keep the "ports" togather | 19:07 |
| robbiew | imbrandon: nah..just curious | 19:07 |
| robbiew | I know the OBS can build for other distros, so just an "easy" way to support multiple RPM-based clients | 19:08 |
| imbrandon | yup, even builds right from git, someone sugested it like 5 min after i posted em | 19:08 |
| imbrandon | i was like erm , nice | 19:08 |
| imbrandon | infact i should put the OSX and RPM docs in /docs today | 19:09 |
| jcastro | looks like a nice thing for the next set of builds | 19:09 |
| jcastro | hmm I dig that new style you guys linked to too | 19:09 |
| jcastro | also, I'm going to take a crack at that About page in the docs. | 19:09 |
| imbrandon | :) | 19:09 |
| jcastro | it's basically the most boring three paragraphs I've ever read in my life. | 19:10 |
| imbrandon | jcastro: see how i did the front page and you can jaz it up | 19:10 |
| imbrandon | with plain html | 19:10 |
| imbrandon | for pictograms and such | 19:11 |
| m_3 | imbrandon: got some other additions to the toc in a sec | 19:11 |
| imbrandon | m_3: cool, i only had that one merge | 19:11 |
| m_3 | relation stuff | 19:11 |
| imbrandon | for now | 19:11 |
| imbrandon | so i'm back hands off for a few, was thinking about combineing the provider config pages and adding the OSX/RPM pages | 19:12 |
| imbrandon | but i'll do them as merge req's | 19:12 |
| jcastro | hmm yeah | 19:12 |
| jcastro | a separate page for OSX and RPMs would be useful | 19:13 |
| m_3 | we had some stuff in drafts that needed to go out toplevel | 19:13 |
| imbrandon | yea basicly the info i have on the github pages | 19:13 |
| m_3 | then it needs just overall love | 19:13 |
| imbrandon | :) | 19:13 |
| m_3 | jcastro: yeah, that's a good idea | 19:13 |
| jcastro | heya hazmat | 19:14 |
| imbrandon | i'll start a draft for it now, "ports" unless someone has a better name | 19:14 |
| jcastro | do you have powers to kick off the doc generating cron on demand? | 19:14 |
| jcastro | like say ... nowish? | 19:14 |
| jcastro | robbiew: http://www.hanselman.com/blog/ManagingTheCloudFromTheCommandLine.aspx | 19:16 |
| jcastro | there's a link to the cool node tools for azure btw. | 19:17 |
| imbrandon | yea their account mgmt on the cli is pretty sweet, i was thinking aobut how to add that to juju-jitsu | 19:17 |
| robbiew | jcastro: ack, thx | 19:17 |
| imbrandon | azure import account.json --> jitsu import environments.json :) | 19:18 |
| imbrandon | SpamapS: ^ | 19:18 |
| jcastro | jI want that kind of syntax for AWS'es tools | 19:19 |
| jcastro | not "oh in order to make that easy you should grab smoser's scripts from git." | 19:19 |
| m_3 | jcastro: give the doc gen a couple of minutes | 19:19 |
| jcastro | ok | 19:20 |
| jcastro | m_3: man, everyone is excited about docs today | 19:20 |
| jcastro | people must be bored | 19:20 |
| imbrandon | LOL | 19:20 |
| imbrandon | its my new sexy theme, well about to be new sexy theme when it builds :) | 19:21 |
| * imbrandon ducks | 19:21 | |
| hazmat | jcastro, no.. | 19:25 |
| hazmat | jcastro, that's a prod machine run by is | 19:25 |
| m_3 | jcastro: docs were just big on the review queue | 19:29 |
| m_3 | jcastro: yeah, I don't see an obvious way to kick it off from lp | 19:29 |
| jcastro | it's no biggie I think | 19:29 |
| m_3 | jcastro: well all the queued items are in... please pull and take a look locally when you get a chance. it still needs love across the board as far as content and organization is concerned | 19:30 |
| hazmat | jcastro, for a preview its, there is a cron job i can/have poked at http://jujucharms.com/docs | 19:30 |
| m_3 | hazmat: just updated like two minutes ago... poke again after a bit pls | 19:31 |
| * m_3 back to charms | 19:31 | |
| jcastro | oh cool | 19:31 |
| hazmat | m_3, just switched out to 10m pulls | 19:31 |
| jcastro | m_3: I'm hoping for elastic search to make it! | 19:32 |
| jcastro | though the queue says 11 months | 19:32 |
| jcastro | I think it's measuring from the bug being filed | 19:32 |
| jcastro | not the branch being attached | 19:32 |
| * jcastro goes to file a bug | 19:32 | |
| hazmat | jcastro, not all of the bugs have branches attached.. | 19:33 |
| m_3 | jcastro: yeah, it's age of bug | 19:33 |
| hazmat | some just drop it in the description or a comment | 19:33 |
| jcastro | right | 19:33 |
| jcastro | but we don't care to review it unless there's a branch attached | 19:33 |
| hazmat | imbrandon, one more suggestion for the navtree, make it perm re screen pos, else you can click on it, and loose it if you subnavigate something | 19:34 |
| jcastro | like if I filed a wishlist a year ago, and someone attaches a branch today, the age should be one day, not one year and one day. | 19:34 |
| hazmat | jcastro, there is a branch noted on the bug just not attached.. its fairly common | 19:34 |
| imbrandon | ahh yea, i actually have that in the css and turned it off, wasent sure | 19:35 |
| imbrandon | hazmat: ^ | 19:35 |
| hazmat | imbrandon, cool, i think its makes sense, that whole area isn't being used, and navtree follows focus makes sense i think | 19:35 |
| imbrandon | yea, it made some finky flicker tho, but i can fix that i'm sure, i'll toy with it tonight | 19:36 |
| imbrandon | funky* | 19:36 |
| hazmat | thanks | 19:36 |
| m_3 | jcastro: yeah, if there's a bug last modified time | 19:37 |
| m_3 | jcastro: otherwise we can make up some sort of time since picked up into the queue | 19:38 |
| m_3 | then that'd catch when it's removed from the queue b/c of status change | 19:38 |
| m_3 | and the clock starts over when the status puts it _back_ in the queue... | 19:38 |
| jcastro | ok I'll file that | 19:39 |
| imbrandon | see we could easily make this the front page of juju.u.c tho :) | 19:41 |
| imbrandon | it really has all the info etc | 19:42 |
| hazmat | m_3, yeah.. last modified works a bit better | 19:44 |
| hazmat | m_3, the queue doesn't keep state | 19:44 |
| hazmat | although modified has its own problems | 19:45 |
| m_3 | right | 19:47 |
| m_3 | it's good enough | 19:47 |
| imbrandon | hazmat: ohh i see what you mean about the subnav | 19:52 |
| imbrandon | hrm, thats a bit more tricky | 19:52 |
| SpamapS | jimbaker: hey, how is jitsu watch supposed to work? I want to wait for agent-state: started ... | 19:53 |
| imbrandon | because it cant be fixed if you scroll, but needs to be fixed if you click | 19:53 |
| SpamapS | ahh wait | 19:53 |
| SpamapS | --state | 19:53 |
| imbrandon | hazmat: hrm, actually bootstrap scrollspy.js would work i think | 19:55 |
| jimbaker | SpamapS, correct | 19:55 |
| jimbaker | which also will apply --num-units | 19:55 |
| jimbaker | =1 if you're watching a service | 19:55 |
| jimbaker | if you're using the latest proposed branch | 19:56 |
| m_3 | SpamapS: --help is pretty verbose | 19:58 |
| m_3 | jitsu watch -h | 19:58 |
| * m_3 is excited about the test possibilities that opens up | 19:58 | |
| SpamapS | yeah | 20:00 |
| m_3 | jimbaker: I'm curious to see what you did to make it play so nicely with shell signals | 20:00 |
| SpamapS | we need to be able to wildcard the units | 20:00 |
| m_3 | jimbaker: it responds so nicely to timeout | 20:00 |
| m_3 | jimbaker: I wish we could do the same with some other juju commands (I mess up juju ssh all the time and try to ctrl-c it to no avail) | 20:01 |
| imbrandon | hahah me too | 20:01 |
| SpamapS | Isn't that just because the KeyboardInterrupt isn't being handled properly? | 20:02 |
| SpamapS | need to shutdown the reactor or something | 20:02 |
| m_3 | SpamapS: dunno... thought it was trapping something it shouldn't | 20:02 |
| SpamapS | imbrandon: is there a way to get sphinx to display arbitrary doc fields in the HTML? | 20:04 |
| SpamapS | :Version: 0.1 | 20:04 |
| SpamapS | I want to show that | 20:04 |
| SpamapS | actually I can just dup them into visible text | 20:05 |
| imbrandon | yea | 20:05 |
| imbrandon | i think i know what ya mean | 20:05 |
| imbrandon | gimme example ,but yea, sphinx is like god, i seriously have fallen in love with it, its got some rough spots but yea | 20:06 |
| imbrandon | and the template syntax is like Twig :) | 20:06 |
| imbrandon | SpamapS: oh yea for a version | 20:07 |
| imbrandon | just add it to the conf.py ( look in the html section ) as a option | 20:08 |
| imbrandon | then use like {{ option_name }} | 20:08 |
| imbrandon | in the footer or something | 20:08 |
| imbrandon | you can even do python etc with like .. code:: python | 20:09 |
| imbrandon | print "blah" | 20:09 |
| imbrandon | etc | 20:09 |
| SpamapS | imbrandon: easier to just make it visible as text.. :-P | 20:11 |
| imbrandon | :) | 20:12 |
| SpamapS | actually hm, its available as {{ meta['...'] }} | 20:13 |
| imbrandon | sudo reboot | 20:14 |
| imbrandon | bah | 20:14 |
| hazmat | SpamapS, its the ssh subprocess that makes keyboardinteruppt a bit nasty afaicr | 20:15 |
| SpamapS | hazmat: twisted should handle it in the reactor shutdown, shouldn't it? | 20:15 |
| SpamapS | or are we just subprocess'ing it directly? | 20:15 |
| hazmat | not its twistedified | 20:16 |
| imbrandon | okie, i got way too early of a start today, taken a cue from mexico and going for a mid-day nap, back after bit yall | 20:17 |
| jaustinpage | does anyone know any good resources for trying to debug problems with juju deploying? | 21:07 |
| jaustinpage | im trying to figure out why the nova-compute charm is giving me trouble | 21:07 |
| jaustinpage | r / juju deploying / juju charms deploying / g | 21:08 |
| SpamapS | jaustinpage: this channel is the best way to debug things. :) | 21:15 |
| SpamapS | jaustinpage: I mean, to find info how to debug. :) | 21:15 |
| SpamapS | jaustinpage: also askubuntu.com is good as we have a bot in here which alerts us to new questions. :) | 21:15 |
| SpamapS | jaustinpage: what seems to be the problem? | 21:16 |
| === salgado is now known as salgado-afk | ||
| SpamapS | wow, argparse's subparser formatting is ridiculous | 21:34 |
| SpamapS | jml: FYI, fix for bug 1015574 in juju-jitsu trunk. Thanks for playing! | 21:42 |
| _mup_ | Bug #1015574: No way of discovering subcommands <juju-jitsu:In Progress by clint-fewbar> < https://launchpad.net/bugs/1015574 > | 21:42 |
| * SpamapS goes to the dentist | 21:42 | |
| jaustinpage | Spamaps: figured out what i did wrong. Aparently the space in between the : "option" in yaml is important, i was leaving it out like this :"option:, and it was unhappy with me :-) | 22:11 |
| jaustinpage | r/"option:/"option"/g | 22:11 |
| SpamapS | ugh, argparse.. you steaming pile.. why can't you just do what I want? | 23:31 |
| SpamapS | subparsers are basically a joke. Argh. | 23:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!