[07:15] testline [07:39] <_mup_> Bug #873907 was filed: Security group on EC2 does not open proper port < https://launchpad.net/bugs/873907 > [07:40] https://bugs.launchpad.net/juju/+bug/873907 [07:40] <_mup_> Bug #873907: Security group on EC2 does not open proper port < https://launchpad.net/bugs/873907 > [08:06] shang: I think you need a "juju expose wordpress" [08:07] shang: and, I think you're right about the docs, someone mentioned them not getting updated [08:07] shang: I should probably try to find out how that's all meant to work :) [08:08] fwereade: so after the add-relation, just run the expose command? [08:08] * shang testing it [08:09] shang: that should be it [08:09] shang: here's the critical section of the user-tutorial docs, that hasn't landed for somereason: http://paste.ubuntu.com/707807/ [08:11] shang: (sorry I missed you before) [08:12] fwereade: no worries ;-) [08:13] fwereade: cuz I know Jane did a demo few days ago, so I was pretty sure things should be working, just can't figure out the missing pieces... [08:15] shang: sadly I'm not really sure where to start looking for the magical documentation-updater [08:16] shang: it might be helpful, just for now, to grab trunk and "cd docs && make html" [08:17] shang: but I have a documentation bug to fix *unless someone else has already grabbed it) so once that's fixed I'll be bothering people incessantly about auto-updating [08:19] shang: if you confirm it's working for you, I'll mark the bug invalid and add an explanation [08:19] fwereade: the expose command should take care of the security groups part, right? [08:19] shang: that's right [08:19] shang: still having problems? [08:20] * shang tried the expose, but didn't see EC2 security group open the port [08:20] fwereade: yeah [08:20] * fwereade is perplexed and goes off to peer at the code [08:21] shang: did you get a "Service wordpress is exposed" message, but nothing happened? [08:21] fwereade: from the status command, the wordpress open-ports:[] [08:21] fwereade: yeah [08:22] shang: hmm; can you ssh to the bootstrap node and see if there's anything in the provisioning agent log? [08:25] fwereade: it looks fine from where I can see it [08:25] http://paste.ubuntu.com/707819/ [08:29] shang: I remain perplexed :( [08:29] shang: let me see if I can repro [08:38] fwereade: ok, and even if I manually open the port 80 on the wordpress security instance, the wordpress has not being configured... let me know if that just me... [08:39] shang: hm, that then sounds like a problem with the charm [08:40] fwereade: does the 3306 needs to be open for the service to be configured? [08:41] shang: I'm afraid I don't know, everything I've done has been on the provider side... I've not had much experience debugging charms [08:41] fwereade: ah, ok... [08:43] wrtp, sorry, I *completely* missed you [08:43] shang: just a suggestion [08:44] fwereade: it was nothing anyway :- [08:44] ) [08:44] shang: FWIW, deploys and exposes fine for me [08:44] fwereade: BTW it was me that submitted that doc fix - isn't the documentation automatically updated? [08:45] shang: what's your juju-origin, and where did you get your charms from? [08:45] wrtp: I recall jimbaker saying that the auto-updating wasn't working, but I was distracted and never followed up [08:45] fwereade: i se [08:45] e [08:46] fwereade: I was using the -> sudo apt-get install charm-tools; charm update examples; charm getall examples [08:46] fwereade: let me refresh them, perhaps [08:47] shang: I'm not sure this is a relevant question, but just in case: do the charms you're deploying have a "revision" file? [08:49] fwereade: yes, wordpress: rev. 30 [08:49] mysql rev. 103 [08:53] shang: hm, I'm feeling pretty short on ideas :( [08:53] fwereade: um... :( [08:54] shang: it might be worth trying to just deploy wordpress from scratch with a debug-log running [08:54] shang: (all I mean is that the problem isn't obvious, not that I'm giving up ;)) [08:55] fwereade: thanks! :D [08:55] fwereade: Let me give that another try [08:55] shang: (open a separate terminal and "juju debug-log" before you deploy) [08:56] fwereade: actually, I will run it on a different machine, maybe a fresh one and see if I can reproduce the issue [08:57] shang: cool, I'm about to try with the charms from charm-tools instead of trunk, see if I can repro that myself [08:59] fwereade: thanks a lot [09:19] fwereade: what is the command (or location) you get the charms? [09:20] shang: I've always just tested with the examples repo in trunk [09:20] fwereade: ok [09:26] shang: fyi, I'm seeing the same problem [09:26] shang: no idea why yet ;) [09:26] fwereade: so it is because the charm-tools [09:26] shang: that seems likely [09:27] shang: but I can't say exactly what yet [09:27] fwereade: ok, at least we know what is causing it... which is a good start :-) [09:27] shang: yep -- thanks :) [09:48] g'morning [09:48] hazmat: morning [09:48] juju docs ticket is pending here fwiw.. https://portal.admin.canonical.com/48456 fwiw [09:49] * hazmat tries to catch up on the back log [09:49] hazmat: sweet [09:50] ty [09:50] fwereade, np [09:50] shang, so you've got a service deployed and exposed and its not available? [09:50] and juju status says its 'started'? [09:51] shang, could you paste bin the output of 'juju status' [09:51] oh [09:51] fwereade, your seeing it too? [09:51] hazmat: yeah, I guess it's something to do with the wordpress charm [09:52] hazmat: I'm floundering along in a semi-helpful way, but this is the first charm I've made any attempt at debugging ;) [09:52] shang, fwereade, so getting the unit log is pretty helpful to understanding unit specific problems [09:53] shang, fwereade before deploying, you can get it directly from juju if you start a juju debug-log in a separate shell before deploying/relating .. it captures all the logs from all the agents.. [09:54] shang, fwereade after the fact, you can use 'juju ssh wordpress/0' to login directly to the machine [09:54] the log for a unit lives at /var/lib/juju/units/wordpress-0/formula.log i believe [09:55] hazmat: hm, I was aware of the existence of juju ssh, I just never thought of actually using it :/ [09:55] fwereade, no worries, we have better tools as well.. [09:55] hazmat: debug-log is helpful, indeed [09:55] fwereade: I ran the command: bzr branch lp:~charmers/charm/oneiric/mysql/trunk mysql [09:56] fwereade: still getting the same issue [09:56] hazmat: let me get u the logs [09:56] fwereade, shang real debugging.. is using juju debug-hooks wordpress/0, right after deploying the unit, it will set up a tmux session on the machine [09:57] and pop up new windows for hook executions, with all the hook env variables setup. you can manually execute the hook or interactively edit/perform work [09:57] its good to have a log first of what's wrong thouh [09:57] hazmat: http://pastebin.ubuntu.com/707872/ [09:57] hazmat: ok, let me try again [09:57] * hazmat tries with the local provider [09:58] fwereade: which trunk did u use? [09:59] shang: sorry, I was referring to the examples in juju trunk [09:59] fwereade: ah, ok [10:00] shang, so status looks good, getting the /var/lib/juju/units//charm.log file is probably needed to debug a charm further [10:00] we should probably have a special cli option builtin for this purpose [10:01] hazmat: shouldn't the open-ports have the 80 in it? [10:01] shang, it should [10:02] shang, the wordpress charm in principia never does open-port [10:03] which is why its broken [10:03] shang, nice catch [10:04] hazmat: so we start the wordpress instance [10:04] and run the command: juju debug-hooks wordpress/0 [10:04] in another terminal to see the debug info? [10:07] shang, yes.. its not debug info.. its a tmux session .. where windows/shells will pop up that 'replace' a hook execution, instead activity done interactively by the user is the hook, when your ready for the hook to be done, you exit the pop'd up window [10:09] * hazmat works on fixing principia wordpress [10:10] hazmat: would you let me know when you're done? I had this theory that was *probably* the issue, but haven't managed to actually fix it, and it would be nice to see the successful diff [10:12] (and I wasn't going to go and confidently pronounce how to fix the problem until I'd actually, y'know, done so) [10:14] fwereade, normally its just .. adding a call to open-port anywhere in the formula, the wordpress in principia (or whatever its called) is derived from juju/examples.. but diverged prior to the bashification.. in this case i'm effectively doing a hand merge of the bash script [10:14] 100% of all open-port usage is non dynamic [10:15] zero calls to close port [10:15] * hazmat takes a deep breath and moves on [10:15] hazmat: ah, I wondered about that [10:15] cheers [10:19] hazmat: do you still need the charm.log? [10:20] shang, no its cool, thanks though [10:21] hazmat: ok, thanks [10:22] <_mup_> juju/wordpress r50 committed by kapil.thangavelu@canonical.com [10:22] <_mup_> pull from juju trunk, bashify, and include open-port call [10:24] shang, if you update your branch/checkout of the formula it should work now [10:25] shang, you'll need to destroy the service and redeploy with the new formula.. i didn't include an upgrade script [10:26] hazmat: ok, let me try [10:43] * hazmat should go back to sleep [12:49] hazmat: so, FindMachineSpec [12:49] hazmat: the problem with returning a list of possible specs is that it might be outrageously long [12:50] with all combinations of n parameters [12:50] wrtp, yeah.. if its encapsulating all permutations [12:50] yeah, so i think it might be better to expose some interface for finding possible values of each parameter [12:50] wrtp, so i was thinking something a bit more simple.. [12:50] exactly [12:51] as in: possible RAM config, possible OS image, possible location, etc [12:51] think about driving a ui for example is a good scenario to keep in mind [12:51] ie. what would you want to see [12:51] hm, this sounds a lot like facter [12:51] SpamapS: facter? [12:52] facter shows you RAM, OS, CPU#, etc. [12:52] SpamapS, its more akin to dash or ec2 ui [12:52] its used a lot in puppet [12:52] and chef [12:52] I missed the context tho [12:52] SpamapS: i was trying to come up with a nice way of specifying a machine to start [12:52] SpamapS, just discussing environment interfaces in go [12:53] oh like, you want to choose the machine type for the user? [12:53] wrtp, so i wouldn't worry about the enumeration stuff for now, we can add that latter [12:53] hazmat: yeah [12:53] SpamapS, no.. more like we want to give the user the option, and be able to validate it [12:53] or present a ui with options [12:53] SpamapS: for reference, here's my first stab at a spec/doc for a Go interface to juju: http://paste.ubuntu.com/707950/ [12:54] hazmat: yeah, i'll keep it ultra simple for now, with the expectation of fleshing it out later [12:54] SpamapS, but carry the user selection down to the provider [12:54] Wow I'm quite confused [12:54] at what point do you get to ask users questions? [12:54] SpamapS, right now its kinda broken we only grab it from the config file, a user specification is passed down to the provider [12:54] (at what point would we ever WANT users to be bothered with questions?) [12:54] SpamapS, at deploy time [12:55] SpamapS, optionally we fall back to env defaults [12:55] SpamapS, i want to deploy cassandra on a HUGE machine ;-) [12:55] i'm more imagining an intelligent choice based on a previously specified user constraint [12:55] rather than user interaction per se [12:55] SpamapS, but haproxy on a tiny machine [12:56] the size of cassandra is based somewhat on usage [12:56] Hrm, I doubt users want to be stopped and asked about this [12:56] interesting [12:56] if they don't do --ram BIG or --machine-type m1.large ... env default seems appropriate [12:57] and that's what it will continue to be [12:57] i'm thinking that the user probably wants to be able to verify that they won't be paying more than a certain amount of money [12:57] it would DEFINITELY be cool to map abstract arguments to provider machine types [12:57] SpamapS: that's the idea [12:57] --budget-per-hour 0.50 [12:57] yup [12:57] But to ask the user.. fail [12:57] i think that's pretty crucial actually [12:58] just say "Cannot determine best machine type, options { x, y , z }" and exit(-1) [12:58] SpamapS: yeah. although the user should be able to iterate without spending, i think. explore the possibilities. [12:58] Still [12:58] this sounds like we're getting way ahead of being awesome at what we currently do. ;) [12:58] SpamapS: more like: "no machine type available that meets your budget constraints" perhaps [12:59] SpamapS: this was all spawned from discussion about the FindImage method in the go docs i posted above [12:59] as a first iteration, just adding --machine-type XXXXXX would be a quantum leap [12:59] SpamapS: yeah, we're way ahead of ourselves, but it probably helps to have an idea of where we might go [13:00] and also being able to change the machine type for a running service would be good [13:00] and i do think being able to plan your budget (and explore different budgets across different providers) is going to be important in the long run [13:01] SpamapS: is that actually possible? [13:01] wrtp: sure, change it, then issue a "replace units" command that would slowly remove the old type and add the new type [13:02] assuming its a service that has the ability to do that.. :) [13:02] if not.. well then.. don't do that! [13:02] :-) [13:02] point being, add-unit just uses whatever was the env default at the time of deploy.. [13:03] SpamapS: so {add-unit; remove-unit}should do the job? [13:04] where remove-unit is removing an old unit [13:04] not the one just added [13:04] sorry to derail, what I am trying to convey is that you're enhancing something that has a weak foundation .. might be good to get a structure in place .. I like the end goal a lot tho [13:05] * SpamapS is just grasping at anything that will distract him from trying to figure out how to elastically grow a ceph cluster [13:05] SpamapS: hmm, just wondering about "whatever was the env default at the time of deploy..". does that mean we'd have to push the current environment to zk on each state change? [13:06] lol [13:06] is there a list anywhere of "current juju shortcomings that we'd like to address"? [13:06] wrtp: the problem is that the provisioner that actually starts machines and assigns them to units has only one clue about the machine type, and thats the one in the service state in ZK [13:07] wrtp: the unit should be able to provide an overriding clue [13:07] wrtp: https://bugs.launchpad.net/juju [13:07] of course [13:07] only 160 ;) [13:08] https://bugs.launchpad.net/juju/+bugs?field.tag=production [13:08] those are the ones we (or maybe just I) think are needed to be fixed for production usage of juju. [13:09] wrtp: bug 829397 is the one I'm basically describing [13:09] <_mup_> Bug #829397: Link a service to a type of hardware and/or specific machine < https://launchpad.net/bugs/829397 > [13:09] SpamapS: that sounds like it's not something coming from the current environment, but from some specification of the service itself. [13:11] wrtp: when deploy happens, the current environment default is copied into the service def [13:12] ? [13:12] SpamapS: hmm. i think i prefer the idea of specifying an environment for a service rather than changing environments.yaml every time. but perhaps that's what would happen. [13:12] wrtp, yeah.. that's a major failing re copying the env per deploy to capture changes [13:13] its easy to fix that [13:13] and we need to do it for multi-user usage [13:13] all things in environments.yaml that are not global should be runtime overrideable and changeable via some kind of command [13:13] ami, machine type, etc. etc. [13:14] definitely. [13:14] we'll bootstrap with the environments yaml and thereafter use some variation of juju set to set env values [13:14] for things like default machine type etc, i'd imagine they would be (should be?) copied into the cloud only once, at bootstrap time [13:14] exactly [13:15] hazmat: but what about that one time where I want to add-unit x1.large .. just to handle today's ridiculous load.. then back to m1.small's [13:16] SpamapS, i'd like to go down the road of deploy cli parameters [13:16] SpamapS: maybe the add-unit command should allow specification of things like machine type [13:16] hazmat: yeah [13:16] let me override it at deploy time yes, but also let me override even that. [13:17] add-unit > deploy > bootstrap [13:17] SpamapS, ? huh [13:17] yeah [13:17] hazmat: if I deploy with one type, I may want to change that later [13:17] SpamapS, sounds good, we just run the risk of turning into knife if we expose all cli options [13:17] but their always optional [13:18] hazmat: knife? [13:18] so add-unit needs an override at the cli level, and I also need to be able to 'juju set service-name machine-type=foo' to change it permanently [13:18] hazmat: be religious about always having a sane default and you won't become knife. :) [13:18] SpamapS: and probably juju set-default machine-type=foo [13:18] wrtp, its the chef cli tool for management [13:18] juju deploy foo should always give you a workable foo [13:18] hazmat: ah thanks [13:20] anyway, I'm highly impressionable, and this recent "Amazon gets platforms" rant from G+ has me thinking about how juju sits as a platform [13:20] SpamapS, do tell [13:20] I'd say its better than some, but has a long way to go to be accessible [13:20] SpamapS, and setting that on a service would do what to existing units? [13:20] hazmat: leave 'em alone [13:20] SpamapS, we're working on it re accessible ;-) [13:20] right, I know a REST interface is in the works, +10 on that [13:20] i'm going to explore some api work today [13:21] yup [13:21] currently we talk directly to the zk instance in the cloud, right? [13:21] yes [13:21] wrtp, via ssh tunnel from the cli [13:21] which should definitely go away [13:21] wrtp, its painfully slow for some ops [13:21] on large installs, many roundtrips [13:22] yeah. a higher level interface would be better. [13:22] * SpamapS curses ceph's incessant "then find some way to copy this little dir to all other nodes" documentation [13:22] SpamapS, if only you had a distributed file system for that ;-) [13:22] so ironic [13:22] some kind of json rpc thing might not be too horrible [13:23] BSON ftw.. ;) [13:23] wrtp, yeah.. thats basically where i'm going .. effectively json rpc to expose the current cli as rest, and then some REST expose of resources [13:23] although the latter is probably superflous for the first cut [13:23] sounds plausible [13:24] niemeyer: hi! [13:24] wrtp: Yo [13:24] niemeyer, greetings [13:24] morning niemeyer [13:28] Hey folks [14:42] fwereade, the juju get stuff changed a little since the review to incorporate feedback, not sure if you wanted to have a second look before its merged [14:42] basically the separate option for schema went away, it just merges the schema with the current values for display now [14:50] hazmat, sounds like a nice idea actually [14:51] hazmat: I'll take a quick look [14:53] fwereade, thanks [14:53] fwereade, bcsaller, jimbaker also there's a trivial but critical fix resolved branch in review.. its only like 10 lines.. https://code.launchpad.net/~hazmat/juju/retry-sans-hook/+merge/79358 [14:54] SpamapS, are we tagging SRU bugs separately, or you planning on just grabbing trunk? [14:54] hazmat, taking a look [14:54] er.. fix for resolved [14:55] hazmat, +1, lgtm [14:57] hazmat, the docstring on command() needs updating, otherwise +1 [14:58] hazmat, for the other one, I don't follow the connection between the code change (which looks good) and the test change [14:59] <_mup_> juju/expose-retry r408 committed by jim.baker@canonical.com [14:59] <_mup_> Merged trunk [15:00] fwereade, the test was making the bad hook ... into a good one, and then calling resolved, by leaving it bad we verify the end state was reached without hook execution [15:01] hazmat: ok, I see now [15:01] hazmat: bit slow today :/ [15:01] hazmat: +1 [15:01] jimbaker, fwereade thanks [15:01] fwereade, its subtle one [15:10] <_mup_> juju/expose-retry r409 committed by jim.baker@canonical.com [15:10] <_mup_> Addressed review points [15:16] <_mup_> juju/trunk r405 committed by jim.baker@canonical.com [15:16] <_mup_> merge expose-retry [r=hazmat,fwereade][f=824279] [15:16] <_mup_> Ensure that port actions related to expose are retried, even when [15:16] <_mup_> unexpected exceptions are raised. [15:18] ok, that bug fix is merged in. i'm taking today off (my kids are out of school today instead of monday for some reason). yet another beautiful day here in colorado :) [15:19] <_mup_> juju/config-get r397 committed by kapil.thangavelu@canonical.com [15:19] <_mup_> cleanup docs [15:19] jimbaker, cheers, have a good one [15:21] i should also mention: when i walked my puppy this morning, i struck up a conversation about ubuntu with a new neighbor. i had my ubuntu pullover on for the chill morning. yet another big fan of ubuntu, good to see! [15:23] jimbaker, pleasing :) [15:49] <_mup_> juju/trunk r406 committed by kapil.thangavelu@canonical.com [15:49] <_mup_> merge config-get [r=fwereade,bcsaller][f=828326] [15:49] <_mup_> New juju subcommand for inspecting a service's current configuration and schema. [15:54] <_mup_> juju/trunk r407 committed by kapil.thangavelu@canonical.com [15:54] <_mup_> merge retry-sans-hook [r=fwereade,jimbaker][f=814987] [15:54] <_mup_> Fixes a bug with unit agent usage of resolved flags that caused [15:54] <_mup_> resolved to always execute hooks, instead of when hook retry was [15:54] <_mup_> explicitly specified. [16:07] happy weekends all, I'll probably drop in a bit later but I think I'm done for now [16:14] fwereade, have a good one [16:42] <_mup_> Bug #874423 was filed: rest/jsonrpc api < https://launchpad.net/bugs/874423 > [16:47] <_mup_> juju/rest-agent-api r402 committed by kapil.thangavelu@canonical.com [16:47] <_mup_> merge trunk [16:53] fwereade: enjoy [17:04] hazmat: I am going to grab trunk, but reconcile each bug in the changelog [17:04] SpamapS, ic, just wondering if we should putting in test cases for each bug thats not a feature [17:04] or tagging them in some way [17:05] hazmat: that would be helpful [17:06] hazmat: lets not get too procedure bound though.. since in this instance, we are "the community" .. we can more or less demand an SRU as long as we aren't flagrantly dropping refactors [17:06] hazmat: but it will go a long way to user trust that we don't break stuff in an update [17:21] <_mup_> Bug #874456 was filed: Initial Go juju commit. < https://launchpad.net/bugs/874456 > [17:22] hazmat: ^^ [17:26] is there any way to get the bzr diff web page to show the diffs between two revisions? [17:26] e.g. here http://bazaar.launchpad.net/~rogpeppe/juju/juju-implementation/changes [17:26] i'd like to see diffs between rev 11 and rev 15 [17:26] or do i have use a local tool for that? [17:28] hmm, i just managed to do it, but i'm not quite sure how! [17:36] wrtp, there's a couple of cli tools for this [17:36] wrtp, i highly recommend the qbzr plugin [17:36] plugin for what? [17:36] for bzr [17:36] ah [17:36] wrtp, its a qt ui on top of bzr, adds a bunch of 'q' prefixed commands [17:36] can i apt-get it? [17:37] wrtp, yes [17:37] i've been doing bzr diff --old x --new y --using diffuse [17:37] but it's not very satisfactory [17:37] wrtp bzr qbzr -r old..new [17:38] i just realised that i forgot to make the changes to my source that we discussed earlier [17:38] wrtp, when reviewing a branch i typically do from within the branch bzr qbzr -r ancestor:path_to_trunk [17:38] which shows you a diff of the branch changes against trunk [17:38] cool [17:38] er.. that should be qdiff not qbzr [17:38] * hazmat needs a nap [17:39] hazmat: when you say "path_to_trunk" do you mean the last trunk revision number? [17:39] wrtp, no i mean the physical path to trunk [17:40] ok. BTW what happens if there's a colon in the path name? [17:40] wrtp, thats for a review of a branch that's getting merged to trunk [17:40] wrtp, i dunno, never came up for me [17:40] wrtp, shouldn't be an issue [17:40] fairy nuff [17:41] wrtp, a double colon introduces some lookup behavior for a branch naming service used by some of the more interesting plugins, like pipeline [17:41] which automates a stack of changes [17:41] too much information probably [17:41] interesting [17:42] i'm slooowly getting there with the bzr stuff [17:42] wrtp, no worries [17:43] wrtp, we should probably a have new developer doc to describe the particulars of best practice bzr layouts for dev [17:44] that would be good [17:44] i've barely used revision control systems in their full modern glory [17:45] hazmat: qdiff FTW! [17:45] marvellous [17:46] i wish someone had told me that when i asked in the main canonical IRC channel... [17:46] wrtp, #bzr on freenode is pretty good stop for bzr questions [17:46] that main channel is just a presence thing, not a question place [17:46] right [17:48] i have to do another qdiff if i want to change the view to diff against another revision, right? [17:49] hazmat: BTW i got an email about a monthly report. where is that? [17:50] wrtp, priv msg [18:08] hazmat: ah, so r406 is definitely a new feature [18:10] SpamapS, backwards compatible but yes.. [18:10] SpamapS, is that an issue? [18:10] yes and no [18:12] <_mup_> Bug #874486 was filed: status should show all relations for multiply-related services < https://launchpad.net/bugs/874486 > [18:13] hazmat: normally we'd have "patch only" releases waved through the SRU process [18:14] hazmat: but since juju has no release process.. it will raise the eyebrows of the SRU team [18:14] SpamapS, i can yank, but we need a date for features to go in [18:14] no don't yank! [18:14] we're not purely in bug fix mode atm, we have open dev/refactor items up for this milestone [18:15] :) [18:15] SpamapS, its easy enough to do.. i just need to be clearer on sru scheduling is [18:15] Just means we have to choose between fighting for the SRU despite the features and cherry picking only the bug fixes [18:15] there is no schedule [18:15] SpamapS, my last understanding was we where going to be going through to 12.04 with srus [18:15] TECHNICALLY, SRU's are only for serious issues [18:16] but in universe, what is serious and what is not is entirely up to the community around the package... [18:16] SpamapS, so do we really need to SRU everything? [18:16] since that is .. us... ;) [18:16] SpamapS, seems like we should just point folks to a stable ppa? [18:17] as I've said, I think if we have some automated tests that verify we didn't break anhing (integration tests, not unit tests) than it should be fnie. [18:17] and we can put in a week or two hiatus on features merges, yank config-get, do the sru, open up the trunk to features, and put out a stable ppa for folks who the latest and greatest [18:17] ugh my SSH is bursty [18:17] get off facetime you durn ipad users here in the starbucks! [18:17] SpamapS, that's what this is for http://wtf.labix.org/ [18:18] SpamapS, it runs unit tests and a functional test [18:18] hazmat: that does not count, because those tests are in tree and may be changed to fit the release [18:18] The tests that work now, must work, unchanged, for every SRU we do [18:18] IMO a stable PPA would also need this level of care [18:19] SpamapS, true for the unit tests, but the functional tests haven't been touched, and don't they live in tree... jimbaker ? [18:19] er.. i don't think [18:19] They live in their own tree, but are under your control, and will likely be updated as juju is changed in backward incompatible ways. [18:20] SpamapS, they'll likely fail first, and we'll see that.. but okay, from a skeptical pov i can see why that's an issue [18:21] Also, they don't really exercise things enough to make me comfortable. I'd like to have all charms deploy, relate to at least one thing, exposed, configs changed, and then destroyed.. [18:21] SpamapS, okay... well you have some other ftests right? [18:21] I think I can automate that [18:21] i need to go back read jamespage's charm tester stuff [18:21] but first a nap b4 the sprint [18:22] I think jp's thing is an even higher order === hazmat is now known as hazaway [18:22] hazaway: sleeeeeep ;) [18:31] hey guys and gals, jst installed ubuntu 11.10, nice to see juju (aka ensemble ;) in there, I wanted to use my local machine, am I correct in thinking I have to setup basic lxc by itself first before trying to use charms ? === hazaway is now known as hazmat [19:14] zodiak: It looks like the docs for the local provider are not on the main url yet, but you can look at there here http://bit.ly/nsjdWu [19:15] zodiak: the local provider will tell you if its missing packages when you try to bootstrap it [19:43] can we get a bump on that RT ticket for the docs? [19:43] this will get worse as 11.10 users start looking into juju [19:57] SpamapS: there is also a branch with a troubleshooting script that collects info to help debug local provider issues and that includes an expansion of those docs as well [20:40] https://portal.admin.canonical.com/48456 [20:40] SpamapS, ^ it was 7 earlier today i thought [20:43] SpamapS, just sent in additional comment noting the urgency [20:44] now its 10 in the queue [20:49] we're dealing with the release turmoil [20:49] but I wonder if its getting bumped because nobody knows its part of the release [20:52] i added an additional note to that effect, and that we're fielding suppot requests because of the mismatch of the old docs to pkg in oneiric [21:26] Is the UI available for Hadoop after Juju is bootstrapped and the environment is setup? (i.e. master with a slave running) [21:33]