[00:02] <jimbaker> indeed very sad news about steve jobs
[01:11] <niemeyer> Cool: http://wtf.labix.org/
[01:29] <hazmat> sadness
[01:30] <hazmat> niemeyer, having some problems building go-tip
[01:30] <hazmat> oh well
[01:30] <niemeyer> hazmat: What's up
[01:30] <niemeyer> ?
[01:31] <hazmat> it error'd out. cleaned and retrying
[01:32] <hazmat> niemeyer, http://pastebin.ubuntu.com/703116/
[01:32] <niemeyer> Reading
[01:32] <hazmat> looks like it failed the acceptance tests
[01:32]  * hazmat tries to figure out scrollback buffers in tmux
[01:32] <niemeyer> hazmat: It's missing the start of the traceback
[01:33] <niemeyer> hazmat: Where the actual reason is mentioned
[01:33] <niemeyer> hazmat: Hmm.. I'm not sure.. I've changed my keys
[01:33] <niemeyer> hazmat: Mine is CTRL-X PGUP
[01:33] <niemeyer> Where X is the tmux special key
[01:35] <hazmat> hmm... maybe its confused by the pkg being installed
[01:37] <hazmat> niemeyer, full traceback http://paste.ubuntu.com/703119/
[01:37] <hazmat> hmm.. not full
[01:38] <niemeyer> hazmat: Strange error that is
[01:38] <niemeyer> hazmat: Looking at the code
[01:38] <niemeyer> hazmat: Can you please paste the contents of your /proc/net/igmp
[01:42] <hazmat> niemeyer, http://paste.ubuntu.com/703122/
[01:43] <hazmat> jimbaker, i think your problems might be related to firewalling.. perhaps the firestarter pkg
[01:45]  * hazmat falls asleep
[01:45] <niemeyer> hazmat: Looks fine.. we can figure it tomorrow
[01:46] <niemeyer> hazmat: Today was already most excellent :-)
[01:46] <niemeyer> hazmat: We even have a clean wtf: http://wtf.labix.org/
[03:05] <jimbaker> hazmat, i removed firestarter, but the wordpress example still does not come up; same issue of Network is unreachable by the ZK client
[03:24] <jimbaker> on second thought, i believe that firestarter simply configures the firewall. so removal probably does nothing. something i'll look at again tomorrow night
[03:24] <jimbaker> err, tomorrow
[08:39] <jamespage> moring - I got my local juju environment working with bscaller's patch for dns resolution
[08:39] <jamespage> nice
[08:40] <jamespage> just killed my laptop but runing to many cassandra units -ooops
[09:00] <kim0> hazmat: Andreas mentioned he's already writing the docs for orchestra/juju interaction, see bug 855989
[09:00] <_mup_> Bug #855989: Document usage with orchestra <juju:Confirmed for kim0> < https://launchpad.net/bugs/855989 >
[11:46] <kim0> nice, lxc deployment works great!
[11:48] <kim0> wordpress connects woohoo This is so awesome \o/
[12:04] <hazmat> kim0, nice!
[12:04] <kim0> hazmat: this is great man :)
[12:04] <hazmat> kim0, indeed, much more fun
[12:04] <hazmat> kim0, fwereade_ comitted some work to auto increment version when you do an upgrade, should help solve one of the common charm author gotchas
[12:05] <kim0> hazmat: yes .. to actually get this lxc stuff working, I had to add revision: to metadata.yaml of some charms
[12:05] <hazmat> kim0, hmm.. really? what was the error?
[12:06] <hazmat> the version separation should have been backwards compatible
[12:06] <kim0> hazmat: 2011-10-06 13:11:40,137 ERROR Bad data in charm info: /home/kim0/Documents/code/juju/juju/examples/oneiric/php/metadata.yaml: revision: required value not found
[12:06] <kim0> there's probably a better way to handle this ? like add revision in a separate file? but I disn't know about it
[12:06] <hazmat> i'm not even sure what that php charm is supposed to be doing
[12:07] <kim0> hazmat: it's all of em ..2011-10-06 11:30:29,797 ERROR Bad data in charm info: /home/kim0/Documents/code/juju/juju/examples/oneiric/wordpress/metadata.yaml: revision: required value not found
[12:07] <kim0> all charms in local "repo" .. were being checked
[12:07] <hazmat> fwereade_, ^
[12:07] <hazmat> yeah.. the revision got moved to a separate file
[12:07] <kim0> so like, echo 1 > revision ?
[12:08] <kim0> then it needs that file added to trunk I suppose
[12:08] <hazmat> kim0, it should have already been on trunk, which is why i'm curious
[12:08]  * hazmat tries it out
[12:09] <kim0> hazmat: I'm on 388 from ppa, too old ?
[12:09] <hazmat> hmm
[12:10] <hazmat> 388 doesn't have the auto upgrade work, and it shouldn't have changes to revision in the charm metadata
[12:12] <hazmat> 388 works for me, trying again with trunk
[12:12] <hazmat> yeah.. both seem fine
[12:31] <kim0> weird
[12:38] <fwereade_> hazmat, kim0: oh crap
[12:38] <hazmat> fwereade_, i couldn't reproduce it
[12:39] <fwereade_> hazmat: it doesn't, indeed, look like it should happen
[12:39] <hazmat> i should try the package  just to be sure
[12:40] <fwereade_> hazmat, kim0: the "required value not found" implies that some of the code is out of date -- before I made that optional
[12:40] <kim0> fwereade_: that's the pkg: 0.5+bzr388-1juju1~oneiric1
[12:41] <fwereade_> kim0: hmm, I guess that would be the problem, I'm pretty sure 389 was when the change landed, let me double-check
[12:41] <fwereade_> hazmat: I guess this was another instance in which I should have rebuilt the PA as soon as it landed?
[12:41] <kim0> cool .. if anyone can force a pkg rebuild, I'd love to test again
[12:42] <hazmat> fwereade_, i'm not sure why.. was there a rev that hit trunk that would be broken?
[12:42] <hazmat> afaik no
[12:42] <hazmat> kim0, sure, i'm just testing out the pkg first
[12:42] <kim0> great
[12:42] <fwereade_> hazmat: likewise, but we knew that 389 wouldn't work with <=388, so anything that would cause mixed code could trigger it
[12:43] <hazmat> fwereade_, yeah.. but this is all client side
[12:43] <fwereade_> hazmat: oh
[12:44] <fwereade_> hazmat: I guess the old code won't work with a new-style charm, though
[12:44] <fwereade_> kim0: where are the charms coming from?
[12:44] <hazmat> hmm
[12:44] <hazmat> kim0, are you using charms from version control and pkg from ppa?
[12:44] <kim0> fwereade_: yeah .. charms are from trunk
[12:44] <kim0> yes
[12:44] <fwereade_> kim0: bingo
[12:44] <kim0> you got it
[12:44] <hazmat> fwereade_, nice catch
[12:44] <kim0> I thought it would be a tiny difference :)
[12:45]  * hazmat rebuilds the ppa
[12:45] <hazmat> looks like someone beat me to it
[12:47] <fwereade_> kim0, charms will work just fine with the revision in both places, so you can just re-add it to metadata.yaml for now; it won't hurt when you try to run with newer code
[12:47] <fwereade_> kim0, it will whine at you a little but that's it
[12:47] <kim0> cool! fwereade_ great work :)
[12:47] <kim0> I hated manual versions too hehe
[12:47] <fwereade_> kim0: (for reference: when both exist, the revision file overrides the value in metadata)
[12:47] <kim0> got it
[12:47] <fwereade_> kim0, cheers :)
[12:47] <kim0> :)
[13:03] <SpamapS> Looks like r388 builds w/ clean unit tests in my PPA ..
[13:16] <jcastro> SpamapS: are you in your room or in this big room?
[13:20] <SpamapS> jcastro: in keynotes now
[13:22] <SpamapS> jcastro: I think I'll head back up to the room shortly tho
[13:32] <fwereade_> morning niemeyer
[13:34] <niemeyer> fwereade_!
[13:34] <hazmat> hmm.. reflowing text is more involved than i'd hoped
[13:34] <niemeyer> hazmat: Hm?
[13:34] <niemeyer> hazmat: Good morning :)
[13:34] <hazmat> niemeyer, good morning.. doing a display of the schema
[13:34] <hazmat> but their are newlines in the description which break up the formatting
[13:35] <hazmat> and then i came across this.. http://www.koders.com/python/fid7886C337B44AD65C83D334544E6CA3E4FBB7E050.aspx?s=timer
[13:35] <hazmat> which is a unicode aware reflow impl
[13:35] <hazmat> actually its not unicode aware
[13:35] <hazmat> hmm.. maybe it is.. but its still way more than i want
[13:37] <hazmat> not sure i can reflow correctly if there are examples in the description either that depend on formatting
[13:37]  * hazmat surveys extant charms
[13:38] <niemeyer> Still waiting for the link to load, so I'm not sure about what this is really about yet
[13:38] <niemeyer> hazmat: I'm lacking context I guess.. why are we getting into reflowing text at all?
[13:39] <hazmat> niemeyer, just trying to pretty print the schema, pretty.print() doesn't quite do it if there are embedded newlines in the description
[13:40] <hazmat> i'm using some indentation + newline to separate options, but the description field is freeform
[13:40] <hazmat> and breaks up the formatting
[13:40]  * hazmat goes for a punt and some newline separation for context
[13:41] <hazmat> niemeyer, pls ignore -> server time :-)
[13:42] <niemeyer> hazmat: Sorry, but why aren't we simply dumping the config.yaml?
[13:42] <hazmat> niemeyer, try.. a pretty print on a dictionary with values that have embedded new line.. it ends up on a single line
[13:42] <niemeyer> hazmat: Ok.. let me try.. $ cat config.yaml..  yeah, looks good?
[13:43] <hazmat> hmm
[13:43] <hazmat> i guess i could try pretty printing with yaml instead of the python dict
[13:47] <hazmat> no.. still looks pretty bad
[13:49] <hazmat> niemeyer, http://paste.ubuntu.com/703396/
[13:50] <hazmat> first one is yaml dump with indent=4, second one is manually printing
[13:50] <hazmat> keep in mind the data is not from file on disk but from the charm state
[13:55] <SpamapS> niemeyer: do we expect anything else to land after r388 ?
[13:55] <hazmat> SpamapS, i'd use 391 as a base
[13:56] <hazmat> SpamapS, it has the auto incrementing work for upgrade work which makes things quite a bit nicer, as well as the separation of revision into a separate file from metadata
[13:56] <niemeyer> SpamapS: Yeah, 391 is the current base
[13:56] <niemeyer> SpamapS: My hope is that we'll be looking after bug fixes now only
[13:56] <niemeyer> hazmat: The yaml there isn't right..
[13:56] <niemeyer> hazmat: It looks ugly because it's inlining the values
[13:57] <niemeyer> hazmat: plugin: {description:
[13:57] <SpamapS> oh ok
[13:57] <niemeyer> hazmat: It can do much better than that automatically
[13:58] <hazmat> niemeyer, that was with yaml.dump(schema_dict, indent=4) .. the docs on pyaml aren't very helpful
[13:58] <niemeyer> hazmat: I know.. I don't even recall how to print it nicely myself, but I'm sure it's possible and easy
[13:58] <niemeyer> hazmat: Let me look
[13:58] <hazmat> i'll try.. maybe turning off the default flow style
[13:58]  * SpamapS triggers rebuild w/ r391
[13:59] <niemeyer> hazmat: I know because I've tweaked the printing in goyaml
[13:59] <niemeyer> hazmat: Which is backed by the same code
[14:00] <SpamapS> really a ton of buzz this week around juju
[14:00] <hazmat> niemeyer, i switched to 'default_flow_style' off.. http://paste.ubuntu.com/703402/
[14:00] <hazmat> which gets the key on a separate line, but is still less useable than doing it by hand
[14:01] <hazmat> imo
[14:02] <niemeyer> hazmat: Do you really want to get into serializing yaml by hand? :)
[14:02]  * SpamapS wonders if that would be doable on mechanical turk ;)
[14:02] <hazmat> niemeyer, its just printing k,v in a dict
[14:03] <hazmat> niemeyer, we loose the user formatting when we serialize to the charm config node
[14:03] <niemeyer> hazmat: Hint: your manual yaml is broken.
[14:03] <hazmat> niemeyer, i'm not trying to print yaml.. i'm trying to print human consumable info
[14:04] <niemeyer> hazmat: Which we've agreed to print in yaml so far?
[14:04] <hazmat> in an easy to digest and normal fashion
[14:06] <niemeyer> hazmat: The yaml in that paste looks quite normal and easy to digest.. I'd really prefer to sustain the current convention we have of displaying human consumable information in yaml, since besides being readable and nice to digest it's also machine readable
[14:07] <hazmat> niemeyer, fair enough
[14:07] <niemeyer> hazmat: The decision we made in status is already paying off.. it's already being processed to do decisions based on the status
[14:08] <hazmat> niemeyer, does yaml guarantee key ordering?
[14:08] <niemeyer> hazmat: IIRC, maps should not assume a defined ordering
[14:09] <niemeyer> hazmat: There are ordered maps as well, IIRC, but we're not using them
[14:10] <niemeyer> hazmat: WEll.. there's probably _anything_ you can imagine in yaml, unfortunately :-)
[14:10] <niemeyer> It's the only place I've ever seen a convention for base-60 floats (!)
[14:11] <SpamapS> r391 building in PPA https://code.launchpad.net/~clint-fewbar/+archive/fixes/+build/2826656
[14:11] <hazmat> fun.. i'm sure doing yaml dump will save some unicode problems.. just curious if we can give the user a normalized presentation of description, default, type for a given option or ordering across options
[14:11] <niemeyer> hazmat: I suspect it's key-sorting on dump, but I'm not sure
[14:12] <hazmat> SpamapS, i hand't noticed  that streaming build log before, nice
[14:12] <SpamapS> yeah, keeps me from angrily pacing
[14:15] <niemeyer> Wow..
[14:16] <niemeyer> http://blog.golang.org/2011/10/preview-of-go-version-1.html
[14:18] <rog> niemeyer: lots of tasty changes there.
[14:56] <fwereade_> niemeyer: btw, I have an MP for that deploy bug lying around, but I didn't target to eureka because I had a vague feeling it might be finished
[14:56] <fwereade_> niemeyer: what, if anything, should I be doing about it?
[14:56] <hazmat> fwereade_, eureka is still open for bug fixes
[14:56] <hazmat> new feature dev is on florence
[14:56] <fwereade_> hazmat: ah, cool, thanks
[14:56] <niemeyer> fwereade_: What hazmat says
[14:58] <hazmat> niemeyer, so do we want to start a new series or separate merge branch for florence till eureka closes, or just hold off on  florence merges
[14:58] <hazmat> niemeyer, also we'll need a new kanban
[14:58] <fwereade_> niemeyer: also, lp:~fwereade/juju/charm-store-hack appears to work
[14:58] <fwereade_> niemeyer: python juju/charm/store -r REPO -k KEY -c CERT -p PORT
[14:59] <fwereade_> niemeyer: and edit juju.charm.repository to construct a RemoteCharmRepository with the appropriate url base
[14:59] <fwereade_> niemeyer: [edit] python juju/charm/store.py -r REPO -k KEY -c CERT -p PORT
[15:02] <hazmat> fwereade_, nice
[15:03] <niemeyer> fwereade_: Wow, sweet!
[15:04] <niemeyer> hazmat: I think let's hold off at least for this week, and focus on getting the last few fixes/polishes into eureka
[15:05] <SpamapS> https://launchpadlibrarian.net/82132481/buildlog_ubuntu-oneiric-i386.juju_0.5%2Bbzr391-1juju1~oneiric1_FAILEDTOBUILD.txt.gz
[15:05] <SpamapS> buildd failures for 391
[15:06] <SpamapS> looks like a timeout..
[15:08] <niemeyer> SpamapS: Indeed
[15:08] <niemeyer> SpamapS: Worth a retry
[15:08] <niemeyer> SpamapS: The wtf is clean for a while, FWIW
[15:09] <niemeyer> SpamapS: http://wtf.labix.org/
[15:12] <SpamapS> niemeyer: yeah I don't even try the builds until that is "OK"
[15:13] <niemeyer> SpamapS: Sweet
[15:14] <jamespage> morning/afternoon all
[15:15] <jamespage> I'm having issues with charm where the charm name contains a number
[15:15] <jamespage> for example - cassandra is fine - but tomcat7 errors
[15:15] <jamespage> Message: Bad charm URL 'local:oneiric/tomcat7': invalid name (URL inferred from 'local:tomcat7')
[15:17] <niemeyer> jamespage: I suspect this is a bug in the regex.. rog actually brought that up.. /me checks
[15:19] <niemeyer> jamespage: Yeah, it's bogus, sorry about that.. we'll fix
[15:20] <jamespage> niemeyer; ta
[15:23] <fwereade_> niemeyer, it's not necessarily *quite* as simple as that
[15:23] <fwereade_> niemeyer: sorry, I mentioned that in an MP discussion somewhere
[15:23] <niemeyer> fwereade_: It's not?
[15:24] <fwereade_> niemeyer: we could fix charm names to end with number, but then we need to make sure the final string of number is not preceded by a -
[15:24] <hazmat> SpamapS, i've been able to run that test a couple hundred times, haven't reproduced
[15:24] <fwereade_> niemeyer: cs:oneiric/foobar-7
[15:24] <niemeyer> fwereade_: That sounds trivial
[15:24] <SpamapS> hazmat: given that its building on a virtual host... could just be that it needs a slightly higher timeout.
[15:24] <fwereade_> niemeyer: well, it is really
[15:24] <niemeyer> :-)
[15:25] <hazmat> SpamapS, its not really a timeout per se, its a deferred being called twice, resulting in an uncaught exception, which leads to a timeout
[15:25] <hazmat> SpamapS, ie. it would always timeout with that circumstance regardless of timeout length
[15:25] <fwereade_> niemeyer: it's just that I reverted to the original regex when I noticed, pending further discussion, which I guess got lost
[15:26] <niemeyer> fwereade_: I lost it as well in the buzz, but I'll put another regex in place.. hold on
[15:26] <hazmat> SpamapS, hmm.. actually you might be right, its a 2.6 second test as is
[15:26] <hazmat> SpamapS, the timeout is causing the deferred to fire early
[15:27] <hazmat> SpamapS, i'll take a look, i think we can rework the config set tests to not use the status build infrastructure which is tons more stuff than it needs
[15:28] <_mup_> Bug #869272 was filed: charm names should be able to end with a digit <juju:In Progress by fwereade> < https://launchpad.net/bugs/869272 >
[15:29] <fwereade_> niemeyer: target to eureka, right?
[15:30] <niemeyer> fwereade_: Yeah
[15:30] <fwereade_> niemeyer: cheers
[15:36] <_mup_> juju/config-set-sans-status r392 committed by kapil.thangavelu@canonical.com
[15:36] <_mup_> simplify setup for status tests, takes runtime from 12.5s for 4 tests to 2s
[15:36] <niemeyer> fwereade_, hazmat, SpamapS, jamespage: Is this right:
[15:36] <niemeyer> "^[a-z]+([a-z0-9-]+[a-z][a-z0-9]*)?$"
[15:37] <fwereade_> niemeyer: I *think* so, but I haven't written any tests yet :p
[15:38] <niemeyer> fwereade_: Cool, can you take this over?
[15:38] <fwereade_> niemeyer: I intend to, but I need to pop out for a while in about 1 minute
[15:38] <hazmat> works for the formulas i have locally
[15:39]  * hazmat tries to remember the url to the latest charms from lp
[15:39] <hazmat> https://api.launchpad.net/devel/charm?ws.op=getBranchTips
[15:39] <fwereade_> niemeyer: I'll fix CharmURL when I get back
[15:39] <niemeyer> fwereade_: Thanks!
[15:39] <fwereade_> laters
[15:43] <hazmat> niemeyer, works against all the extant charms on lp
[15:44] <niemeyer> hazmat: Super.. and it blocks the bad cases too I suppose (starting and ending with -, starting with digit, and ending with - and digit)
[15:44]  * niemeyer => lunch!
[15:47] <jamespage> should the expose/unexpose commands have context with the local provider?  I assume not as they make no difference :-)
[15:47] <jimbaker> jamespage, they are not meaningful for the local provider
[15:48] <jamespage> jimbaker: ack - thanks for the confirmation
[15:49] <hazmat> jamespage, they don't
[15:50] <_mup_> Bug #869289 was filed: Simplify config set tests to reduce runtime significantly. <juju:In Progress by hazmat> < https://launchpad.net/bugs/869289 >
[15:50] <hazmat> SpamapS, just put a MP into the queue which should reduce the runtime of those tests by 6x
[15:50] <hazmat> that should hopefully avoid any issues on that particular test case
[15:54] <_mup_> juju/config-set-sans-status r393 committed by kapil.thangavelu@canonical.com
[15:54] <_mup_> remove commented out bits, oops
[15:55] <negronjl> hi guys:  Is there a way to deploy different releases on the same deployment.  Something like this charm on oneiric ( maybe specify ami and size ) and another one on natty ( maybe also specify ami and size ) ?
[15:55] <jimbaker> hazmat, i was about to ask about those commented-out bits ;)
[15:57] <negronjl> I have some charms that work on oneiric and others that work on natty.  I am wondering if there is a way to use them both by just telling juju to use oneiric for some and natty for some others
[15:59] <hazmat> rog, would you mind have a look niemeyer's go branches in review ?
[15:59] <m_3> negronjl: +1, but I'd like to specify image-id and instance-type in charm metadata
[15:59] <negronjl> m_3: I like that idea too :)
[15:59] <rog> hazmat: sure. where do i find them?
[15:59] <m_3> negronjl: what I've been doing to solve that is just adding logic around `lsb_release -cs` in the charm
[15:59] <hazmat> rog, http://j.mp/juju-eureka
[16:00] <hazmat> negronjl, we've added the notion of charm series which i think will correspond to what the distro series used to deploy them is, but its not easily intermixed atm as its an environment setting
[16:02] <negronjl> hazmat: Thanks.  Is it somewhere in your roadmap?  Do you know of any work-around to accomplish this ?
[16:04] <niemeyer> fwereade_, hazmat: Hmm.. was just thinking over lunch we might do something slightly more restrictive
[16:05]  * niemeyer hacks something quick
[16:05] <hazmat> negronjl, i don't think its functionally that way now, and its not listed on the roadmap atm, i'd need to defer to niemeyer and fwereade_ who've been discussing this.. ie. charm series atm doesn't correspond to distro.. hmm.. i don't see any way to capture this
[16:06] <hazmat> atm
[16:06] <negronjl> hazmat: ok.  that's too bad but, thanks for the info.
[16:07] <niemeyer> negronjl: Yes, charms are specific to a given Ubuntu series
[16:07] <niemeyer> fwereade_: In fact, we'll have to address a missing aspect in that regard, I think..
[16:08] <hazmat> negronjl, atm the only way to address is via default-image-id modified between deploys
[16:08] <niemeyer> hazmat, fwereade_: "^[a-z][a-z0-9]+(-[a-z0-9]*[a-z][a-z0-9]*)*$"
[16:08] <hazmat> niemeyer, yeah.. atm charm series doesn't actually correspond to an image launch against a series afaics
[16:09] <niemeyer> hazmat: Yeah, but the idea is really to use the charm URL series for that
[16:09] <negronjl> niemeyer: It would be useful to be able to tell juju which release ( ami-id, size ) to use for diff. charms.  ATM I have a hadoop charm that only works on natty ( for now ) and a cloudfoundry charm that only works on oneiric.  It would be useful to be able to demonstrate the two of them without having to destroy the environment between them.
[16:09] <niemeyer> hazmat: It's not a big deal since there's a single one today, but that's definitely the intention
[16:09] <niemeyer> negronjl: The ami-id will come out of the charm URL series
[16:10] <niemeyer> negronjl: Size, etc, is a different issue we'll have to address
[16:10] <niemeyer> Anyway.. must go back to lunch, just wanted to propose the regex before fwereade_ worked on it
[16:11] <negronjl> niemeyer: thx for the info
[16:11] <hazmat> niemeyer, yeah.. we'll need some more leg work for that to happen, machine allocation happens without regard to the unit/charm being placed atm
[16:12]  * niemeyer mumbles something about placement hack..
[16:12]  * niemeyer => lunch, again
[16:12] <hazmat> :-)
[16:13] <hazmat> that's not really the problem per se, we just need to propogate more info to the machine state regarding its type/series constraints, placement is just the abstraction layer that it needs to get to
[16:31] <_mup_> juju/safer-perms-on-juju-dir r392 committed by kapil.thangavelu@canonical.com
[16:31] <_mup_> stricter perms when creating default juju config and juju dir
[16:35] <niemeyer> hazmat: It is the problem in that the model is not suitable yet
[16:35] <niemeyer> We'll get there, though
[16:52] <_mup_> juju/local-provider-docs r392 committed by kapil.thangavelu@canonical.com
[16:52] <_mup_> local provider docs
[17:08]  * hazmat lunches
[17:20] <rog> hazmat, niemeyer: reviews done
[17:23] <hazmat> rog, awesome thanks
[17:24] <hazmat> rog, via email?
[17:24] <rog> i replied on the comment form. doesn't that send an email to interested parties?
[17:25] <rog> hazmat: ^
[17:26] <hazmat> rog, oh.. it does.. just to vote  on the mp in addition to the comment, right underneath the  textarea you can do a approve/needs fixing/etc on the merge itself
[17:26] <hazmat> i missed it cause i was scanning the top of the merge proposal for votes
[17:28] <rog> done
[17:31] <niemeyer> rog:
[17:31] <niemeyer> parts = append([]string{dir.Path}, parts...)
[17:31] <niemeyer> appending to parts directly is bad behaviour because
[17:31] <niemeyer> it could interfere with any callers that call join
[17:32] <niemeyer> rog: I'm not really sure about what you mean there?
[17:32] <rog> niemeyer: parts is an argument to the function. append has side effects.
[17:32] <niemeyer> rog: This example has absolutely no side effects.. I don't really get what you mean
[17:34] <rog> niemeyer: doh, sorry, i'd read it wrong
[17:34] <rog> ignore!
[17:35] <niemeyer> rog: Phew, cool, np :)
[17:37] <niemeyer> rog: "Seems to me like the body of this loop would be better"
[17:37] <niemeyer> rog: Good idea there, thanks
[17:39] <Zeelot> morning
[17:39] <niemeyer> Zeelot: Morning!
[18:01] <rog> ok, a little question. i'm trying to trace through juju actions on bootstrap.
[18:01] <Zeelot> so it seems like all the examples use one ec2 instance for each service. How bad of an idea is it to create a charm that installs a full php application onto a single instance? something like php+apache+couchdb+rabbitmq
[18:01] <rog> in this file, juju/control/bootstrap.py, it looks as if it's calling the bootstrap function defined in this file: juju/providers/common/base.py
[18:01] <Zeelot> is this all just preference of how we want to manage our instances?
[18:02] <rog> but that function just seems to return a list of machines - how does the bootstrap process actually get initiated?
[18:03] <rog> (because the run function in juju/providers/common/bootstrap.py just seems to return a list of machines, and not actually do anything)
[18:03] <niemeyer> Zeelot: php+apache sounds fine.. I'd put couchdb and rabbitmq in separate charms
[18:03] <niemeyer> Zeelot: Note that this is just the beginning.. we'll be adding support for multiple charms in a single machine in the future
[18:03] <rog> what am i missing?
[18:04] <niemeyer> rog: Let me check
[18:06] <niemeyer> rog: Hmm
[18:06] <Zeelot> niemeyer: ah, perfect. I'm also wondering, is this just for EC2? So if I am developing on a local environment, I currently use a VM with a basic ubuntu server. Juju isn't going to help me with anything there, is it? So I still have my vagrant + chef/puppet recipes to set up my VM but at that point, why use juju to set up my software on ec2 when I already have my recipes from chef or puppet? I might simply just be misunderstanding the goals for juju
[18:06] <niemeyer> rog: I'm not sure how you got to the conclusion that it just runs a list of machines and doesn't do anything
[18:06] <niemeyer> rog: The bootstrap method in base.py calls Bootstrap.run, which does more than that
[18:07] <niemeyer> Zeelot: juju deploys on EC2, OpenStack, Cobbler/Orchestra (physical), and locally through LXC
[18:07] <rog> it calls get_zookeeper_machines, but that didn't look like it did much more than interrogate the state for the list of machines
[18:08] <Zeelot> alright, I'll have to look at those other things then because I'm not sure what they are :) thanks
[18:08] <niemeyer> Zeelot: If you already have something else that deploy your software on EC2 in a way you're very happy with, I wouldn't look for anything else :-)
[18:08] <niemeyer> Zeelot: juju is very different from chef and puppet, though
[18:09] <Zeelot> niemeyer: we don't have anything for deploying to ec2 but we are looking into making puppet or chef recipes. If juju can help me also set up VMs, then I am fine with it
[18:09] <niemeyer> Zeelot: Yeah, that's juju! :)
[18:09] <Zeelot> juju looks like a much more complete solution to deploying to ec2
[18:09] <niemeyer> Zeelot: Not only set up the VMs, but we're working on the full orchestration experience
[18:09] <niemeyer> Zeelot: Reusable building blocks a command away
[18:09] <Zeelot> excellent
[18:10] <niemeyer> Zeelot: and scaling up and down, recovery, etc etc
[18:10] <niemeyer> Zeelot: There's a lot to do still, of course, but the future looks unlike anything else out there
[18:11] <rog> niemeyer: i can't see where the actual machine is bootstrapped. is it as a side-effect of find_zookeepers ?
[18:11] <niemeyer> rog: Just follow the pipeline
[18:11] <rog> i'm trying!
[18:11] <niemeyer>         machines = self._provider.get_zookeeper_machines()
[18:11] <niemeyer> ...
[18:11] <niemeyer>         machines.addErrback(self._on_no_machines_found)
[18:11] <Zeelot> any useful tips for what I should be reading to get caught up on what I need to do in order to use juju for setting up my VM? Or is that part of a future feature?
[18:11] <niemeyer> rog: What happens on no_machines_found?
[18:12]  * rog groans.
[18:12] <hazmat> Zeelot, docs are pending in the merge queue, but theirs a message on the  mailing list which goes through the basics
[18:12] <rog> that's a bit gross
[18:12] <niemeyer> rog: Yeah, I'm happy you're unhappy about it
[18:12] <rog> no wonder i couldn't see it
[18:12] <Zeelot> alright, thanks
[18:12] <hazmat> Zeelot, https://lists.ubuntu.com/archives/juju/2011-October/000844.html
[18:13] <hazmat> Zeelot, complete example of config in this one.. https://lists.ubuntu.com/archives/juju/2011-October/000847.html
[18:13] <hazmat> Zeelot, that should work fine in a vm as well
[18:13] <Zeelot> awesome
[18:14] <Zeelot> looks like I need to learn about LXC first
[18:17] <hazmat> Zeelot, its basically os level namespacing for isolation.. a jail or chroot on steroids... much less overhead than full virtualization
[18:18] <Zeelot> hmm, is it possible to use a VM like virtualbox? Mostly a requirement for the developers that work on windows or mac
[18:18] <hazmat> Zeelot, just to be clear its not for setting up vms, its for a setting up a vm from inside the vm
[18:18] <Zeelot> ah, then that's probably fine
[18:18] <hazmat> it will do isolation of the different services within the vm using lxc
[18:19] <Zeelot> interesting
[18:19] <hazmat> its mostly meant for ubuntu physical machines, but it works fine in a virtual machine
[18:19] <Zeelot> so then I could simply have a basic ubuntu server VM that I never alter, and use juju to set up dev environments for my various projects?
[18:21] <hazmat> Zeelot, outside of install juju and doing deploys from within the vm, yes.. you'd be using an environment per project as well probably to get separation between them
[18:24] <Zeelot> thanks for the info
[18:38] <jimbaker> rog, bootstrap is an example where the inlineCallbacks style works better, especially when the logic gets convoluted - do the bootstrap *if* there's a certain error (EnvironmentNotFound)
[18:39] <jimbaker> but as you see here, it's currently quite convoluted and requires a twisted way of thinking, so to speak
[18:44] <rog> jimbaker: i still can't quite see what's going on. ahhh, the crux is returnValue, i think i see now
[18:45] <rog> oh, no, i still don't see it
[18:46] <jimbaker> rog, i'd be happy to walk you through it
[18:46] <rog> actually, i *think* i see it.
[18:46] <rog> but i don't understand why a callback is added that is known to return an error, only to do something on the error.
[18:47] <jimbaker> rog, yeah, the logic is certainly more convoluted than what would pass a review now imho
[18:48] <jimbaker> rog, also the use of the command pattern with the run, vs just having a function is something that is not helpful
[18:48] <niemeyer> rog: Which callback is added that is known to return an error?
[18:48] <rog> jimbaker: couldn't you just yield launch_machine or something?
[18:49] <rog> _on_machines_found
[18:50] <jimbaker> rog, there is nothing in Bootstrap that couldn't just be a single inlineCallbacks function, correct
[18:50] <rog> AFAICS the only reason that ErrBack gets called is because _on_machines_found returns an error, which it always will (or is there some subclass subterfuge going on there?)
[18:50] <niemeyer> rog: _on_machines_found doesn't return an error
[18:50] <rog> niemeyer: oh. so why does errBack get called?
[18:51] <niemeyer> rog: errback gets called on errors
[18:51] <rog> niemeyer: so where's the error coming from?
[18:51] <rog> niemeyer: because without an error, nothing happens, right?
[18:51] <niemeyer> rog: Take a moment to read this: http://twistedmatrix.com/documents/current/core/howto/defer.html
[18:51] <jimbaker> the errback is called from get_zookeeper_machines
[18:51] <niemeyer> rog: It will help you a lot in your understanding of the code base
[18:51] <jimbaker> or i should say, because of it :)
[18:52] <jimbaker> so machines in the run function is a Deferred
[18:52] <rog> yes, because of returnValue, right?
[18:52] <rog> which is why we can call addCallback and addErrback, yes?
[18:52] <jimbaker> rog, looking at its definition, but not because of returnValue
[18:52] <rog> oh
[18:53] <jimbaker> that's just a convention required by the inlineCallbacks decorator
[18:53] <niemeyer> rog: returnValue is a hack related to inlineCallbacks
[18:53] <rog>     machines = []
[18:53] <rog> does that make a deferred value?
[18:53] <rog> oh, findZooKeepers is inlineCallbacks
[18:53] <niemeyer> rog: inlineCallbacks explores Python generators to try to avoid the callback-based logic (addErrback, addCallback, etc) and make the code a bit more linear
[18:54] <rog> i'm used to seeing inlineCallbacks functions yield things rather than returning them
[18:54] <hazmat> yeah.. its syntatic sugar using python generators under the hood
[18:54] <jimbaker> rog, yes, findZookeeper uses the inlineCallbacks decorator. so it wraps the function such that its invocation returns a Deferred
[18:54] <jimbaker> that Deferred in turn is returned (trivially) by get_zookeeper_machines
[18:54] <niemeyer> rog: returnValue raises an exception that is caught by the inlineCallback decorator to stop the generator
[18:55] <rog> jimbaker: yes, i think i kind of understand that (although i haven't read that document)
[18:55] <niemeyer> rog: It's a "return" from a generator, because generators can't return
[18:55] <rog> ah ok. i see. lovely stuff.
[18:55] <niemeyer> rog: I'd call it syntatic salt
[18:55] <jimbaker> rog, i highly recommend just looking at the source code of inlineCallbacks, it's pretty straightforward code
[18:55] <rog> rofl
[18:55] <jimbaker> in the sense that setting up trampolines can be
[18:56] <niemeyer> jimbaker: WHAT?
[18:56] <rog> jimbaker: i will some time. i get  the principle.
[18:56] <niemeyer> ROTFL
[18:58] <rog> it's a kinda beautiful subversion of a few language features
[18:58] <jimbaker> rog, sounds good. one convention you will notice in our code is that we don't do use inlineCallbacks if we are just returning a Deferred (eg the passthrough in get_zookeeper_machines)
[18:58] <niemeyer> rog: http://paste.ubuntu.com/703548/
[18:58] <rog> jimbaker: yeah, that confused me
[18:58] <jimbaker> rog, i understand
[18:58] <niemeyer> rog: Look at that, and pay attention next time jimbaker tells you something is straightforward
[18:59] <rog> i understand what's going on now. the interplay between deferred stuff and exceptions wasn't... obvious.
[19:00] <rog> exc_info()[2].tb_next
[19:00] <rog> no that's not straightforward as i would understand the term
[19:00] <jimbaker> rog, a good reason not to just pass through is if you want to do something that logically occurs after a value that you would return
[19:01] <jimbaker> rog, hah, i didn't say straightforward meant easy
[19:01] <jimbaker> for what it needs to do, it's straightforward
[19:01] <rog> jimbaker: i'll take it from you
[19:01] <niemeyer> jimbaker: Yeah, you meant straightforward as in extremely involved
[19:02] <rog> well, it's less than 100 lines of code
[19:03] <rog> well, having suffered that enlightenment, i shall go and cook some curry
[19:03] <niemeyer> rog: and most of them are comments even ;-)
[19:03] <niemeyer> rog: Do check the documentation about deferreds out later/tomorrow
[19:03] <jimbaker> rog, and it's also do something helpful - trying to diagnose improper use of returnValue, using the fact that the traceback can be interrogated
[19:04] <niemeyer> rog: It'll help a lot on your understanding of the base
[19:04] <rog> jimbaker, niemeyer: thanks for holding my hand through that. i feel.... better.
[19:04] <jimbaker> again, for what it is trying to do, it's straightforward
[19:04] <niemeyer> jimbaker: Yeah.. a lot more straightforward than parsing apt-cache's output for sure
[19:05] <jimbaker> niemeyer, :( it helps to know what it should be, enough said. parsing is the easy part
[19:06] <niemeyer> OMG, what a feeling of emptiness on the eureka kanban
[19:06] <_mup_> juju/local-provider-docs r393 committed by kapil.thangavelu@canonical.com
[19:06] <_mup_> missing doc file, doh
[19:07] <niemeyer> hazmat: Danke :)
[19:07] <rog> niemeyer: ping re merge requests, BTW
[19:08] <niemeyer> rog: Cool
[19:08] <niemeyer> rog: Cheers
[19:08] <hazmat> bcsaller, jimbaker, fwereade_ even though there's no items on the kanban, i've just been going through low hanging bugs in the general queue.. till we get some new ones
[19:08] <hazmat> there's alot to choose from
[19:08] <rog> see y'all tomorrow
[19:08] <jimbaker> hazmat, ok, we might want to reserve some of them
[19:09] <hazmat> jimbaker, its better to pick them as your doing them, else we end up with reserved queues which serve no purpose except delay
[19:10] <jimbaker> hazmat, should have been more precise, reserve one per person :)
[19:10] <jimbaker> as in assigned
[19:10] <hazmat> jimbaker, sure.. but people need to self select what they want to tackle
[19:11] <jimbaker> hazmat, again sorry for my lack of clarity, this is what i meant
[19:11] <niemeyer> fwereade_: It's a bit late for you.. do you want me to handle the regex stuff?
[19:14] <jimbaker> hazmat, ok, i will do juju scp, low hanging and useful
[19:14] <hazmat> jimbaker, hmm.. thats actually a feature not a bug
[19:14] <hazmat> jimbaker, definitely would be nice, but we're trying to be feature freeze, bug fix only
[19:15] <hazmat> till next week and oneiric is out
[19:20] <jimbaker> hazmat, should this include branches that escaped review because they didn't have a milestone on it, like this trivial from SpamapS: https://code.launchpad.net/~clint-fewbar/juju/remove-default-ami/+merge/71278 ?
[19:20] <hazmat> jimbaker, i just push those to the correct milestone so they show up on the kanban
[19:21] <jimbaker> ok, i will mark the corresponding bug for eureka then
[19:22] <niemeyer> hazmat: hmm.. what's the next milestone's name? florence?
[19:22] <niemeyer> hazmat: I'll put the kanban to build
[19:22] <hazmat> niemeyer, yup
[19:22] <niemeyer> Cool
[19:30] <jimbaker> hazmat, i think we can do a fix released on bug 810648
[19:30] <_mup_> Bug #810648: The revision number in formula metadata is not very useful to users <juju:New> < https://launchpad.net/bugs/810648 >
[19:31] <hazmat> niemeyer, done
[19:32] <jimbaker> just passing through, this looks like a good feature for florence: bug 814974
[19:32] <_mup_> Bug #814974: config options need a "file" type <juju:New> < https://launchpad.net/bugs/814974 >
[19:32] <hazmat> niemeyer, actually i'm not sure
[19:32] <fwereade_> niemeyer, just back: everyone's asleep, and I'd find it relaxing, if you haven't already done it
[19:32] <hazmat> niemeyer, its still a problem for a regular deploy
[19:33] <hazmat> niemeyer, definitely addressed part of it
[19:33] <hazmat> niemeyer, it will silently use the already env stored formula ignoring the one on disk
[19:34] <hazmat> which may have newer changes
[19:34] <jimbaker> bug 816621 looks invalid to me, based on the comments
[19:34] <_mup_> Bug #816621: Juju doesn't appear to set up a complete environment while running the installation scripts and hooks <cloudfoundry:New> <juju:New> < https://launchpad.net/bugs/816621 >
[19:34] <niemeyer> fwereade_: Haven't started it yet
[19:35] <niemeyer> hazmat: Sorry, ECONTEXT
[19:35] <niemeyer> hazmat: What are you referring to again?
[19:36] <hazmat> oh.. sorry jimbaker mentioned it .. i lost econtext
[19:37] <jimbaker> hazmat, i'm not certain what the context is, either, since i mentioned a number of bugs here ;)
[19:38] <niemeyer> http://j.mp/juju-florence is up
[19:38] <hazmat> niemeyer, great, thanks
[19:39] <niemeyer> fwereade_: Please note I've suggested a follow up regex that has probably scrolled up already
[19:39] <niemeyer> fwereade_: I can dig it again if you want
[19:39] <niemeyer> fwereade_: It's slightly more restrictive than the initial suggestion
[19:39] <niemeyer> fwereade_: But avoids things like foo------bar
[19:39] <niemeyer> fwereade_: and foo-32-bar
[19:55] <jimbaker> still one usage of ensemble in trunk, debian/ensemble.docs - required to be that for any reason?
[20:49] <niemeyer> hazmat: have a sec for a quick review: http://paste.ubuntu.com/703602/
[20:50] <hazmat> niemeyer, is that the same regex from earlier today on the channel?
[20:51] <niemeyer> hazmat: It's the second one I mentioned in the channel
[20:51] <niemeyer> hazmat: Not the one you've run against existing formulas
[20:51] <niemeyer> hazmat: This is slightly more strict
[20:51] <niemeyer> hazmat: It forbids things like a--b
[20:51] <niemeyer> hazmat: and a-1-b
[20:51] <niemeyer> hazmat: But allows a1 and a1-b2
[20:52] <hazmat> but it allows n1-a1-n1 ?
[20:52] <niemeyer> hazmat: and even a1-2b
[20:52] <niemeyer> hazmat: Yeah
[20:52] <niemeyer> hazmat: Just the number can't be by itself without an accompanying char
[20:52] <niemeyer> hazmat: Nor can two dashes be seen next to each other
[20:52] <hazmat> niemeyer, sounds good, un momento going to try and break it ;-)
[20:52] <niemeyer> hazmat: Woot
[20:53] <niemeyer> hazmat: It forbids single letter names as well, which doesn't sound like a bad idea :-)
[20:54] <niemeyer> Hmm.. actually.. it does sound like a bad idea
[20:54] <niemeyer> Because it forbids a-foo
[20:54]  * niemeyer changes
[20:54] <niemeyer> hazmat: Just changed the first + to a *
[20:55] <hazmat> niemeyer, cool
[20:55] <hazmat> niemeyer, looks good, we should have this documented in the formula author guide as well
[20:56] <niemeyer> hazmat: Hmm.. maybe.. but at the same time we can just say "use sensible names" :)
[20:57] <hazmat> well lower case, must begin with a letter, can use numbers following letters, can use single hyphens between characters and numbers
[20:57] <hazmat> sensible is a state of mind ;-)
[21:00] <niemeyer> hazmat: Will mention it
[21:00] <niemeyer> (_formula_ author.. huh huh)
[21:02] <niemeyer> hazmat: http://paste.ubuntu.com/703606/
[21:02] <niemeyer> Hmm.. the revision should be taken out
[21:02]  * niemeyer does it
[21:03] <hazmat> niemeyer, sounds good
[21:03] <niemeyer> hazmat: http://paste.ubuntu.com/703607/
[21:03] <niemeyer> Cool, cowboying it
[21:03] <hazmat> niemeyer, this thing gets bigger by the second ;-)
[21:03] <hazmat> +1
[21:03] <niemeyer> hazmat: Yeah, I'll commit before this beast gets out of control!
[21:04] <hazmat> bcsaller, jimbaker if either of you have a moment, i'd appreciate a look over the local provider docs
[21:04] <hazmat> jimbaker, did rebooting after yanking that firewall software help?
[21:04] <jimbaker> hazmat, will do
[21:04] <jimbaker> hazmat, i didn't try a reboot
[21:04] <hazmat> https://code.launchpad.net/~hazmat/juju/local-provider-docs/+merge/78465
[21:06] <_mup_> juju/trunk r392 committed by gustavo@niemeyer.net
[21:06] <_mup_> Fixed charm name URL so that mambo5 works as a name. Also documented
[21:06] <_mup_> the name format and removed revision from docs.  [r=hazmat]
[21:07] <niemeyer> Stepping out for shaking the bones
[21:10] <jimbaker> hazmat, ok, i will try rebooting. after that, if it doesn't work, time to rtfm ;)
[21:10] <hazmat> jimbaker, you can probably verify pre reboot from sudo iptables --list
[21:11] <hazmat> rules which drop packets might be interferring
[21:21] <jimbaker> hazmat, hmmm, i guess it's possible these rules could cause issues - http://pastebin.ubuntu.com/703611/ - zk is running on the actual machine (so 192.168.0.106) iirc, whereas the agents are on lxc containers in the 192.168.122.0 network
[21:23] <jimbaker> let's try a reboot anyway...
[21:26] <jimbaker> back
[21:28] <jimbaker> time to get coffee, i will check the local deployment shortly
[22:02] <jimbaker> hazmat, guess what, the reboot worked this time
[22:02] <hazmat> jimbaker, sweet!
[22:03] <jimbaker> hazmat, i suppose the iptables settings are transitory, in how they are managed by firestarter
[22:03] <jimbaker> still need to rtfm, but definitely on the end of the queue now
[22:04] <_mup_> juju/trunk r393 committed by kapil.thangavelu@canonical.com
[22:04] <_mup_> merge config-set-sans-status [r=bcsaller,jimbaker][f=869289]
[22:04] <_mup_> Minor test optimization for config-set to get it under timeout threshold
[22:04] <_mup_> on low powered vhost used for automated test running.
[22:04] <jimbaker> hazmat, anyway, really glad we have the local stuff working, there were lots of branches involved, but the codebase specifically for local support is pretty minimal. nice.
[22:24] <_mup_> juju/safer-perms-on-juju-dir r393 committed by kapil.thangavelu@canonical.com
[22:24] <_mup_> update per review comments
[22:26] <Aram> hi.
[22:34] <hazmat> Aram, hi
[22:37] <_mup_> juju/trunk r394 committed by kapil.thangavelu@canonical.com
[22:37] <_mup_> merge safer-perms-on-juju-dir [r=bcsaller,jimbaker,niemeyer][f=869289]
[22:37] <_mup_> Tighten up permissions up on default creation of environments.yaml and ~/.juju dir.
[23:24] <hazmat> SpamapS, did you want to merge the removal of the deb packaging? i just pushed into the review queue.. but wanted to double check
[23:46] <hazmat> really need an interface repository
[23:50] <jimbaker> hazmat, i think we can mark this bug as fix released too: bug 810649
[23:50] <_mup_> Bug #810649: Revision number should be optional in metadata <juju:Confirmed> < https://launchpad.net/bugs/810649 >
[23:54] <hazmat> jimbaker, i realized its not quite the same
[23:55] <hazmat> jimbaker, the auto-increment stuff requires an upgrade
[23:55] <hazmat> jimbaker, common case is to just want to deploy a new service as you edit
[23:55] <hazmat> jimbaker, its probably as good as we'll have it for a little while though