[00:06] <_mup_> Bug #810808 was filed: Formula install hook never completes < https://launchpad.net/bugs/810808 > === franciscosouza_ is now known as franciscosouza === koolhead17|afk is now known as koolhead17 [07:56] Morning all [11:51] Morning kim0 :) [11:52] DigitalFlux: Morning o/ [11:52] what is the status of deploying Ensemble's formulas into LXC ? [11:52] an experimental branch exists .. however it's certainly not 'ready' [11:52] you can play freely on ec2 however .. launch micro instances :) [11:53] i'm guessing this one https://code.launchpad.net/~clint-fewbar/ensemble/lxc-container ? [11:53] yeah should be [11:53] yeah, that's my plan for today [11:53] what are you going to be working on [11:53] * DigitalFlux need to find where to configure ensemble to use micro instances .. [11:53] The Trac formula [11:53] oh I see [11:53] https://bugs.launchpad.net/principia/+bug/795480 [11:53] <_mup_> Bug #795480: Formula needed: Trac < https://launchpad.net/bugs/795480 > [11:53] yaay \o/ [11:54] let me help with configuring the t1.micro thing [11:54] kim0: please, go ahead [11:55] DigitalFlux: check out http://fewbar.com/2011/06/so-what-is-ensemble-anyway/ [11:55] search for m1.small [11:55] You need to add default-instance-type: m1.small [11:55] Ahh, that was a long article :) [11:55] * DigitalFlux checking .. [11:55] to ~/.ensemble/environments.yaml [11:55] in your case .. it would be t1.micro of course [11:55] hehe, looks like i already did that before :) [11:55] cool :) [11:55] default-instance-type: t1.micro [11:55] * kim0 nods [11:55] ok neat .. [11:56] * DigitalFlux coding his first Ensemble formula :) [11:56] \o/ [11:56] DigitalFlux: feel free to grab me any time once you have a question [11:56] kim0: i will indeed :), Thanks kim0 [12:03] RoAkSoAx: morning o/ [12:07] kim0: hmm, here is some point that i want to discuss [12:07] RoAkSoAx: I see you haven't added your cool session yet to https://wiki.ubuntu.com/UbuntuCloudDays/Timetable .. please add one today :) Thanks [12:07] DigitalFlux: shoot [12:08] kim0: so i looked over the current principia formulas [12:08] like in case of checking the wordpress formula [12:08] i see that not all the underlying components are obvious [12:08] like ? [12:09] where the web server layer is not that shiny here [12:09] you just install the wordpress package [12:09] i understand that this may get apache with the default config [12:09] but is this the perfect way to go .. from the prespective of code reuse ? [12:10] or will it better to create a separate apache formula and relate it to the wordpress formula ? [12:10] ah .. we just had this discussion yesterday :) [12:10] good question indeed [12:10] so basically .. Ensemble should be getting settable parameters soon [12:10] I think we're talking about CM vs. packaging here .. [12:11] which would let you choose which web server for example you'd like to use [12:11] setting the standards in this for Ensemble from the early beginning will solve a lot of formula 'styling' in the future BTW ! [12:11] the need is recognized .. the code is already sitting in review queue [12:11] good catch however [12:12] aha, awesome [12:13] wow, lots of hooks in mysql :) [12:13] my expectation is that the mysql formula will have the largest amount of hooks around :) [12:13] DigitalFlux: yes it is growing :) [12:14] DigitalFlux: you only need to worry about db-relation only for starters [12:15] kim0: well, i originally check it in order to know how it 'automatically' creates and hands random passwords for WP [12:15] * kim0 nods [12:15] kim0: I guess i should do that for Trac/SVN integration .. [12:15] although the beautiful part .. is you don't have to understand it [12:15] * DigitalFlux nods [12:22] Okie [12:22] How can i set some service config 'parameters' for some formula that should be deployed [12:22] like where i'm creating a Trac project here, how can i set it's name ? [12:23] good morning [12:24] hazmat: Morning o/ [12:24] DigitalFlux: that's the configuration stuff I talked about earlier, the one that is not ready yet .. for now hardcode some names [12:24] kim0: i see, ok, good to know, Thanks [12:26] * kim0 can't wait for the config-set stuff to land either ;) [12:29] bug 810765 [12:29] <_mup_> Bug #810765: if a formula in a repo has invalid metadata, it can stop any deploy from the repo. < https://launchpad.net/bugs/810765 > [12:41] <_mup_> ensemble/deploy-tolerates-broken-formulas-bug-810765 r276 committed by kapil.thangavelu@canonical.com [12:41] <_mup_> repository.find ignores invalid formula metadata. [12:49] I guess there is no Ubuntu EC2 images that can boot on instance-store micro-size, right / [12:49] ? [12:49] DigitalFlux, there are [12:49] only EBS .. [12:50] oh.. instance-store [12:50] DigitalFlux, ensemble tries to use ebs for all ec2 instances [12:50] it should work with instance-store instances though [12:50] hazmat: aha, i was just booting an instance manually for testing some stuff .. [12:51] you have to specify the image in default-image-id in environments.yaml [12:51] lets use the ebs then .. [12:51] hazmat: yeah, did that, Thanks :) [13:16] morning niemeyer, fwereade [13:16] hazmat: Yo! [13:16] hazmat: heyhey [13:17] how's it going? [13:17] Man, there's a beep-beep-beep going on here that is driving me crazy [13:18] hazmat: thanks for the review [13:18] hazmat: did you get a chance to think over my response? [13:18] fwereade, np, parts of it still digesting [13:18] as far i can see even though bootstrap code is reusable, it still needs modification on a per provider basis [13:19] at least to set the attribute [13:19] i'm still recovering from a bit of a cold the last few days.. i'll be glad when its gone [13:19] agreed, but that attribute does actually differ across providers [13:19] kim0: howdy! Yeah I'll do this weekend as I'm still unsure on what to do [13:19] the actual logic -- start a machine with specific variables if there isn't one running already -- is completely generic [13:20] fwereade, niemeyer last day of the sprint, any conclusions on cobbler integration? [13:20] and I'm concerned that if we subclass FooLaunchMachine every time we will end up with noticeable duplication [13:20] hazmat: we have something that runs for andres [13:21] fwereade, it doesn't need a subclass of launch machine to avoid the pre callback [13:21] I need to make sure I can duplicate it on my machine before I go [13:21] and then there'll be a fair amount of work before it's production-ready [13:21] but it feels like a good first sprint to me :) [13:21] hazmat: please explain [13:21] fwereade, cool, so there's another branch that does the cobbler integration? [13:22] fwereade, the bootstrap has the launch class, it can instantiate, get the variables, modify, and invoke start machine [13:22] hazmat: at the moment we have lp:~ensemble/ensemble/bootstrap-cobbler [13:23] hazmat: strongly disapprove of that approach, it makes it hard to change LaunchMachine without changing Bootstrap [13:23] fwereade, their already intimately connected [13:24] try changing the scripts output of launchmachine and you have to change them both [13:24] hazmat: fair point [13:24] hazmat: I have a half-formed idea that says that would be best addressed by making machine_data/variables more structured [13:25] its already invoking a public method of launchmachine, this just swithes it to another, cleanups up the data passing, and avoids pushing callback logic manipulating variables into multiple places [13:25] hazmat: so I *think* it's a data-format connection more than a code-flow connection [13:26] hazmat: well: it makes it call 2 methods, instead of passing one callback into one method [13:26] (good point about the unnecessary post_ callback, ty for that) [13:27] passing callbacks arounds obscures flow, its better to just invoke the method, consume the value, and invoke another method [13:28] hazmat: my issue is that that means duplicating the existing flow in LaunchMachine.run [13:28] if we change that, we also have to change bootstrap [13:29] however, if bootstrap is just using run on its own, which is tested separately, we can be confident that changes to LM that don't affect the interface to run won't affect bootstrap [13:29] fwereade, it means simplifying the flow in launch_machine.run. imo.. it removes the callback parameter insertion into the deferred chain [13:30] fwereade, start_machine is also a public method on LM, and tested [13:30] hazmat: ok, so the choice is between 2 simple flows, in different places, that have to stay the same; or one slightly-more-complex flow in just one place [13:31] fwereade, re the same, as i said, their already fairly intimately connected, simplifying the flow doesn't change that [13:33] hazmat: would your perception of the connections be different if variables was a custom object instead of a class? [13:34] hazmat: because I think the intimacy of that connection is a result of the unstructured nature of that data [13:35] hazmat: (besides, I thought you were the one arguing for a simpler flow? I'm advocating a slightly more complex flow that eschews duplication) [13:35] RoAkSoAx: okie thanks :) [13:36] fwereade, no re custom object, i think i've already stated why.. its the callback param to mutate data in a particular order that i take issue with [13:36] fwereade, we're talking about a single line of duplication [13:36] and we're removing several lines of complexity and the callback parameters [13:36] hazmat: well, 2 lines -- I agree it's not really a big issue [13:37] hazmat: but I've already removed one callback [13:38] so you seem to be arguing that: [13:38] if pre_start_machine is not None: [13:38] launch_chain.addCallback(pre_start_machine) [13:38] is excessively complex, and is better addressed by duplicating a simple flow [13:38] hazmat: is that an accurate statement of your position? [13:40] hazmat: What's that callback param that mutates data in particular order? [13:41] fwereade, i'm saying that variables = lm.get_machine_variables(); modify_variables(variables); do_something_with_variables();... is cleaner than.. do_something_else(modify_variables_callback) [13:41] hazmat: in isolation, yes [13:42] hazmat, fwereade: Where's that logic? [13:42] Just want to follow it [13:42] niemeyer, common.launch.LaunchMachine.run [13:42] ensemble.providers.common.launch [13:42] * niemeyer looks [13:43] I agree with hazmat, I think [13:43] Whoever runs run() can do anything before and after it, if needed [13:44] hazmat: Is that your point? [13:44] niemeyer, well i this case the before part is manipulating data internal to that method, the after part callback was already removed [13:45] hazmat: So what's your suggestion to address that data? [13:45] i'm saying the bootstrap can just get the data using the public api of the launchmachine, manipulate it, and call the start_machine api of it [13:45] niemeyer: but it's not soing stuff before run [13:45] niemeyer: it's before start_machine [13:46] hazmat: I think I may be starting to be convinced [13:46] fwereade: Yeah, got it [13:46] hazmat: but I'm still concerned that a change to LaunchMachine.run would require a non-obvious change to Bootstrap [13:47] Well.. [13:47] Hmm [13:47] fwereade, run shouldn't have any subclass responsibility, they need to implement start_machine.. and changes to the data would incur a need to change.. we need to trust the api we construct, not create holes in them so that the provider can hide from the consumer [13:48] That whole machine_data blob of unstructured data is pretty sad, to be honest [13:48] agreed [13:48] Who owns the data? [13:48] both cloud-init and the provider [13:48] If you invert it, get_machine_variables within LaunchMachine will have to take into consideration that someone else is setting packages [13:49] its constructed from api params, ensemble config, cloud-init defaults, and provider details [13:49] hazmat: Not really.. no one owns it.. we just pass it around, and everyone sticks the data in as if it was fine [13:49] IMO changes to the data are a red herring here, and we can all agree that a more structured solution would make life easier [13:49] This should really be a proper object, rather than a dictionary [13:50] (ok, the whole purpose of the code is to change the data, but it's the control flow we're debating) [13:50] fwereade: It is relevant.. if you just invert the order, it will break the logic [13:50] niemeyer: yes... I don't think I said otherwise [13:51] fwereade: You said it was a red herring.. I'm just saying it's relevant [13:53] So, yeah.. I suggest we don't address this change right now.. [13:53] We'll have to change the way in which these methods alter the data [13:54] and if we do this, we should really be using a structured object which has add_packages() methods and the such [13:54] so that we don't have to worry about who's doing what in which order [13:55] niemeyer, it doesn't really effect the discussion at hand.. because the underlying data here is ordered [13:55] I also agree with fwereade that it's a good thing we have a single place for the run() logic that starts a machine. [13:55] and its a discussion of the implementation used to effect that ordering, either hidden behind a callback from the consumer, or explicitly ordered by the consumer [13:56] Actually [13:56] Hmm [13:56] niemeyer: precisely, I don't know how run() is going to change in the future but I don't want to have to keep Bootstrap's reimplementation i sync [13:57] the actual api contract for the provider is start_machine, which is the same in either case.. the only purpose of run is to provide data before start_machine [13:57] bootstrap just does the same [13:57] imo [13:58] instead of obscuring flow with a callback only used by bootstrap, just make bootstrap provide the params [13:58] hazmat: that hadn't been my perspective but perhaps you're right [13:58] hazmat: No, the contract is really run [13:58] hazmat: I'd seen the get_machine_variables and start_machines methods as public just because we expect them to be overridden [13:58] hazmat: Hopefully the whole LaunchMachine thing can go away, and bootstrap should actually use provider.start_machine [13:59] hazmat, fwereade: All these variables that are being set in the pre_start_hook should really be injected upfront [13:59] hazmat: Passed to the method [14:00] hello [14:00] That would make it a single interface, without any ordering issues [14:00] i need some help! http://paste.ubuntu.com/644790/ [14:00] daker: Hey! [14:00] niemeyer: but for that we do need a more structured machine_data [14:01] basically just for the ordering of scripts [14:01] fwereade: Not necessarily.. as long as we change get_machine_variables within LaunchMachine to take into consideration that there's pre-exisitng data that may be meaningful, instead of blindly killing everything [14:01] which I freely stipluate is a mess, and has giant flashing lights saying "this will bite us in the future" [14:01] Which was my original point [14:01] niemeyer: ah, I see [14:02] niemeyer: but without structured machine_data I think we're still just shuffling the points at which we assume too much around the code [14:03] niemeyer, its not just pre-existing data, its data that needs to merged in particular order.. the underlying data structure here is a list, the bootstrap needs to have some of its elements added prior to the end of any machine .. to ensure the zk tree is initialized prior to the machine agent firing [14:03] daker: try: $PYTHONPATH=`pwd` ./bin/ensemble shutdow [14:03] hazmat: Yeah.. which is a terrible terrible interface [14:03] daker: try: $PYTHONPATH=`pwd` ./bin/ensemble shutdown [14:03] fwereade, niemeyer alternatively we could just have this as a flag to get machine variables [14:04] hazmat: and why I'm suggesting we don't touch this before we actually want to fix it properly [14:04] and pass that bootstrap flag to launchmachine.run or provider.start_machine [14:04] hazmat: This, specifically, should _really_ go away: [14:04] scripts = vars_out["scripts"] [14:04] machine_agent_script = scripts.pop() [14:04] scripts.extend([ [14:05] niemeyer, agreed [14:05] niemeyer, the best way to do that atm is to unify the data construction [14:05] and parameterize it with a bootstrap flag [14:05] hazmat: That sounds pretty good, actually [14:05] it exists the way it does due to its origin as a subclass method [14:05] RoAkSoAx, doesnt' work :/ No such file or directory [14:06] fwereade: ? [14:06] RoAkSoAx, http://paste.ubuntu.com/644795/ [14:06] hazmat, niemeyer: I think so... I was opposed to making B an LM subclass, because it isn't and LM... but I think it's fine to have LM know how to construct a zk instance specifically [14:07] yep, I think I like that a lot [14:07] cool [14:07] make that change and propose again? [14:08] we maintain machine_data ickiness but at least it's all in one inheritance tree ;) [14:08] fwereade, make that change, and just add a comment to the mp to that effect, i'll have a look and approve [14:08] fwereade, and it also gets rid of the callback param [14:08] cool, thanks very much [14:08] indeed :) [14:08] I was never proposing the callback as a perfect solution... just, to my mind, the least worst of the ones we'd considered :) [14:09] much appreciated [14:09] fwereade, np, thanks for discussing [14:09] * daker <= SOS [14:10] daker, your installing ensemble from bzr? [14:10] daker, we generally recommend people not developing ensemble code to just the ppa which is updated daily [14:10] daker, in this particular case its a PYTHONPATH issue [14:11] there was one from a ppa an i removed it [14:11] daker: remove the $ from $PYTHON.... [14:11] RoAkSoAx, ah [14:11] daker, RoAkSoAx suggestion looks good to me [14:11] with the $ removed [14:11] works thanks hazmat RoAkSoAx [14:16] hazmat, niemeyer: it crosses my mind that then the get_instance_id_command method then moves to LaunchMachine [14:20] fwereade, sounds good.. perhaps renamed get_bootstrap_instance_id() [14:21] one less provider subclass responsibility on bootstrap.. bootstrap becomes a true generic.. you could even move the launch class to the provider itself and make bootstrap truly generic [14:22] i guess bootstrap goes away entirely then [14:22] as a separate command cls [14:29] hazmat: precisely, I was abut to write exactly that before I got distracted :) [14:29] hazmat: and you may be right about it going away entriely [14:29] hazmat: cool :) [14:30] Woohay things going away entirely [14:31] there's nothing quite so nice as deleting code :) [14:31] anyway all that will have to wait until I have a working cobbler environment [14:31] which I need before I go away from andres [14:31] but I think we have a plan :) [14:34] hazmat, niemeyer: although that actually implies a common MachineProvider base class with a .bootstrap() method [14:34] ...which then implies that actually a *lot* of methods can be defined on the base class [14:34] fwereade: Hm? [14:34] fwereade: I don't see how one thing implies the other [14:35] niemeyer: hmm, perhaps not, just a sec [14:39] niemeyer: agreed, not implied; we'll see how it looks when we have 2 implementations [14:41] kirkland: I agree (wrt. figuring out who is working on what in principia) [14:42] jcastro: well, that, and an easy way to see what's currently in principia [14:42] jcastro: an equivalent of apt-cache search [14:42] kirkland: any idea when the whole repository will get hooked up? [14:42] (heh, that's exactly what I was going to ask, apt-cache search) [14:43] jcastro: I've heard Launchpad is going to land the needed changes this week [14:43] jcastro: Work starts immediately [14:43] oh, perfect, that's great timing. [14:43] jcastro: and yeah, we'll have ensemble search :) [14:43] Oh, and it's Friday.. maybe it's even there arleady [14:44] * robbiew notes we need to sort out "principia" as a name [14:44] jcastro: dunno, SpamapS was on that [14:44] ok I'll ping him when he's around [14:44] robbiew: I thought we're just going with "ensemble formulas"? [14:44] and "ensemble core"? [14:48] jcastro: well the thread didn't really conclude...so maybe I'll do that now [14:48] ;) [14:52] kim0, check now https://code.launchpad.net/~daker/ensemble/small-fix/+merge/68038 [14:53] jcastro: not so sure we need an "Ensemble core"..."Ensemble" is fine, imo [14:53] * jcastro nods [14:56] * kim0 disk seems to be dying [14:58] hey guys *waves* [14:58] is there anywhere that we'll keep versions of Ensemble in a tar archive? [14:58] finishing my macports implementation of the Ensemble client :) [15:04] lynxman, you mean like a release of ensemble. or a release of formulas? [15:06] hazmat: release of ensemble, the port need somewhere to download a tar from [15:07] lynxman: awesome... tons of devs on mac using ubuntu in the cloud [15:07] m_3: that's the idea :) hit first and hit nicely [15:07] lynxman, any chance it could construct one on the fly with a bzr export? [15:07] hazmat: hmm you'll be making my life miserable doing that :) [15:08] hazmat: that would mean installing bzr then pulling and so forth, completely foreign to how ports works [15:08] lynxman, atm we don't have a release.. is my only concern.. i think we where planning on having one in the next few months to coincide with the release of oneiric [15:08] lynxman, right.. but there are ports that pull from vcs i thought? [15:08] hazmat: yes but they do nasty stuff [15:08] niemeyer, release time? ^ [15:08] hazmat: just saying it out loud :) [15:09] niemeyer, this actually dove tails nicely with what robbiew was mentioning about setting some sort of more stable weekly release [15:09] hazmat: robbiew was talking about the sync into Oneiric, IIRC [15:09] hazmat: oh, that's true [15:09] hazmat: We can do a weekly release, though [15:10] right...and sync them into Oneiric ;) [15:10] niemeyer: would be okay to get a tar.gz in the ensemble project for the last milestone? [15:10] niemeyer: that would be easy for me to parse [15:11] lynxman: We can do tarballs for sure.. what do you mean by last milestone? [15:11] robbiew, hazmat: Yeah, good point [15:12] lynxman, trunk is stable so we can cut directly from it [15:12] robbiew, hazmat: My point was just that we don't need release tarballs to sync [15:12] ack [15:12] robbiew, hazmat: But might be interesting to be more careful about what is going into Oneiric either way [15:12] does setup.py produce a good dist output? [15:12] niemeyer: I mean looking at the ensemble project page, right now last milestone is capetown [15:12] niemeyer: something like that [15:12] * SpamapS just emailed the list with his weekly release plans [15:12] SpamapS: bzr export --format=.tar.gz [15:13] niemeyer: *OH* right.. thats much simpler. :) [15:13] lynxman: CUrrent one is Dublin [15:13] lynxman: WE should update it [15:13] niemeyer: so.. dublin :) [15:13] SpamapS, it should [15:13] lynxman: It's pretty old [15:13] niemeyer: at this point, with Oneiric 3 months away, would it make sense to make the next milestone "orlando-2" ? [15:13] lynxman: I mean, the last one [15:14] lynxman: I'd recommend bzr export --format=.tar.gz [15:14] or austin? :) [15:14] lynxman: To get going [15:14] next release name.. startswith 'E', dublin release ends at the end of july afaicr [15:14] SpamapS: We'll need something with an E :-) [15:14] oh you guys have *got* to stop using the cities we're in [15:14] that is *CONFUSING* [15:14] I remember now you explained that already [15:14] dublin was coincidence [15:15] SpamapS: It's actually the opposite [15:15] niemeyer: yeah, the thing is that I can either curl a tar from somewhere (what I was asking at first) or go around doing a whole bzr export, was asking which is better for you guys [15:15] SpamapS: Canonical should stop putting sprints in our milestone names! [15:15] * SpamapS votes for Entendre as the next release name.. 'ensemble entendre' has a nice french comedic ring to it [15:15] SpamapS: ;-) [15:15] SpamapS: maybe Ecublens? It's a nice city in the French part of Switzerland ;) [15:16] http://maps.google.com/maps?hl=en&q=ecublens%2C%20ch [15:17] it's where the EPFL is based [15:18] Ooo I like lynxman's [15:18] * SpamapS dreams of swiss beer and pretzls [15:20] niemeyer: so you prefer a bzr branch then... just from trunk? [15:22] niemeyer: to lnxman's point, it would be prudent to start branching trunk when a new milestone is started... [15:22] lynxman: Just while we don't have actual releases, that would be preferable [15:22] niemeyer: okay, will try to make it that way, thanks [15:22] Once there are releases.. it will be critical... but yeah, w/o a release, they're just points in time. [15:22] SpamapS: Not necessarily.. milestones are more organizational than anything else [15:22] SpamapS: Weekly releases with proper tagging should be enough [15:23] should we just tag w/ the date? 0.5.2011.07.15 ? [15:25] SpamapS: Probably just a sequence number on the version itself might be fine [15:25] SpamapS: We always have the date out of the revision information [15:25] I actually like the way it works now.. 0.5+bzrXXX [15:25] because its very clear how to go get that release [15:25] SpamapS: Well, we might also do this [15:25] SpamapS: Using the revision number [15:25] SpamapS: 0.5.XXX [15:26] thats what XXX is [15:26] oh [15:26] the only reason I don't like that, is that its pretending to be a release [15:26] LOL [15:26] SpamapS: It's not just pretending.. ;) [15:26] or at least, pretending to be more of a release than the 0.5 already is pretending [15:26] SpamapS: It _is_ a release [15:27] * SpamapS thinks a massage is a nice release too.. :) [15:27] yeah.. its really not that important... [15:27] Oh I was thinking on one other thing.. [15:27] how about dropping the debian dir from the trunk and nesting the Ubuntu packaging for the daily builds? [15:28] Would be good to have a single place for packaging maintenance. [15:28] SpamapS, sounds good to me.. the ec2-build script should probably get yanked then [15:29] hazmat: is that used anymore? [15:42] SpamapS, nope [16:04] Alright folks .. my disk drive decided to die now, seems like I'll begin a badblocks party .. I'm off next week, so may not be online all the time. see you soon [16:12] SpamapS, niemeyer, hazmat, m_3, anyone: why is this happening. I need help on this. https://pastebin.canonical.com/49825/ [16:13] negronjl: IIRC, there's a bug where if any of the formulas in your repository have bad metadata, none of them are deployable. [16:13] SpamapS: I fixed that already. this is different. [16:13] oh [16:13] * SpamapS waits for the second timeout-refresh of pastebin [16:13] negronjl, we really need the debug log to see what's going on [16:14] maybe the start hook failed? [16:14] or is still running? [16:14] negronjl, also, i think it would be best if we used paste.ubuntu.com [16:14] jimbaker. ahh...let me re-do it all with debug-hooks, debug-log and pastebin.ubuntu.com ... I'll be back [16:15] negronjl, i don't think you need debug-hooks yet :) [16:15] negronjl: you can just ssh to the box and look at the formula.log [16:15] SpamapS: re-doing it. I'll get all that info in a minute. [16:16] negronjl: /var/lib/ensemble/units/cloudfoundry-server-0/formula.log [16:16] negronjl, SpamapS is right... that's all debug-log is doing is aggregating the logs together [16:17] in fact one problem with debug-log is that it misses some log info... but as far as i know, just very early in the agent startup process now [16:17] negronjl: Best way to find out is log in the machine and read the log [16:17] niemeyer: doing that now :) [16:17] I'll paste it back in a minute [16:17] negronjl: We have to create a neat way to just find out the recent logs [16:17] negronjl: Not really hard.. just need to put it in place [16:17] negronjl: Would be tremendously helpful in these cases indeed [16:18] some helpers would do that [16:19] sudo 'ensemble-admin tail-logs' would work [16:20] SpamapS, sounds like an after the fact debug-log [16:22] SpamapS, in general i always run debug-log, might be nice if we made it easier to use, eg, ensemble bootstrap --debug to start debugging immediately [16:22] can debug-log take an arg for unit? [16:23] however, the debug log was never designed to be more than a simple solution for formula dev. some sort of log collection tool would be nice to have integrated at some point (to bring back some previous discussion we've had) [16:24] m_3: yeah [16:25] jimbaker: if it were changed to a ring buffer and always done.. then debug-log would just tap into the ring buffer and keep tailing it. [16:25] m_3, it's quite flexible: ensemble debug-log --help http://paste.ubuntu.com/644868/ [16:25] jimbaker: think 'dmesg' [16:27] ok, didn't register that include/exclude took unit-names [16:28] think maybe the solution to _that_ problem is more coffee [16:30] Here is the pastebin for the formula.log: http://pastebin.ubuntu.com/644870/ [16:32]