[00:56] kim0, i was curious where the log of last weeks cloud-meeting was at [01:21] hazmat: http://irclogs.ubuntu.com/2011/04/13/%23ubuntu-cloud.html#t19:01 and summary at http://foss-boss.blogspot.com/2011/04/ensemble-cloud-community-meeting_14.html [02:07] kim0, awesome thanks! [02:07] <_mup_> Bug #766721 was filed: upgrade hook should get access to previous and new versions numbers of the formula < https://launchpad.net/bugs/766721 > [03:20] <_mup_> ensemble/config-state-manager r197 committed by bcsaller@gmail.com [03:20] <_mup_> merge trunk [03:52] <_mup_> ensemble/expose-1-dummy-provider r200 committed by jim.baker@canonical.com [03:52] <_mup_> Dummy provider support for exposing ports [03:52] <_mup_> ensemble/expose-1-dummy-provider r201 committed by jim.baker@canonical.com [03:52] <_mup_> Merged trunk [03:56] <_mup_> ensemble/expose-1-dummy-provider r202 committed by jim.baker@canonical.com [03:56] <_mup_> Test code path on unexposing ports in dummy provider [10:40] g'morning [11:27] <_mup_> ensemble/natty-image r189 committed by kapil.thangavelu@canonical.com [11:27] <_mup_> add a wait to ensure ssh is available, bump default image to natty daily from 20-4-2010 [11:27] <_mup_> ensemble/natty-image r190 committed by kapil.thangavelu@canonical.com [11:27] <_mup_> merge trunk [11:28] <_mup_> Bug #767021 was filed: Use natty machine image < https://launchpad.net/bugs/767021 > [12:05] <_mup_> ensemble/resolved-state-api r187 committed by kapil.thangavelu@canonical.com [12:05] <_mup_> move is relation running api, up stack [12:17] <_mup_> ensemble/config-get r199 committed by bcsaller@gmail.com [12:17] <_mup_> config-get synced to current [12:25] <_mup_> ensemble/ensemble-resolved r244 committed by kapil.thangavelu@canonical.com [12:25] <_mup_> test cases for resolved command line. [12:25] bcsaller, g'morning.. still up? [12:26] hazmat: sadly yes [12:26] bcsaller, fwiw, i took a stab at getting the yaml-state tests running with with the hook state context, worked beautifully. [12:26] er. running with the hook state context tests that is [12:26] ha, I was just playing with that. [12:26] thats great [12:27] state/relation should change as well [12:28] bcsaller, i'm curious what your game plan is with the hook context, extend it with a yaml state for unit relation settings, and service settings and extend the api to get/set/delete + _relation and get + _service and wire that into the api server? [12:29] bcsaller, if you need any help, i've got some extra cycles [12:29] thats pretty much the direction I'm headed. I already went through and did config-get but then I had to wire it into hook.flush to call write and I figured I'd better insert a pipe for those [12:30] other flush calls [12:31] bcsaller, even with the service stuff there is still only one yaml state for the purposes of modification by the hook, afaics. the service settings are read only from the hooks [12:31] wiring in the initialize/read on the yaml state proved a bit more invasive but minor [12:32] yeah, I imagine you did the same thing, but I just put it in the hooks node cache. [12:33] and use a single instance var for the service options [12:34] hmm.. i ended up bypassing the node cache, and stuck the yaml states as attributes, there's a spot in read which checks if its self unit relation, where i just divert to the instance yaml state [12:34] s/read/get_value [12:34] i'm sure they both work fine. [12:36] yeah === DigitalFlux_ is now known as DigitalFlux [12:55] <_mup_> ensemble/resolved-state-api r188 committed by kapil.thangavelu@canonical.com [12:55] <_mup_> new state errors for resolved. [13:04] <_mup_> ensemble/resolved-state-api r189 committed by kapil.thangavelu@canonical.com [13:04] <_mup_> get/set/clear for unit resolved and relation resolved. [13:15] bcsaller, fwiw, i expect the workflow for service change would look like that for an upgrade (only from the running state circular transition) [13:16] hmm.. dynamic dependencies [13:17] but against a static set of knows [13:17] works [13:49] Yo! [14:00] niemeyer, top of the morning [14:01] hazmat: Hey man, feeling good today? [14:01] niemeyer, yup.. making good progress on resolved [14:01] doing a some user oriented docs for it now [14:01] hazmat: Sweet [14:01] its hard to talk about sometimes without exposing internals [14:06] <_mup_> Bug #767147 was filed: upgrade-formula should have a --force option to allow for upgrading without incrementing the version. < https://launchpad.net/bugs/767147 > [14:12] so.. natty by default? really? ;) [14:12] * SpamapS clings tightly to his beloved LTS [14:16] hazmat: You've answered privately to me on that thread, was that the intention? [14:17] SpamapS: Hehe :) [14:19] hazmat: I think you missed xx-relation-departed in the development update [14:20] niemeyer, no it wasn't.. [14:20] niemeyer, i'll resend [14:20] hazmat: Cool, thanks.. will wait for it before responding [14:20] hazmat: Just so people get in the proper order [14:21] hazmat: People will be amazed at how fast I can answer a message, though ;-) [14:21] niemeyer, :-) [14:22] ooo I didn't know upgrades were moving along so nicely [14:23] niemeyer, sent [14:23] hrm.. nothing in docs/source ?? [14:23] SpamapS, i forget to move them out of drafts [14:23] hazmat: Oh, we have to move something else too [14:23] * niemeyer tries to remember [14:23] The configuration stuff [14:24] niemeyer, looks like it already is for service-config [14:24] not sure if its wired into the index [14:24] hazmat: It's in drafts? [14:24] hazmat: Drafts don't have to be manually inserted [14:24] hazmat: indeed. I saw the bug report about passing versions and it immediately made me think that we should be copying debian packaging in this regard.. [14:24] niemeyer, its not in the drafts. [14:24] hazmat: Right, it should be [14:24] It's not ready yet [14:25] ah.. yeah.. i'll do a quick branch to fix that up. [14:25] hazmat: It's also not in the index, but the right thing is to simply move it to the drafts directory [14:25] hazmat: Just cowboy it [14:25] SpamapS, i'm all ears.. what's debian do? [14:25] as [trivial] [14:25] k [14:25] hazmat: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html [14:26] hazmat: you can probably skip to 6.5 [14:26] hazmat: and 6.6 is actually where my mind went [14:26] "Details of unpack phase of installation or upgrade" [14:27] hmm [14:27] Now, frankly.. I'd say less than 1% of packages I've touched implement things like 'abort-deconfigure' [14:28] But the useful bits are postinst (upgrade|install) and preinst (upgrade|install) .. and somewhat.. prerm [14:28] SpamapS, right now our model is a single hook for the upgrade.. on failure we're going to allow either retry or manual fiddling and resolution. [14:28] hazmat: thats probably ok, because we don't care at all about removal [14:28] breaking it out into a half-dozen hooks... [14:29] i dunno it might be real world required.. but i'm not sure debian packaging is the friendly feel that ensemble is going for [14:29] I'm thinking more about the flow [14:29] *probably* want to call install again [14:30] but w/ one hook, can be done at maintainer's choice.. [14:30] hazmat: hah true dat. ;) [14:30] SpamapS, hmmm.. yeah.. i expect the smarts of the upgrade are hopefully encapsulated in the package upgrade.. i'm totally willing to revisit, but it would be nice if it was practice driven. [14:31] adding the upgrade version thing otoh, just seems like a no-brainer [14:32] its useful information for sure [14:32] Did we ever settle on revision number being anything other than an int? [14:33] hazmat: also how are upgrades of units handled? in parallel w/ no coordination? [14:34] SpamapS, yes.. there's a separate upgrades doc from the formula doc which explores more advanced upgrade options [14:34] SpamapS, the remote sides never see the upgrade with a formula-upgrade atm [14:34] it looks like the service is still there.. [14:35] if they try to talk to it via their relation settings, the response will be delayed till the upgrade is complete [14:35] if the upgrade fails, all hooks are queued till the issue is resolved.. [14:36] how its resolved is the subject of a new command ensemble resolved.. which allows manually correcting for hook errors on units and unit relations, i'm writing some docs for it atm [14:37] hazmat: well that makes perfect sense. in the upgrade hook I can enumerate and do sets right? [14:37] SpamapS, not yet [14:38] ok.. because that would be useful [14:38] the only real functionality that the upgrade hook offers atm that's different than normal hooks is that its executed first out of the new formula. [14:38] but no, services should be resilient to transience of their related partners.. [14:38] SpamapS, yeah.. i did some discussion of that in the futures section of the upgrade-formula doc [14:38] re enumerate and set [14:39] hazmat: its kind of a corner case really [14:39] SpamapS, the real issue with it at the moment, is that looks we're tending towards some anonymous relations [14:39] SpamapS, i definitely think its realistic [14:39] maybe a corner, but for advanced upgrading usage, its a pretty important piece. [14:40] by tending to anon relations, i mean the mysql formula for example, can have multiple relations with clients named 'db'.. [14:40] The one I worry about is the new config file that needs to be generated.. need to enumerate and basically rejoin every relation. [14:40] the identity of those multiple instances of the same name is a question.. [14:41] hazmat: sorry I've gone cross eyed again. huh? [14:41] at the moment with another command targeting unit relations, i'm treating them as a set, but if we expose to hooks, they have to have some names [14:41] SpamapS, say we have two wordpress blogs/services, and they both connect to mysql [14:41] now mysql has two relations instances, but they have the same name. [14:42] two services w/ the same name? [14:42] SpamapS, two relations with the same name [14:42] so the services are 'blog0' and 'blog1' .. .right? [14:42] SpamapS, sure [14:42] mysql has seen them as such and there are two databases? [14:43] perhaps we should encode the remote service name in user visible portion of the relation to add a qualifier for enumeration [14:43] ^of the relation name [14:43] its sort of the natural order of things [14:43] niemeyer, ^ re anon relation addressing [14:43] service_name+relation_name == unique relation id [14:44] hazmat: ECONTEXT [14:44] SpamapS, yeah.. that sounds good to me [14:44] hazmat: Let me read back [14:44] hazmat: given that one would be able to enumerate their established relations and have something that can be used to pass to tools to say "relation-list blog0-db" ? [14:45] actually blog0:db would imply it is the :db on blog0's side.. but its really the db on mysql's side isn't it? [14:45] SpamapS, yeah.. probably as RELATION_NAME=blog0-db relation-list [14:45] yeah.. its the mysql side. [14:46] Well I love the idea of being able to do that [14:46] we can reverse the order rel-name/service-name [14:47] hazmat: Ok, in sync again [14:47] hazmat: I don't think we should use the service name anywhere in a relation [14:48] niemeyer, even as a transient qualifier? [14:48] transient id [14:48] hazmat: It enables people to build custom-logic based on the service name, which is a big killer for the formula concept [14:48] hmmm.. it does [14:48] hazmat: We have unique ids for the relation already [14:48] hazmat: The internal ids [14:49] hazmat: They're not semantically meaningful, but that's exactly the idea.. they shouldn't be [14:49] niemeyer, are you suggesting we expose them to hooks for the purpose of iteration/transient ids? [14:49] niemeyer, cool [14:49] hazmat: Yeah, I think it'd be fine to have, e.g. db-424 [14:49] hazmat: Just to enable people to iterate over multiple relations in an upgrade hook or similar [14:50] niemeyer, yup.. sounds good. [14:50] Yeah it doesn't matter what the id is, just that a formula can be aware of them on upgrade so that they can list/get all the data out of them. [14:50] <_mup_> Bug #767195 was filed: Ensemble should have hook cli apis to enumerate and interact with all the relations of a unit. < https://launchpad.net/bugs/767195 > [14:51] transcript in the bug report [14:51] hazmat: Thanks [14:51] SpamapS: Right [14:52] hazmat: when you say the upgrade spec is in drafts.. where is that so I can read it? [14:53] SpamapS, its in the docs/source/drafts dir.. it will be online in about 15m.. after i move things around for trunk. [14:53] and the doc site rebuilds [14:53] niemeyer, any reason we're not using rtfd? [14:53] i thought we where, but the links point back to chinstrap [14:53] hazmat: It broke repeatedly [14:53] oh doh :) [14:53] hazmat: So I gave up on them and put a cronjob in place [14:53] niemeyer, ugh.. did we get any feedback or insight from them.. i thought it was pretty active dev [14:54] hazmat: It is pretty active.. perhaps too active :) [14:54] hazmat: At one point they said "Oh, sorry, we broke bzr support a couple of weeks ago in PyCon" [14:54] its amazing to me after doing tdd, how many branches get merged in openstack with neglible or no tests. [14:54] hazmat: The second time I didn't bother to ask [14:54] but their dev is insanely active [14:54] hazmat: so I'd like to see some coordination possibilities. You mention it in the doc a bit.. [14:55] hazmat: Yeah, to me it feels a bit like building a bomb :-) [14:55] SpamapS, yeah.. those are still open questions, i'd be glad to brain storm with you on it. [14:55] what should it look like to a formula author, what should ensemble do to enable it. [14:56] i mean we can totally play tick-tac-toe in a formula.. we can probably do a round-robin :-) [14:56] hazmat: basically it would be good to be able to run 'rm -f /srv/code/live && ln -s /srv/code/4481 /srv/code/live' at the exact same time on all machines. [14:56] hazmat: that is a huge reason people are using mcollective right now [14:57] SpamapS, its async, but the latency should be comparable to mcollective [14:57] perhaps better [14:57] hazmat: Yeah, that's what I was going to say [14:57] hazmat: We're almost certainly better [14:57] hazmat: Due to the live connections [14:57] niemeyer, mcollective is pub/sub on amqp.. not parallel ssh, so its pretty comparable [14:57] hazmat: another way people do it is they pick an exact second they want it to happen. [14:58] at least that was my understanding of it [14:58] hazmat: Ah, ok, yeah, that may be similar [14:58] i found a pretty nifty implementation of func in python.. using zeromq the other day, https://github.com/thatch45/salt [14:58] right mcollective is a two way channel to each box facilitated via AMQP [14:59] also uses ruby factr lib to expose to its python scripts. [14:59] er. expose machine info [14:59] thats just the default agent [15:00] people write them to do all kinds of weird stuff. :) [15:00] the amorphous nature is one reason we have an opportunity to provide something with more structure and less custom work [15:02] niemeyer, here's the delta for the trivial docs update.. https://pastebin.canonical.com/46437/ [15:02] SpamapS: Yeah, we have to think a bit more about actual impact, but being able to coordinate execution does sound like something we should be looking at [15:02] hazmat: It shouldn't be in the index [15:03] hazmat: Wait.. is it reversed? [15:03] niemeyer: I think we talked about a relation-cas command before... getting back to what I wanted tho.. relation-lock ;) [15:03] niemeyer, the upgrades doc talks about the general update scenarios, and the upgrade-formula one goes into details of the formula upgrade. [15:03] niemeyer, into internals/specs? [15:04] either way, thats a nice to have. just being able to upgrade formulas is GREAT right now [15:04] hazmat: They are both being inserted into the index? [15:04] SpamapS, should be a few more goodies coming for formula authors before budapest [15:04] settings is, IMO, the last thing before I will start deploying and managing a couple of things on ensemble. [15:04] niemeyer, atm yes. [15:04] hazmat: You can just drop the files in drafts/ [15:05] Looking specifically at Roundcube for my webmail. :) [15:05] hazmat: Oh, wait, sorry.. have you merged upgrades already? [15:05] SpamapS, yeah.. that's key [15:05] niemeyer, yes.. the upgrades are merged, i did a few end-to-end tests yesterday [15:05] hazmat: Awesome, fantastic, sorry for the confusion [15:06] hazmat: +1 on the change [15:06] niemeyer, cool, thanks [15:07] <_mup_> ensemble/trunk r203 committed by kapil.thangavelu@canonical.com [15:07] <_mup_> pull docs for committed upgrade functionality out of drafts, move service-config into the drafts dir till it lands. [trivial][r=niemeyer] [15:07] SpamapS: Oh, that's awesome [15:08] hazmat: Regarding the natty branch, can we try to ssh actively rather than just sleeping? [15:09] niemeyer, not sure what you mean by active.. fabric uses it but jumps if doesn't work.. [15:09] hazmat: Active != sleeping [15:09] i could try turning up the logging there and see if i can find some additional info out of it. [15:09] hazmat: Nah [15:09] but its pretty low priority to me [15:10] hazmat: Just pondering, but that's rare enough [15:10] +1ing [15:16] parser.add_argument("--log-level", [15:16] help="Set a logging level " [15:16] "CRITICAL|DEBUG|INFO|ERROR|WARNING", [15:16] default=logging.WARNING) [15:16] Hmm [15:16] INFO is the most commonly used default for logging, I think [15:16] Was just reviewing ahmed's branch with --log-level=INFO everywhere [15:16] kim0: ^ [15:17] Wait, hmmm.. [15:18] It might be more complicated than that.. --log-level means two different things for different commands it seems [15:18] * niemeyer inspects further [15:19] Ah, yes indeed [15:41] did it again.. [15:41] re email send [15:42] dog walk.. bbiab [15:55] <_mup_> ensemble/expose-1-dummy-provider r203 committed by jim.baker@canonical.com [15:55] <_mup_> Merged trunk [15:56] <_mup_> ensemble/expose-2-hook-commands r203 committed by jim.baker@canonical.com [15:56] <_mup_> Initial commit [15:56] <_mup_> ensemble/expose-2-hook-commands r204 committed by jim.baker@canonical.com [15:56] <_mup_> Merged upstream [15:57] so let me know whether or not INFO is fine for logging [15:59] kim0: I'm working on a fix for that [15:59] kim0: It is fine for logging [15:59] cool [15:59] kim0: The issue is that INFO should be the default [15:59] aha .. yeah agree [15:59] kim0: and it's not because we're currently mixing two different concepts [16:00] just bec it's the correct level [16:00] kim0: Filtering logs, and logging at a given level [16:00] kim0: I'm fixing that [16:00] got you .. rock on [16:00] reminder of our meeting in 3 hours [16:00] kim0: If you want, you can already change that in your branch [16:00] kim0: Just remove all the --log-level INFO from ensemble-log calls [16:00] kim0: Thanks [16:01] ok .. will clean that and push [16:02] this is to change the default level in the code or the command? [16:06] hazmat: The command [16:07] hazmat: It's logging everything as WARNING, because it's incorrectly picking the filtering argument to use as the level to log for [16:07] Almost done with the fix.. will push after lunch [16:09] ick [16:09] niemeyer, cool [16:20] niemeyer, sorry i didn't realize you had posted to me privately.. if that was intentional [16:21] hazmat: It wasn't.. my fault this time === niemeyer is now known as niemeyer_lunhc === niemeyer_lunhc is now known as niemeyer_lunch [16:48] brb, need to drop off car for service [16:57] niemeyer_lunch: should I remove x in "set -eux" in formulas ? [17:02] I think it's too verbose to be the default for anything :) === niemeyer_lunch is now known as niemeyer [17:10] kim0: Agreed [17:10] kim0: Yes, please remove it [17:10] * kim0 nods [17:10] yipee [17:11] off to lunch, bbiab [17:11] niemeyer: pushed the updated branch "set -eu" and no "--log-level INFO" [17:13] kim0: Awesome, thanks! [17:21] kim0, makes sense to me with the new logging you're doing [17:22] cool [17:22] hmm I think I'm hitting some bug [17:22] although i did find -x to be very helpful [17:22] probably while developing the formula only [17:22] we really need the relation setting logging [17:23] also it would be interesting to have some sort of monitoring of the nodes integrated in some way (not necessarily though logging). need to think of what my wishlist should be [17:23] hehe [17:24] can someone please check http://paste.ubuntu.com/596612/ [17:24] anyway, round 2 on getting car fixed, my father in law put the wrong tires in the car [17:24] some twisted errors [17:24] jimbaker: :) that's what fathers in law are for hehe [17:26] I think ensemble-log is broken or something [17:26] exceptions.AttributeError: Logger instance has no __call__ method [17:51] hmm should I file a bug ? [18:13] kim0, back now. yes, -x is definitely necessary for formula debugging with bash script hooks (at least for this novice bash scripter) [18:13] jimbaker: any idea why I'm getting those errors http://paste.ubuntu.com/596612/ though [18:14] kim0, yikes that's ugly [18:14] yeah :) [18:14] trying to write that user tutorial, but the moon is misaligned :) [18:15] I wonder what ensemble version runs on the ec2 instances? does it pull trunk [18:15] kim0, it does look like a problem with ensemble-log as you mentioned [18:15] kim0, by default it does, but you can choose another branch instead [18:16] ok cool [18:16] <_mup_> Bug #767364 was filed: ensemble-log logs in wrong level < https://launchpad.net/bugs/767364 > [18:16] is it realistic to expect those ensemble-log crashes to be fixed soonish .. like today :) [18:17] for an environment in your ~/.ensemble/environments.yaml (or otherwise specified), use something like this: [18:17] ensemble-branch: https://code.launchpad.net/~jimbaker/ensemble/new-hook-semantics-remove-ensemble-change-env-var [18:18] thanks [18:18] now i should not be so quick to say it will choose trunk as the desired version... in my environments.yaml file, i do have this [18:18] kim0: That's pretty weird [18:18] ensemble-branch: http://bazaar.launchpad.net/~ensemble/ensemble/trunk [18:18] bcsaller: Do you have any hints on thta? [18:18] that [18:19] i just comment out as desired [18:19] jimbaker: thanks :) [18:19] kim0, i suspect someone who doesn't run bleeding edge has more experience on this one aspect to be honest ;) [18:19] hmm [18:20] looks like the setup of passing in the log handle would be wrong there [18:20] kim0, if you ever use ensemble-branch, prepared to be occasionally confused as might get stuff out of sync. ("didn't we fix that? ahhh...") [18:21] jimbaker: trunk is probably a safe choice for me [18:21] :) [18:22] kim0, indeed, i think that's the case. it doesn't impact your principal use case, which is formula dev. but if you want to try out a new branch that fixes a problem, then it lets you have immediate access [18:31] bcsaller: should I file a bug on that logging thing [18:32] kim0: yes, I think its on the server side, sounds misconfigured [18:33] * hazmat catches up [18:34] ensemble defaults to trunk if its not specified via 'ensemble-branch' [18:35] interesting tracebacks, one in amp and one in the amp server protocol when calling out to the logging [18:36] looks like ensemble-log is broken [18:36] hook cli api that is [18:36] * hazmat reboots for natty updates [18:36] <_mup_> Bug #767391 was filed: ensemble-log causing twisted crashes < https://launchpad.net/bugs/767391 > [18:40] hazmat, thanks for the clarification. what happens when ensemble is installed from a ppa? [18:45] jimbaker, trunk on the remote [18:45] hazmat, sounds good for now i think [18:49] <_mup_> ensemble/trunk r204 committed by gustavo@niemeyer.net [18:49] <_mup_> Merged add-ensemble-log-to-examples branch [a=kim0] [r=niemeyer] [18:49] <_mup_> This adds sensible ensemble-log messages to the example formulas, and [18:49] <_mup_> removes the excessively verbose -x flag from scripts. [18:50] <_mup_> Bug #767405 was filed: Add open-port and close-port hook commands < https://launchpad.net/bugs/767405 > [18:52] <_mup_> Bug #767407 was filed: Add "ensemble expose" and "ensemble unexpose" subcommands < https://launchpad.net/bugs/767407 > [18:55] <_mup_> Bug #767414 was filed: Modify "ensemble status" to display exposed ports and whether a service is exposed or not < https://launchpad.net/bugs/767414 > [18:58] <_mup_> Bug #767418 was filed: Modify the provisioning agent to watch ZK settings for exposed services and makes appropriate firewall changes through the provider < https://launchpad.net/bugs/767418 > [18:59] <_mup_> Bug #767420 was filed: Add a provider implementation for EC2 to support port exposing < https://launchpad.net/bugs/767420 > [19:00] Starting meeting in 1 minute in #ubuntu-cloud : jimbaker hazmat bcsaller niemeyer [19:00] kim0: Ack [19:00] kim0, over there now [19:00] yeah the minute just flipped .. let's do it [19:02] <_mup_> Bug #767426 was filed: Modify the canonical WordPress formula to demonstrate exposing < https://launchpad.net/bugs/767426 > [19:37] koolhead17: So, welcome [19:38] niemeyer: am still a n00b in coding [19:38] * koolhead17 pokes TeTeT :) [19:38] koolhead17: That's fine [19:39] koolhead17: No one is born knowing it :-) [19:39] :D [19:40] koolhead17: But you'll need quite a bit of patience to push through the basics [19:40] koolhead17: "bzr branch lp:ensemble" will get you the project source [19:40] niemeyer: cool [19:41] hi koolhead17 [19:41] * koolhead17 installs virtualbox [19:41] koolhead17: You'll also need lp:txaws [19:41] documentation and other non coding contributions are welcome as well.. [19:41] and an amazon ec2/aws account [19:41] koolhead17: kim0 can also give you a hand to get your first working environment, since I think he's doing exactly that right now [19:41] kim0: Right? [19:41] hazmat: i will jump to the documentation work soon [19:41] koolhead17: Once you have that in place, you have a world to poke around :0 [19:41] :) [19:42] was the s3 problem fixed in txaws? [19:42] nehehe [19:42] koolhead17: feel free to shoot any questions or problems at me :) [19:42] koolhead17: You can start developing some custom formulas to get a feeling, try to get some small sized improvements going, etc [19:42] I have a working env already .. but yeah no problem [19:43] kim0: Yeah, the idea was just that if you might be able to easily guide him through the basics of setting up an environment since you've done that not too long ago [19:43] but i need multi system setup to test my deployment. isn`t it [19:43] ? [19:43] koolhead17: you probably want to deploy the example wordpress formula .. feel the magic .. love it .. then start writing a new formula .. wow [19:43] kim0: I'll likely skip a lot of steps [19:43] TeTeT, niemeyer was working on it re s3 bug [19:43] TeTeT, hazmat: Yes, it's fixed [19:43] niemeyer, great! [19:43] awesome :) [19:43] koolhead17: ensemble basically uses ec2 only for now .. so you don't need any physical machines [19:44] i don`t have any account on ec2 [19:44] but i can borrow one from a friend of mine [19:44] ec2 offers a free account (free tier) [19:45] you just need to register with a credit card though [19:45] after that the fun begins :) [19:45] niemeyer, how often do the docs update.. i moved the upgrade docs a while ago. [19:46] hazmat: Every 5 minutes [19:46] hazmat: Must be something wrong, checking [19:48] kim0: i hate cc [19:48] am scared of it [19:48] koolhead17: don't be :) [19:49] kim0: will only use a CC if someone gifts one to me :P [19:49] hehe you wish [19:49] it won't really be charged anything (unless you screw up somehow ) so dont worry too much [19:52] is there a apt command which tells you about its depandency with other packages? [19:52] hazmat: Just looking for phones [19:53] Okay, I'm up [19:53] koolhead17, apt-cache rdepends will show you reverse deps [19:53] apt-cache show will show you deps [19:53] hazmat: cool [19:55] koolhead17: but since you'd run ensemble from trunk .. it's not too useful :) [19:56] kim0: o.O [19:56] o.0 [19:56] koolhead17: try, sudo apt-get install python-zookeeper python-txaws [19:56] those are what I needed [19:57] koolhead17: there was some python egg too .. can't remember its name [19:57] am on lucid BTW :P [19:58] lucid .. the land of the ancient [19:58] the land of the corp services team :) [19:58] hehe [19:58] kim0: am in love with LTS [19:58] until few night my laptop was running on 8.04 [19:58] if you're interesting in running bleeding edge non released software .. lucid is not gonna be too happy [19:59] although netbook has latest one [19:59] :P [19:59] koolhead17: natty VM then [19:59] can't wait for natty to be released to upgrade to oneirirc :) [19:59] kim0: i will install virtualbox cos my hw is not supported. [20:00] kim0: i had a question i asked the same [20:00] vbox will work great [20:00] since all the heavy lifting happens in ec2 .. it should be ok [20:00] why /etc/lsb-release does not mention natty beta2 [20:00] it will be a good feature to add [20:00]