_mup_Bug #873907 was filed: Security group on EC2 does not open proper port <juju:New> < https://launchpad.net/bugs/873907 >07:39
_mup_Bug #873907: Security group on EC2 does not open proper port <juju:New> < https://launchpad.net/bugs/873907 >07:40
fwereadeshang: I think you need a "juju expose wordpress"08:06
fwereadeshang: and, I think you're right about the docs, someone mentioned them not getting updated08:07
fwereadeshang: I should probably try to find out how that's all meant to work :)08:07
shangfwereade: so after the add-relation, just run the expose command?08:08
* shang testing it08:08
fwereadeshang: that should be it08:09
fwereadeshang: here's the critical section of the user-tutorial docs, that hasn't landed for somereason: http://paste.ubuntu.com/707807/08:09
fwereadeshang: (sorry I missed you before)08:11
shangfwereade: no worries ;-)08:12
shangfwereade: 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:13
fwereadeshang: sadly I'm not really sure where to start looking for the magical documentation-updater08:15
fwereadeshang: it might be helpful, just for now, to grab trunk and "cd docs && make html"08:16
fwereadeshang: 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-updating08:17
fwereadeshang: if you confirm it's working for you, I'll mark the bug invalid and add an explanation08:19
shangfwereade: the expose command should take care of the security groups part, right?08:19
fwereadeshang: that's right08:19
fwereadeshang: still having problems?08:19
* shang tried the expose, but didn't see EC2 security group open the port08:20
shangfwereade: yeah08:20
* fwereade is perplexed and goes off to peer at the code08:20
fwereadeshang: did you get a "Service wordpress is exposed" message, but nothing happened?08:21
shangfwereade: from the status command, the wordpress open-ports:[]08:21
shangfwereade: yeah08:21
fwereadeshang: hmm; can you ssh to the bootstrap node and see if there's anything in the provisioning agent log?08:22
shangfwereade: it looks fine from where I can see it08:25
fwereadeshang: I remain perplexed :(08:29
fwereadeshang: let me see if I can repro08:29
shangfwereade: 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:38
fwereadeshang: hm, that then sounds like a problem with the charm08:39
shangfwereade: does the 3306 needs to be open for the service to be configured?08:40
fwereadeshang: I'm afraid I don't know, everything I've done has been on the provider side... I've not had much experience debugging charms08:41
shangfwereade: ah, ok...08:41
fwereadewrtp, sorry, I *completely* missed you08:43
fwereadeshang: just a suggestion08:43
wrtpfwereade: it was nothing anyway :-08:44
fwereadeshang: FWIW, deploys and exposes fine for me08:44
wrtpfwereade: BTW it was me that submitted that doc fix - isn't the documentation automatically updated?08:44
fwereadeshang: what's your juju-origin, and where did you get your charms from?08:45
fwereadewrtp: I recall jimbaker saying that the auto-updating wasn't working, but I was distracted and never followed up08:45
wrtpfwereade: i se08:45
shangfwereade: I was using the -> sudo apt-get install charm-tools; charm update examples; charm getall examples08:46
shangfwereade: let me refresh them, perhaps08:46
fwereadeshang: I'm not sure this is a relevant question, but just in case: do the charms you're deploying have a "revision" file?08:47
shangfwereade: yes, wordpress: rev. 3008:49
shangmysql rev. 10308:49
fwereadeshang: hm, I'm feeling pretty short on ideas :(08:53
shangfwereade: um... :(08:53
fwereadeshang: it might be worth trying to just deploy wordpress from scratch with a debug-log running08:54
fwereadeshang: (all I mean is that the problem isn't obvious, not that I'm giving up ;))08:54
shangfwereade: thanks! :D08:55
shangfwereade: Let me give that another try08:55
fwereadeshang: (open a separate terminal and "juju debug-log" before you deploy)08:55
shangfwereade: actually, I will run it on a different machine, maybe a fresh one and see if I can reproduce the issue08:56
fwereadeshang: cool, I'm about to try with the charms from charm-tools instead of trunk, see if I can repro that myself08:57
shangfwereade: thanks a lot08:59
shangfwereade: what is the command (or location) you get the charms?09:19
fwereadeshang: I've always just tested with the examples repo in trunk09:20
shangfwereade: ok09:20
fwereadeshang: fyi, I'm seeing the same problem09:26
fwereadeshang: no idea why yet ;)09:26
shangfwereade: so it is because the charm-tools09:26
fwereadeshang: that seems likely09:26
fwereadeshang: but I can't say exactly what yet09:27
shangfwereade: ok, at least we know what is causing it... which is a good start :-)09:27
fwereadeshang: yep -- thanks :)09:27
fwereadehazmat: morning09:48
hazmatjuju docs ticket is pending here fwiw.. https://portal.admin.canonical.com/48456 fwiw09:48
* hazmat tries to catch up on the back log09:49
fwereadehazmat: sweet09:49
hazmatfwereade, np09:50
hazmatshang, so you've got a service deployed and exposed and its not available?09:50
hazmatand juju status says its 'started'?09:50
hazmatshang, could you paste bin the output of 'juju status'09:51
hazmatfwereade, your seeing it too?09:51
fwereadehazmat: yeah, I guess it's something to do with the wordpress charm09:51
fwereadehazmat: I'm floundering along in a semi-helpful way, but this is the first charm I've made any attempt at debugging ;)09:52
hazmatshang, fwereade, so getting the unit log is pretty helpful to understanding unit specific problems09:52
hazmatshang, 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:53
hazmatshang, fwereade after the fact, you can use 'juju ssh wordpress/0' to login directly to the machine09:54
hazmatthe log for a unit lives at /var/lib/juju/units/wordpress-0/formula.log   i believe09:54
fwereadehazmat: hm, I was aware of the existence of juju ssh, I just never thought of actually using it :/09:55
hazmatfwereade, no worries, we have better tools as well..09:55
fwereadehazmat: debug-log is helpful, indeed09:55
shangfwereade: I ran the command: bzr branch lp:~charmers/charm/oneiric/mysql/trunk mysql09:55
shangfwereade: still getting the same issue09:56
shanghazmat: let me get u the logs09:56
hazmatfwereade, shang  real debugging.. is using juju debug-hooks wordpress/0, right after deploying the unit, it will set up a tmux session on the machine09:56
hazmatand pop up new windows for hook executions, with all the hook env variables setup. you can manually execute the hook or interactively edit/perform work09:57
hazmatits good to have a log first of what's wrong thouh09:57
shanghazmat: http://pastebin.ubuntu.com/707872/09:57
shanghazmat: ok, let me try again09:57
* hazmat tries with the local provider09:57
shangfwereade: which trunk did u use?09:58
fwereadeshang: sorry, I was referring to the examples in juju trunk09:59
shangfwereade: ah, ok09:59
hazmatshang, so status looks good,  getting the /var/lib/juju/units/<unit-name>/charm.log file  is probably needed to debug a charm further10:00
hazmatwe should probably have a special cli option builtin for this purpose10:00
shanghazmat: shouldn't the open-ports have the 80 in it?10:01
hazmatshang, it should10:01
hazmatshang, the wordpress charm in principia never does open-port10:02
hazmatwhich is why its broken10:03
hazmatshang, nice catch10:03
shanghazmat: so we start the wordpress instance10:04
shangand run the command:  juju debug-hooks wordpress/010:04
shangin another terminal to see the debug info?10:04
hazmatshang, 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 window10:07
* hazmat works on fixing principia wordpress10:09
fwereadehazmat: 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 diff10:10
fwereade(and I wasn't going to go and confidently pronounce how to fix the problem until I'd actually, y'know, done so)10:12
hazmatfwereade, 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 script10:14
hazmat100% of all open-port usage is non dynamic10:14
hazmatzero calls to close port10:15
* hazmat takes a deep breath and moves on10:15
fwereadehazmat: ah, I wondered about that10:15
shanghazmat: do you still need the charm.log?10:19
hazmatshang, no its cool, thanks though10:20
shanghazmat: ok, thanks10:21
_mup_juju/wordpress r50 committed by kapil.thangavelu@canonical.com10:22
_mup_pull from juju trunk, bashify, and include open-port call10:22
hazmatshang, if you update your branch/checkout of the formula it should work now10:24
hazmatshang, you'll need to destroy the service and redeploy with the new formula..  i didn't include an upgrade script10:25
shanghazmat: ok, let me try10:26
* hazmat should go back to sleep10:43
wrtphazmat: so, FindMachineSpec12:49
wrtphazmat: the problem with returning a list of possible specs is that it might be outrageously long12:49
wrtpwith all combinations of n parameters12:50
hazmatwrtp, yeah.. if its encapsulating all permutations12:50
wrtpyeah, so i think it might be better to expose some interface for finding possible values of each parameter12:50
hazmatwrtp, so i was thinking something a bit more simple..12:50
wrtpas in: possible RAM config, possible OS image, possible location, etc12:51
hazmatthink about driving a ui for example is a good scenario to keep in mind12:51
hazmatie. what would you want to see12:51
SpamapShm, this sounds a lot like facter12:51
wrtpSpamapS: facter?12:51
SpamapSfacter shows you RAM, OS, CPU#, etc.12:52
hazmatSpamapS, its more akin to dash or ec2 ui12:52
SpamapSits used a lot in puppet12:52
hazmatand chef12:52
SpamapSI missed the context tho12:52
wrtpSpamapS: i was trying to come up with a nice way of specifying a machine to start12:52
hazmatSpamapS, just discussing environment interfaces in go12:52
SpamapSoh like, you want to choose the machine type for the user?12:53
hazmatwrtp, so i wouldn't worry about the enumeration stuff for now, we can add that latter12:53
wrtphazmat: yeah12:53
hazmatSpamapS, no.. more like we want to give the user the option, and be able to validate it12:53
hazmator present a ui with options12:53
wrtpSpamapS: for reference, here's my first stab at a spec/doc for a Go interface to juju:  http://paste.ubuntu.com/707950/12:53
wrtphazmat: yeah, i'll keep it ultra simple for now, with the expectation of fleshing it out later12:54
hazmatSpamapS, but carry the user selection down to the provider12:54
SpamapSWow I'm quite confused12:54
SpamapSat what point do you get to ask users questions?12:54
hazmatSpamapS, right now its kinda broken we only grab it from the config file, a user specification is passed down to the provider12:54
SpamapS(at what point would we ever WANT users to be bothered with questions?)12:54
hazmatSpamapS, at deploy time12:54
hazmatSpamapS, optionally we fall back to env defaults12:55
hazmatSpamapS, i want to deploy cassandra on a HUGE machine ;-)12:55
wrtpi'm more imagining an intelligent choice based on a previously specified user constraint12:55
wrtprather than user interaction per se12:55
hazmatSpamapS, but haproxy on  a tiny machine12:55
hazmatthe size of cassandra is based somewhat on usage12:56
SpamapSHrm, I doubt users want to be stopped and asked about this12:56
SpamapSif they don't do --ram BIG or --machine-type m1.large  ... env default seems appropriate12:56
hazmatand that's what it will continue to be12:57
wrtpi'm thinking that the user probably wants to be able to verify that they won't be paying more than a certain amount of money12:57
SpamapSit would DEFINITELY be cool to map abstract arguments to provider machine types12:57
wrtpSpamapS: that's the idea12:57
SpamapS--budget-per-hour 0.5012:57
SpamapSBut to ask the user.. fail12:57
wrtpi think that's pretty crucial actually12:57
SpamapSjust say "Cannot determine best machine type, options { x, y , z }" and exit(-1)12:58
wrtpSpamapS: yeah. although the user should be able to iterate without spending, i think. explore the possibilities.12:58
SpamapSthis sounds like we're getting way ahead of being awesome at what we currently do. ;)12:58
wrtpSpamapS: more like: "no machine type available that meets your budget constraints" perhaps12:58
wrtpSpamapS: this was all spawned from discussion about the FindImage method in the go docs i posted above12:59
SpamapSas a first iteration, just adding --machine-type XXXXXX would be a quantum leap12:59
wrtpSpamapS: yeah, we're way ahead of ourselves, but it probably helps to have an idea of where we might go12:59
SpamapSand also being able to change the machine type for a running service would be good13:00
wrtpand i do think being able to plan your budget (and explore different budgets across different providers) is going to be important in the long run13:00
wrtpSpamapS: is that actually possible?13:01
SpamapSwrtp: sure, change it, then issue a "replace units" command that would slowly remove the old type and add the new type13:01
SpamapSassuming its a service that has the ability to do that.. :)13:02
SpamapSif not.. well then.. don't do that!13:02
SpamapSpoint being, add-unit just uses whatever was the env default at the time of deploy..13:02
wrtpSpamapS: so {add-unit; remove-unit}should do the job?13:03
wrtpwhere remove-unit is removing an old unit13:04
wrtpnot the one just added13:04
SpamapSsorry 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 tho13:04
* SpamapS is just grasping at anything that will distract him from trying to figure out how to elastically grow a ceph cluster13:05
wrtpSpamapS: 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:05
wrtpis there a list anywhere of "current juju shortcomings that we'd like to address"?13:06
SpamapSwrtp: 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 ZK13:06
SpamapSwrtp: the unit should be able to provide an overriding clue13:07
SpamapSwrtp: https://bugs.launchpad.net/juju13:07
wrtpof course13:07
SpamapSonly 160 ;)13:07
SpamapSthose are the ones we (or maybe just I) think are needed to be fixed for production usage of juju.13:08
SpamapSwrtp: bug 829397 is the one I'm basically describing13:09
_mup_Bug #829397: Link a service to a type of hardware and/or specific machine <production> <juju:Confirmed> < https://launchpad.net/bugs/829397 >13:09
wrtpSpamapS: that sounds like it's not something coming from the current environment, but from some specification of the service itself.13:09
SpamapSwrtp: when deploy happens, the current environment default is copied into the service def13:11
wrtpSpamapS: 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
hazmatwrtp, yeah.. that's a major failing re copying the env per deploy to capture changes13:12
hazmatits easy to fix that13:13
hazmatand we need to do it for multi-user usage13:13
SpamapSall things in environments.yaml that are not global should be runtime overrideable and changeable via some kind of command13:13
SpamapSami, machine type, etc. etc.13:13
hazmatwe'll bootstrap with the environments yaml and thereafter use some variation of juju set to set env values13:14
wrtpfor things like default machine type etc, i'd imagine they would be (should be?) copied into the cloud only once, at bootstrap time13:14
SpamapShazmat: 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's13:15
hazmatSpamapS, i'd like to go down the road of deploy cli parameters13:16
wrtpSpamapS: maybe the add-unit command should allow specification of things like machine type13:16
wrtphazmat: yeah13:16
SpamapSlet me override it at deploy time yes, but also let me override even that.13:16
wrtpadd-unit > deploy > bootstrap13:17
hazmatSpamapS, ? huh13:17
SpamapShazmat: if I deploy with one type, I may want to change that later13:17
hazmatSpamapS, sounds good, we just run the risk of turning into knife if we expose all cli options13:17
hazmatbut their always optional13:17
wrtphazmat: knife?13:18
SpamapSso 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 permanently13:18
SpamapShazmat: be religious about always having a sane default and you won't become knife. :)13:18
wrtpSpamapS: and probably juju set-default machine-type=foo13:18
hazmatwrtp, its the chef cli tool for management13:18
SpamapSjuju deploy foo should always give you a workable foo13:18
wrtphazmat: ah thanks13:18
SpamapSanyway, I'm highly impressionable, and this recent "Amazon gets platforms" rant from G+ has me thinking about how juju sits as a platform13:20
hazmatSpamapS, do tell13:20
SpamapSI'd say its better than some, but has a long way to go to be accessible13:20
hazmatSpamapS, and setting that on a service would do what to existing units?13:20
SpamapShazmat: leave 'em alone13:20
hazmatSpamapS, we're working on it re accessible ;-)13:20
SpamapSright, I know a REST interface is in the works, +10 on that13:20
hazmati'm going to explore some api work today13:20
wrtpcurrently we talk directly to the zk instance in the cloud, right?13:21
hazmatwrtp, via ssh tunnel from the cli13:21
SpamapSwhich should definitely go away13:21
hazmatwrtp, its painfully slow for some ops13:21
hazmaton large installs, many roundtrips13:21
wrtpyeah. 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" documentation13:22
hazmatSpamapS, if only you had a distributed file system for that ;-)13:22
SpamapSso ironic13:22
wrtpsome kind of json rpc thing might not be too horrible13:22
SpamapSBSON ftw.. ;)13:23
hazmatwrtp, yeah.. thats basically where i'm going .. effectively json rpc to expose the current cli as rest, and then some REST expose of resources13:23
hazmatalthough the latter is probably superflous for the first cut13:23
wrtpsounds plausible13:23
wrtpniemeyer: hi!13:24
niemeyerwrtp: Yo13:24
hazmatniemeyer, greetings13:24
fwereademorning niemeyer13:24
niemeyerHey folks13:28
hazmatfwereade, 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 merged14:42
hazmatbasically the separate option for schema went away, it just merges the schema with the current values for display now14:42
fwereadehazmat, sounds like a nice idea actually14:50
fwereadehazmat: I'll take a quick look14:51
hazmatfwereade, thanks14:53
hazmatfwereade, 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/7935814:53
hazmatSpamapS, are we tagging SRU bugs separately, or you planning on just grabbing trunk?14:54
jimbaker hazmat, taking a look14:54
hazmater.. fix for resolved14:54
jimbakerhazmat, +1, lgtm14:55
fwereadehazmat, the docstring on command() needs updating, otherwise +114:57
fwereadehazmat, for the other one, I don't follow the connection between the code change (which looks good) and the test change14:58
_mup_juju/expose-retry r408 committed by jim.baker@canonical.com14:59
_mup_Merged trunk14:59
hazmatfwereade, 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 execution15:00
fwereadehazmat: ok, I see now15:01
fwereadehazmat: bit slow today :/15:01
fwereadehazmat: +115:01
hazmatjimbaker, fwereade thanks15:01
hazmatfwereade, its subtle one15:01
_mup_juju/expose-retry r409 committed by jim.baker@canonical.com15:10
_mup_Addressed review points15:10
_mup_juju/trunk r405 committed by jim.baker@canonical.com15:16
_mup_merge expose-retry [r=hazmat,fwereade][f=824279]15:16
_mup_Ensure that port actions related to expose are retried, even when15:16
_mup_unexpected exceptions are raised.15:16
jimbakerok, 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:18
_mup_juju/config-get r397 committed by kapil.thangavelu@canonical.com15:19
_mup_cleanup docs15:19
hazmatjimbaker, cheers, have a good one15:19
jimbakeri 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:21
fwereadejimbaker, pleasing :)15:23
_mup_juju/trunk r406 committed by kapil.thangavelu@canonical.com15: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:49
_mup_juju/trunk r407 committed by kapil.thangavelu@canonical.com15: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 caused15:54
_mup_resolved to always execute hooks, instead of when hook retry was15:54
_mup_explicitly specified.15:54
fwereadehappy weekends all, I'll probably drop in a bit later but I think I'm done for now16:07
hazmatfwereade, have a good one16:14
_mup_Bug #874423 was filed: rest/jsonrpc api  <juju:New> < https://launchpad.net/bugs/874423 >16:42
_mup_juju/rest-agent-api r402 committed by kapil.thangavelu@canonical.com16:47
_mup_merge trunk16:47
wrtpfwereade: enjoy16:53
SpamapShazmat: I am going to grab trunk, but reconcile each bug in the changelog17:04
hazmatSpamapS, ic, just wondering if  we should putting in test cases for each bug thats not a feature17:04
hazmator tagging them in some way17:04
SpamapShazmat: that would be helpful17:05
SpamapShazmat: 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 refactors17:06
SpamapShazmat: but it will go a long way to user trust that we don't break stuff in an update17:06
_mup_Bug #874456 was filed: Initial Go juju commit. <juju:In Progress by rogpeppe> < https://launchpad.net/bugs/874456 >17:21
wrtphazmat: ^^17:22
wrtpis there any way to get the bzr diff web page to show the diffs between two revisions?17:26
wrtpe.g. here http://bazaar.launchpad.net/~rogpeppe/juju/juju-implementation/changes17:26
wrtpi'd like to see diffs between rev 11 and rev 1517:26
wrtpor do i have use a local tool for that?17:26
wrtphmm, i just managed to do it, but i'm not quite sure how!17:28
hazmatwrtp, there's a couple of cli tools for this17:36
hazmatwrtp, i highly recommend the qbzr plugin17:36
wrtpplugin for what?17:36
hazmatfor bzr17:36
hazmatwrtp, its a qt ui on top of bzr, adds a bunch of 'q' prefixed commands17:36
wrtpcan i apt-get it?17:36
hazmatwrtp, yes17:37
wrtpi've been doing bzr diff --old x --new y --using diffuse17:37
wrtpbut it's not very satisfactory17:37
hazmatwrtp bzr qbzr -r old..new17:37
wrtpi just realised that i forgot to make the changes to my source that we discussed earlier17:38
hazmatwrtp,  when reviewing a branch i typically do  from within the branch bzr qbzr -r ancestor:path_to_trunk17:38
hazmatwhich shows you a diff of the branch changes against trunk17:38
hazmater.. that should be qdiff not qbzr17:38
* hazmat needs a nap17:38
wrtphazmat: when you say "path_to_trunk" do you mean the last trunk revision number?17:39
hazmatwrtp, no i mean the physical path to trunk17:39
wrtpok. BTW what happens if there's a colon in the path name?17:40
hazmatwrtp, thats for a review of  a branch that's getting merged to trunk17:40
hazmatwrtp, i dunno, never came up for me17:40
hazmatwrtp, shouldn't be an issue17:40
wrtpfairy nuff17:40
hazmatwrtp, a double colon introduces some lookup behavior for a branch naming service  used by some of the more interesting plugins, like pipeline17:41
hazmatwhich automates a stack of changes17:41
hazmattoo much information probably17:41
wrtpi'm slooowly getting there with the bzr stuff17:42
hazmatwrtp, no worries17:42
hazmatwrtp, we should probably a have new developer doc to describe the particulars of best practice bzr layouts for dev17:43
wrtpthat would be good17:44
wrtpi've barely used revision control systems in their full modern glory17:44
wrtphazmat: qdiff FTW!17:45
wrtpi wish someone had told me that when i asked in the main canonical IRC channel...17:46
hazmatwrtp, #bzr on freenode is pretty good stop for bzr questions17:46
hazmatthat main channel is just a presence thing, not a question place17:46
wrtpi have to do another qdiff if i want to change the view to diff against another revision, right?17:48
wrtphazmat: BTW i got an email about a monthly report. where is that?17:49
hazmatwrtp, priv msg17:50
SpamapShazmat: ah, so r406 is definitely a new feature18:08
hazmatSpamapS, backwards compatible but yes..18:10
hazmatSpamapS, is that an issue?18:10
SpamapSyes and no18:10
_mup_Bug #874486 was filed: status should show all relations for multiply-related services <juju:New> < https://launchpad.net/bugs/874486 >18:12
SpamapShazmat: normally we'd have "patch only" releases waved through the SRU process18:13
SpamapShazmat: but since juju has no release process.. it will raise the eyebrows of the SRU team18:14
hazmatSpamapS, i can yank, but we need a date for features to go in18:14
SpamapSno don't yank!18:14
hazmatwe're not purely in bug fix mode atm, we have open dev/refactor items up for this milestone18:14
hazmatSpamapS, its easy enough to do.. i just need to be clearer on sru scheduling is18:15
SpamapSJust means we have to choose between fighting for the SRU despite the features and cherry picking only the bug fixes18:15
SpamapSthere is no schedule18:15
hazmatSpamapS, my last understanding was we where going to be going through to 12.04 with srus18:15
SpamapSTECHNICALLY, SRU's are only for serious issues18:15
SpamapSbut in universe, what is serious and what is not is entirely up to the community around the package...18:16
hazmatSpamapS, so do we really need to SRU everything?18:16
SpamapSsince that is .. us... ;)18:16
hazmatSpamapS, seems like we should just point folks to a stable ppa?18:16
SpamapSas 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
hazmatand 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 greatest18:17
SpamapSugh my SSH is bursty18:17
SpamapSget off facetime you durn ipad users here in the starbucks!18:17
hazmatSpamapS,  that's what this is for http://wtf.labix.org/18:17
hazmatSpamapS, it runs unit tests and a functional test18:18
SpamapShazmat: that does not count, because those tests are in tree and may be changed to fit the release18:18
SpamapSThe tests that work now, must work, unchanged, for every SRU we do18:18
SpamapSIMO a stable PPA would also need this level of care18:18
hazmatSpamapS, true for the unit tests, but the functional tests haven't been touched, and don't they live in tree... jimbaker ?18:19
hazmater.. i don't think18:19
SpamapSThey live in their own tree, but are under your control, and will likely be updated as juju is changed in backward incompatible ways.18:19
hazmatSpamapS, they'll likely fail first, and we'll see that.. but okay, from a skeptical pov i can see why that's an issue18:20
SpamapSAlso, 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
hazmatSpamapS, okay... well you have some other ftests right?18:21
SpamapSI think I can automate that18:21
hazmati need to go back read jamespage's charm tester stuff18:21
hazmatbut first a nap b4 the sprint18:21
SpamapSI think jp's thing is an even higher order18:22
=== hazmat is now known as hazaway
SpamapShazaway: sleeeeeep ;)18:22
zodiakhey 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 ?18:31
=== hazaway is now known as hazmat
bcsallerzodiak: 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/nsjdWu19:14
bcsallerzodiak: the local provider will tell you if its missing packages when you try to bootstrap it19:15
SpamapScan we get a bump on that RT ticket for the docs?19:43
SpamapSthis will get worse as 11.10 users start looking into juju19:43
bcsallerSpamapS: 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 well19:57
hazmatSpamapS, ^ it was 7 earlier today i thought20:40
hazmatSpamapS, just sent in additional comment noting the urgency20:43
hazmatnow its 10 in the queue20:44
SpamapSwe're dealing with the release turmoil20:49
SpamapSbut I wonder if its getting bumped because nobody knows its part of the release20:49
hazmati 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 oneiric20:52
evandevIs the UI available for Hadoop after Juju is bootstrapped and the environment is setup? (i.e. master with a slave running)21:26
SpamapSevandev: which "UI" would you be referring to?21:33
SpamapSevandev: and also, which charm? the one at lp:charm/oneiric/hadoop-master ?21:33
evandevwell im using a local charm from http://github.com/charms/hadoop-master & hadoop-slave21:34
evandevand by UI I mean GUI ports 50030 / 50070 / 5007521:34
evandevThrough those charms tho hadoop is not even getting installed so I guess thats why im running into an error21:36
SpamapSevandev: I believe the charms do open those ports21:43
SpamapSevandev: are you seeing an error in the install step?21:43
evandevHadoop is not being installed on the hadoop-master/021:44
SpamapSevandev: did you look at /var/lib/juju/units/haddop-master-0/charm.log ?21:45
SpamapSevandev: did you look at /var/lib/juju/units/hadoop-master-0/charm.log ?21:46
SpamapSi kan spel21:46
SpamapSevandev: also you probably need to 'juju expose hadoop-master' or the firewall will block access21:47
evandevThat was it.21:48
evandevThanks SpamapS very much21:48
SpamapSevandev: no problem. Note that there are a bunch more charms at https://code.launchpad.net/charm21:49
SpamapSevandev: the github page is just an experiment by m_3 ;)21:49
SpamapSm_3: ^^21:49
evandevYea I want to modify a charm to install the CDH3 distrobution from cloudera21:49
evandevBut thank you again. I really appreciate it21:51
zodiakbcsaller, hrm, so, whenever I do a juju deploy --repository=juju-charms local:memcached using lxc, the state never changes from null and I don't get any ip22:32
bcsallerzodiak: maybe you could download and run this script http://bazaar.launchpad.net/~bcsaller/juju/local-troubleshooting/view/head:/misc/devel-tools/juju-inspect-local-provider22:35
zodiakdownloading (and thanks)22:35
zodiakpastie up the output I take it ? :)22:36
bcsalleryeah, that would be great22:36
zodiakit's probably something 'duh' .. and if it is, that's awesome. I don't mind being an idiot :D22:37
m_3SpamapS: dang, those are still up from the openstack demo... different charms for natty -vs- oneiric... I'll fix it22:40
m_3the real fix is to get the oneiric hadoop packages into the partner ppa22:42
bcsallerzodiak: other than seeing a typo in that script I don't see the issue yet, still looking though22:43
zodiakbcsaller, thanks.. sorry about all this :)22:43
bcsallerzodiak: no problem at all22:43
bcsallerzodiak: it looks like its building out the initial image cache in /var/cache/lxc as expected, but we'd then expect an image to later appear when lxc-ls is run22:44
bcsallerzodiak: is this still running or have you stopped it with a destroy environment?22:45
zodiakI have done bootstrap and destroy a number of times22:48
zodiakhow long should I wait for the state to change ? I waited like 45 minutes earlier22:48
zodiakand I am on FiOS so.. ;)22:49
bcsallerzodiak: ... it shouldn't take that long at all. So this script is new, this is helpful in terms of me finding out what info to gather. I'm going to include some changes and maybe we can try running it again :)22:50
zodiaklet me try and rm -rf the cache/lxc and bootstrap again22:51
zodiakI think it's something permissions related22:51
zodiakI am doing juju bootstrap as my user, not a problem. do a deploy and /var/cache/juju becomes owned by root22:52
bcsallerzodiak: yes, local provider will ask for permissions via sudo when it needs them22:57
bcsallerlxc interactions happen as root22:57
zodiakthen shut my mouth :D22:57
bcsallerzodiak: in your ~/.juju/environments.yaml you defined a data-dir for the local provider, is the bootstrap creating a directory as expected in that data-dir?22:58
zodiaklet me double check22:58
zodiakit is indeed22:58
zodiakcharms, files, state and units (and a nice log ;)22:58
bcsallerthe machine-agent.log, could you paste the last 20 lines or so22:59
zodiaksurely.. want me to wipe that and lxc cache clean first ?22:59
bcsallerzodiak: can't hurt :) will take a little longer23:00
zodiakeh.. I am at work.. not a problem ;)23:00
hazmatzodiak, it would be good to pastebin the master-customize.log it sounds like23:03
hazmatany problem creating units23:03
hazmatis typically related23:03
bcsallerhazmat: I was making sure it was getting that far first23:05
bcsallerlxc-ls returned nothing, implying no template23:05
hazmatbcsaller, oh.. yeah.. machine-agent.log indeed23:06
* hazmat goes back to mediawiki hacking and lurking23:06
bcsallerhazmat: :)23:06
bcsallerhazmat: you're back home after this weekend, right?23:07
hazmatbcsaller, monday late night23:08
bcsallerI'd like to schedule some time, maybe Tues to talk about the Co-lo stuff a little, I've been working through the old comments and some newer thinking and would like to go over it with you23:08
zodiakbcsaller, the last line of the machine-agent.log is looking hopeful ..23:10
zodiak2011-10-14 16:05:32,853: unit.deploy@DEBUG: Creating master container...23:10
zodiakwill let you know how it goes ;)23:10
bcsallerthat is a good sign23:10
hazmatbcsaller, sounds good23:10
bcsallerzodiak: soon lxc-ls should show that it has a master template23:10
bcsalleronce you have this working subsequent deployments are much faster23:11
zodiakyup. it does indeed.23:11
zodiaklxc-ls does show 'stef-sample_local-0-template23:11
zodiakbut juju status still says state:null and no ip address23:11
bcsallerthats expected at this point23:12
zodiakawesome :)23:12
bcsallerit works by creating a template23:12
bcsallerand then it clones that for unit deployments23:12
bcsallerbut creating the master the first time can take a little while23:12
zodiakah. so even though lxc-ls .. gotcha23:12
bcsallernow, kapils suggestion will become important though, in data-dir/units there a master-customize.log23:13
bcsallerthat that will provide insight into the creation of the master container23:13
hazmata good sanity check if its done .. is if ps aux | grep lxc23:14
hazmathas any output23:14
hazmatif not...  lxc-ls should show stuff23:14
bcsallerhazmat: in the troubleshooting section of the doc I recommend: pgrep lxc| head -1| xargs watch pstree -alU23:15
zodiakps auxfw to the rescue.. still chunking away :)23:15
bcsallerzodiak: yeah, the output of the master-customize.log is only written to the log file at the end of the run, but it will help us if this doesn't work23:18
zodiakbcsaller, okay, so, machine-agent.log says 'juju.agents.machine@INFO: Started service unit memcached/0'23:22
bcsallerzodiak: thats a good sign23:22
zodiakwhich is nice.. looking good there..23:22
zodiakbut nothing in the units/ folder23:23
bcsallerand juju status hasn't changed?23:23
zodiakand state is still null :\23:23
bcsallerdoes "juju ssh memcached/0" work?23:24
zodiaknope. sticks on 'waiting for unit to come up'23:25
hazmatbcsaller, unit agent grep, and manual chroot and upstart perhaps23:25
zodiakI didn't do any AWS on this machine before, I don't need to setup them if I am using lxc correct ?23:25
hazmatzodiak, correct23:25
zodiakhazmat, danke.23:25
zodiaksorry about all this guys+gals :(23:25
bcsallerhazmat: yeah, I think we should be able to ssh as ubuntu into the box23:26
bcsallerzodiak: happy to help get this working23:26
bcsallerzodiak: we want to get the ip address of the unit so we can ssh in23:27
bcsallerzodiak: did status have it yet or no?23:27
zodiaknope.. still no status :(23:27
bcsallerthere are other ways23:27
bcsallerI usually use nmap -sp but you might not have that installed23:28
bcsallerlooks like this should work for you though23:28
zodiakyup.. I have nmap23:28
bcsallerhost stef-sample_local-memcached-0
bcsalleroh, with nmap it was -sP (uppercase) anyway23:29
zodiakgot it (the nmap I mean)23:30
zodiakand yes .. .1 is up23:30
bcsaller1 is the host machine, if there isn't another ip on that bridge then it didn't bring up another container yet23:31
bcsallerwhat does lxc-ls show now?23:31
zodiakah ... 228 in that case23:31
hazmat.1 is the bridge address, also has dnsmasq..23:31
bcsallerahh, ok23:31
hazmatzodiak can you login into that .228 address (ubuntu@)23:31
bcsallerssh ubuntu@ should get you into that container23:31
zodiakit does indeed :D23:32
zodiakstatus still reports it as null state and no ip (fyi)23:32
bcsallerthe ubuntu account will have full sudo access and can look at the logs in /var/log/juju which should help us understand23:32
zodiakgotcha. let me take a look see23:32
zodiakthat log directory is empty23:33
bcsallerin other shell can you run the script I gave you before as root with stef-sample_local-memcached-0 as the cmdline argument23:34
bcsallerit should pull /etc/juju/juju.conf and so on to help us review that23:34
bcsallerin the container we can also check /etc/init for the upstart job for the charm23:35
bcsallerI suspect that the charm itself is failing23:35
hazmatls: cannot access /usr/lib/juju/juju: No such file or directory23:36
zodiakbad luck on my part choosing that charm ?23:36
hazmatbcsaller, ^23:36
bcsallerzodiak: the examples that come with juju, mysql and wordpress work23:36
bcsallerhazmat: I saw that, but the juju package doesn't appear to be installed23:36
hazmatbcsaller, that's the root issue isn't it23:36
bcsallerI think so, yes, wondering how that happened. We'd been using the PPA for most of the testing, but that should be working as well...23:37
hazmatzodiak, can you try putting juju-origin: ppa in environments.yaml... destroy-environment && bootstrap23:38
hazmatdon't need to clear out the cache23:38
hazmatthe lxc cache that is23:38
zodiakhazmat, can do.. one sec23:38
bcsallerzodiak: the master-customize.log was never written though, right?23:39
zodiakif nothing else, I am getting used to juju :)23:39
bcsallerin data-dir/units23:39
zodiakbcsaller, correct23:39
bcsallerthat should have indicated if there was an issue installing the package.. .oh well. setting it PPA as suggested should work23:39
zodiakwhere do I grab the charms from ?23:40
hazmatzodiak, can you pastebin the entire master-customize.log23:40
zodiakmaybe it's something out of date there ?23:40
hazmatthis is before the charm is touched even, so thats not an issue atm23:41
hazmatbut the charms are in bzr on launchpad..23:41
zodiakokay, sorry, where is the master-customize.log ?23:42
hazmata listing of them is at https://code.launchpad.net/charm23:42
bcsallerin your data-dir/units directory23:42
bcsallerbut you said it wasn't there23:42
zodiakit's there after doing the ppa and destroy/bootstrap23:43
hazmatits definitely there if its on to creatin units23:43
zodiaklet me pastie. one sec.23:43
bcsallerzodiak: I also pushed a newer version of the script23:45
zodiakbcsaller, okay... although take a look at the pastie.. it appears to be a bridging issue from the lxc .. at least, that's what it looks like :(23:46
bcsallerzodiak: did you install apt-cacher-ng and is it running?23:46
bcsaller192.168.122.1:3142 in a browser should tell you right away23:47
bcsallerthere is a 'stats' link on the page you should see if its working which show you how the apt cache is working23:48
bcsallerzodiak: was that running or not? from the log it appears not to have been, which is odd because the local provider checks that its installed (but not running I guess)23:54
hazmat zodiak ps aux | grep apt-cacher .. shows something ?23:59
hazmatin the host23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!