[00:01] <hazmat> marcoceppi, while awesome i'd still probably recommend either cloudfront or rackfiles/limelight for a true cdn
[00:01] <hazmat> cdn need points of presence for global effectiveness
[00:02] <SpamapS> hazmat: depends on your perspective. Sometimes all you really want is aggressive caching and fanout
[00:02] <SpamapS> latency is by far the *best* reason for CDN... but by no means the only one
[00:05] <niemeyer> mpl: Super, let me check
[00:05] <hazmat> SpamapS,  ec2 hosts don't really give  fanout, all a juju node for cdn amounts to is a single host.. thats a sig difference.. it can work.. but its not the same league
[00:06] <niemeyer> mpl: Very nice
[00:06] <hazmat>  /me heads out for beer o'clock
[00:06] <niemeyer> hazmat: Cheersfully!
[00:08] <_mup_> juju/go r21 committed by gustavo@niemeyer.net
[00:08] <_mup_> Merged jujugo-log by branch Mathieu. [r=rog,niemeyer]
[00:08] <_mup_> This branch moves logging onto the log package so that it is
[00:08] <_mup_> usable by any of the subpackages, and simplifies/polishes the
[00:08] <_mup_> interface further.
[00:22] <_mup_> juju/scp-command r419 committed by jim.baker@canonical.com
[00:22] <_mup_> Addressed review points
[02:46] <marcoceppi> hazmat: It's not for a CDN, it's a patch for a CDN issue that needs to scale. So it's using hadoop charm with a custom charm I wrote that creates a sort of...CDN proxy...for an issue several customers are having because Cisco has rackcdn.com blacklisted in their enterprise router software
[02:49] <marcoceppi> For those customers we have our templating engines on their site switch out rackcdn.com with another DNS and the servers fetch the file from the CDN, cache it, then serve it up. Bandaid until the blacklist is lifted which could take a while
[04:35] <_mup_> juju/scp-command r420 committed by jim.baker@canonical.com
[04:35] <_mup_> PEP8/PyFlakes
[04:37] <_mup_> juju/scp-command r421 committed by jim.baker@canonical.com
[04:37] <_mup_> Updated tab completion
[04:47] <_mup_> juju/scp-command r422 committed by jim.baker@canonical.com
[04:47] <_mup_> Slim down help output
[04:48] <_mup_> juju/scp-command r423 committed by jim.baker@canonical.com
[04:48] <_mup_> PEP8
[04:53] <_mup_> juju/trunk r425 committed by jim.baker@canonical.com
[04:53] <_mup_> merge scp-command [r=fwereade,hazmat][f=720307]
[04:53] <_mup_> Implements juju scp subcommand.
[07:20] <rog> fwereade_: mornin'
[08:03] <fwereade_> rog: heyhey :)
[08:03] <rog> fwereade_: :-)
[08:04] <fwereade_> rog: hmm, you were up disturbingly early ;)
[08:04] <rog> fwereade_: it's not uncommon - i usually don't make a peep in here until i see some activitity tho'
[08:05] <fwereade_> rog, ah, yeah, I tend to follow the same sort of approach
[08:05] <rog> fwereade_: actually 7.20 *is* earlier than usual! had to go out and scrape the ice off the car.
[08:05] <fwereade_> rog, oof
[08:05] <rog> not much ice where you are... :)
[08:06] <fwereade_> rog: well, it's getting pretty cold, it's 15 now :p
[08:06] <rog> lol
[08:06] <rog> mind you, you probably don't have working central heating...
[08:07] <fwereade_> indeed not :)
[08:07] <fwereade_> actually I just realised I need to pop out for a bit
[08:07] <fwereade_> bbs :)
[08:07] <rog> c y
[08:49] <TheMue> Mio
[08:50] <TheMue> argh, moo, that's better
[09:09] <mpl> hi all
[09:28] <rog> mpl: hiya
[10:31] <fwereade_> if anyone who's written trickyish charms is around and awake, please ping me
[11:14] <fwereade_> scratch my request above
[11:52] <niemeyer> Morning all!
[11:52] <fwereade_> heya niemeyer
[11:52] <TheMue> moo
[11:55] <niemeyer> fwereade_, TheMue: Hey folks!
[11:58] <rog> niemeyer, TheMue: morning!
[12:03] <TheMue> hi rog
[12:06] <mpl> yo
[12:13] <niemeyer> rog, mpl: Hey folks
[12:16] <mainerror> Sooo! Juju Charm School today. \o/
[12:20] <niemeyer> mainerror: Ohhh, indeed!
[12:20] <mainerror> Can't wait.
[12:21] <jrgifford> niemeyer: almost forgot about that. :P
[12:21] <jrgifford> what time (UTC) is it again?
[12:23] <mainerror> My Charm drives me nuts. This CMS writes its config options into more than one file ...
[12:23] <mainerror> 15:00 UTC jrgifford.
[12:28] <rog> niemeyer: ec2-ec2test pushed. second stage merge request for ec2 now in (https://codereview.appspot.com/5449065/)
[12:28] <niemeyer> rog, mpl, TheMue: I think we should give a push to make sure all of the packages we're handling run fine on the latest weekly
[12:28] <niemeyer> rog: Already on re-review the former one
[12:28] <niemeyer> rog: Already on re-reviewing the former one
[12:29] <rog> niemeyer: i was wondering if we should let the latest weekly settle a bit before digging in
[12:30] <mainerror> What are you guys going to write in Go by the way?
[12:30] <niemeyer> mainerror: We're running an experiment to run juju on Go
[12:30] <mainerror> Oh, nice. :)
[12:31] <mainerror> Right now it is using Python, right?
[12:31] <niemeyer> mainerror: That's right
[12:31] <TheMue> niemeyer: Based on weekly? Not on r60?
[12:31] <niemeyer> TheMue: Yeah, weekly
[12:31] <mpl> niemeyer: just curious? why not using the releases instead of the weeklies?
[12:31] <niemeyer> TheMue: r60 is too old by now, and given our timeframe, there's not much benefit in sticking to it
[12:31] <niemeyer> mpl: ^
[12:31] <mpl> ok
[12:32] <TheMue> niemeyer: hmm, imho weekly is currently changing too often. but i'll look.
[12:32] <niemeyer> I suspect most of the incompatibilities for Go 1 are already in too
[12:33] <rog> TheMue: i think it's easier to update in stages rather than all at once. we haven't got a large set of users, so it's not that much problem for us currently.
[12:33] <mainerror> Oh wow! Go has GTK bindings.
[12:34] <TheMue> rog: yep, the backlog of the current weekly and the r60 is already quite large.
[12:34] <TheMue> *sigh*
[12:34] <mpl> mainerror: are you speaking of mattn ones? if so, you should know that nsf is also redoing them.
[12:34] <mainerror> Indeed. They are not 100% done yet but still a good start.
[12:34] <rog> TheMue: gofix does a lot, but it's not a panacea
[12:35] <mainerror> I see.
[12:37] <mainerror> mpl: Did he host it on Github as well? I can't find it. :/
[12:38] <mpl> mainerror: well, you'd better ask him directly on #go-nuts
[12:39] <mainerror> Oh, awesome. :)
[12:40] <TheMue> rog: i know, that's what i wrote on G+ too. i would like a r61 before go 1.
[12:40] <niemeyer> rog: What's the branch name?
[12:41] <rog> niemeyer: which branch?
[12:41] <niemeyer> rog: The one you mentioned
[12:41] <rog> niemeyer: i pointed to the codereview page.
[12:41] <rog> niemeyer: it's lp:~rogpeppe/juju/go-juju-ec2-regions
[12:41] <niemeyer> rog: Ok, I feel like I'm missing something
[12:41] <rog> i think
[12:41] <rog> the first one is go-juju-initial-ec2
[12:41] <niemeyer> rog: It says " juju/ec2: add code to accept an ec2 region in the configuration file"
[12:42] <niemeyer> rog: But there's a _lot_ in there, completely unrelated to this description
[12:42] <niemeyer> rog: Is there a pre-req missing?
[12:42] <rog> niemeyer: yes - i couldn't add it after i'd forgotten to add it first
[12:42] <rog> niemeyer: i thought you knew about the first one
[12:42] <niemeyer> rog: The first one was initial-foo, right?
[12:43] <niemeyer> rog: which we debated a lot on
[12:43] <niemeyer> rog: I haven't heard on it since?
[12:43] <rog> niemeyer: https://codereview.appspot.com/5432056/
[12:43] <rog> niemeyer: i pushed a new version which is skeleton only
[12:43] <rog> niemeyer: didn't you get the email?
[12:43] <niemeyer> rog: Ok, the last comment says "I'm doing that right now."
[12:43] <niemeyer> rog: Check the review out
[12:44] <rog> niemeyer: ah, i did another lbox propose and changed the description, and thought you'd see that
[12:44] <rog> niemeyer: anyway, there it is.
[12:44] <niemeyer> rog: Understood, thanks. I'll hack a bit on lbox today I think, to implement submit, and also to fix that problem
[12:44] <niemeyer> rog: It should mail asking for another look
[12:45] <rog> niemeyer: i think there should be a distinction between uploading, mailing and changing the description
[12:45] <niemeyer> rog: But let me review your branches first..
[12:45] <rog> niemeyer: that would be good, thanks
[12:45] <niemeyer> mpl: How's your agenda? Do you have something in mind already to work on?
[12:46] <mpl> niemeyer: nope. I haven't really had time to think about it. I'm very open to suggestions for now ;)
[12:47] <niemeyer> mpl: May I suggest you go over all of the packages for juju, goamz, gozk, and goyaml, and see if there are any incompatibilities with weekly to be fixed?
[12:47] <niemeyer> mpl: goamz has a bunch of sub-packages as well
[12:47] <niemeyer> rog: Have you merged the error fixes on goamz that you had pending, or is there some to go still?
[12:48] <rog> niemeyer: i *think* so. i'll just check
[12:49] <mpl> niemeyer: alright, will do. can't start on it right away though.
[12:49] <niemeyer> mpl: That's fine, thanks
[12:49] <niemeyer> mpl: After that, let's see if we come up with a more interesting/long task involving juju logic
[12:50] <niemeyer> mpl: These branches that rog is working on are the base, so it's a bit hard to split the workload, but with those in, it should be much easier
[12:50] <mpl> niemeyer: I'd like that. if it can involve me learning about cloud stuff, even better.
[12:50] <niemeyer> mpl: Absolutely
[12:50] <niemeyer> mpl: EC2 provider is precisely what we're working on
[12:51] <mpl> niemeyer: no worries. I surely don't want to disturb your workflow guys.
[12:51] <niemeyer> mpl: You're helping, rather than disturbing
[12:52] <mpl> psh, I know you guys have spent more time hand holding me so far than if you have done it yourself. but I'm too ashamed as it's often a necessary process.
[12:52] <mpl> *not too ashamed.
[12:53] <rog> niemeyer: have you renamed goamz/aws yet?
[12:53] <mpl> anyways, gotta run to a meeting, ttyl.
[12:53] <rog> niemeyer: that's the last of error-fixes in goamz
[12:53] <rog> mpl: see ysa
[12:53] <rog> ya
[12:53] <niemeyer> rog: Not sure.. checking
[12:53] <rog> niemeyer: it still needs pushing
[12:53] <niemeyer> mpl: Cheers!
[12:54] <niemeyer> rog: Dude.. we're doing something wrong
[12:54] <rog> niemeyer: we should probably tag r60 versions of the goamz packages so that people can still use r60 with them
[12:54] <niemeyer> Crap
[12:54] <rog> ?
[12:54] <niemeyer> rog: Yeah, precisely
[12:55] <rog> niemeyer: that's not too hard, right?
[12:55] <niemeyer> rog: That's exactly what I was talking about
[12:55] <niemeyer> rog: It's trivial
[12:55] <niemeyer> rog: But we may have broken people trying to use it
[12:55]  * niemeyer handles that right away
[12:55] <niemeyer> rog: Have you pushed the branch?
[12:55] <rog> niemeyer: which branch?
[12:55] <niemeyer> rog: goamz/aws
[12:55] <rog> niemeyer: i've pushed ec2 and s3
[12:55] <rog> niemeyer: nope
[12:56] <rog> niemeyer: i don't think i sent it for review, in fact
[12:56] <niemeyer> rog: Ok, do you have any pending changes?
[12:56] <rog> niemeyer: yes, just error fixes
[12:56] <niemeyer> rog: Ok, leave that with me then
[12:56] <niemeyer> rog: I'll fix the whole thing
[12:57] <rog> niemeyer: there are two ErrorMatches that gofix doesn't catch, otherwise it's all gofix
[12:57] <niemeyer> rog: Cool.. I'll fix that and fix the tagging
[13:00] <TheMue> anyone have experiences with go weekly and release in parallel?
[13:00] <TheMue> i would need both
[13:00] <rog> TheMue: i have them in separate directories
[13:00] <rog> TheMue: and a prefix command to run one in preference
[13:01] <rog> TheMue: http://paste.ubuntu.com/757007/
[13:01] <rog> (excuse the fact it's not bash, but i'm sure you get the idea)
[13:02] <rog> TheMue: i call it "go-release". as in: go-release goinstall foo; go-release 6g x.go
[13:02] <rog> etc
[13:02] <TheMue> ic, looks good
[13:06] <rog> niemeyer: gocheck looks like it needs an r60 tag too - it looks like the r59 version fails
[13:06] <rog> on r60
[13:07] <niemeyer> rog: Uh oh
[13:07] <niemeyer> rog: Can you pin-point which version to tag?
[13:07] <rog> niemeyer: will do
[13:07] <niemeyer> rog: Thank you
[13:11] <rog> niemeyer: ironically, it's revision 60
[13:11] <niemeyer> rog: LOL
[13:32] <rog> just off for lunch and to bake a cake, back in an hour
[13:34] <niemeyer> rog: Enjoy
[13:35] <TheMue> ... and dcc us some cake
[13:35] <niemeyer> :)
[13:43] <niemeyer> rog: I _think_ it's all sorted out
[13:43] <niemeyer> rog: In goamz, specifically
[14:17] <rog> niemeyer: cool.
[14:18] <rog> TheMue: and sorry, would've but didn't have enough bananas so the cake is only 62% the size it should've been. so none spare!
[14:20] <TheMue> rog: *deeplySigh* so I've got to find surrogate when I'm on x-mas market later with my family
[14:25] <rog> jimbaker: you know what would be really cool - if you could use scp to copy between units without involving the local machine, e.g.  juju scp wordpress/0:/etc/wordpress/config-* wordpress/1:/etc/wordpress
[14:27] <marcoceppi> Charm school soon \o/
[14:34]  * uksysadmin is ready for charm school. "How yoooou doin'?"
[14:36] <rog> niemeyer: before i continue in the same vein, do you think go-juju-initial-ec2 and go-juju-ec2-region are pointing vaguely in the right direction? if not, i'd prefer to fix those rather than carry further on the wrong way.
[14:38] <jcastro> good morning everyone!
[14:38] <jcastro> uksysadmin: thanks for stopping by, we'll start in ~20 minutes!
[14:40] <rog> niemeyer: oh cool, just got yr msg
[14:49] <uksysadmin> looking forward to charming my servers
[14:52]  * mainerror will probably be 10 minutes late
[14:53] <niemeyer> rog: Yeah, I think initial-ec2 is ready to go in with those settled
[14:53] <rog> niemeyer:
[14:53] <rog> niemeyer: cool. i've done those - i'll do the push
[14:54] <jcastro> m_3_: around?
[14:56] <mainerror> o/
[14:56] <rog> niemeyer: done.
[14:56] <niemeyer> rog: Looking
[14:57] <niemeyer> rog: patch set is unchanged
[14:57] <mpl> niemeyer: is it lp:gozk or lp:~juju/gozk/zk that you want me to check? also, fyi https://launchpad.net/gozk/zk returns a 404
[14:57] <niemeyer> rog: But it was pushed 5 minutes ago
[14:58] <niemeyer> mpl: gozk/zookeeper.. you've renamed it :-)
[14:58] <rog> niemeyer: sorry, did the publish messages, did the push to ~rogpeppe..., forgot to do the lbox propose
[14:58] <niemeyer> rog: lbox propose pushes as well, btw
[14:59] <mpl> niemeyer: yeah but maybe you wanted me to check the whole project, wasn't sure.
[14:59] <rog> niemeyer: yeah, but i've had it push to the wrong place, so i tend to do it myself to make sure
[14:59] <m_3_> jcastro: yo
[14:59] <jcastro> hi!
[14:59] <niemeyer> rog: Cool
[15:00] <niemeyer> mpl: Ah, no, just gozk/zookeeper is great already
[15:00] <rog> niemeyer: dammit, i'm too late, the diff is empty
[15:01] <marcoceppi> \m/
[15:01] <jcastro> niemeyer: rog: mind if we kick you out for the charm school?
[15:01] <rog> jcastro: no probs
[15:01] <niemeyer> jcastro: Not at all, thanks for pushing this
[15:01] <jcastro> but do idle in case there are questions!
[15:01] <jcastro> Ok, welcome everyone to the first ever #juju charm school
[15:01] <jcastro> we'll give it another minute for the stragglers to arrive
[15:01] <niemeyer> rog, mpl: => #juju-tmp
[15:01] <mpl> niemeyer: ah yes, silly me, your message pointing to that url (with zk) is from september. I had the rename the other way around in my head, sorry.
[15:02] <niemeyer> TheMue: => #juju-tmp
[15:05] <jcastro> Ok everyone.
[15:05] <jcastro> Welcome to the first ever virtual charm school!!!
[15:05] <jcastro> I am your emcee, Jorge Castro
[15:05] <jcastro> I work on the community team at Canonical on Cloud
[15:05] <jcastro> I am joined today by ....
[15:05] <m_3_> Hi all, I'm Mark Mims
[15:06] <m_3_> I'm here to help answer charm questions
[15:06] <jcastro> ok
[15:06] <jcastro> so first off, we'd like to see who's here to learn, so everyone who is here for charm school, raise your hand and give us a one line description of yourself
[15:06] <medberry> o/
[15:06] <ivoks> \o
[15:07] <marcoceppi> o/ I love juju
[15:07] <TheMue> o/
[15:07] <nijaba> o/ (just a pm having a look)
[15:07] <chute> o/
[15:07] <ahs3> o/
[15:08] <uksysadmin> o/ interested in learning how to deploy cloud environments in (as well as bare metal provisioning of) OpenStack
[15:08] <jcastro> oh nice one. :)
[15:08] <jcastro> ok so first, before we get into details on charms
[15:09] <jcastro> let me arm you with some docs and links, that you can reference
[15:09] <jcastro> first off, obviously, we have: https://juju.ubuntu.com/ and https://juju.ubuntu.com/docs
[15:09] <jcastro> which is where we centralize all the information on juju
[15:09] <jcastro> for news about juju and the latest charms, we put that on http://cloud.ubuntu.com
[15:10] <jcastro> for example yesterday someone submitted a status.net charm
[15:10] <jcastro> http://cloud.ubuntu.com/2011/12/deploying-status-net-quickly-with-juju/
[15:10] <jcastro> We like to heavily talk about new charms
[15:10] <jcastro> because while juju is an amazing tool, it's the charms that make it useful
[15:10] <jcastro> in the same way that you might love apt, but you really love the huge repository that comes along with it
[15:11] <jcastro> so we're running these sessions to help people write charms for things they care about.
[15:11] <jcastro> So, before we get into the anatomy of a charm
[15:11] <jcastro> does anyone have any questions so far?
[15:11] <jcastro> hopefully you understand enough about juju to grasp the concepts.
[15:11] <jcastro> but if you don't, we can get you started on the right road.
[15:11] <medberry> how does one charm a package to use mysql when the current package has depends for a locally installed mysql?
[15:12] <medberry> erm, to use the mysql on another box....
[15:12] <fmo> Do you consider juju ready for production environments?
[15:12] <jcastro> medberry: mark is answering yours now
[15:12] <jcastro> fmo: we consider it a tech preview in 11.10
[15:13] <m_3_> medberry: so the key here is to write a relation hook for your service
[15:13] <fmo> Thank you, it's a bit out of scope but is it the same for Orchestra?
[15:13] <jcastro> fmo: it's at the stage where you would start to look at it for 12.04ish timeframe deployment.
[15:13] <m_3_> medberry: that relation hook would essentially reconfigure your app to point to the remote mysql instance
[15:14] <medberry> nod. m_3, thanks. Is there an example charm (off the top of your head) I should refer to that does this?
[15:14] <m_3_> medberry: it does this by exchanging crediential info for a db with the mysql charm
[15:14] <jcastro> fmo: Not quite sure on orchestra but I /believe/ it's at the same level, though orchestra bundles some things that are already mature, like squid, etc.
[15:14] <ivoks> m_3_: but you would still end up with unused mysql-server running on 'app' node, wouldn't it? i think this is a packaging bug
[15:14] <fmo> thank you :)
[15:14] <m_3_> lots of charms connect to mysql this way... mediawiki would be a good one
[15:15] <medberry> fmo, I believe you can consider Orchestra more mature than Juju and ready for deployments.  zul may know more.
[15:15] <medberry> m_3_, thanks, I'll look at it (and others)
[15:15] <m_3_> ivoks: your relation hook could pass debconf info and dpkg-reconfig the package though
[15:15] <ivoks> m_3_: right, thanks
[15:15] <m_3_> ivoks: so what you would do depends on the interface exposed by the package itself
[15:16]  * medberry was thinking specifically of moodle if someone wants the context.
[15:16] <jcastro> oh are you working on moodle?
[15:16] <jcastro> that would be great!
[15:16]  * m_3_ grins
[15:17] <jcastro> ok, this brings me to the next quick topic, who has written a charm already? and who is planning on working on one?
[15:17]  * nijaba plans on doing one for limesurvey
[15:17] <jcastro> and does anyone have an itch to scratch to work on a certain charm?
[15:17] <uksysadmin> o/ as far as getting a basic something going (like nginx behind haproxy) to try and understand the concepts
[15:18] <ivoks> o/ postfix-dovecot
[15:18] <ivoks> (as soon as i find time :)
[15:18] <nijaba> (same here)
[15:18] <marcoceppi> o/ finishing phpmyadmin and steam
[15:19] <jcastro> (steam in this context is being able to quickly deploy a steam server for game clients to connect)
[15:19] <medberry> jcastro, yep, and someone has pointed out in O and P moodle only has a recommends on the server bits (not a depends like in Lucid.)
[15:20] <jcastro> o/ I'm working on an alice IRC charm, which is a self hosted web irc client.
[15:20] <jcastro> ok, so let's start with looking at the anatomy of a charm
[15:20] <medberry> marcoceppi, I saw that Aleph One was just released fully open source...
[15:21]  * marcoceppi nods
[15:21] <jcastro> but before we start a charm
[15:21] <jcastro> you need to map out what you want your charm to do
[15:22] <jcastro> https://juju.ubuntu.com/docs/write-charm.html#have-a-plan
[15:22] <jcastro> in this document we outline some tips in the things you need to think about when planning out how to write your first charm.
[15:22] <jcastro> usually I make a quick mindmap of what I need
[15:22] <jcastro> so for example
[15:22] <jcastro> status.net
[15:23] <jcastro> I know I'll need mysql
[15:23] <mainerror> o/ - I'm a juju fanboy.
[15:23]  * mainerror is also late
[15:23] <jcastro> and that the charm would have a relationship with mysql
[15:23] <hazmat>  /join #juju-tmp
[15:23] <jcastro> http://charms.kapilt.com/interfaces/mysql
[15:23] <m_3_> http://pad.ubuntu.com/charmschool-2011-12-02
[15:23] <jcastro> I can then see what other programs use mysql
[15:24] <jcastro> this is useful because now I can look at other LAMP projects and use that to build my charm
[15:24] <jcastro> which is what we want, reuse.
[15:24] <jcastro> So you can use the charm browser to look for other services that have relationships with services you care about
[15:24] <jcastro> The guy who wrote the status.net charm just derived it from his last LAMP charm
[15:25] <jcastro> part time, it was only 2 days from first cut to being accepted into the charm school
[15:25] <jcastro> and Marco/Clint are working on some convenience tools to make common tasks easier
[15:25] <jcastro> marcoceppi: can you explain about your convenience functions?
[15:25] <jcastro> (and then we'll go into this: http://pad.ubuntu.com/charmschool-2011-12-02)
[15:26] <jcastro> wrong URL, I mean this: http://pad.ubuntu.com/charmschool-2011-12-02
[15:27] <jcastro> ok we can get back to Marco
[15:27] <marcoceppi> Sure, so I wrote a few functions that I found myself using a lot in bash, primarily ch_get_file which is passed a file url and either a url to it's hash (md5, sha1, etc) or the actual hash itself. From there it'll download/compare file -> hash
[15:27] <marcoceppi> There are a few others, check if a string is a file or a url, check if a string is a valid hash
[15:28] <marcoceppi> You can find them: http://bazaar.launchpad.net/~charmers/charm-tools/trunk/view/head:/helpers/sh/net.sh to use in a charm make sure you have the juju ppa added, install charm-helper-sh, and source /usr/share/charm-helper/sh/net.sh
[15:29] <SpamapS> marcoceppi: FYI, there is a PPA just for those helpers,   ppa:charmers/charm-helpers
[15:29] <marcoceppi> I believe the idea is to grow out charm helpers to include helper functions in all the languages
[15:29] <marcoceppi> <3 SpamapS
[15:29] <jcastro> and if I make something I think can be reused, do we just submit it to charm tools?
[15:29] <SpamapS> marcoceppi: otherwise you'll pull in a new version of juju
[15:30] <m_3_> SpamapS: yay!
[15:30] <SpamapS> they'll be in the distro for 12.04
[15:30] <jcastro> Since we're just getting a bunch of  charms started, if you're writing a charm and feel that you can improve the charm tools to make it better for the next person, then we certainly encourage you to do that.
[15:30] <marcoceppi> definitely
[15:31] <jcastro> ok, any questions on the tools before m_3_ gets into the meat of a charm?
[15:33] <jcastro> ok, moving on ....
[15:33] <SpamapS> are the tools webscale?
[15:33] <SpamapS> ;)
[15:33] <jcastro> everyone should have this URL open: http://pad.ubuntu.com/charmschool-2011-12-02
[15:33] <jcastro> and we'll review this charm
[15:34] <jcastro> Mark will bold the sections of the document he's talking about
[15:34] <jcastro> and then when he moves on he'll unbold it and then bold the section he'll be reviewing next.
[15:34] <m_3_> I'll give people a sec to join the pad
[15:34] <marcoceppi> pad needs syntax highlighting :P
[15:35] <m_3_> ok, so we'll make sure everyone has juju installed and working in a bit... first of all, let's cover some basic concepts of charms with an example
[15:36] <m_3_> I pulled a community-contributed charm off the list... just landed yesterday or the day before
[15:37] <m_3_> so the first section we have is a basic listing of the charm contents
[15:37] <m_3_> notice there're a couple of yaml files, a copyright, and then a set of scripts in the hooks/ directory
[15:38] <m_3_> the scripts in the hooks/ directory are all in shell for this example
[15:38] <m_3_> but juju takes great pains to be language/tool agnostic
[15:39] <m_3_> you can use your fav toolset.. hooks just have to run and exit with return codes similar to a shell script ( 0 is good )
[15:39] <m_3_> so before we dig into the contents of the hooks
[15:39] <m_3_> let's see what this charm is / does
[15:39] <m_3_> take a look at the metadata
[15:40]  * m_3_ not a fast etherpad formatter :)
[15:40] <m_3_> so it looks like the service described by this charm...
[15:40] <m_3_> consumes a db (mysql in this case)
[15:40] <m_3_> and presents a website
[15:41] <m_3_> ok, that's pretty simple... and has a _lot_ in common with other services
[15:41] <m_3_> so juju uses this metadata specification to stitch together different services
[15:42] <m_3_> when juju spins a service unit up for this charm
[15:42] <m_3_> it can 'relate' other services that match up
[15:42] <m_3_> (does this by your command of course... but we'll get to the juju cli in a bit)
[15:43] <chmac> Any insight on where adding Rackspace support lies in the priority list for the juju project?
[15:43] <chmac> We're based in the UK and so UK IPs are a big must at the moment, which means AWS is out as they only have an Irish presence, nothing in the UK itself.
[15:44] <chmac> Otherwise, I'd be very interested in experimenting with juju, it sounds like an awesome project.
[15:44] <m_3_> chmac: juju can handle a number of different providers
[15:44] <m_3_> including openstack
[15:44] <m_3_> so when juju spins up a service unit for this charm
[15:44] <m_3_> the first hook it calls is 'install' naturally enough
[15:45] <m_3_> please take a sec to look at the install hook in the pa
[15:45] <m_3_> pad
[15:45] <m_3_> starts off installing ppas and packages
[15:46] <m_3_> it's worth noting here that juju charms can be used to install services that install from packages
[15:46] <m_3_> but it can also be used to install other ways as well
[15:46] <m_3_> you can clone directly from the tip of your source code repo if you'd like
[15:46] <m_3_> anything goes
[15:47] <m_3_> for charms contributed back to the community please prefer packages when available
[15:47] <m_3_> but that's not necessary
[15:47] <m_3_> so this particular charm adds ppas/and packages
[15:47] <m_3_> then 'ch_get's a file from status.net
[15:48] <m_3_> (this is one of marco's tools to download and cryptographically verify payloads in charms)
[15:48] <m_3_> anyway... rest of the script is pretty clear
[15:48] <m_3_> note the open-port at the bottom
[15:49] <m_3_> juju defaults to everything closed off... you have to explicitly open what you want via the 'juju expose' command
[15:49] <m_3_> so that's install
[15:49] <m_3_> there're start/stop hooks too... these're usually trivial 'service xxx start'
[15:50] <medberry> so if you fail the open-port, there are iptables that prevent it? (firewall rules?)
[15:50] <m_3_> correct
[15:50] <m_3_> (not exactly iptables always)
[15:50] <m_3_> depends on the provider
[15:50] <medberry> ah, aws / openstack port rules, gotcha.
[15:50] <m_3_> (and still in development iirc on bare-metal provider)
[15:51] <m_3_> so some charms are for services that just install a service and spin it up
[15:51] <m_3_> some services don't relate to other services
[15:51] <m_3_> and we'd be done if that were the case for status.net
[15:51] <m_3_> here, we need a db
[15:51] <m_3_> and we could potentially add a reverse-proxy in front of it
[15:52] <m_3_> etc etc
[15:52] <m_3_> so before we move on to relations...
[15:52] <m_3_>  any questions so far?
[15:52] <jcastro> relations are the real meat of charms, so we'll pause here for questions
[15:54] <m_3_> ok, on to relations!!
[15:54] <m_3_> now this is the really cool part of juju... ok _a_ really cool part of juju
[15:54] <m_3_> so when you look at the config for a service
[15:55] <m_3_>  you can often bust it up into "the config specific to installing that node" and "the config specific to relating to another service"
[15:55] <m_3_> often the relation config info is a nice concise set of info
[15:55] <m_3_> well juju uses these boundaries to 'install' as a separate step from 'relate'
[15:56] <m_3_> so the basic story here is to
[15:56] <m_3_> 1.) spin up status.net
[15:56] <m_3_> 2.) spin up mysql
[15:56] <m_3_> 3.) relate the two
[15:56] <m_3_> 4.) expose status.net to the outside world
[15:57] <m_3_> when we relate two services the charm hooks for those services exchange info
[15:57] <m_3_> take a look at what's bold in the pad
[15:57] <m_3_> that's an example of the status.net charm getting relation-specific config info from the mysql service
[15:58] <m_3_> the mysql (db-relation-{joined,changed} hooks create a new db and credentials and then pass it to the service joining)
[15:58] <m_3_> so the status.net charm 'relation-get's the mysql db info that it needs
[15:58] <m_3_> now we can write this info into the config for status.net... and bam!
[15:59] <m_3_> take a minute to browse the db-relation-changed hook
[16:00] <m_3_> BTW all hooks are optional... only implement what you need... events will fire for {joined,changed,departed,broken}
[16:00] <m_3_> does this 'relation-get' exchange of information make sense to everybody?
[16:00] <m_3_> any questions about this
[16:01] <m_3_> it's this very separation of config info into 'install' and 'relation'-specific config that allows juju to start handling horizontal scaling quite nicely
[16:01] <m_3_> butmore on that later :)
[16:02] <m_3_> ok, take a sec to look at the website-relation-changed hook too
[16:02] <medberry> m_3_, compare "relation-get" with "config-get" which occurs later.
[16:02] <medberry> config-get comes from config.yaml?
[16:02] <m_3_> it's perdy darned simple
[16:03] <m_3_> was just gonna do config-get next
[16:03] <medberry> okeydokey
[16:03] <m_3_> so relation-get gives you info from the other side of a relation... another service
[16:03] <m_3_> config-get gives you info from a couple of different places:
[16:03] <m_3_> defaults are in config.yaml
[16:04] <m_3_> I can set them at deploy-time on the command line
[16:04] <m_3_> ( juju deploy -elocal --repository ~/charms --config ~/my_status_net.yaml local:statusnet status
[16:05] <m_3_> or I can also set them individually via the command line:
[16:05] <m_3_> at any time during the life of the service, I can 'juju set statusnet var1=val1 var2=val2'
[16:06] <m_3_> there's a config-changed hook that can handle these changes in addition to the install or relation config
[16:07] <m_3_> ok, so one more thing about relations and relation-hooks and then we can move on
[16:08] <m_3_> when a relation is joined, relation-changed hooks can fire repeatedly
[16:08] <m_3_> they do this as long as either side is calling relation-sets
[16:08] <m_3_> what this means is that your code has to be able to be called over and over again without barfing your config
[16:09] <m_3_> (idempotency for you math geeks out there.... i^2=i)
[16:09] <m_3_> it's not hard, but it's good practice to make all of your hooks idempotent
[16:10] <m_3_> alright, I could ramble on all day about scaling service and show you example stacks... but let's get on with charm school!
[16:10] <m_3_> any questions about the status.net charm before we move on?
[16:12] <jcastro> no questions so far?
[16:12] <jcastro> there's no way you guys can be that good. :)
[16:13]  * m_3_ is just that exciting to watch type :)
[16:13] <amithkk> jcastro: lol
[16:13] <mainerror> What do I do if there is no install_cli.php script for configure the site?
[16:13] <m_3_> mainerror: wow, that's a tough one
[16:13] <chmac> m_3_: I thought I'd read somewhere that juju only supports EC2 compatible clouds at the moment.
[16:14] <chmac> m_3_: Does juju support rackspace right now?
[16:14]  * jrgiffordwebchat has same question as chmac 
[16:14] <amithkk> m_3_: Cant juju be installed on any server?
[16:14] <m_3_> mainerror: I'd write the install scripts myself and have the charm's install hook call my install scripts
[16:14] <marcoceppi> mainerror I had a problem like that, in where I just had to re-write the web-based installer into the charm
[16:15] <m_3_> chmac: yes, during the last ODS we even did the meta thing on openstack...
[16:15] <mainerror> I see. Thanks. :)
[16:15] <m_3_> i.e., we had a bare-metal rack
[16:15] <m_3_> chmac: we used juju to deploy openstack itself on the bare metal rack
[16:15] <chmac> m_3_: Wow, awesome, so juju can deploy new Rackspace servers just as it deploys new EC2 servers?
[16:15] <medberry> openstack is not per se the same thing as rackspace.
[16:15] <chmac> m_3_: Great, I'll get into the documentation in greater detail.
[16:16] <m_3_> chmac: then we backed out and used another juju environment to spin up a hadoop cluster on that openstack cloud
[16:16] <m_3_> chmac: note that juju doesn't support the rackspace-api... just the ec2-compatible-api on openstack
[16:17] <m_3_> medberry: thanks
[16:18] <chmac> I've read that juju's not production ready, is that really true, or is it more cautionary? :-)
[16:18] <m_3_> chmac: sorry, I don't know if rackspace has a public-facing openstack cloud yet
[16:18] <m_3_> chmac: definitely true
[16:18] <m_3_> chmac: there are components that need to be made highly available before it's totally production ready
[16:18] <jcastro> chmac: it's a tech preview in 11.10
[16:19] <chmac> m_3_: Really? It's so tempting to use it in production :-)
[16:19] <jrgiffordwebchat> so.. it was a tech preview in 11.04/11.10, for 12.04 it'll be production?
[16:19] <m_3_> chmac: we're shooting for production-ready in 12.04 (long-term-support) version of ubuntu
[16:19] <m_3_> chmac: I would use it in production
[16:19] <jcastro> chmac: but certainly we encourage people to run it in dev so that we can get feedback to make it better in 12.04 for an LTS.
[16:19] <chmac> Makes sense
[16:19] <jcastro> chmac: this is why we want people banging on it now
[16:19] <m_3_> but you've got to take some extra precautions atm to insure service/data integrity
[16:20] <chmac> m_3_: Now that's what I'm talking about, see, I'm usually happy to test earlier than most :-)
[16:20] <m_3_> it does spin up EBS-rooted instances in ec2 atm for instance just to be on the safer side
[16:20] <chmac> I'll investigate the openstack api issue with Rackspace, maybe there's an alternative provider in the UK.
[16:20] <chmac> Thanks for the snappy response, gotta run now, being taken shopping! :-)
[16:20]  * m_3_ totally ignorant
[16:20] <jcastro> thanks for coming!
[16:20] <m_3_> fun fun!
[16:21] <jcastro> any other questions?
[16:21] <jcastro> amithkk: I believe you asked if juju can be installed on any server?
[16:21] <m_3_> amithkk: sorry missed your question
[16:22] <m_3_> did the above discussion asnwer that?
[16:24] <mainerror> What is the best practice to create an install script for a service if there is no direct download option?
[16:24] <m_3_> mainerror: best is to use apt-get install
[16:24] <m_3_> mainerror: next is to download a payload... binary or tarball
[16:25] <medberry> .. then git clone?
[16:25] <m_3_> then install accordingly... cli.sh or ./configure && make && make install
[16:25] <m_3_> git clone's totally cool... we have several charms that do it already
[16:25] <m_3_> (safer to 'git clone <url> -b stable_branch_name')
[16:26] <amithkk> m_3_: yep
[16:26] <mainerror> What I meant is, what if there is no wget usable direct URL but only a redirect URL?
[16:26] <m_3_> mainerror: so in the latter case, you'd need the install hook to install 'build-essential'
[16:26] <amithkk> sorry for the slow responce
[16:26] <m_3_> or whatever's needed for that build
[16:27] <m_3_> mainerror: hmmm... not sure I'm following, but perhaps a ppa for that charm would work?
[16:27] <medberry> I think I know the answer... but clarifying:
[16:27] <medberry> jcastro,  m_3_, if I want to populate some content, does that happen after juju deploy? Assume I'm using public charms--should I mod them or just do the population on the host after the fact?
[16:27] <mainerror> Ah, right. That would be an option.
[16:27] <medberry> (ie, load web content, etc.)
[16:28] <jcastro> I think mainerror means
[16:28] <m_3_> medberry: sure, you can pull/install during a relation hook even
[16:28] <jcastro> what if I can't wget a tarball directly?
[16:28] <jcastro> and it's buried in some website that has redirects, etc.
[16:29] <mainerror> Indeed but m_3 actually answered it, I think.
[16:29] <m_3_> so you _could_ just stick a tarball in the charm itself... there're some size limitations to that, but I don't remember them off-hand
[16:29] <mainerror> As I understood his answer was to create a package for it in a PPA. Maybe I misunderstood.
[16:30] <medberry> m_3_, but that's no longer really a public charm (if it has my content in it). So I've locally forked the charm?
[16:30] <m_3_> mainerror: heck, let's go over the specific thing you're trying to do
[16:30] <m_3_> medberry: yes, exactly
[16:30] <m_3_> medberry: which is ok... anything goes in charms
[16:30] <medberry> thanks all.
[16:30] <m_3_> medberry: your choice to make something harder to maintain, and/or private/proprietary
[16:30] <mainerror> Uhm, it was more of a general question. Luckily I can wget it directly.
[16:30] <medberry> mainerror, is there an example--some actual issue you can point us at?
[16:31] <medberry> ah.
[16:31] <m_3_> medberry: but contrib back to community set of charms in the 'charm store' is different
[16:31] <medberry> nod.
[16:31] <m_3_> they get tagged according to all sorts of different criteria
[16:32] <jcastro> I wouldn't consider a tarball in a charm best practice
[16:32] <jcastro> ideally if it was an open project you could get them to fix that
[16:32] <m_3_> prefer packages if available
[16:32] <jcastro> or ask them to mirror their tarball releases on launchpad
[16:32] <jcastro> or package it in a PPA as a contribution to ubuntu and that project
[16:33] <m_3_> marcoceppi has a 'use_upstream' config option on a charm
[16:33] <marcoceppi> yeah, it switches between latest stable tarbal and what's in the repos.
[16:33] <m_3_> true => pull from source, otherwise install the package
[16:33] <marcoceppi> but it always defaults to the repo, you have to juju set inorder to get the upstream version
[16:34] <m_3_> which is really a beautiful way to handle that from a user-perspective (as long as default is pkgs :)
[16:34] <jcastro> but if it's some horrible program that you can't improve and need it for work or something then feel free to get as ugly as you want, but for the public charms in the charm store we're looking for nice clean charms that people can use and adapt.
[16:34] <jcastro> ok, we've gone through the charm
[16:34] <jcastro> and this ends the official charm school
[16:34] <jcastro> however
[16:34] <jcastro> we certainly encourage you to hang out
[16:34] <jcastro> smoke if you got em
[16:35] <jcastro> and feel free to ask us questions
[16:35] <jcastro> or let us know what you're working on
[16:35] <jcastro> or ask for help or a review
[16:35] <jcastro> we hold office hours (see topic) or you can always post to the list
[16:35] <jcastro> but the juju team works a ton, and usually are always in here and love to answer questions from users
[16:35] <jcastro> so please don't be shy!
[16:36] <medberry> tx guys.
[16:36] <amithkk> awesome session!
[16:36] <mainerror> Thanks for this session!
[16:36] <jcastro> we'll make the logs handy for everyone
[16:37] <dannf> thanks guys - is service maintenance within the scope of juju? e.g. keeping mysql up to date w/ security patches?
[16:37] <marcoceppi> That's a good question actually
[16:38] <m_3_> dannf: yes, there's an upgrade action called from the command line 'juju upgrade <service-name>'
[16:38] <dannf> and that is implemented with a hook, i presume?
[16:38] <m_3_> that you can customize with a dedicated upgrade hook
[16:39] <dannf> sweet
[16:39] <m_3_> usual practice is to make 'install' idempotent and then symlink to the upgrade hool
[16:39] <m_3_> s/hool/hook/
[16:39] <dannf> makes sense
[16:40] <m_3_> dannf: rolling upgrades can be done, but you have to segment the service a bit... i.e., plan for it... this'll improve over time
[16:41] <m_3_> i.e., if you've got a 20-unit service and only wanna upgrade a few of them at a time
[16:41] <m_3_> scaling in juju is just cool!  but that'll be another charm school :)
[16:42] <jcastro> yes, it's actually unfair to juju not mentioning scaling this time
[16:42] <jcastro> but when we get to it you'll really start to see the power
[16:42] <m_3_> it's a kind of magic
[16:42] <m_3_> sorry, had to
[16:42] <m_3_> :)
[16:43]  * m_3_ now has song stuck in head
[16:43]  * mainerror too
[16:48] <m_3_> hazmat niemeyer: y'all can have the channel back... thanks!
[16:48] <mpl> wheee
[16:49] <mpl> feels good to come out of the dark irc corner
[16:58] <niemeyer> Oh, hey.. #juju is back
[16:58] <niemeyer> rog: Review sent
[17:00] <rog> niemeyer: w.r.t. Bootstrap, I said that I would change the test (to test for len(ms)==1) once Bootstrap actually starts a machine, but for the time being i think it's ok.
[17:02] <niemeyer> rog: It's not..
[17:03] <niemeyer> rog: Comment the test out if you can't satisfy it.. a test assertion that asserts something wrong is doing what exactly
[17:04] <niemeyer> rog: Or, maybe better
[17:04] <niemeyer> rog: Comment Bootstrap out
[17:04] <rog> that's a better idea
[17:04] <niemeyer> rog: Then the test is probably correct
[17:04] <niemeyer> rog: It should not Destroy, though
[17:05] <rog> niemeyer: why not?
[17:05] <niemeyer> rog: Because that's the complement of Bootstrap
[17:05] <niemeyer> rog: Destroy doesn't work in a real deployment without Bootstrap, I think
[17:05] <niemeyer> fwereade_: Does it?
[17:05] <rog> niemeyer: currently, Destroy takes down all machines that were started from the current environment
[17:06] <rog> niemeyer: which seems ok
[17:06] <fwereade_> niemeyer, reading context
[17:06] <niemeyer> rog: Hmm.. fair enough.. that sounds like a good behavior, even if we don't do that in Python
[17:06] <fwereade_> niemeyer, I don't think destroy-environment is actually an *error* if you don't have an environment
[17:07] <niemeyer> fwereade_: The question is whether it kills all machines, even if we don't find the data about it in e.g. S3
[17:08] <fwereade_> niemeyer, checking
[17:09] <fwereade_> niemeyer, it gets ec2 machines by reservation, so it should be safe
[17:09] <niemeyer> fwereade_: Cool, thanks
[17:19] <rog> niemeyer: i replied with one question about about open vs Open
[17:19] <niemeyer> rog: and I already replied to it
[17:21] <rog> niemeyer: i think i'd prefer to wait until the occasion arises, if that's ok
[17:21] <niemeyer> rog: Sure, no prob
[17:22] <rog> niemeyer: the previous weekly builds find with all tests passing btw, so it's *something* that's changed recently
[17:22] <niemeyer> rog: You mean re. http?
[17:22] <rog> niemeyer: yeah
[17:27] <rog> niemeyer: https://codereview.appspot.com/5448085/
[17:28] <niemeyer> rog: goamz should be entirely fixed, tagged, and shiny already
[17:29] <rog> niemeyer: i just pulled and it didn't seem to be
[17:29] <rog> unless...
[17:29] <rog> ah, rename!
[17:30] <rog> no
[17:30] <rog> niemeyer: http://paste.ubuntu.com/757292/
[17:31] <rog> it still needs fixing, i think
[17:31] <rog> (that was done just after i'd removed the aws directory, BTW)
[17:32] <niemeyer> rog: I think I screwed up pushing to ~niemeyer.. let me see
[17:32] <rog> niemeyer: renames are awkward - it should lazily evaluate aliases i think
[17:32] <niemeyer> rog: yeah, I'm sorry
[17:33] <niemeyer> rog: The rename worked fine, but I forgot the --remember
[17:33] <niemeyer> rog: Which means the fixup and tagging afterwards went to the wrong location
[17:34] <niemeyer> rog: Ok, I _think_ everything should be fine now, including the more unknown packages (sdb, etc)
[17:34] <rog> niemeyer: if i push to lp:goamz/aws, it should remember that, even if it's later changed to be an alias for something else, i reckon
[17:34] <niemeyer> rog: It doesn't
[17:34] <rog> i know
[17:34] <niemeyer> rog: Unless you say so with --remember
[17:34] <niemeyer> rog: Ah, you're expressing a wish, sorry
[17:34] <rog> yeah
[17:34] <niemeyer> rog: Yeah, it makes sense to me too
[17:45] <rog> niemeyer: PTAL
[17:46] <niemeyer> rog: e.Destroy has already been mentioned in two other reviews.. please fix it or respond to the point.
[17:47] <rog> [17:06] <niemeyer> rog: Hmm.. fair enough.. that sounds like a good behavior, even if we don't do that in Python
[17:47] <niemeyer> rog: That's not the same issue
[17:47] <niemeyer> rog: We should be able to Open without Destroy
[17:48] <niemeyer> rog: Or do you think we shouldn't?
[17:48] <rog> niemeyer: i think that the destroys will happen at the end
[17:49] <rog> niemeyer: so it shouldn't matter
[17:49] <rog> niemeyer: what do you propose as a solution?
[17:49] <niemeyer> rog: So if I open the same environment 10 times, you think we should destroy it 10 times
[17:49] <rog> niemeyer: yeah.
[17:49] <niemeyer> rog: That's silly isn't it?
[17:49] <rog> niemeyer: probably :-)
[17:49] <niemeyer> rog: So let's do something else..
[17:50] <rog> niemeyer: your suggestion was to have suite.Bootstrap, right?
[17:50] <niemeyer> rog: I suppose each environment only has to be destroyed once, and that we don't really have to do through the same object that created it
[17:50] <rog> niemeyer: so the environment that got bootstrapped gets destroyed
[17:51] <niemeyer> rog: Does that make sense?
[17:51] <fwereade_> happy weekends everybody :)
[17:51] <niemeyer> fwereade_: thanks, have a great one too
[17:51] <rog> fwereade_: have a good one
[17:51] <niemeyer> rog: I don't mind to change the original suggestion.. just want to have some conversation going about the topic
[17:52] <niemeyer> rog: You say Destroy shouldn't depend on Bootstrap.. that's fine by me too
[17:52] <rog> niemeyer: i think that if we're wanting to test Bootstrap/Destroy with different opens, we can bypass the suite environment handling
[17:53] <niemeyer> rog: I don't want to test.. it's the opposite.. I don't want the suite to be doing something that makes no sense all the time
[17:53] <rog> most tests will be against a single environment, i think
[17:55] <rog> niemeyer: isn't it worth doing something that makes sense most almost all of the time? hmm, i dunno.
[17:55] <niemeyer> rog: Sorry, I don't get that point..
[17:56] <niemeyer> rog: The same environment shouldn't be destroyed twice.. it will fail, and the test will fail because Destroy fails
[17:56] <rog> anyway, my thought was that we could have a Bootstrap method as well as an Open method. the  Bootstrap method marks the env to be destroyed at the end.
[17:56] <niemeyer> rog: That was my suggestion, that you advocated against by saying Destroy should always be called :-)
[17:56] <rog> which will happen exactly once for each env created via bootstrap
[17:56] <niemeyer> rog: Which is fine by me
[17:57] <rog> niemeyer: that was then :-)
[17:57] <niemeyer> rog: The only point I'm trying to address is not destroying thing twice
[17:57] <niemeyer> rog: and it's easy to do that
[17:57] <rog> niemeyer: yeah, ok i'll do that
[17:57] <rog> see whether i can do it in 3 minutes!
[17:57] <niemeyer> rog: Well.. let's do this
[17:57] <niemeyer> rog: Please merge it as-is..
[17:58] <niemeyer> rog: We'll sort it out later
[17:58] <rog> ok
[17:58] <rog> it's ok as is?
[17:58] <niemeyer> rog: yeah
[17:59] <niemeyer> rog: I'm starting to think we should just Destroy it within each test as necessary and be done with it. Let's see how things show up in practice once we have a few additional tests
[17:59] <rog> niemeyer: the problem with that is that the env is left around if you do a failed Assert
[17:59] <niemeyer> rog: defer
[17:59] <rog> ok
[18:00] <niemeyer> But let's see.. it's bothering a bit knowing this will blow up but I'm probably concerned too soon
[18:01] <rog> bugger, conflicts
[18:02] <niemeyer> Huh.. how come?
[18:08] <rog> niemeyer: all sorted now. jeeze. i *think* i got all the steps right.
[18:09] <rog> gotta go, i am required to pack for the weekend. see ya monday. thanks for all the reviews, i love 'em really :-)
[18:10] <niemeyer> rog: Thanks a lot for everything this week, it was awesome
[18:10] <niemeyer> rog: and you're very welcome
[18:10] <rog> niemeyer: and if you did manage to have a look at ec2-region before then i'd be very happy indeed...
[18:10] <niemeyer> rog: Oh, wait
[18:11] <niemeyer> rog: I've checked it out, but the proposal includes unrelated changes from the previous branch
[18:11] <niemeyer> rog: I mentioned that in the codereview itself
[18:11] <rog> fuck
[18:11] <rog> which changes?
[18:13] <rog> niemeyer: i can fix it if you let me know right now, otherwise i'll have to leave it
[18:13] <niemeyer> rog: See the codereview
[18:14] <niemeyer> rog: I think it had all the ec2-initial changes in
[18:14] <rog> niemeyer: which file?
[18:14] <niemeyer> rog: All of them
[18:14] <niemeyer> rog: Or most, anyway.. checking out
[18:14] <rog> niemeyer: i thought ec2-initial was approved, bar these changes
[18:14] <niemeyer> rog: It is!
[18:14] <niemeyer> rog: and it's merged even, right?
[18:15] <rog> yeah
[18:15] <niemeyer> rog: My point is that this: rog: https://codereview.appspot.com/5449065/
[18:15] <niemeyer> rog: Has a ton of unrelated changes coming from other branches
[18:15] <rog> ah, sorry, i thought you were referring to the review just done
[18:15] <rog> one mo
[18:17] <rog> niemeyer: there, is that better?
[18:18] <rog> niemeyer: it looks like the changes are relevant now
[18:18] <rog> gotta go
[18:19] <niemeyer> rog: Superb, thanks!
[18:19] <niemeyer> rog: Enjoy
[23:01] <_mup_> Bug #899433 was filed: YAML errors in charms should be obvious to users <juju:New> < https://launchpad.net/bugs/899433 >