[05:50] <george_e> Where in the filesystem of a unit does Juju store the hook scripts?
[11:49] <hazmat> g'morning
[12:06] <noodles775> hazmat, m_3 : Hi! I'm currently using the latest postresql charm (r17), and it still used localhost: http://paste.ubuntu.com/745058/
[12:07] <noodles775> hazmat, m_3: But I've just realised that r17 of that charm didn't update the revision... retrying now after manually updating the rev (as I'm still using the same environment)
[12:07] <hazmat> noodles775, good catch
[12:09] <noodles775> And that was it indeed, it's getting the IP now. Thanks!
[12:12] <noodles775> So the only remaining issue for me seems to be that the postgresql charm uses the relationname as the db name (which psql doesn't like if it contains hyphens): http://paste.ubuntu.com/745066/
[12:23] <hazmat> noodles775, worth a bug against the charm, it should escape them
[12:24] <noodles775> hazmat: Will do now... thanks.
[12:29] <noodles775> hazmat: is this where bugs are now reported for charms? Or is there somewhere newer: https://bugs.launchpad.net/charm
[12:29] <hazmat> noodles775, each charm has its own bug tracker.. for postgresql its .. https://bugs.launchpad.net/charm/oneiric/+source/postgresql
[12:30] <noodles775> Great, thanks.
[12:30] <hazmat> noodles775,  the charm browser at charms.kapilt.com is useful for finding the relevant links
[13:02] <fwereade> hazmat, does test_full_run in the base agent test ring any bells for you?
[13:21] <hazmat> fwereade, its a test that actually launches the agent afaicr
[13:21] <hazmat> fwereade, is it breaking?
[13:22] <fwereade> hazmat, yeah, and while it's surely something I'm doing it seems I'llhave to start poking into twisted itself to figure it out
[13:22] <hazmat> fwereade, cause might be a missing env var/cli option
[13:22] <fwereade> hazmat, hm, yes, plausible
[13:23] <hazmat> fwereade, i'd try printing os.environ to a file from an early entry point (cli parse setup)
[13:24] <fwereade> hazmat, well in fact it's not technically *breaking*, but it is exiting the whole test run
[13:24] <hazmat> huh
[13:24]  * hazmat looks up the test
[13:27] <hazmat> fwereade, i don't see anything obvious, even a mismatched mock statement there shouldn't exit the tests, i'd pdb into run().. it doesn't look like it actually forks a process here just simulates the startup.
[13:28] <fwereade> hazmat, sounds good
[13:28] <fwereade> hazmat, (sorry vague, moved on to something else for a bit, will be back on that in a bit)
[13:29] <hazmat> fwereade, no worries
[13:45] <noodles775> hazmat: hi again. I created https://bugs.launchpad.net/charm/+source/postgresql/+bug/893088 , but atm am just trying to find a work-around...
[13:46] <noodles775> I've re-name my charm to apache_django_wsgi (both the directory and in the metadata), but get:
[13:46] <noodles775> Bad charm URL: http://paste.ubuntu.com/745120/
[13:46] <noodles775> Let me know if you've seen that before... /me keeps plugging away.
[13:47] <marcoceppi> The postgres charm should probably do a string replace on - with _
[13:48] <noodles775> marcoceppi: yep, or something similar that enforces db/user names psql is happy with (there could be other invalid chars?). But atm, I just want to get my own charm working :)
[13:48] <hazmat> its this file that needs a mod http://charms.kapilt.com/charms/oneiric/postgresql/hooks/common.sh
[13:48] <marcoceppi> Yeah, sanitation would probably need to take place in all the db charms
[13:49] <hazmat> noodles775, most of the other invalids are done just by restrictions on the charm/service name
[13:49] <hazmat> which juju handles
[13:49] <noodles775> hazmat: yep, which is how I'm trying to work-around the issue atm (my charm name), but am getting Bad charm URL... digging now.
[13:51]  * noodles775 removed both '-'s and '_'s... now it's accepting it.
[14:37] <hazmat> noodles775, committed a fix upstream
[14:37] <hazmat> postgres charm escapes dashes now
[14:38] <noodles775> hazmat: sweet, thanks - I'll rename my charm again so it's readable :)
[15:37] <SpamapS> marcoceppi: regarding the passing of config on deploy, I think you *should* be able to say --set 'x=y z=foo' .. but you can't right now. Maybe open a bug?
[15:38] <marcoceppi> SpamapS: Cool, I'll do that and see if I can create a patch for it
[15:50] <jcastro> marcoceppi: have you seen george? Last I checked he was mostly there but stuck on a juju problem
[15:50] <SpamapS> hazmat: is there any reason we aren't using the DescribeRegions AWS API call instead of a static list of regions?
[15:51] <hazmat> SpamapS, txaws doesn't support, and schema def is static thing atm, we could fix both, but its been low priority
[15:58] <SpamapS> hazmat: ok I'll open a low priority bug against both. Just making sure its possible/makes sense.
[15:59] <hazmat> SpamapS, i'm not sure it does make sense
[15:59] <SpamapS> hazmat: I tried using txaws-discover --action DescribeRegions and it fails because of key problems. Is txaws using an outdated API or something?
[15:59] <jimbaker> not certain why we don't just use boto + deferToThread
[16:00] <SpamapS> jimbaker: +++++
[16:00] <hazmat> jimbaker, indeed, or libcloud
[16:00] <SpamapS> ;)
[16:00] <hazmat> SpamapS, the schema is defined to validate environments.yaml, but we need to consult the environments.yaml to make the describe regions call...
[16:01] <jimbaker> cool, this is widely used. see for example some of the openstack tests. etc
[16:01] <SpamapS> hazmat: so make sure it is formatted right, and trust that the user isn't an idiot. :)
[16:01] <hazmat> easy enough to do a second pass at the cost of a roundtrip
[16:01] <SpamapS> if they put in us-beast-1 its ok.. right? ;)
[16:01] <SpamapS> they'll get a failure on bootstrap
[16:02] <marcoceppi> jcastro: I was talking to him last night for a bit
[16:02] <marcoceppi> but then he went to bed
[16:03] <hazmat> SpamapS, fair enough, we can yank that part of the schema
[16:03] <SpamapS> I'm getting more and more worried about these juju set* commands ... without a way to export the env.. we're making it really hard to reproduce environments.
[16:03] <SpamapS> hazmat: we can just make it verify that its a valid hostname (starts with a letter, [0-9-]+) right?
[16:03] <hazmat> SpamapS,  marcoceppi, you can pass a config file at deploy time
[16:04] <hazmat> SpamapS, sounds good
[16:04] <SpamapS> hazmat: convenience feature though, would be nice to be able to have one command that does the deploy and set's without having to write a config file out.
[16:04] <SpamapS> hazmat: I can see that being an important part of an autoscaler actually
[16:05] <hazmat> jimbaker, i'm pretty convinced of the utility of doing a provider like that, we really need to stop concerning ourselves with twisted bindings to the world
[16:05] <hazmat> and just interact with the world
[16:05] <SpamapS> "when my database gets 10,000 shards, deploy a new one with this shard hash value"
[16:05] <SpamapS> hazmat: you would make the rackspace guys *VERY* happy :)
[16:05] <hazmat> SpamapS, i think an autoscaler can figure out how to write a file ;-)
[16:06] <m_3> noodles775: just catching up with the conversation... is that stack happy with '-'s and '_'s in the charm names now?
[16:06] <SpamapS> hazmat: mtaylor has been asking me "why not libcloud" for a while now. :)
[16:07] <hazmat> SpamapS, the answer was for a while that it didn't have support what we needed, but i had a look again last month, and it does seem to support the basics of everything we'd want
[16:07] <hazmat> the sshscriptdeploy stuff in particular to trigger initialization of the instance
[16:07] <noodles775> m_3: I haven't yet tried as I'd re-named my charm, but will do so tomorrow. Looking at the change, I expect it to work :)
[16:10] <m_3> noodles775: cool.. I'll spin it up with various names today
[16:15] <marcoceppi> SpamapS hazmat I agree, being able to say juju deploy --config="game=tf2" steam is a lot more convenient than having to create a config file :)
[16:15]  * marcoceppi is lazy
[16:15] <jimbaker> hazmat, agreed on that. we saw that w/ lxc support by the local provider for example, also a pragmatic usage
[16:15]  * marcoceppi s/--config/--set/
[16:23] <SpamapS> hazmat: sweeeeet (re libcloud)
[16:24]  * hazmat grabs some food
[16:24] <_mup_> Bug #893176 was filed: do not limit ec2 region to static list of regions <juju:New> < https://launchpad.net/bugs/893176 >
[16:32] <_mup_> Bug #893184 was filed: Deploy should allow for a "config set" flag <juju:New> < https://launchpad.net/bugs/893184 >
[16:33] <jcastro> SpamapS: soon I will be confident enough to file bugs like that instead of asking you if ideas are dumb before hand. :)
[16:33] <SpamapS> jcastro: indeed, thanks for the nudge. :-D
[16:34] <SpamapS> jcastro: I was thinking the same thing but didn't actually validate my assumptions until you asked. :)
[16:34] <SpamapS> jcastro: so please, feel free to continue asking "dumb" questions.
[16:40]  * m_3 hopes SpamapS never tires of answering our dumb questions :)
[16:55]  * SpamapS hopes google never tires of making him look smarter than he is
[16:55] <jimbaker> hazmat, looking at libcloud's support for providers, yes that would be very nice: http://libcloud.apache.org/supported_providers.html - no way would we want to do each of these
[16:55] <jimbaker> i do assume that http://libcloud.apache.org/driver-features.html#deploy means the same thing as cloud-init ?
[16:56] <SpamapS> gogrid and linode.. nice
[16:56] <jimbaker> maybe the best thing to do is to support libcloud as a new provider
[16:56] <hazmat> jimbaker, basically... we'd either format cloud-init as a script, or transfer and invoke cloud init remotely
[16:57] <SpamapS> hazmat: seems like it would be worthwhile to work in an extension to libcloud to support cloud-init directly.
[16:57] <SpamapS> hazmat: or at least, metadata/userdata directly.
[16:57] <jimbaker> SpamapS, that makes a lot of sense
[16:57] <SpamapS> the world would probably thank us for that.
[16:58] <hazmat> SpamapS, all we really need to support it is remote ssh
[16:58] <SpamapS> (and it would also have the nice effect of making Ubuntu a preferred platform for libcloud users)
[16:58] <hazmat> true
[16:59] <SpamapS> hazmat: heh.. an ssh usurper provider has been on my list of things to hack out for a while.. just feed it a list of boxes and it will ssh in and run the agent. ;)
[17:00] <jimbaker> SpamapS, sure, you handle the provisioning with say capistrano, seems feasible
[17:03] <jimbaker> anyway, i think it would be nice if we got a bug in for a libcloud provider. i would like to work on it myself. the only thing i see missing here  in libcloud is firewall support, but it's a good reason to machine-based firewalls instead
[17:09] <_mup_> Bug #893204 was filed: Support libcloud provider <juju:New> < https://launchpad.net/bugs/893204 >
[17:10] <jimbaker> SpamapS, i filed this so we can track and see if this makes sense. seems like the consensus here is that it does
[17:11] <SpamapS> jimbaker: yes, I'm going to mark it as Confirmed and Wishlist. Once we've got a handle on it, we may need to break it up into a blueprint.
[17:12] <SpamapS> jimbaker: seems like a good thing to start on as soon as the 12.04 stabilization/prod work is done.
[17:15] <SpamapS> speaking of that, how is the "subordinate services" work coming?
[17:17] <jimbaker> is bcsaller out this week? (the best person to ask here)
[17:51] <hazmat> jimbaker, not per the team calendar
[17:51] <hazmat> but the person who maintains the calendar is out.. so who knows.
[18:06] <hazmat> he'll be on shortly, just did a meeting with him re co-lcoation
[18:08] <hazmat> jimbaker, ping?
[18:30] <SpamapS> hazmat: I thought of some charms that need to be available as both subordinate and regular services.. so I'm wondering if that will throw a wrench into the spec
[18:31] <SpamapS> hazmat: like NFS server.. you want to be able to expose the data dir of a service via NFS.
[18:31] <SpamapS> bcsaller: ^^
[18:32] <bcsaller> SpamapS: You can define normal relationships from subordinate service outside of the container
[18:33] <bcsaller> SpamapS: its only the relationship with the principal service that is special
[18:34] <bcsaller> SpamapS: and so in that sense it is both a subordinate service (to the prinicpal) and a normal charm to anyone else
[18:35] <hazmat> SpamapS, i tend to think of most of the coordinate services as a head / tail er.. server / client.. where we deploy the clients in co-located fashion, and relate them to the server, this holds for logging, distributed fs, monitoring, etc.
[18:35] <hazmat> hmm
[18:36] <hazmat> so in that case expose the data-dir of a service via nfs.. is deploy an nfs-client, that has a relation to the primary that setups the data-dir as an nfs mount.
[18:37] <hazmat> so its not per se exporting data per se as a separate volume nfs style, just using an existing mounted volume for the storage
[18:54] <SpamapS> So another scenario is ceph.. the ceph charm operates as both the client and server for ceph
[18:55] <SpamapS> it would be useful to make the ceph client a subordinate of a service that wants to store data in ceph
[19:00] <bcsaller> SpamapS: that sounds correct, I don't see an issue though?
[19:01] <SpamapS> Ok at one point I got the impression that we couldn't subordinate normal charms.
[19:16] <bcsaller> SpamapS: the client would be a subordinate charm with a normal relationship to the master
[19:16] <bcsaller> and a subordinate relation to its principal service
[19:23] <SpamapS> ceph is a normal charm, and works as a client or server
[19:24] <SpamapS> so I could add a subordinate relation to ceph so it can talk to the.. I don't know the term.. other service in the container?
[19:24]  * SpamapS re-reads the spec
[19:28] <marcoceppi> How can I test juju from the repo?
[19:28] <marcoceppi> from the bzr repo?
[19:31] <bcsaller> SpamapS: yes, a subordinate relation is what you'd need there. I think that is all you'd need to define but I'll keep playing with the use-case
[19:34] <bcsaller> SpamapS: we had a top level subordinate:true in the metadata, I've taken that out and it only depends on changing the interface now
[19:35] <jimbaker> hazmat, hi
[19:36] <hazmat> marcoceppi, bzr branch lp:juju && cd ./bin/juju -h
[19:36] <hazmat> marcoceppi, the ppa is rebuilt daily, if you have a package install of juju, it might be good to remove it to avoid any version confusion
[19:37] <marcoceppi> hazmat: thanks, I'm just trying to test this patch I've made
[19:39] <SpamapS> bcsaller: ahh cool! ok
[19:40] <jimbaker> hazmat, thanks for the approval on ssh passthrough. i will write up the new juju scp command shortly, as well as my thoughts on bug 814974
[19:40] <_mup_> Bug #814974: config options need a "file" type <juju:In Progress by jimbaker> < https://launchpad.net/bugs/814974 >
[19:40] <jimbaker> biab, time for lunch
[19:40] <hazmat> jimbaker, great, i wanted to touch base on what's next, but i'll finish up reviews on your branches first
[19:41] <jimbaker> hazmat, i think i'll take a look at the ssh key stuff
[19:41] <hazmat> jimbaker, cool
[19:41] <jimbaker> that's an important prod issue
[19:41] <jimbaker> hazmat, cool
[19:44] <_mup_> Bug #893281 was filed: Subordinate services require topology support <juju:New for bcsaller> < https://launchpad.net/bugs/893281 >
[19:58] <_mup_> juju/session-expiration r409 committed by kapil.thangavelu@canonical.com
[19:58] <_mup_> add session expiration documentation
[19:58] <_mup_> juju/session-expiration r410 committed by kapil.thangavelu@canonical.com
[19:58] <_mup_> merge trunk
[20:54] <hazmat> sidnei, did your ssd get resurrected?
[20:55] <sidnei> hazmat, haven't had much time to play with it unfortunately. seems like it's a known issue with sandforce-based drives, and a firmware upgrade might solve it.
[20:57] <sidnei> http://lmgtfy.com/?q=sandforce+cold+start+bug
[20:57] <hazmat> sidnei, ic.. good luck with that.. i'm hopeful sandforce controllers will be getting better ootb now that they have much larger testing resources since they got acquired.. just got a new ssd myself (samsung) like 10m ago, tbd
[21:00] <hazmat> sidnei, hm.. that's interesting.. i was putting together a nas with my old ocz sandforce drive (won't fit in new laptop).. and noticed it wasn't being picked up the bios, what was odd though is the ubuntu partioner could see the drive.. this might be relevant.. although i'm not convinced its not a mb bios issue
[21:01] <sidnei> yeah, if the partitioner triggers a pci rescan or something, it might get the drive to initialize properly
[21:14] <jcastro> this is why I am intel only. :)
[21:17] <marcoceppi> I think I'm going to stick to making charms, and leave juju in the capable hands of those who know
[21:21] <_mup_> Bug #893332 was filed: Watches are needed for changes to subordinate services <juju:In Progress by bcsaller> < https://launchpad.net/bugs/893332 >
[21:23] <jcastro> marcoceppi: the charms are the best part anyway, for the rest we can just whine
[21:57] <jcastro> hey guys, what's best practice for SMTP?
[21:57] <jcastro> there's no mail charm
[21:58] <jcastro> and I assume on EC2 they just don't allow port 25 or any of that do they? Don't they have like an email API or something instead?
[21:59] <jcastro> but if you use the amazon simple email service then the charm becomes aws specific ...
[22:20] <marcoceppi> You can mail out of port 25, bulk stuff you need to fill out a request
[23:13] <m_3> hazmat: is charm.log going away in favor of a combined unit-agent log in /var/log/juju?
[23:16] <m_3> (charm.log is there in EC2, but missing in LXC)
[23:19] <_mup_> Bug #893379 was filed: inconsistent logging between different providers <juju:New> < https://launchpad.net/bugs/893379 >