[00:02] indeed very sad news about steve jobs [01:11] Cool: http://wtf.labix.org/ [01:29] sadness [01:30] niemeyer, having some problems building go-tip [01:30] oh well [01:30] hazmat: What's up [01:30] ? [01:31] it error'd out. cleaned and retrying [01:32] niemeyer, http://pastebin.ubuntu.com/703116/ [01:32] Reading [01:32] looks like it failed the acceptance tests [01:32] * hazmat tries to figure out scrollback buffers in tmux [01:32] hazmat: It's missing the start of the traceback [01:33] hazmat: Where the actual reason is mentioned [01:33] hazmat: Hmm.. I'm not sure.. I've changed my keys [01:33] hazmat: Mine is CTRL-X PGUP [01:33] Where X is the tmux special key [01:35] hmm... maybe its confused by the pkg being installed [01:37] niemeyer, full traceback http://paste.ubuntu.com/703119/ [01:37] hmm.. not full [01:38] hazmat: Strange error that is [01:38] hazmat: Looking at the code [01:38] hazmat: Can you please paste the contents of your /proc/net/igmp [01:42] niemeyer, http://paste.ubuntu.com/703122/ [01:43] jimbaker, i think your problems might be related to firewalling.. perhaps the firestarter pkg [01:45] * hazmat falls asleep [01:45] hazmat: Looks fine.. we can figure it tomorrow [01:46] hazmat: Today was already most excellent :-) [01:46] hazmat: We even have a clean wtf: http://wtf.labix.org/ [03:05] 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] 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] err, tomorrow [08:39] moring - I got my local juju environment working with bscaller's patch for dns resolution [08:39] nice [08:40] just killed my laptop but runing to many cassandra units -ooops [09:00] 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 < https://launchpad.net/bugs/855989 > [11:46] nice, lxc deployment works great! [11:48] wordpress connects woohoo This is so awesome \o/ [12:04] kim0, nice! [12:04] hazmat: this is great man :) [12:04] kim0, indeed, much more fun [12:04] 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] hazmat: yes .. to actually get this lxc stuff working, I had to add revision: to metadata.yaml of some charms [12:05] kim0, hmm.. really? what was the error? [12:06] the version separation should have been backwards compatible [12:06] 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] 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] i'm not even sure what that php charm is supposed to be doing [12:07] 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] all charms in local "repo" .. were being checked [12:07] fwereade_, ^ [12:07] yeah.. the revision got moved to a separate file [12:07] so like, echo 1 > revision ? [12:08] then it needs that file added to trunk I suppose [12:08] kim0, it should have already been on trunk, which is why i'm curious [12:08] * hazmat tries it out [12:09] hazmat: I'm on 388 from ppa, too old ? [12:09] hmm [12:10] 388 doesn't have the auto upgrade work, and it shouldn't have changes to revision in the charm metadata [12:12] 388 works for me, trying again with trunk [12:12] yeah.. both seem fine [12:31] weird [12:38] hazmat, kim0: oh crap [12:38] fwereade_, i couldn't reproduce it [12:39] hazmat: it doesn't, indeed, look like it should happen [12:39] i should try the package just to be sure [12:40] hazmat, kim0: the "required value not found" implies that some of the code is out of date -- before I made that optional [12:40] fwereade_: that's the pkg: 0.5+bzr388-1juju1~oneiric1 [12:41] 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] hazmat: I guess this was another instance in which I should have rebuilt the PA as soon as it landed? [12:41] cool .. if anyone can force a pkg rebuild, I'd love to test again [12:42] fwereade_, i'm not sure why.. was there a rev that hit trunk that would be broken? [12:42] afaik no [12:42] kim0, sure, i'm just testing out the pkg first [12:42] great [12:42] hazmat: likewise, but we knew that 389 wouldn't work with <=388, so anything that would cause mixed code could trigger it [12:43] fwereade_, yeah.. but this is all client side [12:43] hazmat: oh [12:44] hazmat: I guess the old code won't work with a new-style charm, though [12:44] kim0: where are the charms coming from? [12:44] hmm [12:44] kim0, are you using charms from version control and pkg from ppa? [12:44] fwereade_: yeah .. charms are from trunk [12:44] yes [12:44] kim0: bingo [12:44] you got it [12:44] fwereade_, nice catch [12:44] I thought it would be a tiny difference :) [12:45] * hazmat rebuilds the ppa [12:45] looks like someone beat me to it [12:47] 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] kim0, it will whine at you a little but that's it [12:47] cool! fwereade_ great work :) [12:47] I hated manual versions too hehe [12:47] kim0: (for reference: when both exist, the revision file overrides the value in metadata) [12:47] got it [12:47] kim0, cheers :) [12:47] :) [13:03] Looks like r388 builds w/ clean unit tests in my PPA .. [13:16] SpamapS: are you in your room or in this big room? [13:20] jcastro: in keynotes now [13:22] jcastro: I think I'll head back up to the room shortly tho [13:32] morning niemeyer [13:34] fwereade_! [13:34] hmm.. reflowing text is more involved than i'd hoped [13:34] hazmat: Hm? [13:34] hazmat: Good morning :) [13:34] niemeyer, good morning.. doing a display of the schema [13:34] but their are newlines in the description which break up the formatting [13:35] and then i came across this.. http://www.koders.com/python/fid7886C337B44AD65C83D334544E6CA3E4FBB7E050.aspx?s=timer [13:35] which is a unicode aware reflow impl [13:35] actually its not unicode aware [13:35] hmm.. maybe it is.. but its still way more than i want [13:37] 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] Still waiting for the link to load, so I'm not sure about what this is really about yet [13:38] hazmat: I'm lacking context I guess.. why are we getting into reflowing text at all? [13:39] 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] i'm using some indentation + newline to separate options, but the description field is freeform [13:40] and breaks up the formatting [13:40] * hazmat goes for a punt and some newline separation for context [13:41] niemeyer, pls ignore -> server time :-) [13:42] hazmat: Sorry, but why aren't we simply dumping the config.yaml? [13:42] niemeyer, try.. a pretty print on a dictionary with values that have embedded new line.. it ends up on a single line [13:42] hazmat: Ok.. let me try.. $ cat config.yaml.. yeah, looks good? [13:43] hmm [13:43] i guess i could try pretty printing with yaml instead of the python dict [13:47] no.. still looks pretty bad [13:49] niemeyer, http://paste.ubuntu.com/703396/ [13:50] first one is yaml dump with indent=4, second one is manually printing [13:50] keep in mind the data is not from file on disk but from the charm state [13:55] niemeyer: do we expect anything else to land after r388 ? [13:55] SpamapS, i'd use 391 as a base [13:56] 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] SpamapS: Yeah, 391 is the current base [13:56] SpamapS: My hope is that we'll be looking after bug fixes now only [13:56] hazmat: The yaml there isn't right.. [13:56] hazmat: It looks ugly because it's inlining the values [13:57] hazmat: plugin: {description: [13:57] oh ok [13:57] hazmat: It can do much better than that automatically [13:58] niemeyer, that was with yaml.dump(schema_dict, indent=4) .. the docs on pyaml aren't very helpful [13:58] 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] hazmat: Let me look [13:58] i'll try.. maybe turning off the default flow style [13:58] * SpamapS triggers rebuild w/ r391 [13:59] hazmat: I know because I've tweaked the printing in goyaml [13:59] hazmat: Which is backed by the same code [14:00] really a ton of buzz this week around juju [14:00] niemeyer, i switched to 'default_flow_style' off.. http://paste.ubuntu.com/703402/ [14:00] which gets the key on a separate line, but is still less useable than doing it by hand [14:01] imo [14:02] 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] niemeyer, its just printing k,v in a dict [14:03] niemeyer, we loose the user formatting when we serialize to the charm config node [14:03] hazmat: Hint: your manual yaml is broken. [14:03] niemeyer, i'm not trying to print yaml.. i'm trying to print human consumable info [14:04] hazmat: Which we've agreed to print in yaml so far? [14:04] in an easy to digest and normal fashion [14:06] 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] niemeyer, fair enough [14:07] 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] niemeyer, does yaml guarantee key ordering? [14:08] hazmat: IIRC, maps should not assume a defined ordering [14:09] hazmat: There are ordered maps as well, IIRC, but we're not using them [14:10] hazmat: WEll.. there's probably _anything_ you can imagine in yaml, unfortunately :-) [14:10] It's the only place I've ever seen a convention for base-60 floats (!) [14:11] r391 building in PPA https://code.launchpad.net/~clint-fewbar/+archive/fixes/+build/2826656 [14:11] 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] hazmat: I suspect it's key-sorting on dump, but I'm not sure [14:12] SpamapS, i hand't noticed that streaming build log before, nice [14:12] yeah, keeps me from angrily pacing [14:15] Wow.. [14:16] http://blog.golang.org/2011/10/preview-of-go-version-1.html [14:18] niemeyer: lots of tasty changes there. [14:56] 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] niemeyer: what, if anything, should I be doing about it? [14:56] fwereade_, eureka is still open for bug fixes [14:56] new feature dev is on florence [14:56] hazmat: ah, cool, thanks [14:56] fwereade_: What hazmat says [14:58] 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] niemeyer, also we'll need a new kanban [14:58] niemeyer: also, lp:~fwereade/juju/charm-store-hack appears to work [14:58] niemeyer: python juju/charm/store -r REPO -k KEY -c CERT -p PORT [14:59] niemeyer: and edit juju.charm.repository to construct a RemoteCharmRepository with the appropriate url base [14:59] niemeyer: [edit] python juju/charm/store.py -r REPO -k KEY -c CERT -p PORT [15:02] fwereade_, nice [15:03] fwereade_: Wow, sweet! [15:04] 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] https://launchpadlibrarian.net/82132481/buildlog_ubuntu-oneiric-i386.juju_0.5%2Bbzr391-1juju1~oneiric1_FAILEDTOBUILD.txt.gz [15:05] buildd failures for 391 [15:06] looks like a timeout.. [15:08] SpamapS: Indeed [15:08] SpamapS: Worth a retry [15:08] SpamapS: The wtf is clean for a while, FWIW [15:09] SpamapS: http://wtf.labix.org/ [15:12] niemeyer: yeah I don't even try the builds until that is "OK" [15:13] SpamapS: Sweet [15:14] morning/afternoon all [15:15] I'm having issues with charm where the charm name contains a number [15:15] for example - cassandra is fine - but tomcat7 errors [15:15] Message: Bad charm URL 'local:oneiric/tomcat7': invalid name (URL inferred from 'local:tomcat7') [15:17] jamespage: I suspect this is a bug in the regex.. rog actually brought that up.. /me checks [15:19] jamespage: Yeah, it's bogus, sorry about that.. we'll fix [15:20] niemeyer; ta [15:23] niemeyer, it's not necessarily *quite* as simple as that [15:23] niemeyer: sorry, I mentioned that in an MP discussion somewhere [15:23] fwereade_: It's not? [15:24] 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] SpamapS, i've been able to run that test a couple hundred times, haven't reproduced [15:24] niemeyer: cs:oneiric/foobar-7 [15:24] fwereade_: That sounds trivial [15:24] hazmat: given that its building on a virtual host... could just be that it needs a slightly higher timeout. [15:24] niemeyer: well, it is really [15:24] :-) [15:25] 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] SpamapS, ie. it would always timeout with that circumstance regardless of timeout length [15:25] niemeyer: it's just that I reverted to the original regex when I noticed, pending further discussion, which I guess got lost [15:26] fwereade_: I lost it as well in the buzz, but I'll put another regex in place.. hold on [15:26] SpamapS, hmm.. actually you might be right, its a 2.6 second test as is [15:26] SpamapS, the timeout is causing the deferred to fire early [15:27] 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 < https://launchpad.net/bugs/869272 > [15:29] niemeyer: target to eureka, right? [15:30] fwereade_: Yeah [15:30] 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] fwereade_, hazmat, SpamapS, jamespage: Is this right: [15:36] "^[a-z]+([a-z0-9-]+[a-z][a-z0-9]*)?$" [15:37] niemeyer: I *think* so, but I haven't written any tests yet :p [15:38] fwereade_: Cool, can you take this over? [15:38] niemeyer: I intend to, but I need to pop out for a while in about 1 minute [15:38] works for the formulas i have locally [15:39] * hazmat tries to remember the url to the latest charms from lp [15:39] https://api.launchpad.net/devel/charm?ws.op=getBranchTips [15:39] niemeyer: I'll fix CharmURL when I get back [15:39] fwereade_: Thanks! [15:39] laters [15:43] niemeyer, works against all the extant charms on lp [15:44] 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] should the expose/unexpose commands have context with the local provider? I assume not as they make no difference :-) [15:47] jamespage, they are not meaningful for the local provider [15:48] jimbaker: ack - thanks for the confirmation [15:49] jamespage, they don't [15:50] <_mup_> Bug #869289 was filed: Simplify config set tests to reduce runtime significantly. < https://launchpad.net/bugs/869289 > [15:50] SpamapS, just put a MP into the queue which should reduce the runtime of those tests by 6x [15:50] 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] 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] hazmat, i was about to ask about those commented-out bits ;) [15:57] 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] rog, would you mind have a look niemeyer's go branches in review ? [15:59] negronjl: +1, but I'd like to specify image-id and instance-type in charm metadata [15:59] m_3: I like that idea too :) [15:59] hazmat: sure. where do i find them? [15:59] negronjl: what I've been doing to solve that is just adding logic around `lsb_release -cs` in the charm [15:59] rog, http://j.mp/juju-eureka [16:00] 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] hazmat: Thanks. Is it somewhere in your roadmap? Do you know of any work-around to accomplish this ? [16:04] fwereade_, hazmat: Hmm.. was just thinking over lunch we might do something slightly more restrictive [16:05] * niemeyer hacks something quick [16:05] 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] atm [16:06] hazmat: ok. that's too bad but, thanks for the info. [16:07] negronjl: Yes, charms are specific to a given Ubuntu series [16:07] fwereade_: In fact, we'll have to address a missing aspect in that regard, I think.. [16:08] negronjl, atm the only way to address is via default-image-id modified between deploys [16:08] hazmat, fwereade_: "^[a-z][a-z0-9]+(-[a-z0-9]*[a-z][a-z0-9]*)*$" [16:08] niemeyer, yeah.. atm charm series doesn't actually correspond to an image launch against a series afaics [16:09] hazmat: Yeah, but the idea is really to use the charm URL series for that [16:09] 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] hazmat: It's not a big deal since there's a single one today, but that's definitely the intention [16:09] negronjl: The ami-id will come out of the charm URL series [16:10] negronjl: Size, etc, is a different issue we'll have to address [16:10] Anyway.. must go back to lunch, just wanted to propose the regex before fwereade_ worked on it [16:11] niemeyer: thx for the info [16:11] 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] :-) [16:13] 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] hazmat: It is the problem in that the model is not suitable yet [16:35] 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] hazmat, niemeyer: reviews done [17:23] rog, awesome thanks [17:24] rog, via email? [17:24] i replied on the comment form. doesn't that send an email to interested parties? [17:25] hazmat: ^ [17:26] 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] i missed it cause i was scanning the top of the merge proposal for votes [17:28] done [17:31] rog: [17:31] parts = append([]string{dir.Path}, parts...) [17:31] appending to parts directly is bad behaviour because [17:31] it could interfere with any callers that call join [17:32] rog: I'm not really sure about what you mean there? [17:32] niemeyer: parts is an argument to the function. append has side effects. [17:32] rog: This example has absolutely no side effects.. I don't really get what you mean [17:34] niemeyer: doh, sorry, i'd read it wrong [17:34] ignore! [17:35] rog: Phew, cool, np :) [17:37] rog: "Seems to me like the body of this loop would be better" [17:37] rog: Good idea there, thanks [17:39] morning [17:39] Zeelot: Morning! [18:01] ok, a little question. i'm trying to trace through juju actions on bootstrap. [18:01] 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] 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] is this all just preference of how we want to manage our instances? [18:02] but that function just seems to return a list of machines - how does the bootstrap process actually get initiated? [18:03] (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] Zeelot: php+apache sounds fine.. I'd put couchdb and rabbitmq in separate charms [18:03] 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] what am i missing? [18:04] rog: Let me check [18:06] rog: Hmm [18:06] 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] 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] rog: The bootstrap method in base.py calls Bootstrap.run, which does more than that [18:07] Zeelot: juju deploys on EC2, OpenStack, Cobbler/Orchestra (physical), and locally through LXC [18:07] 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] alright, I'll have to look at those other things then because I'm not sure what they are :) thanks [18:08] 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] Zeelot: juju is very different from chef and puppet, though [18:09] 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] Zeelot: Yeah, that's juju! :) [18:09] juju looks like a much more complete solution to deploying to ec2 [18:09] Zeelot: Not only set up the VMs, but we're working on the full orchestration experience [18:09] Zeelot: Reusable building blocks a command away [18:09] excellent [18:10] Zeelot: and scaling up and down, recovery, etc etc [18:10] Zeelot: There's a lot to do still, of course, but the future looks unlike anything else out there [18:11] niemeyer: i can't see where the actual machine is bootstrapped. is it as a side-effect of find_zookeepers ? [18:11] rog: Just follow the pipeline [18:11] i'm trying! [18:11] machines = self._provider.get_zookeeper_machines() [18:11] ... [18:11] machines.addErrback(self._on_no_machines_found) [18:11] 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] rog: What happens on no_machines_found? [18:12] * rog groans. [18:12] Zeelot, docs are pending in the merge queue, but theirs a message on the mailing list which goes through the basics [18:12] that's a bit gross [18:12] rog: Yeah, I'm happy you're unhappy about it [18:12] no wonder i couldn't see it [18:12] alright, thanks [18:12] Zeelot, https://lists.ubuntu.com/archives/juju/2011-October/000844.html [18:13] Zeelot, complete example of config in this one.. https://lists.ubuntu.com/archives/juju/2011-October/000847.html [18:13] Zeelot, that should work fine in a vm as well [18:13] awesome [18:14] looks like I need to learn about LXC first [18:17] Zeelot, its basically os level namespacing for isolation.. a jail or chroot on steroids... much less overhead than full virtualization [18:18] hmm, is it possible to use a VM like virtualbox? Mostly a requirement for the developers that work on windows or mac [18:18] Zeelot, just to be clear its not for setting up vms, its for a setting up a vm from inside the vm [18:18] ah, then that's probably fine [18:18] it will do isolation of the different services within the vm using lxc [18:19] interesting [18:19] its mostly meant for ubuntu physical machines, but it works fine in a virtual machine [18:19] 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] 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] thanks for the info [18:38] 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] but as you see here, it's currently quite convoluted and requires a twisted way of thinking, so to speak [18:44] jimbaker: i still can't quite see what's going on. ahhh, the crux is returnValue, i think i see now [18:45] oh, no, i still don't see it [18:46] rog, i'd be happy to walk you through it [18:46] actually, i *think* i see it. [18:46] 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] rog, yeah, the logic is certainly more convoluted than what would pass a review now imho [18:48] rog, also the use of the command pattern with the run, vs just having a function is something that is not helpful [18:48] rog: Which callback is added that is known to return an error? [18:48] jimbaker: couldn't you just yield launch_machine or something? [18:49] _on_machines_found [18:50] rog, there is nothing in Bootstrap that couldn't just be a single inlineCallbacks function, correct [18:50] 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] rog: _on_machines_found doesn't return an error [18:50] niemeyer: oh. so why does errBack get called? [18:51] rog: errback gets called on errors [18:51] niemeyer: so where's the error coming from? [18:51] niemeyer: because without an error, nothing happens, right? [18:51] rog: Take a moment to read this: http://twistedmatrix.com/documents/current/core/howto/defer.html [18:51] the errback is called from get_zookeeper_machines [18:51] rog: It will help you a lot in your understanding of the code base [18:51] or i should say, because of it :) [18:52] so machines in the run function is a Deferred [18:52] yes, because of returnValue, right? [18:52] which is why we can call addCallback and addErrback, yes? [18:52] rog, looking at its definition, but not because of returnValue [18:52] oh [18:53] that's just a convention required by the inlineCallbacks decorator [18:53] rog: returnValue is a hack related to inlineCallbacks [18:53] machines = [] [18:53] does that make a deferred value? [18:53] oh, findZooKeepers is inlineCallbacks [18:53] 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] i'm used to seeing inlineCallbacks functions yield things rather than returning them [18:54] yeah.. its syntatic sugar using python generators under the hood [18:54] rog, yes, findZookeeper uses the inlineCallbacks decorator. so it wraps the function such that its invocation returns a Deferred [18:54] that Deferred in turn is returned (trivially) by get_zookeeper_machines [18:54] rog: returnValue raises an exception that is caught by the inlineCallback decorator to stop the generator [18:55] jimbaker: yes, i think i kind of understand that (although i haven't read that document) [18:55] rog: It's a "return" from a generator, because generators can't return [18:55] ah ok. i see. lovely stuff. [18:55] rog: I'd call it syntatic salt [18:55] rog, i highly recommend just looking at the source code of inlineCallbacks, it's pretty straightforward code [18:55] rofl [18:55] in the sense that setting up trampolines can be [18:56] jimbaker: WHAT? [18:56] jimbaker: i will some time. i get the principle. [18:56] ROTFL [18:58] it's a kinda beautiful subversion of a few language features [18:58] 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]