#juju-dev 2012-04-02 <niemeyer> Hello there! <TheMue> niemeyer: moin <niemeyer> mthaddon: ping <mthaddon> niemeyer: hi hi <niemeyer> mthaddon: Yo <niemeyer> mthaddon: How're things going in the store? <mthaddon> niemeyer: I posted an update to the RT with the things we still need to look at (mostly around deployments and mongo authentication) <niemeyer> mthaddon: I've seen it <niemeyer> mthaddon: re. auth, you can actually put auth data in the command line arg already <mthaddon> ah cool - how do we do that? and will that mean the auth info shows up in "ps"? <mthaddon> niemeyer: ^ <niemeyer> mthaddon: Hmm, yeah, potentially <niemeyer> mthaddon: You can use a URL such as mongodb://foo:bar@address/juju <mthaddon> niemeyer: can we pull from a config file instead? otherwise it kind of defeats the point of having any auth info :) <niemeyer> mthaddon: Yeah, of course <mthaddon> great <niemeyer> mthaddon: Will have that ready to go in a moment.. have your read about protecting a db? <niemeyer> mthaddon: You can workaround it, btw.. even if it's boring.. but I'm happy to make that saner for you <mthaddon> niemeyer: I'm happy to work around it if there's a good way of doing that - what is that? <niemeyer> mthaddon: Just testing now to see if I'm not speaking crack <mthaddon> k, thx <niemeyer> mthaddon: Nevermind, I am crazy * mthaddon not minding <niemeyer> mthaddon: Either way, I'd be unhappy with such a hack.. I'll have a more proper fix <niemeyer> mthaddon: Btw, meanwhile, have you read about the auth stuff on dbs? <mthaddon> niemeyer: the docs don't seem very in depth, but I have read http://www.mongodb.org/display/DOCS/Security+and+Authentication <mthaddon> why on earth you'd have an "auth = True/False" and a "noauth = True/False" option in the configs seems beyond me... <niemeyer> mthaddon: Cool, that should be enough <niemeyer> mthaddon: You mean to have both, or to have it at all? <mthaddon> niemeyer: having both - can only lead to confusion <niemeyer> mthaddon: Yeah, I'd guess it's something to do with the overriding of defaults <niemeyer> mthaddon: But, I've never used both, so have no idea really <TheMue> so, leaving today for my Go talk at the GTUG <niemeyer> TheMue: Ah, super, good luck there, and please let us know how it goes <TheMue> niemeyer: sure, and I'll add the presentation to slideshare later <niemeyer> TheMue: Sweet <niemeyer> robbiew: Is your wifi going bad as well? <hazmat> jimbaker, ping <jimbaker> hazmat, hi <hazmat> hi jimbaker just going through rel hook context, looks good, but one question i had was if there was testing around rel mutation during the execution <hazmat> ie. a new rel added post the invoker setup, or one removed <jimbaker> hazmat, there's testing of adding a relation. there should be one for removing a relation, as you mention <jimbaker> hazmat, i can readily add that <hazmat> jimbaker, can you point me to it? <hazmat> jimbaker, the add one that is.. i'm also wondering about membership consistent views on membership mutation <hazmat> like if one relation has a unit, and another should have it, but its been removed during the execution. <jimbaker> hazmat, see test_get_relation_hook_context <jimbaker> i didn't address membership <hazmat> jimbaker, yeah.. its tricky, we don't want to fetch all units of all rels for each hook exec, but it does make a hook's perspective on membership possibly inconsistent when working across multiple relations <jimbaker> hazmat, yes <hazmat> jimbaker, so effectively we do already know the memberships <hazmat> their in the respective schedulers <niemeyer> Oops.. no Go reviewers.. <jimbaker> hazmat, the scheduler does pass in the membership to the implied relation hook context <jimbaker> my proposal continues the current practice of caching it on first read, in this case as would be done with relation-list <niemeyer> mthaddon: Can you please check this out and include a LGTM in case it actually Looks Good To You? https://codereview.appspot.com/5967064 <mthaddon> niemeyer: can you update the RT with what you want me to do? - currently otp <niemeyer> mthaddon: Cool, nevermind.. will just submit as I have to leave for lunch in a few minutes <hazmat> jimbaker, sure.. but we could have consistent membership if we could pass the other schedulers membership sets to their respective hook contexts. <hazmat> jimbaker, i'm fine with that being in another branch, but what do you think of the approach? <jimbaker> hazmat, there's still no guarantee that you have a consistent view of membership - only that you have the other schedulers cached membership <hazmat> jimbaker, the schedulers cached membership is point in time consistent with what the unit has been informed of to date <hazmat> its altered as various hooks are executed.. hmm.. although the execution representing the membership change may merely be queued, such that the membership change notification is pending but not actualized/known to the charm even though its represented in the cached set. <jimbaker> hazmat, right, scheduling is occurring differently than membership watches - there are effectively 2 queues here <hazmat> jimbaker, um.. not true per se.. scheduling is the target of the membership & change watchers, but that's separate from execution. the cache is consistent wrt to execution of hooks for a single context, but its altered prior to the execution.. that's a trivial to fix.. it can do the cache alteration after successful exec and pass in the modified set to the execution, and then it could be used as a membership set for other contexts. <hazmat> jimbaker, but yes there are two queues.. the scheduler queue, and the hook executor queue <niemeyer> mthaddon: Change submitted, config file support is ready, RT updated <niemeyer> and lunch time <niemeyer> biab <mthaddon> niemeyer: cool, thx <niemeyer> mthaddon: np, I'm back too <niemeyer> mthaddon: Let me know how it goes, please <hazmat> jimbaker, is there a reason why the relation-id-option has a merge target of the relation-hook-context? <hazmat> bcsaller, this reitveld diff looks borked.. like trunk hadn't been merged yet to the parent/prerequisite https://codereview.appspot.com/5845061/ <jimbaker> hazmat, that's mysterious to me... i simply used lbox propose -req to specify that it required lp:~jimbaker/juju/relation-ids-command as prereq <jimbaker> does lbox work with multiple levels of prereqs? <jimbaker> that was my assumption, since we use that in lp <bcsaller> hazmat: yeah, it was merged before, but I'll look at it again, I noticed this this morning as well <hazmat> jimbaker, it justs a pre-req, and does the diff against that, but it does have a -target option that result in changing the merge target from its default, but the default may indeed be the branch's pull location <hazmat> not sure <jimbaker> bcsaller, have you been able to use lbox for stacked branches? <bcsaller> jimbaker: my branches got so tangled up its hard to know where the issue is :-/ <bcsaller> jimbaker: so maybe... :) <jimbaker> bcsaller, understood <hazmat> jimbaker, are you using bzr-pipeline? <jimbaker> hazmat, i do not <hazmat> bcsaller, the status changes look very nice <bcsaller> hazmat: cool <hazmat> bcsaller, can you re propose it via lbox to clean up the diff? <bcsaller> I don't know if that will clean it up, but I can try <hazmat> bcsaller, assuming the parent/pre-requisite has parent merged, it should <hazmat> er.. has trunk merged <hazmat> off to an appt, bbiab <jimbaker> biab, my son fractured his wrist and needs a cast put on <niemeyer> Time to reboot.. <niemeyer> Hmm.. things looking better in Unity now <niemeyer> I wonder if the network issues have been fixed too #juju-dev 2012-04-03 <niemeyer> mthaddon: ping <mthaddon> niemeyer: hi <niemeyer> mthaddon: Hey man <niemeyer> mthaddon: We have our first bug to investigate <niemeyer> mthaddon: For some weird reason the charm at /charm/oneiric/mysql is returning 0 bytes <niemeyer> mthaddon: Theoretically, this should never happen since the charm is only linked into its final destination at the end of the importing process, which means any errors in between should leave it out <niemeyer> mthaddon: Oh, wow.. it looks like other charms are empty too <niemeyer> mthaddon: e.g. oneiric/jenkins <niemeyer> mthaddon: Can we debug this? <mthaddon> niemeyer: sure, can you give me a few mins - have another issue I'm looking at just now <niemeyer> Sure <mthaddon> niemeyer: okay - checking the logs <niemeyer> mthaddon: There's more than one in that state, so it's not a one-off event <mthaddon> niemeyer: nothing interesting in the web app logs - checking charmload <niemeyer> mthaddon: Please also run this later: db.charms.find({"urls": "cs:oneiric/jenkins"}) <niemeyer> mthaddon: In the juju db <mthaddon> niemeyer: https://pastebin.canonical.com/63655/ <niemeyer> mthaddon: Oops.. where's the size? <mthaddon> juju 0.453125GB <mthaddon> is that what you mean? <niemeyer> mthaddon: Nope.. I mean I don't see the size in that json output <niemeyer> mthaddon: Please try this now: db.charms.find({"urls": "cs:oneiric/wordpress"}) <mthaddon> niemeyer: https://pastebin.canonical.com/63657/ <niemeyer> mthaddon: see the "size" there? <niemeyer> mthaddon: This is the bug that would happen if the database was loaded with the charmload prior to that update we did <niemeyer> mthaddon: The reason for dumping the database was avoiding this bug <mthaddon> niemeyer: ok, so we need to dump it again, confirm all cronjobs are stopped, and then start again? <niemeyer> mthaddon: No, now it's too late.. we don't want to break stuff people are using now <niemeyer> mthaddon: I'll do what I should have done in the first place and write an upgrader <niemeyer> mthaddon: My laziness clearly didn't pay off <mthaddon> okey doke <niemeyer> mthaddon: okay <niemeyer> mthaddon: Here is the fix: <niemeyer> mthaddon: https://pastebin.canonical.com/63660/ <mthaddon> niemeyer: is there any kind of logging/transactional status to this? just wondering what output you'll want to see to confirm it's done the right thing <niemeyer> mthaddon: No transactions.. you can exit on the first iteration of the loop if you want to be super sure <niemeyer> mthaddon: Hold on, will provide it <niemeyer> Ah, quit, not exit <mthaddon> yeah, quit() <niemeyer> mthaddon: https://pastebin.canonical.com/63664/ <niemeyer> mthaddon: Cool <niemeyer> mthaddon: This should tell you the first item it fixed, and give you a chance to go look <mthaddon> niemeyer: Fixing cs:~4-ja-d/oneiric/appflower <mthaddon> niemeyer: how do we verify that, or is that good enough? <niemeyer> mthaddon: Cool, if you do the find we had above now, with this url, it should show the entry with a size <niemeyer> mthaddon: Also, in addition to the find, please use .next() at the end <niemeyer> mthaddon: It will give you better formatted output <niemeyer> mthaddon: db.charms.find({urls: "cs:~4-ja-d/oneiric/appflower"}).next() <niemeyer> more precisely.. <mthaddon> niemeyer: https://pastebin.canonical.com/63666/ * mthaddon sees size there, suspects that's a good thing <niemeyer> mthaddon: Yep, looks good.. intact, and has a size which probably matches the actual file <mthaddon> ok, going ahead with the original paste <niemeyer> mthaddon: Hold on a second, though.. <mthaddon> holding <niemeyer> mthaddon: I'll download the actual charm <mthaddon> k <niemeyer> mthaddon: https://pastebin.canonical.com/63667/ <mthaddon> cool cool! <mthaddon> so go ahead with the first paste? <niemeyer> mthaddon: Good to go.. <mthaddon> k <mthaddon> niemeyer: and done <niemeyer> mthaddon: Super, please save the output in case something goes terribly wrong.. unlikely, but whatever <mthaddon> niemeyer: https://pastebin.canonical.com/63669/ <niemeyer> mthaddon: Superb, it's in the pastebin for eternity <niemeyer> mthaddon: Thanks for the help <mthaddon> yep :) <mthaddon> sure, np <niemeyer> mthaddon: Btw, do we have access from the charmd process to perform outside queries? <niemeyer> mthaddon: HTTP queries, more precisely <mthaddon> niemeyer: do you mean are the charmd processes exposed directly to the world? no, just through apache -> haproxy <mthaddon> apache -> haproxy -> charmd, I mean <niemeyer> mthaddon: No, I mean the opposite <niemeyer> mthaddon: Can I query *from* the charmd process into the world <mthaddon> niemeyer: all our servers have egress firewalls - if you want to connect to specific things we can make exceptions though <niemeyer> mthaddon: Cool, it's a specific thing indeed.. I'm pondering about collection of stats <mthaddon> k <niemeyer> TheMue: ping <TheMue> niemeyer: pong <niemeyer> TheMue: Heya <niemeyer> TheMue: How're things going there? <niemeyer> TheMue: How was the presentation? <TheMue> niemeyer: has been fine, the audience has been very interested. i only talked too long. ;) <niemeyer> TheMue: Nice! <TheMue> niemeyer: i have to fix three little typos in the slides and then they will be published <niemeyer> TheMue: COol <TheMue> niemeyer: but next time i'm keeping the pure talk shorter and concentrate more on a practical part. <niemeyer> TheMue: It's easy to go overboard which such a wide topic <TheMue> niemeyer: indeed, there is so much you can say about a language like go. and many people didn't know anything about concurrency or higher-order functions <niemeyer> TheMue: What was the meeting core topic? Is it a Linux User Group? <TheMue> niemeyer: but i've been asked to talk at other GTUGs (will be called GDG - Google Developer Group - in future) <TheMue> niemeyer: a Google User Group <niemeyer> TheMue: Hmm.. curious <niemeyer> TheMue: A group of users that ... ? <niemeyer> Use Google? :-) <TheMue> niemeyer: to be more special, a Google technology User Group. android, google apis, dart, go, ... <niemeyer> TheMue: Weird.. feels so open <niemeyer> Although I guess a LUG is equally open <niemeyer> TheMue: What about juju land? <TheMue> niemeyer: here i'm continuing with real watchers and wait for your lgtm <niemeyer> TheMue: Sounds good.. I should dedicate some good amount of time to reviews today <niemeyer> TheMue: How's the real watchers stuff going? <TheMue> niemeyer: using the watcher package helps, but i had to extend it a bit, you see it in the proposed service config watcher <niemeyer> TheMue: Ok <niemeyer> TheMue: have you been able to push things forward, or are you blocked? <TheMue> niemeyer: if a pipelined goroutine needs to signal an error, it needs a way to tell it to the watcher. <niemeyer> TheMue: Isn't that what Stop is for? <TheMue> niemeyer: i would say, like roger, that the config watcher is fine. and so i'm continuing based on that (implementing further watches the same way using a new branch based on the config watch branch) <niemeyer> TheMue: It doesn't have to be based on if there's no real dependency between them <TheMue> niemeyer: Kill() is for signalling errors <niemeyer> TheMue: Within the watcher.. something that happens out of the watcher.*Watcher isn't responsibility of that type <TheMue> niemeyer: Stop() is the a client/user of a watch can tell that it isn't interested anymore <niemeyer> TheMue: Exactly.. and if an error happens outside of that watcher, that's what should be done <niemeyer> TheMue: If you're feeling a need to Kill the watcher from outside, some abstraction is being broken somewhere <niemeyer> TheMue: I'll be happy to have a look at the branch after lunch <TheMue> niemeyer: it's a pipelined goroutine, in case of the config node the data may be invalid (yaml error), but i want to pass this information to the client of the watch. so i Kill() with that error. and the client, calling Stop(), get's this error returned. <niemeyer> TheMue: Exactly, that's not right <niemeyer> TheMue: You're using the watcher to pass errors for something it has no idea about <niemeyer> TheMue: Bad abstraction <niemeyer> TheMue: The watcher within the watcher package watches.. it's not supposed to be a conduit for errors of someone else <niemeyer> Anyway, really have to step out for lunch.. back in a moment <TheMue> niemeyer: the pipelined goroutine needs to tell the watcher 'stop working, there is an error'. <niemeyer> TheMue: No, it actually doesn't.. have you ever heard of a function called fkill in C? <niemeyer> TheMue: You call it like this: fkill(fd, "My custom error message") <niemeyer> TheMue: So that when you do fclose(fd), you can the error back <niemeyer> TheMue: Nope.. it doesn't exist, and it's very obviously a weird thing to be doing <niemeyer> TheMue: Similarly, it doesn't make sense to be doing watcher.Kill("Completely unrelated error") <TheMue> niemeyer: how do you handle it with tomb? tomb.Kill("Ouch") and later err := tomb.Wait() <niemeyer> TheMue: The tomb is an internal implementation of the watcher <niemeyer> implementation detail, that is <niemeyer> TheMue: There's nothing about the tomb in the watcher's interface.. we can drop it and create the same API without it <TheMue> niemeyer: yes, and i'm using this behavior, but only from a pipelined goroutines perspective <niemeyer> TheMue: There's no such thing as "pipeline goroutines".. We have a watcher, with an API <niemeyer> TheMue: The fact there's a goroutine inside it is irrelevant <niemeyer> TheMue: We could have 10 goroutines there, or none <TheMue> niemeyer: no, because the goroutine can't directly return an error <niemeyer> TheMue: All of that is merely an implementation detail we use to offer the actual API that is documented <niemeyer> TheMue: Kill isn't part of the API, and it makes no sense to have it there.. how would we document it? <niemeyer> TheMue: // Kill stops the watcher with the given error so that you can call Stop and get the error you provided <niemeyer> TheMue: ? <TheMue> niemeyer: it is documented, see the prpopose <niemeyer> It's a bad abstraction <TheMue> niemeyer: so how would you tell the watcher to end its work and pass the error that led to the error to the user of the watch? <niemeyer> TheMue: Again, fkill.. it makes no sense <niemeyer> TheMue: The watcher knows about errors in the watch <niemeyer> TheMue: It's not supposed to be a conduit for errors happening in logic it has no idea about <TheMue> niemeyer: the watcher (the type Watcher) doesn't know about the error <niemeyer> TheMue: Exactly, and it shouldn't know about *any* external errors <niemeyer> t <TheMue> niemeyer: the error happens in a goroutine listening to the change <niemeyer> TheMue: Exactly <niemeyer> TheMue: That's the place to have the error.. <TheMue> niemeyer: and i have to signal the watcher to stop working <niemeyer> TheMue: That's called Stop <TheMue> niemeyer: and the Stop() of the service config watcher then has to check if the own stored error is nil and return the value of Watcher.Stop() and otherwise the own error <niemeyer> TheMue: It has to do whatever it takes to handle its own problems.. calling foo.PleaseSaveMyError(err) so that foo.HaveYouFailed() when foo is an independent and self-contained abstraction is not nice <TheMue> niemeyer: we use tomb as a tool inside the type Watcher, and we use the Watcher inside the special watcher. so why two different kinds of abstraction, why shouldn't care Watcher for its own error management? <niemeyer> TheMue: I've been explaining it for a while.. Watcher *is* handling its *own* error management <niemeyer> TheMue: What you want is for it to handle somebody else's error management <niemeyer> TheMue: and that's not nice <niemeyer> TheMue: state/watcher shouldn't be a conduit for somebody else's errors <TheMue> niemeyer: tomb is doing the error management of Watcher <niemeyer> TheMue: Yes, that's its only purpose in life <niemeyer> TheMue: Just like mutexes to mutexing, conditional vars to conditional varing, etc.. those are not exposed either. <TheMue> niemeyer: the proposed way Watcher provides a clean API from a users perspective <niemeyer> TheMue: It's not a clean API, for the reasons I've been explaining repeatedly <niemeyer> TheMue: There's no fkill.. let's not have one in the watcher.. <TheMue> niemeyer: i'll change it <TheMue> niemeyer: but i would like you to do the review first, so i can do the changes at once <niemeyer> TheMue: Sure, I'll have a more careful look <niemeyer> TheMue: I love "observices", btw.. we should totally have a place for that somewhere in Juju :-) <TheMue> niemeyer: ;) <TheMue> niemeyer: funny thought mixup into one word <TheMue> niemeyer: should register it as trademark <niemeyer> TheMue: +1 :) <niemeyer> TheMue: The overall branch looks very nice, btw <niemeyer> TheMue: I love how this is evolving <niemeyer> TheMue: You have a proper review <niemeyer> TheMue: I'll move on and fix the tomb stuff we discussed re. tomb.Dying <TheMue> niemeyer: fine, thx <niemeyer> TheMue: Please let me know if the review looks sensible to you <TheMue> niemeyer: yip, will do, first have to fetch my dinner <niemeyer> TheMue: Oh man, if it's late for you that can wait until tomororw <TheMue> niemeyer: it's ok, will at least take a look <niemeyer> TheMue: Do you want to have a quick look at the tomb changes before they go in? <niemeyer> TheMue: Or, would you mind? <TheMue> niemeyer: oh, with pleasure <niemeyer> TheMue: Cool, pushing <niemeyer> TheMue: https://codereview.appspot.com/5981052 <TheMue> *click* <niemeyer> TheMue: As you will have noticed, also renamed ErrStillRunning to ErrStillAlive, as it was off within the naming context <TheMue> niemeyer: Yip, seen. Makes sense. <niemeyer> TheMue: Have you had a chance to look? <TheMue> niemeyer: almost done <niemeyer> TheMue: Superb, thanks <TheMue> niemeyer: just wanted to get a better insight in tomb. <niemeyer> TheMue: That's great for sure <TheMue> niemeyer: review is in <TheMue> niemeyer: took a look at your review, most parts are ok (even if i still find adding adding an own tom to the ConfigWatcher increases complexity, not much, but it does). and i'll move the ConfigWatcher from service.go to state.go <niemeyer> TheMue: Cheers! <niemeyer> TheMue: I'll put the defer into that case where the function is a bit more involved <niemeyer> TheMue: The other cases don't look necessary <TheMue> niemeyer: i like using defer for a linear execution Open()/defer Close(), Dial()/defer Close() etc. Fire and forget, no nesting. <niemeyer> TheMue: Yeah, that's cool in many cases.. but when it's a short lived and simple function, the defer is merely overhead <TheMue> niemeyer: how much overhead? shouldn't be premature optimization <niemeyer> TheMue: This isn't premature optimization.. this is pointless deoptimization.. :) <niemeyer> TheMue: It's assignment.. <niemeyer> It's an assignment, that is <niemeyer> Lock; a = t.foo; Unlock <niemeyer> TheMue: What are you defering for? <niemeyer> TheMue: You're right about Kill, though.. it looks better <TheMue> niemeyer: keeping an idiom to establish it more and more so that the code is more maintainable, regardless if the method is a one-liner or more complex <niemeyer> TheMue: Lock; trivial; Unlock is a fine idiom too, looks nice, is clean, and happens to use less resources than a defer <niemeyer> TheMue: Again, you're right about Kill, though <TheMue> niemeyer: ok <niemeyer> TheMue: I've updated the code, in case you'd like to look or LGTM it <niemeyer> TheMue: Although, it's just your suggestion <TheMue> niemeyer: *click* again ;) <TheMue> niemeyer: lgtm <niemeyer> TheMue: Cheers! <niemeyer> TheMue: Thanks for the suggestion as well <TheMue> niemeyer: np, my pleasure <TheMue> niemeyer: i'm off for today, cu tomorrow #juju-dev 2012-04-04 <hazmat> jimbaker, fwereade_ if you guys have a moment, this one needs a review.. https://codereview.appspot.com/5976074/ <jimbaker> hazmat, i will take a look after dinner <hazmat> jimbaker, awesome, thanks.. how's the rel-id stuff working out? <jimbaker> hazmat, i just proposed a new version of relation-hook-context <hazmat> jimbaker, cool, looking at it now <jimbaker> unfortunately it seemed to pick up every single change in trunk <hazmat> jimbaker, yeah.. that diff is foobar'd <jimbaker> i can never get lbox to work <hazmat> jimbaker, what's the cli invocation your using? <jimbaker> i just did lbox propose -cr <hazmat> jimbaker, and what's the bzr info on that branch? <jimbaker> probably most relevant is parent branch: /home/jbaker/canonical/juju/mine/relation-id <jimbaker> which has subsequently been merged into trunk <hazmat> yup <hazmat> jimbaker, can you resubmit the merge proposal by hand and remove the pre-req <jimbaker> hazmat, req= ? <hazmat> jimbaker, bcsaller and i wasted an hr on this problem yesterday.. it ended up being the easiest thing to do unfoobar lbox was to delete the merge proposal <hazmat> req=requisite <jimbaker> hazmat, how do i delete the merge proposal? from lp and rietveld? <hazmat> just from lp <hazmat> jimbaker, i'd try removing the pre-requisite branch via editing first <hazmat> the mp on lp <jimbaker> hazmat, ok <jimbaker> hazmat, shouldn't lbox do this? it seems to have a hard time with prereqs <hazmat> jimbaker, yeah.. it should.. it seems to fall down for pre-requistes that have been merged, along with a pre-existing merge proposal for the branch in question <hazmat> at least thats the conditions for your branch and ben's from yesterday <hazmat> perhaps niemeyer knows some more <jimbaker> plus a chain of rereqs <jimbaker> prereqs <hazmat> its not really a chain.. it just cares about the pre-requisite <hazmat> singular <niemeyer> What's up? <hazmat> niemeyer, fun with lbox <niemeyer> Ah, yeah.. it does that still.. <niemeyer> jimbaker: You have to merge trunk on the pre-req too <hazmat> niemeyer, it seems like lbox respects the merge proposal in preference to rediscovering the prerequisite or taking the pre-requisite on the cli explicitly <niemeyer> and re-push <jimbaker> hazmat, it also was having a prereq issue for relation-ids-command with prereq of relation-hook-context with prereq of relation-id-option, prior to mergin <niemeyer> jimbaker: lbox must pick trunk after the pre-req is merge, but it doesn't do that yet, so you have to merge trunk on the pre-req and repush it, so that the diff against it is right <niemeyer> jimbaker: I'll fix it when I have a moment <hazmat> jimbaker, rel-id-option was foobar'd on target as well though <jimbaker> sorry, the final prereq was relation-id in the chain i mentioned above, not relation-id-option <jimbaker> niemeyer, hazmat, that worked to merge trunk onto relation-id <jimbaker> and repush <hazmat> jimbaker, cool, thanks <hazmat> jimbaker, is it meaningful to distinguish self._context on change flushing via omission of the rel-id? seems like we'd always want the rel-id here, as there is no contextual ref in the log to the rel in question <jimbaker> hazmat, that's a valid point... i was minimizing the test change here since we did have child relations before <jimbaker> it might make more sense to change it to "Flushed values for hook 'blah' on 'db:0':" <jimbaker> then it will be clearer what is the parent and what are the children, if any <hazmat> jimbaker, yeah.. that sounds good.. else this looks good <jimbaker> hazmat, cool, i can readily make that change after dinner - and merge it into trunk if it's approved ;) <hazmat> jimbaker, sounds good <jimbaker> hazmat, approved, sweet, ttyl <hazmat> jimbaker, but pls put in a bug per the previous review <jimbaker> hazmat, sounds good <hazmat> niemeyer, re showing store url when deploying.. how's this look http://paste.ubuntu.com/913980/ <niemeyer> hazmat: +1 <niemeyer> hazmat: Thanks <hazmat> niemeyer, np <hazmat> niemeyer, the immortal session stuff is done, if your curious what it looks like https://codereview.appspot.com/5976074/ <hazmat> mostly just this one.. https://codereview.appspot.com/5976074/patch/1/6 <niemeyer> hazmat: Gosh.. <niemeyer> hazmat: I hope you continue working for Canonical for as long as we have to maintain that logic.. <niemeyer> (at least!) <hazmat> niemeyer, didn't see that much different than some of the watch stuff that TheMue is doing <niemeyer> hazmat: I must be missing something then.. <niemeyer> hazmat: It looks like pretty much the whole file is filled with logic for resetting and reestablishing sessions? <niemeyer> hazmat: and recreating ephemerals, and watches, and ... <hazmat> niemeyer, it is, but it resignals to watches via a synthetic event <niemeyer> hazmat: Heh <niemeyer> hazmat: How is that any similar to what Frank is doing then? <niemeyer> hazmat: Frank has a watch in a loop.. <niemeyer> hazmat: and that's it. <hazmat> niemeyer, yeah.. not much in common, persistent watches and persistent sessions, both both are basically just processing watch events, the session code also traps on conn errors though. <jimbaker> looks like http://wtf.labix.org/ is stuck <jimbaker> hazmat, i'm going to file that bug tomorrow, good night all <jamespage> morning folks - anyone around who can help we out with an issue with the charm store? <jamespage> struggling with charms that use symbolic links for hooks.... zookeeper for example <fwereade> jamespage, *possibly* <TheMue> fwereade: moin <fwereade> jamespage, there were a couple of recent changes I wasn't directly involved in but I think I remember the thrust of it <fwereade> heya TheMue <jamespage> fwereade, right-oh <jamespage> OK so I tried a juju deploy zookeeper on my local oneiric provider <jamespage> works fine with the charm on local disk in a bzr branch <jamespage> but I get an install error using the one from the charm store <jamespage> the symbolic links in the hooks directory appear to get broken as its deployed into the service unit <jamespage> they are simple files with the name of the target file in them rather than symlinks <fwereade> hmmm, just checking: is this to a recent version of juju? <fwereade> jamespage, ^^ <jamespage> fwereade, the zip file containing the charm in ~/.juju/charms looks OK <jamespage> http://paste.ubuntu.com/914260/ <jamespage> fwereade, I run from PPA all the time <jamespage> 0.5+bzr504-1juju4~precise1 <fwereade> jamespage, what I'm really asking is how long ago you bootstrapped that juju <jamespage> fwereade, this morning <jamespage> and it uses juju-origin: ppa explicitly <fwereade> jamespage, ok then, the obvious answer is not the answer ;) <jamespage> just checks - the service unit is using 0.5+bzr504-1juju4~oneiric1 as well <fwereade> jamespage, thanks, I'll try to poke around and see what's up <jamespage> fwereade, great - thankyou! <fwereade_> jamespage, fyi, the *problem* is perfectly clear but it's taking a while to figure out what the "right" answer is <jamespage> fwereade_, would you like a bug report? I'm assuming the problem is not me :-) <fwereade_> jamespage, a bug report would be great, the problem is indeed not you <jamespage> fwereade_, bug 973260 <fwereade_> hazmat, btw, if you're on: https://codereview.appspot.com/5980045 <hazmat> fwereade_, lgtm <hazmat> fwereade_, if you have a moment this one could also use a look.. https://codereview.appspot.com/5976074/ <fwereade_> hazmat, thanks <fwereade_> hazmat, ofc <fwereade_> jamespage, it's in trunk now, thank you for catching that <jamespage> fwereade_, np - thanks for fixing up so quickly <jamespage> I need to pester SpamapS_to get the daily PPA daily again :-) <hazmat> yeah.. it looked like a patch conflict from the packaging <fwereade_> hazmat, semi-review on https://codereview.appspot.com/5976074/ -- let me know your thoughts <hazmat> fwereade_, thanks.. regarding the costs, it comes out to two primary things.. watches which check watch events have to accept a session event, and sequence node based patterns/algorithms (ie. like the std zk lock recipe) need to be rethought <hazmat> we're not doing either of those in juju <hazmat> fwereade_, if your up for another one... https://codereview.appspot.com/5966076/ <fwereade_> hazmat, oo, nice <fwereade_> hazmat, perhaps document those drawbacks a little more obviously <hazmat> bcsaller, review delivered on sub-agent <hazmat> off to get some stitches out, bbiab <bcsaller> hazmat: thanks <jimbaker> wtf.labix.org has not run since r499 <niemeyer> jimbaker: wtf 9867 1.2 7.1 7606936 35736 pts/2 Sl+ 09:21 3:14 python /home/wtf/ftests/build/juju/bin/juju status <niemeyer> jimbaker: The logic for waiting for bootstraps seems a bit borked <jimbaker> niemeyer, ok - maybe we can diagnose. in any event, just wanted to point out that it has been stuck <niemeyer> jimbaker: Yeah, it's getting repeatedly stuck due to this bug <jimbaker> niemeyer, how often does it get stuck? <niemeyer> jimbaker: I last unblocked it on 494 <jimbaker> niemeyer, any logs you might have would be helpful <niemeyer> jimbaker: http://wtf.labix.org/500/ec2-wordpress.out <jimbaker> niemeyer, interesting that it is getting "Too many open files" (so presumably some sort of cleanup is not occurring) after it fails to access s3 <niemeyer> jimbaker: Possibly <jimbaker> so the problem may be not in the loop to connect, but in the connection phase itself <hazmat> niemeyer, isn't this the problem.. ERROR Cannot connect to environment: DNS lookup failed: address 's3.amazonaws.com' not found: [Errno -2] Name or service not known. <niemeyer> hazmat: I don't know, but that seems to have been raised a single time.. <niemeyer> hazmat: and it actually exited.. in one of those attempts, though, it never went back <niemeyer> hazmat: The ps above shows the leak, too <SpamapS> hazmat: perhaps we should push this back to galapagos? https://bugs.launchpad.net/juju/+bug/897645 <hazmat> SpamapS, yeah.. that seems reasonable <niemeyer> The interface of running juju-admin was broken again.. that's why juju status was hanging <niemeyer> usage: juju-admin initialize [-h] --instance-id INSTANCE_ID --admin-identity <niemeyer> ADMIN_IDENTITY --constraints-data <niemeyer> CONSTRAINTS_DATA --provider-type PROVIDER_TYPE <niemeyer> juju-admin initialize: error: argument --constraints-data is required <niemeyer> I'll just skip everything until the last revision <SpamapS> --constraints-data is required? WTF? <SpamapS> oh <SpamapS> thats a mid-merge problem? <fwereade> SpamapS, --constraints-data is required to bootstrap the current code, which should be fine because current code send a cloud-init which includes --constraints-data for initialize <niemeyer> SpamapS: Yeah.. <fwereade> SpamapS, is something else going on? <niemeyer> fwereade: Yeah, except it means the client and the server must be precisely in the same rev for this to work <fwereade> niemeyer, for bootstrap to work, yes <niemeyer> fwereade: FOr juju to work, yes :) <fwereade> niemeyer, having the same rev at bootstrap time should not be an issue, surely? <niemeyer> fwereade: Client before deadline with new server doesn't work.. client after the deadline with old server doesn't work <fwereade> how can a client be bootstrapping an old server? <niemeyer> fwereade: I can imagine several such ways <fwereade> niemeyer, hm, I can see how a non-updated client could get newer code from the PPA that it didn't cover <niemeyer> fwereade: I don't know if it's a problem in practice.. if you considered that with SpamapS, must be all good <fwereade> niemeyer, ...are you talking about people messing around with juju-origin for the old-server-bootstrapped-by-new-client problem? <niemeyer> fwereade: I'm not really bringing any specific scenario up.. just stating the fact that compatibility has been broken at revision 500. <fwereade> niemeyer, I see :( <fwereade> SpamapS, can I assist in any way? <SpamapS> We get skew all the time <SpamapS> Its why I've proposed that we develop a feature where the client pushes *all* of juju onto the bootstrap node or into file storage and that we no longer try to disribute from "distro" or "ppa" after bootstrap. <fwereade> SpamapS, +10 on that <SpamapS> fwereade: for the immediate time being, all is well, no worries. <fwereade> SpamapS, cool <fwereade> SpamapS, I am concerned that I misjudged the --constraints-data thing: my thinking was "either juju-origin matches the client, in which case we're golden; or it doesn't, in which case we're dealing with someone who should know what they're doing" <fwereade> SpamapS, to be fair juju-origin has bitten all of us enough times that assuming people know what they're doing is a touch optimistic <niemeyer> Revision 512 is green on wtf.. #juju-dev 2012-04-05 <niemeyer> TheMue: How did the review look? Good stuff? <TheMue> niemeyer: yip, the changes are back in (after i had another special task: check the translation of the press release to maas) ;) <niemeyer> TheMue: What's coming next? <niemeyer> TheMue: Acting as a translator too? Nice. :) <TheMue> niemeyer: if it's ok for you now i'll submit it and then realize the next watches <TheMue> niemeyer: as long as you don't have something more urgent for me <TheMue> niemeyer: do we have a kind of roadmap in which order the missing parts shall be ported? <niemeyer> TheMue: Not at this time.. we have to do all of them, and nobody else is blocked on missing pieces of the state, so you're free to pick the next slice <niemeyer> TheMue: That said, given we've just entered watches and have them fresh in our minds, sounds like a good choice indeed <niemeyer> TheMue: I'll have a last look right away <TheMue> niemeyer: Fine, so I would continue with those. <niemeyer> TheMue: Just for the record: <niemeyer> """ <niemeyer> Done. Difficult situation would be if in case of an internal watcher error <niemeyer> Dying() returns an error too. Haven't been able to discaver that in the control <niemeyer> flow. <niemeyer> """ <niemeyer> TheMue: It's fine to give precedence to one of the errors in that case <niemeyer> TheMue: You've picked the right end of it as well, IMO.. the underlying error is likely of higher precedence if both exist <TheMue> niemeyer: That has been my thought too. And I think a panic would be too much while some kind of crippled error mix of both won't help too. <niemeyer> Right <niemeyer> TheMue: You got a plain LGTM <TheMue> niemeyer: great, thx <niemeyer> TheMue: Turned out very well.. love the new watch infra <TheMue> niemeyer: me too, one kind of tasks which go can handle very well <robbiew> of course fwereade leaves the room at our 1:1 time <robbiew> lol <niemeyer> :-) <niemeyer> Lunch time.. biab <flacoste> SpamapS: when are you planning on next uploading to the archive? <flacoste> SpamapS: the current archive version doesn't have the constraints support <flacoste> SpamapS: not a big deal, but just would like to know your plans <SpamapS> flacoste: when subordinates lands <flacoste> SpamapS: what's the ETA for that? <SpamapS> bcsaller: how goes it btw? <SpamapS> flacoste: I've seen brief flurries of review/fix/review cycles so it must be close. <fwereade> gn all (actually, happy weekends all, really, holiday tomorrow) <TheMue> fwereade: yip, have a nice long weekend too <niemeyer> fwereade: Have a good one! <hazmat> jimbaker, after your done merging the rel-id work, would you mind having a look at this txzk branch http://codereview.appspot.com/5976074/ <jimbaker> hazmat, will do <hazmat> jimbaker, thanks <niemeyer> jimbaker, hazmat: "Use the new hook command, relation-ids [RELATION_NAME], which takes an <niemeyer> optional relation name (otherwise implies all)" <niemeyer> jimbaker, hazmat Otherwise implies all? <hazmat> niemeyer, yes <hazmat> niemeyer, all relation ids are returned if no name is specified <niemeyer> hazmat: The agreement is that it should imply the current relation name <hazmat> niemeyer, if one exists <hazmat> it does <hazmat> but in the case of a non rel hook context, it won't <niemeyer> hazmat: Yes, if you doesn't exist it should break and say "give me a relation name".. <niemeyer> hazmat: Otherwise the command has a completely different behavior depending on context <jimbaker> niemeyer, hazmat, the actual behavior is to return all the relation ids if no relation name is specified, regardless of context <niemeyer> jimbaker: That's not what we agreed <jimbaker> whether relational or not <hazmat> jimbaker, doesn't it default to an env var? <jimbaker> niemeyer, i can certainly change it <jimbaker> hazmat, it was originally doing that, but that caused the inconsistency <jimbaker> instead we can have it raise an error as niemeyer suggests <hazmat> sounds good <jimbaker> hazmat, cool <niemeyer> jimbaker: """ <niemeyer> 4 This proposal adds a new relation hook command to enumerate the <niemeyer> 5 relations a service participates in33ec:265c:71fe:e26d:2682:4ec2:aaa1:99ab <niemeyer> 6 <niemeyer> 7 relation-ids [RELATION_NAME] <niemeyer> 8 <niemeyer> 9 Hooks that are not relational hooks must specify the relation name as <niemeyer> 10 an argument; otherwise an error is raised stating "Relation name must <niemeyer> 11 be specified". For relational hooks, the corresponding relation name <niemeyer> 12 is the default. <niemeyer> """ <jimbaker> niemeyer, thanks for pointing that out <niemeyer> jimbaker: I'm not reviewing the code going into the Python implementation.. if you don't pay attention to the specification, the point of we agreeing on it is moot <jimbaker> niemeyer, thanks, this was very helpful #juju-dev 2012-04-06 <SpamapS> hazmat: was that subordinates I saw land? <hazmat> SpamapS, there's one last branch for it <hazmat> SpamapS, hmm.. maybe two the agent branch that actually deploys it (which is approved in the queue), and then a followup control branch to restrict remove-relation/destroy-service on subordinates <SpamapS> hazmat: ok. The packaging branch is broken right now due to a patch I have in there for tests.. thinking about just ditching the patch and setting AWS_* when running the tests. <hazmat> SpamapS, is it just those 3 tests in environment.. afaik.. having a look <hazmat> hmm.. looks like a few in the provider as well <hazmat> SpamapS, here's the diff, http://paste.ubuntu.com/917565/ <hazmat> i'm going to apply to trunk if that looks sane 2 u <SpamapS> hazmat: sure, I think the tests should always run without those env vars set. <hazmat> bcsaller, juju.control.tests.test_status.StatusTest.test_render_svg on trunk <robbiew> bcsaller: yo...did you submit your self-review yet? If not, can you get that in today...I'm trying to knock these out! ;) <hazmat> bcsaller, fixed on trunk <hazmat> robbiew, i think he's probably asleep atm, he was up till 3ish <hazmat> SpamapS, trunk runs tests without env vars <robbiew> hazmat: ah, thnx...I'll shoot him an email <SpamapS> hazmat: woot <hazmat> the magic expiration works pretty well, i can suspend and restore local envs with it <hazmat> shiny.. http://www.madeiracloud.com/ <hazmat> hmm. its shiny, but its not very useful afaics <robbiew> lol <jimbaker> lbox still wants to use the honolulu milestone <jimbaker> hazmat, i'm still going through the review of https://codereview.appspot.com/5970080/, but i noticed it's not current with what has been pushed <hazmat> jimbaker, this one http://codereview.appspot.com/5976074/ <jimbaker> hazmat, hmmm, i wonder why i was going against https://codereview.appspot.com/5970080/ ? was it recently linked against the merge proposal? <hazmat> jimbaker, they look the same to me <jimbaker> anyway, the MP now links against ..74 <jimbaker> hazmat, they differ with respect to managed.py #juju-dev 2012-04-07 <jimbaker> hazmat, +1 on that branch <jimbaker> have a good weekend! <hazmat> jimbaker, cool, it works well in practice.. i've been hibernating and rebooting with local envs. <hazmat> jimbaker, cheers you too <hazmat> although i'm realizing that the ephemeral sequence coordination patterns begs for a notification of expiration, and that the sequence ephs shouldn't be tracked.. maybe latter #juju-dev 2012-04-09 <niemeyer> Good mornings <fwereade_> niemeyer, heyhey; nice holiday? <niemeyer> fwereade_: Heya! <niemeyer> fwereade_: Yeah, nice overall.. went to my dad's for a nice barbecue. Ale was working over most of it, though, which removed some of the feeling of easter. <niemeyer> fwereade_: How about you, good stuff there? <fwereade_> niemeyer, aw :( <fwereade_> niemeyer, had a lovely easter actually; went out with cath's family for *awesome* food, and a spot of light walking in the countryside afterwards <niemeyer> fwereade_: Oh, sounds nice indeed <niemeyer> fwereade_: How's the countryside like there? <fwereade_> niemeyer, at this time of year, both rocky and green, once you actually get out there <fwereade_> niemeyer, lots of flowers <fwereade_> niemeyer, over summer it's a bit brown but still really rather lovely <niemeyer> fwereade_: Ah, colorful then <niemeyer> (at this time) <fwereade_> niemeyer, yeah :) <niemeyer> mthaddon: ping <niemeyer> Lunch, biab <hazmat> fwereade_, re error on private cloud with constraints.. http://pastebin.ubuntu.com/922019/ <hazmat> ic the problem <hazmat> fwereade_, effectively required constraints aren't populated for private clouds.. http://pastebin.ubuntu.com/922057/ <hazmat> az and instance type are still valid to specify even lacking the ability to define the vocabulary, the values should pass through <hazmat> fwereade_, i ended up just putting in bandaid to remove the using_amazon check when setting up ec2 provider constraints in r518.. else private cloud usage using the ec2 api was broken.. as the provider requires both constraint keys defined in several places, and the default selection of instance-type m1.small relies on it as well. * hazmat moves on to checking out the sub agent branch <fwereade_> hazmat, thanks, and sorry <fwereade_> hazmat, but I would say that surely we should in fact be getting values rather than getiteming them, rather than exposing meaningless values through the UI? <hazmat> fwereade_, well typically the standard values do have meaning in private contexts, just not the ones we think they do.. i looked at doing gets.. but that's also problematic because the default-instance-type is resolved via constraint <hazmat> which fails when the constraint itself defined <hazmat> what a tangled web we weave when first we practice to abstract ;-) <fwereade_> hazmat, I'm confused; default-instance-type short-circuits constraints <hazmat> fwereade_, it does.. but say you don't have it defined <hazmat> fwereade_, then the default value comes from generic constraints <hazmat> but those are only setup upon registering generics <hazmat> ie. instance-types <fwereade_> hazmat, hmmm, yeah, got you; I'd imagined people were always using default-instance-type and default-image together :( * hazmat grabs some snacks and call its lunch <hazmat> fwereade_, that might be the case for some, but not all. <fwereade_> hazmat, clearly so :( <fwereade_> hazmat, everyone uses default-image-id, though, right? <hazmat> fwereade_, on private clouds yes <fwereade_> hazmat, jolly good <fwereade_> hazmat, when you have a mo, please let me know whether you feel http://paste.ubuntu.com/922279/ is trivial enough to be a trivial <fwereade_> hazmat, tiny tweak to above, http://paste.ubuntu.com/922285/ <hazmat> fwereade_, hmm.. i don't see this as particularly better.. the common vocabulary would suggest common usage even if we can't guarantee the value mapping <hazmat> although likely the ec2 zone is wrong given its part in value construction <hazmat> fwereade_, also i noticed that passing instance-type when it wasn't defined didn't trigger a user error <hazmat> fwereade_, ie. given this patch the user wouldn't ever be able to specify via constraint any instance type they'd have to fallback to specifying it via hot swapping in environments.yaml... even though the value they want to give would work if just passed thorough <fwereade_> hazmat, fair points; <fwereade_> hazmat, I shall think on them <fwereade_> hazmat, thanks <hazmat> fwereade_, np.. i think the underlying issues are the same as when this was implemented just that we haven't had time to put in place the right solutions.. i mean from a different perspective.. --constraints are exposed on private clouds, if usage of them is ignored without warning that's a bad ux. the ideal scenario is of course the same, constraints work everywhere, but that requires both image mapping and instance type mapping definitions, which i thin <hazmat> k we agree is the long term solution. <fwereade_> hazmat, yeah, I think I'm converging on an implementation of that #juju-dev 2012-04-10 <niemeyer> Alow <andrewsmedina> niemeyer: hi :D <niemeyer> andrewsmedina: yo <andrewsmedina> niemeyer: everything ok? <niemeyer> andrewsmedina: Yep, things running well <niemeyer> andrewsmedina: On the quiet side given the holidays <niemeyer> andrewsmedina: at least on the Go side of things.. py folks pushing hard <andrewsmedina> niemeyer: you have any issue for me? <niemeyer> andrewsmedina: The one I suggested last time still looks like a good one to handle, unless you'd like something else for whatever reason <andrewsmedina> niemeyer: that issue is done in python version? <niemeyer> andrewsmedina: Yeah, I believe so <niemeyer> andrewsmedina: hazmat can confirm, thouh <hazmat> greetings <hazmat> andrewsmedina, re env? no <andrewsmedina> niemeyer: I'm need talk with you about juju works on centos. I'm needing a lot of that :( <hazmat> andrewsmedina, it should be fairly straight forward from a software perspective.. the charms though are not portable <hazmat> so a separate distro needs effectively its own set of charms <hazmat> and we would need cloud-init to get the machine initialization in place <andrewsmedina> hazmat: juju commands are restrict to apt <hazmat> andrewsmedina, what apt specific usages there are pretty minimal <hazmat> the biggest work would be making cloud-init run on centos.. amazon has done that already to some extent with their linux ami.. actually it looks like fedora support is already there. <hazmat> https://bugs.launchpad.net/cloud-init/+bug/883286 <andrewsmedina> hazmat: nice <niemeyer> Stepping out for the day, or perhaps back later.. cheers all <hazmat> niemeyer, cheers <SpamapS> *argh* <SpamapS> constraints totally rewrote the same stuff ssl verification touches <SpamapS> :-P * SpamapS puts on his merge pants <SpamapS> wow sheesh, this is like.. a huge refactor <SpamapS> tests changed.. whole structure changed #juju-dev 2012-04-11 <SpamapS> alright, not so bad once I got into it * SpamapS pushes fix for SSL cert verification into juju <hazmat> SpamapS, woot! <hazmat> SpamapS, meld is your friend on the nasty merges <hazmat> i typically invoke via bzr qconflicts <SpamapS> hazmat: none of it was really nasty actually. We both just legitimately changed the same path in a lot of places, but luckily it never got that ugly <SpamapS> most of it was that get_current_ami changed to something much more elegant.. <SpamapS> and what I did was very non-intrusive.. <SpamapS> hazmat: oo, never used that <SpamapS> hazmat: know any good tools for analyzing aggregate code stats for python? <SpamapS> I am putting together a little retrospective for the evolution of the juju codebase over the last 6 months. <hazmat> SpamapS, you mean want LOC over time? * hazmat gives up on english <SpamapS> LOC and maybe test coverage though I know I have to actually *run* the tests to do that <SpamapS> hazmat: I can find a lot of tools to do per-file stats <SpamapS> but I just want to point at a dir and get some interesting numbers <hazmat> SpamapS, nothing python specific comes to mind for that.. you could try just pushing it to ohloh <SpamapS> oooo <SpamapS> yeah that might work :) <SpamapS> argh.. yet another site to login to <hazmat> SpamapS, else.. scripting http://cloc.sourceforge.net/ with bzr -u revno <SpamapS> hazmat: 96 test coverage... not too shabby <SpamapS> 96% I should say <SpamapS> ahh and the worst file is juju/lib/lxc/__init__ .. which would be better if I had not skipped those tests :) <hazmat> yeah.. we dropped 2% since last release <hazmat> sloppy ;-) <SpamapS> I got really weird errors when running coverage tests <SpamapS> exceptions.IOError: /usr/lib/python2.7/dist-packages/ubuntuone-storage-protocol/juju/hooks/tests/hooks/success-hook doesn't exist <hazmat> huh <hazmat> odd path <hazmat> SpamapS, via make coverage? <SpamapS> https://www.ohloh.net/p/juju <SpamapS> hazmat: yeah <hazmat> SpamapS, haven't seen that one before <SpamapS> Step 2 of 3: Importing source code into database (Running 0/1) <SpamapS> *get on with it!* ;) <hazmat> bcsaller, the latest lbox diff looks off <bcsaller> when doesn't it <bcsaller> I'll take a look <hazmat> ic some of the changes that jimbaker made in that diff that are on trunk <bcsaller> hazmat: which branch are you looking at? <hazmat> https://codereview.appspot.com/5892046/ <hazmat> bcsaller, the pre-req needs to have trunk merged <hazmat> lp gets the diff wrong as well.. say its 7k <hazmat> bcsaller, might be easiest to just remove the pre-requiste on the mp and run lbox again <hazmat> but getting the pre-req merged to current trunk should also work * hazmat is tired <hazmat> beer o'clock back in a bit <hazmat> bcsaller, can you run lbox again <bcsaller> hazmat: I had, you think it will be different if I do it again? <hazmat> bcsaller, i modified the mp <hazmat> just now <bcsaller> ahh, ok, running it now, for both <hazmat> bcsaller both?
{'channel': 'juju-dev', 'month': 4}