#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 prpopose
<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 in::
<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 2013-04-01
<jam> fwereade: there you are
<jam> I hereby revoke your ability to submit any more patches :)
<fwereade> jam, hey dude, tyvm for all the review
<fwereade> jam, haha
<fwereade> jam, that's what happens when my family go away for a couple of days and there's noone on irc :)
<dimitern> fwereade: you're on fire on friday :)
<fwereade> dimitern, yeah, 'twas a great day
<fwereade> jam, I was thinking of adding explicit tests for the charm test helpers to charm_test.go, would that be ok with you?
<jam> fwereade: I've been told you don't write tests for test helpers, but *I'm* personally a fan of it.
<jam> (Why is this test failing? Oh the test infrastructure is wrong)
<fwereade> jam, yeah, me too, it's just been 4 years since I've been in an environment where someone else agrees with me on this
<dimitern> jam: are we the only ones today for standup?
<jam> dimitern: technically, but mgz is sitting on mumble
<fwereade> dimitern, fwiw jam's observations on the txns are good ones, and I'm still trying to figure out the Right Thing to do in those cases, but I'm definitely not quite doing it right now
<fwereade> dimitern, jam: the big question for me is what I can safely assume about ops that aren't constructed in plain view... *at the moment* we can simplify those my assuming how the op-creation methods work
<fwereade> dimitern, jam: and *maybe* we should
<jam> fwereade: I did a lot of reviewing, can you link for context?
<fwereade> jam, https://codereview.appspot.com/8126044/diff/1/state/machine.go#newcode310
<fwereade> jam, https://codereview.appspot.com/8126044/diff/1/state/machine.go#newcode447
<fwereade> jam, I have ideas floating around about a layer that lets us work with ops without having to think so much
<jam> fwereade: so if you have a case where retrying will succeed when it would otherwise fail, I'm happy to have the retries
<jam> though a more consistent "try twice" or "try three times" seems useful
<fwereade> jam, "try twice" was deliberate, and I think it's correct but its form may be unhelpful -- the idea there is that we use the exact same gating checks across the board, but an aborted txn should guarantee that one of those will fail; we should therefore always return before attempting to execute a second txn
<fwereade> jam, deserves a comment, I think
<fwereade> jam, the reason for the "try three times" was because I expect lifecycle switches to be icky and demand retries, but neglected to observe that this one's simpler than I assumed
<fwereade> jam, I would be most keen to go for a try-twice approach there for the above reasons
<fwereade> jam, I'd like to roll up the duplicated bits of the txn-futzing code into something a little smarter, but I don't think I can justify it atm because it'd be at least half fishing-trip
<fwereade> mramm, hey, I think it's just me again -- do we need to meet? I have a pile of good reviews and I'll be landing them for the rest of the day I think, not much more to tell
<mramm> fwereade: if I have any questions about the board status, I'll let you know -- but no we don't need a meeting.
<fwereade> mramm, cool
<gary_poster> sorry for basic go question, but what is diff between []params.Port(nil) and []params.Port{} ?  Test expects first and obtains second
<gary_poster> pointer to doc would be aok :-)
<dimitern> gary_poster: I think the first one is just a nil slice, while the second one is an empty one. Both have len() == 0, but the first cannot be modified. The second is equivalent to make([]params.Port, 0)
<gary_poster> ah! thanks dimitern.  I'll see if I can switch one to the other...
<dimitern> gary_poster: actually, both can be modified ok it seems: http://play.golang.org/p/Mr2Y49I2Q2
<gary_poster> dimitern, oh, weird.  So...should DeepEquals find them equivalent?
<gary_poster> append can return back a new instance IIRC
<gary_poster> so you might still be right about initialization diffeerences
<dimitern> gary_poster:  yeah, you're right - append creates a new slice
<dimitern> gary_poster: deepequals should work I think
<dimitern> gary_poster: they're of the same type
<gary_poster> dimitern, http://pastebin.ubuntu.com/5667597/ ISTM that DeepEquals does not behave that way now?  Or am I missing something?
<dimitern> gary_poster: https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/vNodYyoUu9Q - there are no docs about it, but there are some ML questions about it
<dimitern> gary_poster: so "the value of an uninitialized slice is nil"
<fwereade> gary_poster, I suggest using HasLen for slices that might be nil or empty
<fwereade> gary_poster, assuming you're testing
<fwereade> gary_poster, also works on maps
<dimitern> gary_poster: HasLen 0 works on both maps and slices, even if nil, so should work
<gary_poster> fwereade, ack, ty.  So given context (http://pastebin.ubuntu.com/5667597/) of testing larger struct, would you suggest refactoring that DeepEquals assertion to stepping over each attr individually?
<dimitern> gary_poster: the issue for me here is why []T(nil) is returned when it need to return []T{} probably?
<gary_poster> yeah, I was going to try and address that
<fwereade> gary_poster, doing every field seems a bit nasty
<dimitern> try c.Assert(gotEntities[num].Port, DeepEquals, ent.Port)
<fwereade> gary_poster, I'd probably prefer to fix either the return value or what the test checks for
<gary_poster> fwereade, I thought so too.  Cool, I'll pursue that.  thank you again, fwereade and dimitern
<fwereade> gary_poster, cheers
<dimitern> if it fails, then I suppose digging into reflect.DeepEqual to see what might be the issue
<fwereade> dimitern, AIUI nil is not the same as an empty slice, it just acts the same in most situations
<fwereade> dimitern, DeepEquals is not one of those situations
<fwereade> dimitern, consider maps -- nil maps act like empty maps in many situations, but not all
<fwereade> dimitern, maps are a bit worse off because there's no equivalent of append for a map, so the difference is a little more obvious
<dimitern> fwereade: yeah, I was thinking something in those lines
<dimitern> fwereade: and the docs are sparse at places ("if it's not in the docs it's not allowed " etc.)
<fwereade> gn all, hope to pop on and do a few of other people's reviews a bit later
<dimitern> fwereade: have a good one
<thumper> morning
<gary_poster> hi
<gary_poster> I'd really appreciate two reviews of this large but almost-but-not-entirely mechanical branch (circular imports): https://codereview.appspot.com/8086045/
<thumper> hi gary_poster
<gary_poster> hey thumper :-)
<thumper> gary_poster: why the new package for params?
<thumper> gary_poster: instead of using "series" for series and "name" for the service name with comments for "precise" and "wordpress", why not just structure the test so the results show "precise" and "wordpress" ?
<gary_poster> thumper, I did not add the params package, I only added the values to the params package.  params package is supposed to be a place to put structs that are used both by state and by api
<thumper> ok
<gary_poster> the two are not to mix, AIUI; and certainly when they do you get circular imports
<thumper> I bet most of those changes were mind-numbingly boring
<gary_poster> why yes! :-)
<gary_poster> thunper, +1 on changing the examples to the comments.
<gary_poster> thumper, even
 * thumper writes it on the review
<gary_poster> ty
 * thumper looks at the kanban board for something to do
<m_3> thumper: I don't have a leankit acct... would you mind linking lp:~mark-mims/+junk/pyju-packaging-with-alternatives to the packaging item
<m_3> thumper: it's working, but martin can review/cleanup when he gets back from vaca
<thumper> m_3: sure...
<m_3> thumper: thanks!
<m_3> thumper: go packaging should be able to do something similar
 * thumper nods
<m_3> awesome... got an instance running with both 0.6 and 1.9.13 installed from packages
#juju-dev 2013-04-02
<davecheney> can anyone else bootstrap and deploy atm ?
<davecheney> I think rev 1078 broke everything
<rogpeppe> mornin' all
<rogpeppe> davecheney: i'll give it a try
<fwereade__> rogpeppe, I cannot repro that
<fwereade__> rogpeppe, any luck?
<rogpeppe> fwereade__: live tests work ok; i just did a bootstrap and deploy, then realised i hadn't done upload-tools...
<fwereade__> rogpeppe, I did do upload-tools and it seems to work ok
<rogpeppe> fwereade__: trying again
<rogpeppe> fwereade__: good
<rogpeppe> fwereade__: have a good weekend? i see a lot of CLs!
<fwereade__> rogpeppe, cath + laura were away for a bit :)
<fwereade__> rogpeppe, only really a day, but a day is quite a long time when you can just drop the concept of interruptions from your mind
<rogpeppe> fwereade__: i was looking at jam's sync-tools branch and am unsure about the "noisy by default" approach. this represents a change of direction AFAICS and i'm not convinced it's the right one.
<rogpeppe> fwereade__: i'd be happier if those messages were printed given a -v flag.
<fwereade__> rogpeppe, hmm, maybe
<jam> rogpeppe: Consider it an exploration into, "juju doesn't sit there telling me nothing for 2 minutes"
<jam> I know whenever I use juju I have to run "--debug" because otherwise it just appears to hang.
<jam> I'd like to find a middle ground
<jam> but notifying on something that takes more than 10s seems like a good thing to me.
<fwereade__> rogpeppe, my perspective was that the only reason we didn't provide feedback was because we didn't have a good way to do so, and we've all ended up sliding into the always run --debug trap
<rogpeppe> jam: me too, but i think that's ok. i want these commands to work well in a script without needing to add --quiet flags all over the place
<rogpeppe> fwereade__: i think --debug is too much
<jam> rogpeppe: I would guess 'juju' is more of a user binary than a script one, so we should bias towards that.
<rogpeppe> fwereade__: but -v should be just right
<fwereade__> rogpeppe, agreed, I think it's awful
<rogpeppe> jam: i think that's the way we're using it now, but i don't see that as its role in the future necessarily
<fwereade__> rogpeppe, IMO the somewhat forbidding user experience is a Really Bad Thing and anything that works against that is good
<jam> rogpeppe: so I feel your argument is a bit in the "hypothetical use case". If it is a concrete one, then we can design around it. But I'd really like to make sure we are getting feedback from people performing that use case.
<rogpeppe> fwereade__: i don't think the unix tradition is a Really Bad Thing
<jam> Because we already have feedback from the rest of us (non-scriptors)
<jam> that want more feedback
<rogpeppe> jam: i'd like to make -v work well
<rogpeppe> jam: and keep commands quiet by default
<jam> rogpeppe: I would argue that things that get written into a script can do '-q' more easily than users can do '-v'
<rogpeppe> jam: oh please no. i really don't want us to have a -q flag
<rogpeppe> jam: next we'll be printing vt100 escape sequences
<jam> rogpeppe: other than the verbosity being too high, telling users "always supply -v to get feedback" isn't really a good user experience, either.
<fwereade__> rogpeppe, the impact is that *users* don't like it; I personally enjoy this job and would like to keep doing it, and juju being able to attract and retain users is one of the necessary conditions for that to happen long-term
<fwereade__> rogpeppe, what is your objection to "-q"?
<rogpeppe> fwereade__: in general users follow the instructions they're given, which will probably have a -v flag
<fwereade__> rogpeppe, I bet there's a corollary to that stephen hawking thing... even command-line flag you make your users type halves your user base
<rogpeppe> fwereade__: it's just one more piece of complexity. we are already (probably) going to have --verbose, --debug, --info, --error and maybe more logging related options
<fwereade__> rogpeppe, whoa, why would we have those things?
<fwereade__> rogpeppe, log-level maybe
<rogpeppe> fwereade__: we want to be able to set the level of debugging at run time, no?
<rogpeppe> fwereade__: ok, so --verbose, --debug, --log-level and now --quiet too
<fwereade__> rogpeppe, well, honestly, --debug and --verbose *are* plainly nonsense
<rogpeppe> fwereade__: i think we should have --verbose and --log-level only probably
<rogpeppe> fwereade__: with maybe --debug grandfathered in
<fwereade__> rogpeppe, I don;t think that the fact that we have a shitty solution in place is a good argument against making parts of it useful
<rogpeppe> fwereade__: i think that having commands silent by default and chatty when you ask them to be is a good thing.
<fwereade__> rogpeppe, and our users don't
<rogpeppe> fwereade__: we don't need to tell the user every time we make an RPC
<fwereade__> rogpeppe, I don;t think I was suggesting we should
<rogpeppe> fwereade__: from the CL "Mostly because those are the bits that sit waiting on RPC"
<rogpeppe> fwereade__: at the least we should have a public discussion about this
<fwereade__> rogpeppe, it seemed to me that there has been unanimous agreement both at the sprint and among users that our lack of CLI feedback is shit
<fwereade__> rogpeppe, my user knowledge is, I freely admit, second-hand
<fwereade__> rogpeppe, there was not necessarily agreement about what the final answer should look like
<fwereade__> rogpeppe, but I didn't hear anyone claiming that it would be bad to give users a bit of feedback not forced through the log package
<rogpeppe> fwereade__: i think we can give good CLI feedback, but keep things quiet by default. that's the approach we have deliberately taken so far (although our verbose mode is indeed shit) and i think we should have a discussion about it rather than doing it ad hoc in a random CL
<rogpeppe> fwereade__: i agree; i don't think --verbose should affect the log level
<fwereade__> rogpeppe, ok, I didn't actually think that approach was deliberate at all
<rogpeppe> fwereade__: although... given that we've got lots of log levels now, perhaps --verbose should be equivalent to --log-level info
<fwereade__> rogpeppe, maybe... I am still trying to figure out whether user output and logging are the same thing or not
<rogpeppe> fwereade__: i agree. i'm not entirely sure either.
<fwereade__> rogpeppe, I *think* they probably actually are -- but I'm pretty sure the user output doesn't need all that timestamping, badging, etc
<rogpeppe> fwereade__: perhaps we should take all the badging off when printing to std(out? err?)
<fwereade__> rogpeppe, if we had something that logged to stderr with --quiet: nothing, nothing: notice-and-above, --verbose: info-and-above, etc
<fwereade__> rogpeppe, yeah
<rogpeppe> fwereade__: that sounds ok to me actualy
<rogpeppe> lly
<rogpeppe> fwereade__: a notice wants to be seen
<fwereade__> rogpeppe, yeah
<rogpeppe> fwereade__: the question becomes then: what justifies a notice?
<jam> rogpeppe: so one small thing, is that '-v' and all the Log values aren't shown by "juju help status". I haven't quite figured out when they are shown to the user
<fwereade__> jam, they're shown on plain juju help iirc
<jam> fwereade__: that tells you to init bootstrap etc
<jam> no flag help
<rogpeppe> jam: juju help global-options
<fwereade__> jam, tim didn't like polluting all the individual command helps with global flags
<rogpeppe> jam: i argued against the approach of leaving out global flags from individual commands but failed to convince
<jam> rogpeppe, fwereade__: so if a user does "juju help" then "juju help topics" then "juju help global-options" he can then see them
<rogpeppe> jam: yeah :-|
<jam> IOW, they will never see them
<rogpeppe> jam: yeah
<jam> except for someone that has a perversity for reading docs
<jam> or is really struggling with something so goes to each help topic they can find
<rogpeppe> jam: i agree
<jam>  anyway, the help for it says "log additional messages"
<jam> which certainly doesn't sound like give me more feedback.
<rogpeppe> jam: and i don't think we have enough flags to justify the "cleanliness" argument
<jam> rogpeppe: or at least, we should link from "juju help foo" "Additional flags are in: juju help global-options"
<fwereade__> jam, rogpeppe: all the more important, I think, to provide a more sensible level of output by default
<fwereade__> rogpeppe, do you know what the situation is wrt multiple log targets with different badging behaviour?
<jam> fwereade__: so I've obviously made clear why my thoughts are on that, but I think rogpeppe has a fair point that we can have it as a discussion first.
<jam> having it in Log certainly made it undiscoverable
<jam> both to users, and to me as a dev.
<fwereade__> jam, +1
<jam> I'm still not sure how I get access to that flag (ctx.?)
<fwereade__> jam, you shouldn't need it
<fwereade__> jam, as a suggestion
<rogpeppe> fwereade__: i suspect you can only have one level of log line taggin
<rogpeppe> g
<fwereade__> jam, maybe land that with the stderr logging going to Notice, and propose something smarter on the lists?
<fwereade__> jam, cmd/logging.go or something like that
<jam> fwereade__: so "-v" appears to just add stderr as a place to write log messages
<rogpeppe> fwereade__: can we have multiple log targets currently?
<jam> Note that by default, we don't have a log file nor an output to the user
<jam> so by default all messages are dropped into the nether
<fwereade__> jam, yeah, I know, and I agree that is bad
<rogpeppe> jam: i think that's ok, but you know that :-)
<rogpeppe> jam: well, except that i think the default log level should be Notice
<rogpeppe> jam: (whatever that implies)
<fwereade__> rogpeppe, I think the choice of level for particular messages is something that we'll iterate on forever
<rogpeppe> fwereade__: it would be nice to have a guideline though. is a notice an expected event or not, for example?
<fwereade__> rogpeppe, yes, I think so
<rogpeppe> fwereade__, jam: ok, so as a straw man here are the messages from the CL with some possible debug levels against them: http://paste.ubuntu.com/5669776/
<fwereade__> rogpeppe, that looks pretty good to me
<jam> rogpeppe: so the one thing with my patch that we miss going to log, is that it gives incremental messages about copying tools.
<jam> It doesn't know how big the thing is until it has downloaded it
<jam> because Get() doesn't expose the size
<jam> I can certainly use multiple lines for it
<jam> but it was sort of nice to have it all on one line
<fwereade__> jam, I have a thought there actually
<fwereade__> jam, we have a couple of places already where we need to download things preferably-just-once, and check hashes, and suchlike
<rogpeppe> List could provide some metadata
<fwereade__> jam, it *might* be worth checking for commonalities there
<jam> rogpeppe: I imagine Get() might have a Content-Length header as well.
<jam> But it isn't exposed yet.
<jam> I had originally thought to just Put(Get)
<jam> sort of thing
<jam> rather than buffering anything
<jam> but Put() requires knowing the content-length
<rogpeppe> jam: unfortunately goamz/s3 throws away the info
<rogpeppe> afk for 5 mins
<rogpeppe> back
<fwereade__> afk myslf for a bit, sorry
<jam> rogpeppe: yeah, goamz/s3 also doesn't let you Get anonymously :(
<jam> But I already filed that bug.
<fwereade__> jam, I responded to some of your review points, still thinking about others
<fwereade__> jam, in https://codereview.appspot.com/8183044
<jam> fwereade__: I think I've addressed all your comments in https://codereview.appspot.com/8051043/ aside from what to do about user feedback.
<rogpeppe> fwereade__: ping
<dimitern> anybody else having issues with trunk after rev 1089?
<dimitern> it seems cmd/builddb/main.go no longer compiles, because it imports "state" and is not using it
<rogpeppe> dimitern: i see that. if you want to propose a trivial fix, that would be great!
<dimitern> rogpeppe: well, I will but this shouldn't happen - somebody didn't run the tests before committing
<rogpeppe> dimitern: agreed. you're welcome to ascribe blame if you want.
<rogpeppe> :-)
<mgz> there's a thread on the list about that
<dimitern> rogpeppe: I think it's gary_poster's branch
<rogpeppe> dimitern: that makes sense. it was a large change.
<dimitern> and dfc committed after that also without running the tests
<dimitern> I always do go build ./... && go test ./... in juju-core, that's how I caught it
<dimitern> mgz, jam: standup?
<mgz> I'm there
<dimitern> I just left :) let me rejoin
<dimitern> there it is - it's a trivial one-line change to fix trunk: https://codereview.appspot.com/8253043
<rogpeppe> fwereade__, jam: FWIW i also support using a temp file for the tools. but maybe the odd 10MB is not anything to care about these days...
<dimitern> rogpeppe: do you have an idea why UnitStatus consts moved from state to state/api/params?
<rogpeppe> dimitern: because they're visible in the API
<dimitern> rogpeppe: but in state they're not?
<rogpeppe> dimitern: they're visible in both state and state/api
<dimitern> rogpeppe: I added state/status.go to manage unified unit and machine status
<rogpeppe> dimitern: and state/api can't import state
<dimitern> rogpeppe: so I should add state/api/params/status.go just for the constants
<rogpeppe> dimitern: i *think* so. state/api/params gives me discomfort but i haven't figured out a better solution yet (other than duplicating all the types)
<rogpeppe> dimitern: i'm not entirely sure that the recent changes were necessary though
<dimitern> rogpeppe: ok, so can have operations in state/status.go and status consts in state/api/params/status.go - sound sane?
<rogpeppe> dimitern: that sounds reasonable. actually, you could probably have the status consts in state/status.go too. i can't currently think of a compelling reason why not.
<rogpeppe> dimitern: except... then they can't be seen by state/api Go clients.
<dimitern> rogpeppe: well, having status related stuff in 2 modules seems wrong, but as a compromise for the api clients I suppose it's ok
<rogpeppe> dimitern: what operations are you adding?
<dimitern> rogpeppe: getStatus and setStatusOp
<rogpeppe> dimitern: they seem like very state-oriented operations tbh
<dimitern> rogpeppe: they are
<dimitern> rogpeppe: that's why they'll remain in state/, while the consts will be in params
<rogpeppe> dimitern: BTW, i think that when the agents all move to talking via the API, we should be able to merge state/api/params into state/api
<rogpeppe> dimitern: cool. i thought you were bothered by that.
<dimitern> rogpeppe: not especially, fixing merge conflicts now :)
<rogpeppe> dimitern: so unit status is going into its own collection?
<dimitern> rogpeppe: yes, along with the (new) machine status
<rogpeppe> dimitern: the transaction lists get longer and longer :-)
<dimitern> rogpeppe: but the code arguably better :)
<dimitern> rogpeppe: is state/api/params UnitInfo supposed to be almost exactly as state/unit unitDoc? I'm removing 2 fields from there: Status and StatusInfo, now in a separate statuses collection.
<dimitern> rogpeppe: and megawatcher tests fail
<rogpeppe> dimitern: it is, yes
<rogpeppe> dimitern: as the comment says, it's a subset
<dimitern> rogpeppe: so I should remove these 2 fields from UnitInfo as well
<rogpeppe> dimitern: this is part of the problem with making new collections - i assumed that all the information for a unit was to be found in the unitDoc
<rogpeppe> dimitern: i guess so. i will need to make the allWatcher indirect (something i thought i could put off until after 13.04)
<dimitern> rogpeppe: not anymore, for statuses at least
<rogpeppe> dimitern: yeah, i see that
<jam> mgz,dimitern: So I'm still late, but my calendar has the standup ~25min ago, not 1hr 25min ago. I was keeping it the same UTC time (which makes it 1 hour later for you guys). Do you prefer to move it earlier?
<jam> We can certainly do whenever while wallyworld is on vacation for 2 weeks.
<mgz> yeah, the timezone switch make life funner
<dimitern> rogpeppe: PTAL https://codereview.appspot.com/8256043/ - the stuff around the API especially
<rogpeppe> dimitern: looking
<dimitern> also other reviewers are welcome :)
<gary_poster> dimitern, rogpeppe sorry, I definitely did run tests, but I must have done something insufficiently, obviously
<rogpeppe> gary_poster: i know what the problem was
<gary_poster> what was it?
<dimitern> gary_poster: np, it happens, but did you run go build ./... && go test ./... in the juju-core dir?
<rogpeppe> gary_poster: go test ./... does not *build* everything. if there's a package with no tests (which builddb is) it will just  be ignored
<rogpeppe> gary_poster: personally i think that's a bug
<rogpeppe> gary_poster: but it's the case
<gary_poster> rogpeppe, dimitern that's it: I ran go test ./... but not go build ./... .  I did not know if that requirement
<gary_poster> of
<dimitern> rogpeppe: and I really'd like the equivalent of go build for tests..
<rogpeppe> gary_poster: it's not your fault - i've been bitten by that before
<gary_poster> Very good to know, thanks for fixing, and sorry for the problem
<rogpeppe> dimitern: http://paste.ubuntu.com/5670234/ (i call it "gotest-c")
<rogpeppe> dimitern: i pushed quite hard for go test -c ./... to work, but failed i'm afraid
<dimitern> rogpeppe: ah, cool tool
<dimitern> rogpeppe: hmm.. what was the cited reason not to do it?
<gary_poster> actually it wasn't even my branch
<rogpeppe> dimitern: too close to go1.1
<gary_poster> I will go spread the news on juju-gui
<gary_poster> could have been my branch :-)
<dimitern> gary_poster: oh, sorry then - but you see, you could've caught it with go build before go test ;)
<gary_poster> dimitern, definitely!  and it was a juju-gui branch, so we should all know about this
<dimitern> gary_poster: cheers
<dimitern> fwereade__: ping
<fwereade__> dimitern, pong
<dimitern> fwereade__: hey, wanna take a look at machine status CL? https://codereview.appspot.com/8256043/
<fwereade__> dimitern, ack
<jam> rogpeppe: btw, your reply seems to have gone directly to me, rather than juju-dev list
<rogpeppe> jam: oh, thanks!
<davecheney> lads, the build really is broken, http://paste.ubuntu.com/5670353/
<dimitern> davecheney: so my fix was for unrelated issue
<jam> davecheney: What is confusing is that "state entity name" doesn't exist in the source tree. "not fonud in configuration" is present, but with %s and the only bit passes "state entity tag".
<davecheney> jam: lucky(~/src/launchpad.net/juju-core) % bzr st .
<davecheney> modified: version/version.go
<davecheney> it's not my tree
<davecheney> oh, and 1077 isn't that reliable a build either,
<davecheney> http://paste.ubuntu.com/5670359/
<jam> davecheney: so with 1091 bootstrap works and brings an instance up, but deploying fails to bring up the unit agent, is that correct/
<jam> ?
<davecheney> jam: that is correc
<jam> I'm wondering if the cloudinit on unit agents is accidentaly downloading published tools, rather than --upload-tools
<davecheney> correct
<davecheney> this is machine 1
<jam> so it is reverting to 1.9.12 on the non-bootstrap nodes
<davecheney> ha!
<davecheney> 2013-04-02 13:06:11 URL:https://s3.amazonaws.com/juju-dist/tools/juju-1.9.12-precise-amd64.tgz?AWSAccessKeyId=AKIAJ4SOKUWG25EDMAOA&Expires=1680440598&Signature=mL1lQJZkuqtjagofN0jbm%2F3hUz4%3D [2142668/2142668] -> "-" [1]
<jam> davecheney: can you ssh in and check 'jujud --version' ?
<davecheney> ^ indeed they are
<davecheney> jam: good guess
<jam> davecheney: at least it make sense, even if it is still broken :)
<davecheney> so, it's been broken for how long then ?
<davecheney> since last friday ?
<jam> davecheney: my guess is downloading the wrong tools has been true for a while
<jam> but we have'nt broken compatibility in a while
<davecheney> interesting
<davecheney> that could explain why I can't get the fscker to work at _all_ in hp cloud
<rogpeppe> davecheney: yes, if you're trying to deploy a precise charm from quantal, the tools logic will fall back to the tools in the public bucket
<rogpeppe> davecheney: i believe there are plans to change this, but that's how it is currently
<rogpeppe> davecheney: (i suggested that the error would be more obvious if we actually changed the major version, but nobody else thinks that's a good idea)
<davecheney> rogpeppe: oh indeed
<davecheney> you are right
<davecheney> so the tools are following the series of the charm ...
<davecheney> which means --upload-tools is useless
<rogpeppe> davecheney: yes, they have to
<davecheney> rogpeppe: i agree they have too, but they never used too
<davecheney> see prevoius point about --upload-tools being useless
<rogpeppe> davecheney: it means that if you want upload-tools to work you have to deploy a charm with the same series as your current machine
<jam> davecheney: you do the builds, is the -quantal tool any different from the -precise one? Or is it just changing the name of the tarball? (Maybe you have lp do the actual build, I guess)
<rogpeppe> davecheney: which actually makes some kind of sense
<rogpeppe> jam: i suspect there's no actually difference at all.
<davecheney> jam: the Q tools are built by a Q bot
<davecheney> but in practice, it makes no difference
<davecheney> rogpeppe: i know it makes sense
<TheMue> fwereade__: ping
<davecheney> it's just impossible to make work
<davecheney> ie, this cross series lunacy
<fwereade__> TheMue, pong
<davecheney> i have deployed a quantal bootstrap node
<davecheney> then I got to deploy a precise mysql node becuase there is no cs:quantal/mysql charm
<davecheney> and --upload-tools fails me
<davecheney> to be clear
<TheMue> fwereade__: we still have a decision open regarding the environ config.
<davecheney> i understand why it does what it does
<rogpeppe> davecheney: download the precise mysql charm and rename it to quantal
<davecheney> rogpeppe: sure, but I lost the argument about cross series enviroments being a bad thin
<TheMue> fwereade__: shall i refactor it to an own document with its own collection or stay with the attrs and add uuid?
<davecheney> and now I'm having a sook about a place where it has blown up on me in testing
<rogpeppe> davecheney: it wouldn't be such a problem if the error message was more clear
<fwereade__> TheMue, add a new document please
<davecheney> rogpeppe: true, that would at least let me understand what went wrong
<rogpeppe> davecheney: exactly. you are by no means the first person to have been bitten by this hard-to-diagnose issue
<fwereade__> TheMue, there is already a stte.Environment entity, you just need to back it with a doc
<davecheney> rogpeppe: without twisting the knife
<davecheney> this is exactly the kind of nonsnse that will haunt us too our graves with cross series environments
<rogpeppe> davecheney: only if we make backwardly incompatible changes without changing the major version number
<TheMue> fwereade__: ok, will do.
<fwereade__> rogpeppe, davecheney: I am strongly tempted to bump the FindTools changes up out of the backlog... I think they will make the problem much clearer
<rogpeppe> davecheney: i *think* that we're seeing this a lot only because we are not doing that. in normal juju use, no-one will use --upload-tools, and if they do, they'll be compatible *or* the major version number will have changed, and in both those cases you won't have this issue.
<davecheney> FUCK
<davecheney> now when i use --upload-tools it doens't respect default-series
<fwereade__> rogpeppe, davecheney: another thought: if the series really doesn't matter at the moment, why not just hack --upload-tools to fake up quantal,precise,raring copies of the same tarball and upload them all for the appropriate arch?
<davecheney> fwereade__: yeah, that might have to be the solution for the moment
<davecheney> still doesn't solve my second outburst
<fwereade__> davecheney, you can always override default-series, unless I'm very confused
<davecheney>   ap-southeast-1:
<davecheney>     type: ec2
<davecheney>     default-series: precise
<davecheney>     region: ap-southeast-1
<davecheney> lucky(~) % ssh ec2-46-137-197-55.ap-southeast-1.compute.amazonaws.com -l ubuntu -- lsb_release -a
<fwereade__> davecheney, --upload-tools overwrites it, on the basis that if you're uploading tools you want to run them
<davecheney> No LSB modules are available.
<davecheney> Distributor ID: Ubuntu
<davecheney> Description:    Ubuntu 12.10
<davecheney> Release:        12.10
<davecheney> Codename:       quantal
<davecheney> fwereade__: fuck, so now i'm stuck in the position that I cannot test precise charms without a precise host to run juju cli
<fwereade__> davecheney, but that behaviour would surely be dropped if we uploaded multiple tools
<davecheney> fwereade__: hmmm, i don't see how
<davecheney> FindBestTools won't consider tools outside the series
<fwereade__> davecheney, right, but we'd be starting precise machines just fine if we were asking for them
<davecheney> fwereade__: so tim and I cannot do that
<davecheney> i have a quantal machine, he has raring
<fwereade__> davecheney, surely if you do explicitly `deploy precise/wordpress` you'll get a precise machine... it just might not have compatible tools
<davecheney> fwereade__: yup, that works, and leads to the original problem
<davecheney> i guess then if we upload multiple tools
<davecheney> then that is a solid workaround
<fwereade__> davecheney, I think upload-multiple-tools + look-in-one-bucket-only together should make things properly clear
<fwereade__> davecheney, the other related issue is that the environments are not sophisticated in how they handle tools at all... I think they still pick them at the wrong time anyway
<davecheney> fairy nuf
<davecheney> it's late here
<davecheney> i'll catch you on the flip side
<dimitern> rogpeppe: did you manage to review it?
<rogpeppe> dimitern: in a call
<mramm> I'll be out for the day -- but am just doing some home maintenance stuff so I'll be around if needed
<mramm> I'll try to be at the kanban meeting in 20 min though!
<fwereade__> mramm, cool
<rogpeppe> fwereade__: +1
<fwereade__> rogpeppe, cheers
<rogpeppe> fwereade__: --fake-tools raring,quantal
<rogpeppe> fwereade__: perhaps
<fwereade__> rogpeppe, perfect, saves us hardcoding them
<fwereade__> rogpeppe, other possibility is to get the available series' from the environment, by looking at the available images, but that's not something to do now
<jam> could we instead just have FindTools understand an "-any-" series?
<dimitern> fwereade__: how's going?
 * rogpeppe gets a bite to eat
<dimitern> I still need review of https://codereview.appspot.com/8256043/
<dimitern> rogpeppe, fwereade__ ^^
<fwereade__> dimitern, hey, sorry, I was writing one in some detail and got caught up by the meeting
<dimitern> fwereade__: no worries
<dimitern> TheMue: thanks for the review!
<gary_poster> fwereade__, hi.  I have a question about relation errors.  Are they going to be exposed as part of unit status, or somewhere else?
<fwereade__> gary_poster, at the moment there are no relation errors: any relation error puts the whole unit in an error state
<gary_poster> fwereade__, and will that be the case for 13.04? (great by me if so)
<gary_poster> (simply as a matter of integration)
<fwereade__> gary_poster, I was not wholly in favour of this change when we made it, so it might come back one day, but definitely not by 13.04 :)
<gary_poster> fwereade__, cool, sounds good. :-) thanks!
<gary_poster> rogpeppe, fwiw, ^^^ that's off our plate for the time being at least
<rogpeppe> gary_poster: cool
<rogpeppe> dimitern: you have a review
<fwereade__> dimitern, and another
<dimitern> rogpeppe, fwereade__: cheers guys
<dimitern> fwereade__: about juju status discarding errors - it was like that before I changed the unit status not to return error
<dimitern> fwereade__: how are we supposed to report such errors?
<fwereade__> dimitern, that doesn't make me any happier to change it back ;p
<fwereade__> dimitern, there seems to be a checkError() pattern in use in there
<fwereade__> where things we can't get are represented as a {"status-error": "something happened, oh noes"}
<jam> mgz: all the juju patches, should we be reviewing or is that more a kapil thing?
<mgz> it's mostly an auditing thing
<mgz> the fun part is in the packaging branches anyway really
<jam> it looks like most of them are already landed
<mgz> particular because of bug 985285
<_mup_> Bug #985285: juju packaging branch fails using merge-upstream from tarball and upstream branch <Ubuntu Distributed Development:New> < https://launchpad.net/bugs/985285 >
<jam> weird that I get the mp, but not the "merged" emails
<mgz> is there someway I can get bzr to give me a diff ignoring file-id changes?
<mgz> oddly --take-other is deleting files that don't get included as part of other... builddeb is struggling for sanity here
<jam> mgz: so why the backports to 0.5?
<jam> vs just releasing the 0.6/7/whatever?
<mgz> they were just in the list for a release
<mgz> it doesn't hurt and was easy, at least compared to battling builddeb
<mgz> the fact the packing branches are completly screwed is more troublesome
<rogpeppe> fwereade__: ping
<rogpeppe> fwereade__, dimitern: fairly trivial: https://codereview.appspot.com/8266043
<dimitern> rogpeppe: reviewed
<rogpeppe> dimitern: ta!
<TheMue> rogpeppe: and another review
<rogpeppe> TheMue: thanks
 * rogpeppe reaches end of day
<rogpeppe> here's another CL to review, if anyone fancies it. it's on the critical path for the GUI so reviews appreciated. https://codereview.appspot.com/8269043/
<benji> rogpeppe: I bet you are about EOD, but I have a review up if you have a minute: https://codereview.appspot.com/8271043
<rogpeppe> benji: no cycles then?
<benji> rogpeppe: nope; they were only in my head
<rogpeppe> benji: i really have finished already. but one thing: in params_test.go i'd add some Endpoint info, just so we can see what it'll look like when serialized
<benji> rogpeppe: thanks for the suggestion, I'll do so
<thumper> morning
 * thumper head desks
<thumper> fwereade__: ping?
<thumper> benji: you are good to merge
<benji> thumper: thanks!
<thumper> fwereade__: if you come and look later, I'm pretty sure I know what the issue is with tools and bootstrap...
 * thumper may be to blame there...
 * thumper goes to make a coffee
 * thumper waits for dave
#juju-dev 2013-04-03
<thumper> hi davecheney
<davecheney> thumper: hi mate
<davecheney> just about to get on a plane back to syd
<davecheney> got 10 mins to talk
<thumper> oh, ok
<davecheney> thanks for your CL that hard codes precise
<thumper> davecheney: the ec2 screwage was due to the series changes I did some time ago
<davecheney> that will probably solve the problem
<thumper> davecheney: it does (at least for me)
<davecheney> that whole debarcale made me so angry last night
<thumper> davecheney: I was broke, made the change, and it worked and deployed something
<thumper> sorry about that
<thumper> I've been learning a lot about tools recently
<davecheney> nah, not your fault
<thumper> I also have some man page chagnes
<davecheney> I have half a mind to demand that everyone takes one for the team and upgrades off precise so they can see what it's like
<davecheney> this shit just works if your laptop runs precise
<thumper> davecheney: no-one should be using precise
<thumper> davecheney: company policy says you should be using the latest
<thumper> davecheney: and upgrade to the new version at beta time
 * davecheney agrees with thumper
<davecheney> well, i dunno about raring
<thumper> those are the rules
<thumper> the whole company should upgrade to raring at raring beta time
<thumper> always has been therule
<davecheney> i think it isn't well communicated to new starters
<thumper> heh
<davecheney> not that much is
<thumper> davecheney: so I want to run ./scripts/generate-docs.py man -o - | gzip > /usr/share/man/man1/juju.1.gz
<thumper> but I need a sudo somewhere
<thumper> how to I make that work?
<davecheney> thumper: no idea, never used that before
<thumper> :)
<davecheney> is that from the older python juju ?
<thumper> no, something I've just made
<thumper> about to propose it
<thumper> but we need some install magic...
<thumper> for the deb
<davecheney> ohhhhhhhhh, i see the problem
<thumper> right :)
<thumper> I wrote it in python because it was a lot faster for me
<davecheney> this is normally done in a postinstall
<davecheney> right ?
<thumper> right
<davecheney> that runs as root correct ?
<thumper> probably
<davecheney> doesn't fakeroot make it work enough for testing ?
<thumper> but I don't know how to test it
<thumper> well, locally I just go: ./generate-docs.py man
<thumper> man ./juju.1
<thumper> and it works
<davecheney> can you test by making the path relative ?
<davecheney> ie
<davecheney> gzip > usr/share/....
<thumper> I'll ask someone who knows packages :)
<thumper> where do we store our packaging info?
<thumper> and is there a way I can test it?
<davecheney> package info ?
<davecheney> the debian/ overlay ?
<davecheney> have a look at the build recipes from the juju-core page
<thumper> ok, ta
<davecheney> the overlay repo is owned by me
 * thumper nods
<davecheney> no good reason for that
<davecheney> it just is
<davecheney> sorry, i have tiny internet, so it'll be faster for you to find it than me
 * thumper nods
<thumper> that's fine
 * thumper has munchies
 * thumper goes to make dinner, back later to talk with fwereade__
<TheMue> morning
<bigjools> fwereade__: hi, around?
<fwereade__> bigjools, heyhey, in a hangout so responding slowly, but yes
<bigjools> fwereade__: ah ok, I'd like to do a quick hangout with you, can you let me know when you're free please
<jam> fwereade__: 2 things I need to discuss with you, though I'm about to head to lunch. (1) What have we decided about fmt.Fprintf vs log.Infof? I'd like to land something, that is the last bit remaining. (At this point, I've stopped caring, just looking for an answer so I can land). (2) You wanted to talk about --public.
<jam> I should be back in 1-2 hrs. I'll ping you when I'm back
<rogpeppe> morning all
<davecheney> evenin'
<dimitern> jam: Fprintf, as I recall, because log output from commands is discarded
<fwereade__> jam, cheers
<rogpeppe> jam: i would prefer a two stage solution - first crank up the default logging level to "Notice" and add a way to set the logging level. then use log.Infof and log.Noticef as appropriate.
<rogpeppe> jam: the fact that all log output from commands is discarded, even errors, is i think wrong.
<fwereade__> bigjools, heyhey
<fwereade__> bigjools, available in 3 minutes or so, would you start a hangout please?
<bigjools> fwereade__: hi, yes, let me find you on g+
<bigjools> fwereade__: invited you
<dimitern> rogpeppe: when I was doing upgrade-charm cmd, I added logging and was wondering why virtually no other cmds use it (except the bootstrap I think) and fwereade__ suggested that I should remove it, because the output gets ignored
<rogpeppe> dimitern: this is something we need to sort out
<rogpeppe> dimitern: i've made my views clear; i suspect i won't win the argument though.
<dimitern> rogpeppe: yeah it's a little worrying
<rogpeppe> dimitern: thanks for your review this morning, BTW
<dimitern> rogpeppe: sure thing
<dimitern> rogpeppe: so is this a step towards indirect watching
<rogpeppe> dimitern: yup
<fwereade__> dimitern, rogpeppe: it is true that we need to sort out logging/feedback; I'm still not so sure it's something we should be committing to fixing for 13.04
<dimitern> rogpeppe: cool, how is it going to work for status, i'm curious?
<rogpeppe> dimitern: the backing is now free to make whatever changes it likes to the allInfo in response to a mongo change
<rogpeppe> dimitern: when the allWatcher backing sees a status change, it will look up the object that the status is referring to in the allInfo and update the status on that
<rogpeppe> dimitern: i'm not yet sure if we're guaranteed to see the status change before we see the object itself being created
<rogpeppe> dimitern: i think we are, as the status change happens in a separate transaction
<fwereade__> .me afk a bit
<dimitern> rogpeppe: cool stuff! well for one, unit/machine status won't change on u/m creation, only afterwards (it defaults to pending)
<rogpeppe> dimitern: yeah. i'll have to do this for other stuff too, like service config and constraints
 * rogpeppe has a look at the txn source.
<dimitern> rogpeppe: yeah, sgtm
 * rogpeppe just noticed that txn.Runner.Run isn't entirely thread safe
<rogpeppe>  but perhaps i'm missing something
<davecheney> rogpeppe: eeeeeeeeeeeek
<rogpeppe> davecheney: it's nothing too bad
<rogpeppe> davecheney: just that bson.NewObjectId does a non-thread-safe lazy initialization of the machine id
<rogpeppe> davecheney: i'm about to propose a fix
<davecheney> rogpeppe: +1
 * rogpeppe strays off the lbox beaten track and gets bitten by a panic in the undergrowth
 * TheMue dcc's rogpeppe a plaster
 * davecheney visits instantrimshot.com
<dimitern> fwereade__: I realised I didn't include removeStatusOp :) good thing to write better tests
<fwereade__> dimitern, cheers
<dimitern> fwereade__: I think it came along nicely, will propose it in a bit - you wanted to see it, right?
<fwereade__> dimitern, please, yeah
<rogpeppe> mgz: ping
<mgz> hey rogpeppe
<rogpeppe> mgz: i'm just trying to diagnose an lbox problem - it's saying no common ancestor between two branches. how can i see the revisions leading up to a particular revision id? (in this case, gustavo@niemeyer.net-20120622195450-4kpn1az3v9nnld2c)
<mgz> `bzr log -n0 -rrevid:^THAT`
<rogpeppe> mgz: ha! i've just worked it out, no probs
<rogpeppe> mgz: i did bzr log -r ..gustavo@niemeyer.net-20120622195450-4kpn1az3v9nnld2c
<mgz> right, -r is smart by default, if something looks like a revid rather than a revno it can work it out
<rogpeppe> mgz: interestingly yours only printed a single log message
<mgz> yea, you want the leading .. for the history to that point
<dimitern> fwereade__:  there it is - https://codereview.appspot.com/8256043/
<fwereade__> dimitern, cheers, I'm just writing an essay on it atm, I'll look atthe changes soon
<dimitern> fwereade__: wow, an essay, why?
<fwereade__> dimitern, well, not really
<dimitern> fwereade__: to explain why the approach is better than having status in the docs?
<fwereade__> dimitern, I'm just trying to add a concise response to rogpeppe and TheMue's concerns re doc-splitting
<dimitern> fwereade__: :) thought so, cheers - I tried to the best of my knowledge to reply, but I'd appreciate yours as well
<dimitern> fwereade__: following on status stuff, there are 3 cards on the kanban board which are related. i think i can pick up the one about MA setting status next
<rogpeppe> davecheney: https://codereview.appspot.com/8306043
 * davecheney looks
<rogpeppe> mgz: i think something must have been sticky. i started again with a fresh branch and it all worked.
<rogpeppe> davecheney: i can't really see any down sides to the change to use an array rather than a slice. it's about the same number of lines of source, and it has the additional advantage that the indexes are checked at compile time. if there was any additional complexity involved, i'd agree.
<rogpeppe> s/lines of source/number of bytes of source/
<mgz> rogpeppe: lbox does do some very voodoo things and its assumptions when creating new branches and merging don't seem solid to me
<rogpeppe> mgz: yeah, i've got that impression
<rogpeppe> mgz: it doesn't help that the error messages often don't include the stderr from the bzr command that failed
<rogpeppe> mgz: i only found out what was going on by delving in and changing the source
<dimitern> jam: standup?
<rogpeppe> fwereade__: ping
<rogpeppe> dimitern: ping
<dimitern> rogpeppe: pong
<rogpeppe> dimitern: i was just wondering why a Unit doesn't have a charm url set by default.
<rogpeppe> dimitern: perhaps you could explain?
<dimitern> rogpeppe: because it needs to be deployed first
<dimitern> rogpeppe: and there are sanity checks to perform in SetCharm as well
<dimitern> rogpeppe: makes sense?
 * dimitern lunch, bbiab
<rogpeppe> dimitern: so you'll always get a charm url set when a unit starts running?
<dimitern> rogpeppe: I think so, yes - when it's in the started state the charm's already deployed
<rogpeppe> dimitern: cool
<jam> dimitern, mgz: the standup time is still now rather than 1hr ago, though we haven't actually had a chance to discuss moving it.
<mgz> right, we were just checking
<dimitern> back
<dimitern> mgz: ping
<jam> mgz: you coming to mumble?
<jam> fwereade__: I'm back around, though we have our standup for about 15 min. Thanks for commenting on the CL. now just to chat about --public
<fwereade__> jam, sure, I'll be around
<fwereade__> rogpeppe, hell, sorry, I didn't see that
<fwereade__> rogpeppe, what can I do for you?
<rogpeppe> fwereade__: np. i got an answer from dimitern
<dimitern> fwereade__: so basically LGTM from you?
<fwereade__> rogpeppe, ah, yes -- to be specific, the unit sets its charm URL once it knows what charm it's going to use
<fwereade__> dimitern, I have a lot of comments that I'm still making -- we should talk, and figure out which of them should be addressed and when, and that will then segue into an LGTM when we agree :)
<dimitern> fwereade__: sure, thanks
<fwereade__> dimitern, just reviewed, maybe read over it after the standup while I talk to jam?
<dimitern> fwereade__: cheers, sgtm
<dimitern> fwereade__: ping me when you have 10m for a g+ please
<jam> fwereade__: so you had some concern about --public vs local tools
<jam> I believe without --public it is roughly equivalent to '--upload-tools' except we are using the public tools.
<TheMue> fwereade__: thx for your response regarding the multi docs
<fwereade__> TheMue, yw, hope it made some sense
<fwereade__> jam, really quick g+?
<jam> fwereade__: sure
<TheMue> fwereade__: yes, so far i can live with it. only my concerns about transactions done by the accessing software and not the dbms itself still remain. but i'm fine if i'm wrong here. ;)
<mgz> oh lord i think this is actually working...
<rogpeppe> mgz: always a worrying moment
<jam> mgz: you got it?
<jam> yay
<jam> I wonder if you could have avoided the intermediate commit with "rm -rf *; bzr merge --force -r 0..-1 ..."
<jam> but if the commit helps, great.
<rogpeppe> fwereade__: have you got time for a v quick G+ chat?
<fwereade__> rogpeppe, not just now, I think... about to talk to dimiter and will really need some lunch after that I think
<rogpeppe> fwereade__: ok, np. i need to resolve some issues around the allWatcher and split documents.
<rogpeppe> fwereade__: i *think* i understand the issues, but i just want to make sure
<fwereade__> rogpeppe, ah, ok: was my suggestion that it should be directly analogous to annotation watching sensible?
<rogpeppe> fwereade__: not really. we don't want the allWatcher client to be aware of every split.
<fwereade__> rogpeppe, ok, so I guess you want status and presence watches feeding into the unit and machine infos
<rogpeppe> fwereade__: yup
<rogpeppe> fwereade__: and it's the issues around doing that that i need to resolve
<rogpeppe> fwereade__: in particular the txn log ordering
<rogpeppe> fwereade__: for instance, if the status doc is created in the same transaction as its unit, i don't think there's any guarantee that i'll see the unit before i see its status.
<rogpeppe> fwereade__: which means, i think, that i'll need a side-stash where we store items that we've been told about but that we don't yet know the parent docs for.
<rogpeppe> fwereade__: because we don't want to be telling a client about a unit status without any other info about that unit.
<fwereade__> rogpeppe, or you could drop events for unrecognised statuses on the floor, and when first constructing an X doc grab the status explicitly that one time
<fwereade__> rogpeppe, for future changes, just update the fields you need to in the info doc and reorder as appropriate
<fwereade__> rogpeppe, (whether those changes are to the object or to its status)
 * rogpeppe tries to work out if that's guaranteed to work
<jam> interesting, if you start 'lbox submit', and it starts checking your tree, and then you 'bzr switch' while it is still thinking about uploading
<jam> it will end up submitting the new branch
<jam> even though it tested the old
<rogpeppe> jam: ha. "don't do that" :-)
<jam> rogpeppe: fortunately both were meant to be submitted eventually
<jam> I switched in order to clean up the second for submit
<jam> so I just ended up pulling that back into the first
<rogpeppe> jam: i've done a similar thing before.
<rogpeppe> fwereade__: yes, i think that'll work ok. we'll be doing more work than strictly necessary, but that's true all round anyway
<fwereade__> rogpeppe, cool
 * fwereade__ has a relieved :)
<jam> mgz: is everything looking good?
<mgz> think so, doing recipe builds now to see
<mgz> got some local prpv
<mgz> ....provider test failures, under packing build/test environment that didn't appear when run in branch, but that's not related to any changes in branch so far as I can see
<jam> mgz: care to walk me through how to make a bucket public and what its URL would then be?
<mgz> on what cloud?
<jam> mgz: in this case, canonistack
<jam> I think I can 'swift post juju-dist -r ???'
<mgz> ".r:*,.rlistings"
<jam> mgz: then how do I translate that into a public url?
<jam> manually hack the auth info?
<jam> looks like if I do a manual auth request I can just grab the publicURL for the swift endpoint.
<jam> yay, looks like it worked
<jam> we now have a public bucket for canonistack
<dimitern> fwereade__: ping
<fwereade__> dimitern, pong
<dimitern> fwereade__: forgot to ask about moving status docs where they're used, but I figured you meant moving them in unit/machine.go respectively
<fwereade__> dimitern, yeah, sorry
<dimitern> fwereade__: np, so re lazy creation of status docs - now it's explicit in addUnit/MachineOps
<fwereade__> dimitern, sweet
 * dimitern started to feel at home in the state package :)
<dimitern> fwereade__: something's fishy about removeUnitOps - when there's one unit only it returns s.removeOps
<fwereade__> dimitern, always?
<fwereade__> dimitern, or when there's one unit *and* the service is Dying?
<dimitern> fwereade__: when it's dying, RC=0, UC=1
<fwereade__> dimitern, yep -- removal of the last unit should also remove the service
<fwereade__> dimitern, (of a Dying service)
<dimitern> fwereade__: the thing is, this is not enough I think - we should also remove the status there, right?
<fwereade__> dimitern, if removeUnitOps is failing to remove the unit, or any of its associated data, that should be rectified
<dimitern> fwereade__: re https://codereview.appspot.com/8256043/diff/11001/state/service.go#newcode611
<dimitern> fwereade__: I think I'm correct in putting removeStatusOp there, because it'll be included in the case above
<fwereade__> dimitern, hm, ok
<dimitern> fwereade__: if I move removeStatusOp at the end we'll miss the case when svc is dying
<fwereade__> dimitern, you've found two bugs in unit removal, I suspect
<fwereade__> dimitern, one is that the annotation removal is only done at the end, and is missed in the final-unit-of-dying-service case
<dimitern> fwereade__: not quite sure what I found yet, but moving it at the end causes a lot of tests to fail
<dimitern> fwereade__: right!
<fwereade__> dimitern, another is that the constraints removal op is done too early
<dimitern> fwereade__: so all these 3 should go after Remove: true of the unit: constraints, status, annotations
<fwereade__> dimitern, yep: your mission is to find the right way to code that nicely :)
<dimitern> fwereade__: well, just adding them in the append call that adds the removal of the unit doc seems fine?
<fwereade__> dimitern, and on general principles it's probably best to do the service removal ops last, once you've sorted out the unit
<fwereade__> dimitern, yeah, I'm just whining about having to keep track of the constraint removal op
<fwereade__> dimitern, hey, I have an evil idea
<dimitern> fwereade__: yeah?
<fwereade__> dimitern, drop the Assert from removeConstraintsOp and use it unconditionally
<fwereade__> dimitern, mgo/txn will ignore a remove of a doc that doesn't exist
<dimitern> fwereade__: yeah, I did that for removeStatusOp as well
<fwereade__> dimitern, I noticed -- I think it's a good practice in general
<fwereade__> dimitern, for that sort of data anyway
<fwereade__> dimitern, excellent
<dimitern> fwereade__: sweet! now tests pass :)
<fwereade__> dimitern, that'll let you lose a level of indentation in the else clause at the top of the method too
<dimitern> fwereade__: where?
<dimitern> fwereade__: u.doc.MachineId != "" ?
<fwereade__> dimitern, yeah, that becomes `else if ... {` not `else { if ... {`
<dimitern> fwereade__: done, only one thing remains
<dimitern> fwereade__: in the unit/machine get/set status test when dying
<dimitern> fwereade__: Status() always returns successfully, even when the thing is removed
<fwereade__> dimitern, yeah, fix that -- now the docs are guaranteed, there's no justification for that missing=pending nonsense
<dimitern> fwereade__: that's because of the Pending default case
<fwereade__> dimitern, and for that matter there's no justification for Pending being "", either
<dimitern> fwereade__: sure, will do
<dimitern> jam: now I see the sync-tools cmd's filenames are with underscore, I think this needs to change to conform to the other commands. it's not just bitching, but underscores are usually for test modules :)
<rogpeppe> fwereade__: you might be pleased to know that i just saw TestBootstrapAndDeploy pass.
 * fwereade__ cheers wildly and flings lacy unmentionables
<dimitern> fwereade__: wanna last glance at https://codereview.appspot.com/8256043 before I throw it in trunk?
<fwereade__> dimitern, sure, cheers
 * rogpeppe is now trying for a clean run of all live tests
<dimitern> rogpeppe: with the API?
<rogpeppe> dimitern: i'm not sure what you mean
<dimitern> rogpeppe: was it not passing before?
<rogpeppe> dimitern: it's been the reason the live tests haven't been passing for a month or so
<dimitern> rogpeppe: whoa, I totally missed that :) good to hear they pass now
<rogpeppe> dimitern: you should run the live tests some time :-)
<dimitern> rogpeppe: yeah, with openstack I did, but never with ec2
<dimitern> niemeyer: ping
<rogpeppe> fwereade__: dear mr on-call reviewer; here's a review for you :-) https://codereview.appspot.com/8318043
<fwereade__> rogpeppe, cheers
<rogpeppe> hey, we're on revision 12
<rogpeppe> in binary
<rogpeppe> 1100
<dimitern> rogpeppe: not for long :)
<rogpeppe> dimitern: 13 next
<rogpeppe> dimitern: then NaN
<dimitern> or NaB
<rogpeppe> TheMue: ping
<fwereade__> rogpeppe, LGTM
<rogpeppe> fwereade__: thanks
<fwereade__> rogpeppe, I think that's probably a trivial tbh, given that I infer you've run the live tests :)
<rogpeppe> fwereade__: you looked at the juju home stuff in more detail than me, ISTR. perhaps you could suggest a solution to a related panic i'm seeing in the live tests.
<fwereade__> rogpeppe, blarg
<fwereade__> rogpeppe, paste it?
<dimitern> niemeyer: when you see this, can you please remove the flag from the channel that doesn't allow topic changes? we discussed to start using it to convey information through it, like the on call reviewer, possibly bug counts, etc.
<rogpeppe> fwereade__: http://paste.ubuntu.com/5673777/
<rogpeppe> fwereade__: i'm not sure when juju home is supposed to be initialized
<fwereade__> rogpeppe, before any test that needs to use it
<fwereade__> rogpeppe, and at the beginning of cmd/juju.Main
<rogpeppe> fwereade__: i can't see how the live tests work at all then
<rogpeppe> fwereade__: because AFAICS they don't initialise juju home
<fwereade__> rogpeppe, it is possible that they do not: I did not think to verify that in the review
<rogpeppe> fwereade__: they do work, apart from that one test
<rogpeppe> fwereade__: so there's something odd going on
<rogpeppe> fwereade__: ah, i see!
<rogpeppe> fwereade__: the authorized-key field doesn't look at JUJU_HOME
<rogpeppe> fwereade__: right, i know how to fix it now
<fwereade__> rogpeppe, wait, ISTM that we're running a weird test with just the dummy provider mixed in among all the live tests
<fwereade__> rogpeppe, why are we creating a totally fresh config in a test that has a config available already?
<rogpeppe> fwereade__: actually we're just leveraging the dummy provider there, not using it
<rogpeppe> fwereade__: we use it to put the tools into, then fake 'em up into the actual environment
<fwereade__> rogpeppe, hmm, ok, I see
<fwereade__> rogpeppe, not sure I entirely approve but that's the least of my worries :)
<fwereade__> rogpeppe, anyway, thanks
<rogpeppe> fwereade__: np
<niemeyer> dimitern: I believe anyone can change the topic
<niemeyer> dimitern: Via chanserv
<dimitern> niemeyer: do you know how of hand, or I should try google? :)
<niemeyer> dimitern: Hold on
<niemeyer> dimitern: /msg chanserv topic #juju-dev I am a new topic.
<niemeyer> dimitern: This is handy too, for future uses: /msg chanserv help
* ChanServ changed the topic of #juju-dev to: On call reviewer: fwereade
<dimitern> niemeyer: cheers!
<fwereade__> need to think for a bit, going for a walk, be back later
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: fwereade | Bugs: 3 Critical, 54 High - https://bugs.launchpad.net/juju-core/
<mattyw> anyone know what this means (juju-core bootstrap --upload-tools on aws) 2013/04/03 15:17:02 ERROR JUJU:jujud:bootstrap-state jujud bootstrap-state command failed: state entity tag not found in configuration
<mgz> mattyw: see the "Cannot bootstrap instances in ec2" thread on the juju-dev list
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: fwereade | Bugs: 2 Critical, 53 High - https://bugs.launchpad.net/juju-core/
<rogpeppe> fwereade__: another review for you (this one actually fixes the live tests) https://codereview.appspot.com/8321043
<dimitern> rogpeppe: the diff is screwed
<rogpeppe> dimitern: thanks; will try again
<rogpeppe> dimitern: PTAL
<fwereade__> rogpeppe, awesome, LGTM
<rogpeppe> fwereade__: ta!
<rogpeppe> dimitern: i'm not sure how to run the openstack live tests.
<rogpeppe> dimitern: do i need an account on canonistack or something?
<dimitern> rogpeppe: you need creds yeah, there's a wiki page about it, let me find it
<rogpeppe> dimitern: i'll submit anyway if that's ok - it must be better than the old one, and it's not tickling anything provider-specific
<dimitern> rogpeppe: well jujutest is used in both, but yeah, I agree it's good to land
<dimitern> rogpeppe: if openstack live tests fail (which is not uncommon on canonistack) we'll fix them
<rogpeppe> dimitern: yeah; but the logic we're actually testing here is all state-based.
<dimitern> rogpeppe: https://wiki.canonical.com/InformationInfrastructure/IS/CanonicalOpenstack?action=show&redirect=CanoniStack
 * rogpeppe looks for his 2-factor keyring
 * dimitern thinks provisioner tests are kinda crap - no testing is done for errors while starting a machine
<dimitern> does it sound sane to add some way to cause StartInstance to fail in the dummy provider for testing sake?
<TheMue> so, time to leave. one final review for today: https://codereview.appspot.com/8322043
<TheMue> n8 all
<rogpeppe> fwereade__: if you're around, another CL for your delight and delectation: https://codereview.appspot.com/8328043/
<dimitern> rogpeppe: I can take a look
<dimitern> rogpeppe: meanwhile - https://codereview.appspot.com/8330043/ ?
<thumper> morning
<fwereade__> thumper, heyhey
<thumper> hi fwereade__
<fwereade__> thumper, do you have any clue why upgrade-juju is using version.Current?
<thumper> fwereade__: in which place?
<fwereade__> thumper, I think it just uses it once, in bumpedVersion
<thumper> fwereade__: that is (IMO) used only for developers to force a new version
<thumper> fwereade__: which I'd love to find a different way around
<fwereade__> thumper, sure, but I don;t think it's correct, is it?
<thumper> um...
 * thumper looks
<fwereade__> thumper, the agent-version is relevant, and the version of the tools we *built* is relevant
<fwereade__> thumper, or at least the above two might be
<fwereade__> thumper, but I don;t see what the current client version has to do with it
<thumper> fwereade__: I think the expectation there is that the client version will be equal or greater than any existing tools
<fwereade__> thumper, seems like a bit of an assumption to me, but I guess it's a derail anyway
<thumper> fwereade__: yes, I agree that the whole method is wrong
<thumper> fwereade__: could be easily fixed
 * thumper does a few drive by boy-scout branches to feel like something is improving
 * fwereade__ heartily endorses thumper's behaviour
<fwereade__> thumper, btw, do you know offhand what's a valid launchpad id?
<thumper> fwereade__: where are you looking?
<thumper> and id for what?
<fwereade__> thumper, I'm peering suspiciously at the charm.validUser regexp
<fwereade__> thumper, user id
<fwereade__> thumper, in charm/url.go
<thumper> hmm...
<thumper> I'd have to look it up
<thumper> what is the regex?
<fwereade__> thumper, https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CDsQFjAB&url=https%3A%2F%2Fhelp.launchpad.net%2FYourAccount%2FNewAccount&ei=nZVcUcjSO8GS7AaHnIDwCA&usg=AFQjCNE_bzVarX3yyWj40q2JeFnCtuT-hw&sig2=UjM0ZR4vv8kZOCr3nVeAzQ&cad=rja
<fwereade__> er, not that, whatever it is
<fwereade__> thumper, regexp.MustCompile("^[a-z0-9][a-zA-Z0-9+.-]+$")
<thumper> hmm.. not sure we can have capitals
<thumper> A short unique name, beginning with a lower-case letter or number, and containing only letters, numbers, dots, hyphens, or plus signs.
<thumper> so perhaps...
<thumper> that regex matches what LP says
<thumper> though I'm not sure that uppercase is valid there
<fwereade__> thumper, ok, excellent, I just couldn't find where it was specified
<thumper> but I would have to read the LP source
<fwereade__> thumper, seems like it might be covered, so let's go with it
<fwereade__> thumper, they'll all come from LP anyway
<fwereade__> thumper, thanks
<thumper> kk
 * thumper goes to grap his boxing wraps to have something to do while the tests run
 * thumper rages a little
<bigjools> thumper: against a machine?
<thumper> bigjools: against our shitty package dependency chains
<thumper> and circular deps
<thumper> especially in testing
<bigjools> ruh roh
 * thumper made another package
<thumper> hmm...
<thumper> my refactoring got just a little out of hand...
 * thumper stops refactoring
<thumper> davecheney: I have a branch that is more paletable with "precise" in it, has many of the fixes I wanted for removing version.Current without actually removing it yet
<thumper> simple refactoring grew past 800 line diff, so I've stopped
<thumper> tests all still pass \o/
<davecheney> thumper: SUBMIT!!
<thumper> davecheney: well, proposing first :0
<davecheney> seriouslu, i'm blocked at the moment
<davecheney> ok, i shall review in anger
<fwereade__> thumper, this might very *very* well with what I'm about to propose, I just realised I was about to start replacing version.Current with "precise" everywhere :)
<thumper> fwereade__: wait...
<thumper> review incoming
<thumper>  https://code.launchpad.net/~thumper/juju-core/mongo-driveby/+merge/156992
<thumper> other one coming...
<thumper> davecheney: fwereade__: Rietveld: https://codereview.appspot.com/8348043
<davecheney> thumper: ta
 * thumper goes to get gym kit on
<thumper> fwereade__: I hope this doesn't clash with what you've been doing
<fwereade__> thumper, nope, not at all so far, it *might* be a disturbingly perfect matchup
<thumper> fwereade__: that that would be fortuitous
<thumper> I'm about to head off to the gym shortly
<thumper> hmm... I just spotted a copy and paste error
<fwereade__> thumper, you have a preliminary review
<fwereade__> thumper, lots of questions I'm afraid
<thumper> :(
<thumper> ok
<fwereade__> thumper, take heart, I'm +1 on the fundamentals, mostly just quibbling about the details, only really unsure in a couple of places
 * thumper nods
<thumper> I'll look after the gym
<fwereade__> thumper-gym, davecheney: PTAL at https://codereview.appspot.com/8352043
<fwereade__> thumper-gym, davecheney, it's a minimal bootstrap --fake-tools; I have verified that I can use cross-series envs fine, so long as I fake up all required series at bootstrap time
<fwereade__> thumper-gym, davecheney: adding it to upgrade-juju is harder because I get distracted and want to fix things, so I think it's best left for now
<fwereade__> thumper-gym, davecheney: it's not a complete fix but it hopefully gives davecheney in particular a useful way forward
<davecheney> fwereade__: tahnks
<fwereade__> davecheney, if you get a mo, please try it out, in case I've done something stupid
<fwereade__> davecheney, juju bootstrap --upload-tools --fake-series precise
<fwereade__> davecheney, I think covers your use case
<fwereade__> davecheney, you might want precise,quantal if you're on raring and need quantal charms
 * fwereade__ -> bed
#juju-dev 2013-04-04
 * thumper is back to go through the review
<thumper> davecheney:  https://codereview.appspot.com/8348043 has been updated following fwereade__'s review
<thumper> more looks would be good though
 * davecheney looks
 * thumper needs food, goes hunting in the kitchen
 * bigjools imagines thumper spearing a bear roaming in his kitchen
<davecheney> http://creativeroots.org/2011/08/kiwi-anatomy-t-shirt/
<bigjools> haha
<thumper> davecheney: how many people do we have in this TZ that can approve my branch?
 * thumper wonders when jam starts
<thumper> bigjools: not a bear, but I did get some salami and cheese :)
<thumper> lucky me, they didn't put up much resistence
<bigjools> thumper: I found a hot cross bun that was toasted
<thumper> bigjools: did you have to light the fire to toast it?
<thumper> or was it left by a passer-by
<thumper> ?
<bigjools> I could use Ian's dog's breath
<bigjools> it's enough to curl hair
<thumper> heh
 * thumper needs to collect a young child from school
<thumper> bbs
<thumper> davecheney: ping
<thumper> davecheney: https://code.launchpad.net/~thumper/juju-core/package/+merge/157020
 * thumper off until the meeting
<jam> jtv1: just trying to sort out what branch you want reviewed
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: dimitern | Bugs: 2 Critical, 53 High - https://bugs.launchpad.net/juju-core/
<dimitern> morning all
<jam> hi dimitern
<jtv1> Hi jam, hi dimitern
<jtv1> jam: I was about to bring it up...  Had some trouble with lbox, but had to go with the normal way instead:
<jtv1> https://code.launchpad.net/~maas-maintainers/juju-core/maas-provider-skeleton/+merge/157025
<jtv1> I'm just fixing the conflicts.
<jtv1> Oh dear.  I'm getting build errors, but I get the same ones in trunk.
<jtv1> Nonexistent functions in "log," and more.
<dimitern> jtv1: which revision are you on?
<jtv1> 1104
<dimitern> jtv1: me too, just pulled trunk and running the tests; can you paste the errors?
<jtv1> Coming up.
<jtv1> I get the exact same ones for trunk and our branch, so I guess that's a good sign w.r.t. ours.
<jtv1> dimitern: http://paste.ubuntu.com/5675740/
<dimitern> all passes here
<dimitern> jtv1: these are build errors, not test failures - something is not updated I think
<jtv1> I'll run a "go get -u juju-core" then  I guess
<dimitern> jtv1: well, it'll possibly screw up your working dir
<dimitern> jtv1: if you have branches, etc. - maybe try changing $GOPATH to a new dir and get it afresh?
<jtv1> Ouch.
<jtv1> OK, I'll try that, thanks
<rogpeppe> morning all!
<jtv1> Hi rogpeppe
<rogpeppe> jtv1: hiya
<dimitern> rogpeppe: hey
 * davecheney waves
<dimitern> davecheney: hi :)
<rogpeppe> davecheney: good evening; dimitern: yo!
<dimitern> fwereade__: I have a branch for you https://codereview.appspot.com/8330043/
<fwereade__> dimitern, hey, just reviewed
<dimitern> fwereade__: cheers! btw the pending/starting is just the first step, the MA will set the correct status in a follow-up I think
<fwereade__> dimitern, I think I would prefer to set nothing than to set something that's only mostly correct
<fwereade__> dimitern, there's an argument to be made that "provisoned" or "starting" or whatever can be inferred perfectly well from InstanceId
<dimitern> fwereade__: ok, i'll think about it some more
<fwereade__> dimitern, cheers
<dimitern> fwereade__: why do you think breakJuju should panic in the provisioner test?
<dimitern> is the meeting now or in 1h ?
<dimitern> mramm2: ping
 * davecheney wonders if he has time to order a pizza before the meeting
<dimitern> so it's not now
<davecheney> nope, still 6pm in AU
<davecheney> meeting is at 7pm
<dimitern> so when does AU switch to DST?
<davecheney> soon
<davecheney> dimitern: 7th Apr
<dimitern> I see
<davecheney> but not Queensland
<davecheney> they never adopted daylight savings because they were worried it would confuse the Cows
<dimitern> so you're last to go - we already switched last sunday, and US - before 3 weeks
<dimitern> :D cool
<davecheney> dimitern: even inside australia the 7 states shift at different times
<davecheney> /s/times/dates
<davecheney> because when something is hard, it helps to make it even harder by not coordinating
 * davecheney says fuckit, and orders a pizza'
<dimitern> interesting :) and opinionated
<fwereade__> dimitern, sorry
<fwereade__> dimitern, the provisioner test should not have a JujuHome
<dimitern> fwereade__: it's not using it really
<fwereade__> dimitern, it runs in the cloud and doesn't have an environments.yaml or any of the associated crap
<fwereade__> dimitern, yes it is
<dimitern> fwereade__: it has environ config though
<fwereade__> dimitern, it's getting the environment from environments.yaml
<fwereade__> dimitern, which invokes a whole bunch of crap that is *wrong* for this context
<fwereade__> dimitern, I see why it works though
<dimitern> fwereade__: well, it's changing that, not reading it, but I see your point
<fwereade__> dimitern, it's because JujuConnSuite is broken
<fwereade__> dimitern, but fixing that is out of scope
<fwereade__> dimitern, it's changing it and then reading it, right?
<dimitern> fwereade__: I'll split the "make broken env.yaml" from "make broken environ config" for a given dummy method
<dimitern> fwereade__: not
<fwereade__> dimitern, then why's it writing it? :)
<dimitern> fwereade__: reading it - just changing it and returning config.Config
<dimitern> :)
<dimitern> fwereade__: because breakJuju seemed like a good candidate for that, already used in cmd tests
<dimitern> fwereade__: i changed it to reuse it, but it diverged too much from the original and now it's doing 2 unrelated things
<fwereade__> dimitern, sure, but the dummy provider already has exactly the capability you need -- you just set one field in the existing config
<fwereade__> dimitern, I think that just doing that in the provisioner test is neatest
<dimitern> fwereade__: wasn't sure, but now I see it better (after having done it the wrong way first) :)
<fwereade__> dimitern, don't worry, this stuff is nasty to begin with and only made worse by the essentially-random contexts in which we run tests
<dimitern> fwereade__: how about adding an exported call to the dummy provider to make breaking methods easier?
<fwereade__> dimitern, honestly its not that much work to change a config
<fwereade__> dimitern, cfg, err := environ.Config().Apply(map[string]interface{}{"broken": "StartInstance"}); c.Assert(err, IsNil); err = environs.SetConfig(cfg); c.Assert(err, IsNil)
<dimitern> fwereade__: it's not obvious and it's definitely useful to have a shortcut I think, for future use as well
<dimitern> fwereade__: (and documented properly, rather than having to read through the source to figure out how)
<fwereade__> dimitern, isn't that a method that'll be used in exactly one place?
<dimitern> fwereade__: in any place that needs to break the dummy provider's methods without needing environments.yaml
<dimitern> fwereade__: i'm sure there'll be others
<fwereade__> dimitern, I suspect that `UpdateConfig(env Environ, attrs map[string]interface{}) error` would actually be useful
<dimitern> fwereade__: anyway, too early for me to argue properly :) I'll just do it in the provider tests as a helper, which can be extracted if needed
<fwereade__> dimitern, provider or provisioner? :)
<dimitern> fwereade__: yeah, provisioner
<fwereade__> dimitern, cool, thanks
 * dimitern dives into the review queue
<jtv1> dimitern: about those test failures on trunk...  I run "go test ./..." in a fresh Go environment, against trunk, and I get further now but it's still pretty bad: http://paste.ubuntu.com/5675840/
<jtv1> Is that what you're getting?
 * thumper is back
<dimitern> jtv1: you need mongod installed for the state tests
<jtv1> Ah damn, forgot about that.  Will it work on i386 now?
<dimitern> jtv1: i think now, unless you build it + ssl
<dimitern> s/now/not/
<jtv1> OK, I'll try it on the cloud.  Thanks.
<dimitern> jtv1: but it seems mongo is not the only problem - some things are still missing from the checkout
<dimitern> rogpeppe: can you help jtv1 with these issues? ^^
<rogpeppe> jtv1: looks like you might not have mongod installed
<jtv1> I don't â Dimiter already spotted that one.
<jtv1> I'm trying it on the cloud now.
<dimitern> rogpeppe: that's not the only problem though - see the undefined stuff
<jtv1> It was in a fresh Go environment.
<rogpeppe> jtv1: what's your current directory and what's your GOPATH set to?
<jtv1> My GOPATH is /tmp/go (where I built a fresh environment)
<jtv1> I softlinked $GOPATH/src/launchpad.net/juju-core to my own checkout of trunk, and was cd'ed into that.
<rogpeppe> jtv1: ah, that might be your problem
<jtv1> The softlink, the working directory, or the combination?
<rogpeppe> jtv1: the fact that the working directory isn't directly below $GOPATH
<rogpeppe> jtv1: what happens if you do "go test launchpad.net/juju-core/..." ?
<davecheney> jtv1: you can't softlink GOPATH
<davecheney> sorry
<davecheney> the go tool is too smart for symlinks
<jtv1> Too smart for its own good then :)
<rogpeppe> jtv1: it tries to work out the package path by looking at the current working directory
<rogpeppe> jtv1: unfortunately there's not enough information for it to do so
<jtv1> That other command line says "launchpad.net/juju-core/..." matched no packages
<rogpeppe> jtv1: i'm surprised it didn't give you an error actually
<dimitern> jtv1: you can softlink stuff inside $GOPATH though - I have ~/work/go/src/launchpad.net/juju-core -> ~/work/juju-core and it works
<jtv1> Well I'm getting plenty :)
<jtv1> That's what I did too.
<rogpeppe> dimitern: i'm surprised that works actually
<dimitern> (actually it's the other direction, ~/work/juju-core is a symlink to $GOPATH/src/launchpad.net/juju-core)
<rogpeppe> dimitern: ah, that makes more sense
<rogpeppe> t
<jtv1> davecheney: I didn't softlink GOPATH... just $GOPATH/src/launchpad.net/juju-core
<davecheney> sorry, symlinks inside GOPATH are a no no
<rogpeppe> jtv1: the problem is that when the go tool gets the current working directory, it sees ~/mycheckout, not $GOPATH/src/launchpad.net/juju-core
<rogpeppe> jtv1: so it can't work out that you're building launchpad.net/juju-core
<jtv1> rogpeppe: but it'll work as long as I use the launchpad.net/juju-core/... path?
<rogpeppe> jtv1: no; i thought it would, but it doesn't
<jtv1> :(
<rogpeppe> jtv1: (i'm not sure why)
<jtv1> But then how does that softlink work for you!?
<rogpeppe> jtv1: it doesn't
<jtv1> :(
<rogpeppe> jtv1: it works for dimiter because his softlink points *inside* GOPATH
<jtv1> I wonder if maybe it isn't better to have one Go environment per branch...
<rogpeppe> jtv1: i use cobzr, but you can also use bzr colocation
<jam> mgz: we miss you
<mgz> takes too long to sign in to g+ these days...
<jam> mramm2: so you don't feel unloved. PING :)
<thumper> davecheney: would you be happy if I made environs.config.DefaultSeries a const string?
<thumper> I could make the change and merge
<davecheney> thumper: +1
<thumper> davecheney: just proposing those changes
<davecheney> thumper: where does version.CurrentNumber come from ?
<davecheney> was it added recently ?
<thumper> yes, added in that branch
<jtv1> fwereade__: thanks for the  notes on our feature branch!  We were just looking at how big the divergence was, and I think this'll be helpful.
<davecheney> thumper: i can't find it ?
<davecheney> am i an idiot ?
<thumper> davecheney: to of version/version.go
<thumper> davecheney: first change in that file
<thumper> not an idiot, just blind :)
<davecheney> ahh, yes, v sorts afrer e
<davecheney> so, i was right first time :)
<thumper> :(
<thumper> for some reason merging in trunk breaks it
 * thumper pokes
<thumper> jam: your sync-tools changes have broken my branch
 * thumper tries to work out the test
<mgz> yup, that was the plugin crashing...
<mgz> I won't rejoin, signin takes too long
<jam> thumper: the mongo branch or ?
<thumper> jam: yeah, my refactoring...
<thumper> which hits some fake tools somehow
<jam> thumper: I set up a dummy env, and then copy tools out of it
<thumper> I'm getting some extra tools there...
<jam> but you can't set up a dummy env
<jam> without fake tools
<jam> so I delete them
<jam> so the test has known state
<thumper> ah, but not all of them...
<jam> now you need to delete 2 of them, I guess
<thumper> right/
<thumper> I'll poke
<thumper> isn't there a delete all?
<jam> thumper: no, but you can list, iterate, and delete.
<jam> Storage, has Put, Get, List, Remove
<jam> thumper: line 67 is where yoou can change the "lookup Current" into "list all"
<jam> sync_tools_test.go
 * thumper nods
<jam> technically you should be matching against tool patterns, etc. But in practice, I think you can just nuke everything in the dummy env.
<jam> (may get us in trouble in the future :)
<jtv1> Say, does anyone know why the tests for launchpad.net/juju-core/cmd/juju might be timing out?
<jam> jtv1: if you are timing out, most likely you aren't running a mongo that is new enough to support ssl
<jam> that was the most common occurance I've encountered.
<jam> jtv1: this is a 600s timeout, right?
<jtv1> Yes.
<jtv1> During TestPackage.
<jtv1> So maybe I should try Raring?
<jam> jtv1: if you have the wrong mongod in your PATH, it doesn't start
<jam> jtv1: you have to run from the PPA or use the tarball
<jtv1> I just installed the quantal  mongod.
<jam> jtv1: the one from Julian?
<jtv1> No, just the standard one.  What PPA should I use?
<jam> jtv1: https://launchpad.net/~juju/+archive/experimental
<jam> that only has raring
<jam> just a sec
<jam> https://launchpad.net/~julian-edwards/+archive/mongodb
<jam> has quantal
<jtv1> Thanks.
<jam> it looks like raring might come with a default one that is new enough: https://launchpad.net/ubuntu/raring/+source/mongodb/1:2.2.4~rc0-0ubuntu1
<jam> but I'm not positive
<jam> because the SSL support is contentious because of GPL licensing vs OpenSSL, etc.
<jtv1> OK, I'll try the PPA first then.  I'm also keeping notes so hopefully people can re-use them.  Thanks.
<jam> thumper: "constant wouldn't be a string": "const foo string = "stuff"
<thumper> jam: yeah, that is what I have done
<thumper> jam: the target bucket also needs fixing :(
<jam> thumper: I couldn't find exactly when the bucket gets filled, so I just allowed it to have one extra
<thumper> nm, I'm fixing
<jam> It looked like putFakeTools was done on first *connect*
<jam> rather than on creation.
<jam> thumper: the other option is to have a dummy config items that lets you disable auto tools.
<thumper> jam: sure... but not now :)
<mattyw> rogpeppe, it looks like Status has been removed from unitinfo recently?
<rogpeppe> mattyw: yes, unfortunately. i'm working on putting it back right now.
<mattyw> rogpeppe, ok no problem
<thumper> jam: managed to fix all the issues during the call :)
<jam> :)
<thumper> just doing a final test run prior to submitting
<fwereade__> jtv1, you're welcome :)
<fwereade__> jtv1, there will certainly be more but I need to look at it in bits :)
<thumper> I have a feeling tomorrow will be doing all the peer reviews
<thumper> for me at least
<thumper> also
<thumper> yay for checking the tests prior to merging
<thumper> with trunk merged in
<jtv1> fwereade__: I'm trying to get trunk to pass tests right now, and after that I can get a bit of an overview of the divergence.  rvba and I are planning to do the fixing for this one.
<fwereade__> jtv1, cool
 * thumper has merged the branch, and is leaving the office
<thumper> ciao
<dimitern> fwereade__: the provisioner currently aborts if any machine failed to start
<dimitern> fwereade__: I didn't change that, it was already like this
<rogpeppe> dimitern: just FYI, revision 1101 broke our tests against go tip for me.
<dimitern> rogpeppe: can I see  a paste?
<rogpeppe> dimitern: it's probably the go runtime's fault, not yours
<rogpeppe> dimitern: http://paste.ubuntu.com/5676161/
<rogpeppe> dimitern: that's running TestUniterRelations only
<dimitern> rogpeppe: I have no idea why
<dimitern> rogpeppe: could it be a bug in mgo?
<rogpeppe> dimitern: i really don't know. i'm trying to narrow down the problem first.
<rogpeppe> dimitern: it's not helped by the fact that from go revisions 15910 to 16052 our stuff does not build due to a bug in the go compiler.
<dimitern> rogpeppe: ha.. interesting
<fwereade__> dimitern, yeah, but making that sane is part of the job, I think
<fwereade__> dimitern, sorry, bbiab
<dimitern> fwereade__: my point is, when it fails it exits the loop, like the uniter does, and gets restarted
<dimitern> updated https://codereview.appspot.com/8330043/
<fwereade__> dimitern, sorry, still half-having lunch, but: the uniter sets a hook error state and keeps going, because it's meant to handle that failure
<fwereade__> dimitern, the situation is analogous
<fwereade__> dimitern, besides, letting the pro die will fuck the firewaller at the same time, and that has even more complex state to set up every time
<dimitern> fwereade__: so this means general refactoring of the provisioner, not just setting an error status, which I think is outside of this CL
<dimitern> fwereade__: it'll die exactly the same way now, no regression introduced
<dimitern> fwereade__: i'm happy to do the refactoring though, in a follow-up - will get me a chance to know it a whole lot better
<jam> 'AaaaaAaa,e.
<dimitern> jam: very expressive encoding :)
<jam> dimitern: 5-year old keyboard typing. And me hitting <enter> instead of <delete>
<jam> dimitern, mgz: standup?
<fwereade__> dimitern, I think there has been a communication error
<dimitern> fwereade__: oh, what was it?
<fwereade__> dimitern, meh, just what I thought I meant and what you thought I meant re the story
<fwereade__> dimitern, it is ofc my fault :)
<dimitern> fwereade__: sorry, but it's still not clear for me
<fwereade__> dimitern, in my mind, making the provisioner react sensibly to predictable errors -- as does the uniter -- is absolutely part of this story
<fwereade__> dimitern, think through step by step what will happen when we try to provision a machine with bad constraints
<fwereade__> dimitern, the provisioner starts up, sees an unprovisioned machine, tries to provision it... falls over
<fwereade__> dimitern, gets restarted, sees an upprovisioned machine, tries to provision it... falls over
<fwereade__> dimitern, and may well continue doing this forever even if there are other machines that *could* be provisioned
<fwereade__> dimitern, now we have a channel by which errors can escape to something that'll handle them -- however badly -- we should (1) send the errors down that channel and (2) not send them elsewhere
<fwereade__> dimitern, in my mind, the two pieces of work are two sides of the same coin
<dimitern> fwereade__: wanna have a quick g+?
<fwereade__> dimitern, sure
<fwereade__> TheMue, ping
<TheMue> fwereade__: pong
<TheMue> fwereade__: just proposing the changes ;)
<fwereade__> TheMue, heyhey, just wanted to say I'm around if you want to chat about the uuid stuff
<TheMue> fwereade__: found your feedback clear (at least i hope i got it right ;) )
<fwereade__> TheMue, cool :)
<TheMue> fwereade__: so, it's in again
<fwereade__> TheMue, what are the plans for env doc key vs globalKey then? ah ok cool I'll read it :)
<TheMue> fwereade__: i liked your idea, it's then a real global key.
<fwereade__> TheMue, sorry, I think I failed to be clear here
<TheMue> fwereade__: i'm listening
<fwereade__> TheMue, the globalKey for the environment was until recently "e"
<fwereade__> TheMue, I'm not sure why that changed on the Environment entity in the first place
<TheMue> fwereade__: "e#<<name>>"
<fwereade__> TheMue, http://paste.ubuntu.com/5676494/
<fwereade__> TheMue, the global key for the environment is still "e"
<fwereade__> TheMue, that globalKey() method is I think objectively wrong
<TheMue> fwereade__: ah, yes, i meant the the method globalKey() returned
<TheMue> fwereade__: the "e", like for the settings, has been the reason i've used "e" in the first run as document id too
<fwereade__> frankban, ping
<fwereade__> TheMue, yes, exactly
<frankban> fwereade__: pong
<fwereade__> frankban, Environment.globalKey()
<fwereade__> frankban, it doesn't match the usual environment global key as used elsewhere; is this because the existing one ("e") is crazy, or because you didn't know about it?
<fwereade__> TheMue, so, whatever we pick for globalKey is irrelevant
<dimitern> fwereade__: in order for the PA to pick up machines in error state _at all_ is to watch for something other than Life
<frankban> fwereade__: OIC, you mean "e#[name]" vs just "e"? if so, the latter.
<dimitern> fwereade__: I mean machines that were in error status but was resolved
<fwereade__> frankban, cool, thanks, just checking
<fwereade__> dimitern, ah-ha!
<fwereade__> dimitern, ok that makes things more interesting/annoying in the future
<dimitern> fwereade__: PA uses WatchMachines() which is a lifecycle watcher, not on status or anything else
<fwereade__> dimitern, but for now remember we don't expose any way to resolve
<TheMue> fwereade__: so globalKey() should only return "e" and that's also ok as document id for the environment doc in its collection?
<fwereade__> dimitern, so it doesn't matter yet
<fwereade__> TheMue, (1) probably (2) maybe
<TheMue> fwereade__: hehe
<dimitern> fwereade__: so I cannot test the machine is skipped - it'll always be skipped once created and is in error state
<fwereade__> TheMue, in both cases it's worth a discussion if you're not familiar with the context
<dimitern> fwereade__: even after restarting the PA the machine still won't be picked up
<fwereade__> dimitern, and that is correct behaviour
<fwereade__> dimitern, verify that it happens and you're good, I think
<dimitern> fwereade__: ok, but seems incomplete
<TheMue> fwereade__: as the doc is the only one in it's collection the id only has to be static, so i initially thought "e" like the one for the environment conf or its constraints would be fine.
<dimitern> fwereade__: but I guess when we have to deal with resolve it'll come back to this
<fwereade__> dimitern, yeah -- I think it's a problem we can safely solve then
<TheMue> fwereade__: for the globalKey() i have to look more, indeed. interestingly the tests pass all.
<niemeyer> Good mornings
<niemeyer> dimitern: Fixed: https://codereview.appspot.com/8355044
<fwereade__> TheMue, I think I'm fine with "e" all round, actually, but please make sure it's a const somewhere and not used in magic string form
<dimitern> niemeyer: cool, thanks I'll take a look
<TheMue> fwereade__: so shall i change all other places where today simply "e" is used too?
<fwereade__> TheMue, yes please
<TheMue> fwereade__: will do so
<fwereade__> TheMue, although, wait a mo
<TheMue> fwereade__: yes, until your review is in
<fwereade__> TheMue, I'm suspicious of having the two keys be the same
<fwereade__> TheMue, any particular reason not to use the uuid?
<fwereade__> TheMue, it *is* a unique identifier for the environment, after all :)
<fwereade__> TheMue, (we should not use the uuid for the global key, just for the entity key)
<TheMue> fwereade__: when doing the FindId() i have to know the id. otherwise i could also read the first document of the collection. would work too.
<fwereade__> TheMue, just-pick-one is OK for now
<fwereade__> TheMue, if we end up sharing that collection when multitenanting it'll break, but we'd always have to have the env uuid available in the *State, so it'd be a trivial fix
<TheMue> fwereade__: ok, then will do it this way. so i'll use the uuid field as _id.
<dimitern> niemeyer: LGTM
<dimitern> fwereade__: i think this should be about all of it: https://codereview.appspot.com/8330043/
<fwereade__> dimitern, ack
 * dimitern lunch
<benji> I have a small branch up for review, it's pretty straight-forward: https://codereview.appspot.com/8366043
 * rogpeppe is in a sea of *almost* reproducible bugs and uncertain dependencies
<dimitern> benji: I'm on it shortly
<benji> thanks dimitern
<rogpeppe> mgz: do you know of a way of getting bzr to print the revision id it's currently on (not just the latest revision id it knows about)?
<mgz> --tree
<rogpeppe> mgz: ah, i missed that, thanks
<rogpeppe> mgz: i'm quite surprised it's not the default
<rvba`> fwereade__: Hiâ¦ I just wanted to let you know that I was able to implement the missing method InstanceId() in the MAAS provider.  I've followed your advice and used cloudinit to populate a file containing the instanceId and then the method InstanceId() reads from that file.  I've just tested my code in the lab with real machines and a real MAAS deployment and it seems to work ok.
<fwereade__> rvba`, thanks, that's great news
<mgz> it is a little surprising sometimes
<mgz> not an easy default to flip though, revno and revision-info commands mostly used from scripts that would potentially break if the semantics changed
<fwereade__> rvba, I hope it wasn't too much hassle... (there is a path towards completely dropping provider.InstanceId, but it's really nice not to have to do it right now ;))
<fwereade__> mramm2, rogpeppe, TheMue, hey, should we be meeting?
<TheMue> fwereade__: already done :D
<rogpeppe> fwereade__: ah yes
<fwereade__> TheMue, sorry
<rogpeppe> fwereade__, TheMue, mramm2: i'm there
<TheMue> rogpeppe, fwereade__: we've seen that after this morning and with the current state on the board we don't need the meeting today
<fwereade__> rogpeppe, funny, I think I'm there too
<fwereade__> rogpeppe, moot anyway :)
<rvba> fwereade__: it was actually pretty straightforward apart from one trick: I added a method in cloudinit.go to be able to add a runcmd at the *beginning* of the list of commands.
<rvba> Because jujud is started by cloudinit and we need the file containing the instanceId to be present before jujud is started.
<fwereade__> rvba, I've been kinda expecting us to need something like that for about a year, so np there :)
<rvba> All right :)
<rogpeppe> fwereade__, rvba: another possibility would be to change environs/cloudinit so you pass in the cloudinit.Config instead of returning it
<fwereade__> rogpeppe, hmm, that's rather nice I think, and seems to fit the style of cloudinit-composition already used in maas -- rvba, comment?
<TheMue> fwereade__: which way do you prefer the passing of the UUID to NewHookContext to be tested? it's done implicit by compared what is passed to what later is retrieved as env variable.
<rogpeppe> fwereade__: we might rename cloudinit.New to cloudinit.Config.Configure if we did that, perhaps
<rvba> fwereade__: rogpeppe sounds like a good ideaâ¦
<TheMue> fwereade__: the field is only used to set the env variable, there's no other accessor
<fwereade__> rvba, then maybe go with that if that's ok?
<fwereade__> TheMue, so, you need to check it in an actual hook
<rvba> fwereade__: ok, I'll give it a try.
<rogpeppe> rvba: thanks
<fwereade__> TheMue, ATM you don't test that the env var actually has the correct value
<fwereade__> rvba, rogpeppe: tyvm
<TheMue> fwereade__: i do, with the latest CL
<fwereade__> TheMue, you do not
<TheMue> fwereade__: it's generated once, passed to NewHookContext and compared with the env variable in AssertEnv()
<fwereade__> TheMue, you test HookContext
<fwereade__> TheMue, you do not ever test the correct value of the environment uuid, for which you need to actually run a uniter
<fwereade__> TheMue, you do test, perfectly well, that a hook context created with a given UUID will put that UUID into the env
<TheMue> fwereade__: then i got your comment wrong. thought you meant the passing to the HookContext
<fwereade__> TheMue, that's exactly what I mean
<TheMue> fwereade__: hmm
<fwereade__> TheMue, if I changed runHook() to pass in trivial.NewUUID(), what test would fail?
<TheMue> fwereade__: yeah, i know what you mean, but i would have expected a different comment. ;)
<dimitern> benji: reviewed
<benji> thanks
<fwereade__> TheMue, sorry :)
<TheMue> fwereade__: will change (or add) the test
<TheMue> nice, uniter_test has "only" 1632 loc
<dimitern> TheMue: but getting to know all of them is incredibly rewarding in the long term ;)
<TheMue> dimitern: thankfully i know all chars, numbers and signs. will sort it and check it in again, then it's more simple. 1859 x "a", 198 x "b", 1329 x "c" ... :D
<benji> dimitern: thanks for the review, I made the changes you suggest.  Now for a second review.  Any takers?
<dimitern> benji: cheers
<fwereade__> TheMue, you can do it all in the context type
<rogpeppe> niemeyer: ping
<niemeyer> rogpeppe: pongus
<rogpeppe> niemeyer: heya
<rogpeppe> niemeyer: i'm seeing strange failures when running the uniter tests against go tip, and i'm trying to narrow down the issue
<niemeyer> rogpeppe: Ok
<rogpeppe> niemeyer: one symptom in particular i'm seeing is that mgo is returning an error like: Invalid ns [@\x10!]
<rogpeppe> niemeyer: the "Invalid ns" comes from within mongod
<rogpeppe> niemeyer: the ns itself varies - it looks like garbage
<niemeyer> rogpeppe: Ok
<niemeyer> rogpeppe: ns is the collection name
<niemeyer> rogpeppe: plus the database name usually
<rogpeppe> niemeyer: i'm also sometimes seeing a panic in mongoSocket.Acquire
<rogpeppe> niemeyer: do you have an idea of places that it might become corrupt?
<fwereade__> TheMue, just (1) drop context id, add env uuid instead (2) s/UniterSuite-%d/%s/ in goodHook, badHook and hookPattern (and use ctx.uuid instead of ctx.id)
<niemeyer> rogpeppe: No.. mgo doesn't use anything unsafe
<rogpeppe> niemeyer: yeah, i didn't think so.
<rogpeppe> niemeyer: the tests pass ok under the race detector
<niemeyer> rogpeppe: I've seen one of your tracebacks.. it looks like corruption indeed
<niemeyer> rogpeppe: Like, bad corruption, not just a race
<rogpeppe> niemeyer: yeah
<niemeyer> rogpeppe: The thing that it said was nil in the traceback was actually a field that was not a pointer
<rogpeppe> niemeyer: yeah, and i added a nil check before the place that panicked, and i still got a panic there at some point
<rogpeppe> niemeyer: something is quite wrong
<niemeyer> rogpeppe: Might be worth raising that with the core debs
<niemeyer> devs
<rogpeppe> niemeyer: i bisected the problem to the scheduler change, but that might be just exposing some underlying GC race
<rogpeppe> niemeyer: they're following the issue already, i think
<niemeyer> rogpeppe: It sounds like 1.1 is pretty close to release.. it'd be sad if something like that went out
<rogpeppe> niemeyer: i totally agree
<niemeyer> rogpeppe: Oh, you filed something upstream about it already?
<rogpeppe> niemeyer: http://code.google.com/p/go/issues/detail?id=5193
<rogpeppe> niemeyer: it's a pity we can't *entirely* rule out our own stuff, as we do use cgo, but tbh the yaml stuff has been stable for ages.
<niemeyer> rogpeppe: Yeah
<niemeyer> rogpeppe: I may actually end up porting goyaml pretty soon as a non-Canonical task
<niemeyer> rogpeppe: This will help us ruling that stuff out as well
<rogpeppe> niemeyer: that would be marvellous, yes.
<mattyw> rogpeppe, sorry to interrupt, I'm getting a "juju home hasn't been intialized" when trying to call the api, But I've got an envionment running - there aren't any units but the state server is there
<rogpeppe> mattyw: you'll need to import environs/config and copy this function from cmd/juju: http://paste.ubuntu.com/5676897/
<rogpeppe> mattyw: this is an unfortunate consequence of recent changes
<niemeyer> rogpeppe: Here is a crazy idea: would the goyaml package work over rpc?
<rogpeppe> fwereade__: ^
<rogpeppe> niemeyer: hmm, depends on the C API i think
<niemeyer> rogpeppe: Not really
<niemeyer> rogpeppe: What'd go over the wire has nothing to do with C
<fwereade__> mattyw, is this a "juju home..." error coming back from the API server?
<niemeyer> rogpeppe: The point is to quickly build a mock version of goyaml that is type safe
<rogpeppe> niemeyer: i'm thinking of the reflection stuff, but perhaps all that is done Go side
<niemeyer> rogpeppe: It doesn't make a difference
<fwereade__> mattyw, wait, that error is a panic, right?
<niemeyer> rogpeppe: The real goyaml would sit on the other side of the wire
<rogpeppe> niemeyer: to unmarshal, you'd presumably need to send the other side a description of the kind of type you want to unmarshal into, right?
<fwereade__> rogpeppe, API and yaml might not mix so wonderfully... AIUI yaml is a hassle in javascript
<fwereade__> rogpeppe, but maybe I mistake you
<niemeyer> rogpeppe: I don't know.. haven't used the rpc package at all, so I don't know what it is sending
<mattyw> fwereade__, yes it is
<niemeyer> rogpeppe: I know it does send information about the real types, though
<rogpeppe> niemeyer: it sends gob by default
<dimitern> fwereade__: I'm not getting your point here: https://codereview.appspot.com/8330043/diff/11001/worker/provisioner/provisioner.go#newcode273
<niemeyer> rogpeppe: I imagined for the purposes of juju-core, we only marshal a very limited set of types
<dimitern> fwereade__: processMachines already behaves this way, due to the change in pendingOrDead
<niemeyer> rogpeppe: Which means it'd be easy to custom-code it
<rogpeppe> fwereade__: the problem is we've got a real client here, and if you want to use environs.New and have the normal default thing happening, you need to call SetJujuHome
<fwereade__> mattyw, ok, basically an incomplete environ config has somehow made its way into state, and something is throwing a fit because the user environment that usually fills that stuff in is not present
<niemeyer> rogpeppe: and tell the other side what it should unmarshal onto, and send the full value back over the rpc
<fwereade__> rogpeppe, mattyw: sorry, I'm not 100% clear on the exact context
 * rogpeppe goes to look at goyaml
<fwereade__> mattyw, but based on what rogpeppe said I said at lest one untrue thing above
<fwereade__> dimitern, processMachines starts new machines before trashing unknown ones
<niemeyer> rogpeppe: I don't think there's anything interesting to look there
<niemeyer> rogpeppe: The point is to use the real goyaml
<fwereade__> dimitern, if it continues to do this, we could end up with multiple instances of individual agents, and that would be bad
<niemeyer> rogpeppe: and to request unmarshalling over a socket instead of locally
<mattyw> fwereade__, does it sound like my env hasn't bootstrapped properly?
<dimitern> fwereade__: so you suggest moving the trashing before starting?
<fwereade__> dimitern, yes please
<rogpeppe> niemeyer: i don't think you can - you can't pass pointers over the wire
<fwereade__> mattyw, so this is a real live environment that's doing this?
<niemeyer> rogpeppe: You surely can pass structs containing pointers that are set, right?
<niemeyer> rogpeppe: GiveMeAFoo(data []byte) *Foo
<rogpeppe> fwereade__: the point is that, i think, this (previously valid) code will now fail: http://paste.ubuntu.com/5676928/
<mattyw> fwereade__, yes, on aws, I've been having trouble with it recently ( "state entity not found" on the juju mailing list)
<mattyw> fwereade__, but this bootstrap seemed to work
<rogpeppe> niemeyer: the problem is that Unmarshal needs to know what it's unmarshalling into
<niemeyer> rogpeppe: Like, GiveMeAFoo?
<dimitern> fwereade__: sure thing
<rogpeppe> niemeyer: if you can enumerate all the possible types for Foo, that'll work. but i'm not sure you can do that easily.
<niemeyer> <niemeyer> rogpeppe: I imagined for the purposes of juju-core, we only marshal a very limited set of types
<fwereade__> rogpeppe, I don't consider that code to be valid... the amount of magic we put in the environment config was a fuckup of the first order, and this is IMO just the latest toll it is extracting
<rogpeppe> fwereade__: so you don't want us to be able to use juju stuff from a normal Go program?
<fwereade__> rogpeppe, I don't want us to be able to magically infer stuff, no
<rogpeppe> fwereade__: it's not about magically inferring stuff. it's about actually using the juju libraries to interact with juju.
<rogpeppe> niemeyer: i'm not sure. maybe we actually never unmarshal into a struct.
<rogpeppe> niemeyer: but we do
<fwereade__> rogpeppe, the whole problem is the magic inference
<niemeyer> rogpeppe: Hmm.. can't parse that.. :)
<rogpeppe> fwereade__: what magic inference?
<TheMue> fwereade__: thx, needed a bit to follow but i think i've got it
<rogpeppe> niemeyer: here's an example of a type that we unmarshal into: http://paste.ubuntu.com/5676945/
<fwereade__> rogpeppe, everything in environs/config that assumes the existence of $HOME or $JUJU_HOME, or any of the environs themselves that pull stuff out of the env
<TheMue> fwereade__: the UniterSuite-%d has the comment "prevents cross-pollution". so shouldn't it stay?
<rogpeppe> fwereade__: so user code should just duplicate the checkJujuHome function from cmd/juju and be done with it?
<fwereade__> rogpeppe, as far as I'm concerned, if you want to interact programmatically you can supply a valid config
<rogpeppe> fwereade__: the config comes from the user's home directory
<rogpeppe> fwereade__: i think it's perfectly reasonable that if you write a juju-interacting program that it can understand $HOME/.juju/environsments.yaml just like the normal juju command
<niemeyer> rogpeppe: yep?
<rogpeppe> niemeyer: so would we want to hard-code that type as "one of the limited set of types that we use with yaml"? or would we need to break it apart and make an unmarshal RPC for each component piece of it?
<TheMue> rogpeppe: $JUJU_HOME/environments.yaml
<rogpeppe> TheMue: either, right?
<niemeyer> rogpeppe: The former
<TheMue> rogpeppe: yes
<rogpeppe> niemeyer: so every time we change that type, we'd need to update goyaml in sync with it?
<fwereade__> rogpeppe, I think that asking that programmer to be explicit about where he wants his data to come from is pretty reasonable
<niemeyer> rogpeppe: man..
<niemeyer> rogpeppe: I'm suggesting a *test case*
<rogpeppe> niemeyer: ah!
<fwereade__> rogpeppe, if there were lots of people doing that, it might even make sense to export that function
<niemeyer> rogpeppe: To see if things break when we don't have any cgo in the system
<rogpeppe> niemeyer: that's well doable, yeah
<niemeyer> rogpeppe: I'm not suggesting you do any such awful hacks permanently, or even to commit something as bad as that
<rogpeppe> niemeyer: cool, sorry, i didn't realise it was a totally temporary thing you were suggesting
<niemeyer> rogpeppe: np
<rogpeppe> fwereade__: that's what i would suggest
<fwereade__> mattyw, (sorry, btw, I am still thinking... but popping out to get ciggies, brb)
<mattyw> fwereade__, ok thanks
<fwereade__> mattyw, would you paste me the panic please?
<rogpeppe> niemeyer: i'd start by instrumenting goyaml to see what types are actually used (and in fact i think it might just be interface{})
<niemeyer> rogpeppe: Probably not.. but it's a reduced set either way
<rogpeppe> niemeyer: in which case i'm not entirely sure we can make gob work. json might be sufficient though.
<niemeyer> rogpeppe: You can make it work as suggeste
<niemeyer> d
<niemeyer> rogpeppe: By asking the other side to unmarshal onto a specific type, and send back the result
<rogpeppe> niemeyer: gob doesn't allow you to unmarshal onto *interface{} by default.
<niemeyer> rogpeppe: Why does that matter?
<rogpeppe> niemeyer: because (i think) you need to be able to tell the other side what specific type you want to unmarshal onto
<niemeyer> rogpeppe: As I just mentioned, the wire is seeing concrete types
<rogpeppe> niemeyer: and you don't have that information
<niemeyer> rogpeppe: I'm not following..
<niemeyer> rogpeppe: "you need to be able to tell the other side".. so just do!
<rogpeppe> niemeyer: i'm not entirely sure that you can marshal and unmarshal a map[interface{}]interface{} in gob.... but if you register all the possible concrete types, it may work.
<niemeyer> """
<niemeyer> Interface types are not checked for compatibility; all interface types are treated, for transmission, as members of a single "interface" type, analogous to int or []byte - in effect they're all treated as interface{}. Interface values are transmitted as a string identifying the concrete type being sent (a name that must be pre-defined by calling Register), followed by a byte count of the length of the following data (so the value can be skipped if i
<niemeyer> t cannot be stored), followed by the usual encoding of concrete (dynamic) value stored in the interface value. (A nil interface value is identified by the empty string and transmits no value.) Upon receipt, the decoder verifies that the unpacked concrete item satisfies the interface of the receiving variable.
<niemeyer> """
<rogpeppe> niemeyer: yeah, it may work, but i haven't tried it yet
<mattyw> fwereade__, http://pastebin.canonical.com/88419
<niemeyer> rogpeppe: Well, either it works, or there's a bug in the code, or in the documentation
<rogpeppe> niemeyer: it's, let's say, a less explored area :-)
<niemeyer> rogpeppe: Ugh.. I see you got another crash, inside the gc this time
<niemeyer> rogpeppe: and Russ is out.. sucs
<niemeyer> ks
<rogpeppe> niemeyer: yeah.
<rogpeppe> niemeyer: and i have other stuff that i need to be doing too. but... this is important stuff to sort out, i think.
<niemeyer> rogpeppe: If 1.1 is shipped and stuff breaks randomly, yeah, it'll be pretty bad
<rogpeppe> niemeyer: yeah, the gob thing works ok: http://play.golang.org/p/XGWLfQgPzr
<niemeyer> rogpeppe: Cool
<rogpeppe> niemeyer: BTW here's little go hack i'd not thought of before to give you arbitrary variable-length keys to maps: http://play.golang.org/p/cs0HTON9nj
<rogpeppe> niemeyer: i don't think i'd ever actually want to *use* it, but it's kinda cool
<niemeyer> rogpeppe: That's very cool.. hadn't thought about it either (but haven't needed it so far as well)
<dimitern> fwereade__: I disagree with some of your suggestions, not the important ones though - would you take a look again please? https://codereview.appspot.com/8330043
<fwereade__> mattyw, would you explain a little bit more about your use case here? you're trying to open an API connection given an env config?
<niemeyer> rogpeppe: It reminds of erlang
<fwereade__> dimitern, ack
<rogpeppe> niemeyer: binary trees as keys, yay!
<niemeyer> rogpeppe: I'd call {a, b} as head, tali
<niemeyer> tail
<rogpeppe> niemeyer: yeah
<niemeyer> rogpeppe: There are tons of algorithms around this logic.. erlang lists are fully based on them, given the immutability of the language
<niemeyer> rogpeppe: Good one, thanks
<mattyw> fwereade__, at the moment the use case is just, spin up some units, connect to the api and start adding and removing units to see what I get back from the api
<mattyw> fwereade__, (the adding and removing of units would be done using the juju command - not the api)
<fwereade__> dimitern, did you propose your changes?
<fwereade__> mattyw, ok, I do see the problem; and rogpeppe, I take your point, but the fact remains that if we'd done it properly in the first place we wouldn't have to deal with any of this absurdity :(
<fwereade__> rogpeppe, config.SetCLIMode()? :(
<rogpeppe> fwereade__: i'm not sure. for the user-level logic, it makes sense to fall back to stuff in $HOME
<rogpeppe> fwereade__: i'd prefer the logic the other way around actually
<rogpeppe> fwereade__: config.SetDaemonMode
<rogpeppe> fwereade__: so that user-level client code can proceed with as little friction as possible
<fwereade__> rogpeppe, if stuff is going to fail stupidly I want it to fail on the client where we can see it happening
<rogpeppe> fwereade__: haven't we just set stuff up so we'll get a panic on the server not the client?
<dimitern> fwereade__: yeah, I proposed them
<fwereade__> rogpeppe, what I *thought* we were doing was setting stuff up so we'd get a panic in the *tests*
<fwereade__> rogpeppe, but it turns out that JujuConnSuite shares certain characteristics with the honey badger
<dimitern> :D
<fwereade__> rogpeppe, and renders all that useless
<dimitern> the honey badger is the best
 * rogpeppe doesn't know anything about honey badgers
<dimitern> the honey badger just doesn't give a shit basically
<dimitern> rogpeppe: http://en.wikipedia.org/wiki/The_Crazy_Nastyass_Honey_Badger
<rogpeppe> dimitern: 58m views + 1 :-)
<rogpeppe> niemeyer: sum total of ways we use goyaml: http://paste.ubuntu.com/5677075/
<niemeyer> rogpeppe: Hah :)
<rogpeppe> niemeyer: well, from the uniter tests anyway
<niemeyer> rogpeppe: Sure.. you've managed to break things wiht it alone, right?
<rogpeppe> niemeyer: yup
<niemeyer> rogpeppe: Superb
<niemeyer> rogpeppe: piece of cake then
 * rogpeppe is on it
<fwereade__> mattyw, ok, I have not yet come up with the Right answer
<fwereade__> mattyw, the expedient one, though, is as rogpeppe anti-suggested -- copy checkJujuHome from cmd/juju/main.go and call it before you mess with environments locally
 * fwereade__ remains convinced that the CLI is the special case, and that privileging that case to the point where it's inseparable from environ config was a seriously Bad Move
<rogpeppe> fwereade__: i'm not sure about the former, but i think you're probably right about the latter.
<hazmat> does the charm and tools cache also get moved with juju_home?
<fwereade__> hazmat, yeah
<rogpeppe> hazmat: i think so, yes
<fwereade__> hazmat, authorized-keys is the wrinkle
<hazmat> fwereade__, ic. i ended up with authorized-keys-path lookup relative to juju home in addition to absolute lookups. authorized-keys by themselves are content
<fwereade__> hazmat, hell, that is a very good point, would you file a bug please?
<hazmat> fwereade__, sure
<dimitern> rogpeppe: I need one more review of the provisioner stuff https://codereview.appspot.com/8330043/ - it should be quick and simple
<fwereade__> hazmat, that is strange, because the code seems to all be in terms of $HOME
<hazmat> fwereade__, trunk is yes, i needed it for some easier multi-env management so i just added it
<hazmat> i need to reinstall 64bit i think to get going with juju-core.. doing it in vms isn't quite as nice.
<hazmat> or amenable to hacking
<hazmat> on a branch re adding
<hazmat> fwereade__, bug is here.. i think that's what your referencing. bug 1164601
<_mup_> Bug #1164601: JUJU_HOME should support relative lookup paths for authorized-keys-path <juju-core:New> < https://launchpad.net/bugs/1164601 >
<rogpeppe> dimitern: i'm just wondering what is the motivation for the change to processMachines
<dimitern> rogpeppe: so we can remove unknown/not matching machines before trying to start matching unprovisoned ones
<rogpeppe> dimitern: is it just to make sure that we stop unknown instances even when startMachines continually fails?
<dimitern> rogpeppe: it won't fail more than once now - the machine will be in error state and will be ignored
<dimitern> rogpeppe: on the other hand, if a machine was started but SetInstanceId failed we'll remove it next time before
<dimitern> rogpeppe: before trying to start new ones
<rogpeppe> dimitern: i'm not sure i see why the order matters
<rogpeppe> dimitern: won't it all work ok in the original order?
<rogpeppe> dimitern: my reason for asking is that findUnknownInstances and stopInstances may be quite slow, and it might be better if we did the start instance ASAP
<dimitern> rogpeppe: I should refer you to fwereade__ for better explanation then, sorry
<fwereade__> rogpeppe, if we stop unknown ones before starting new ones, we should be able to avoid ever having 2 instances of the same agent running at the same time
<rogpeppe> fwereade__: ah!
 * dimitern still doesn't get how this could happen though..
<fwereade__> dimitern, SetInstanceId fails
<rogpeppe> fwereade__: assuming ec2 eventual consistency does actually tell you the names of all recently  started machines of course :-)
<fwereade__> rogpeppe, yeah, there's that
<fwereade__> rogpeppe, call it a best effort that should hit a number of cases in which we would otherwise be encouraging that sort of inconsistency
<rogpeppe> fwereade__: so should an agent check that its instance id is set before carrying on to do stuff?
<rogpeppe> fwereade__: because otherwise it will be killed ad-hoc
<fwereade__> rogpeppe, probably, that would be sensible
<fwereade__> rogpeppe, and that would eliminate the case I was trying not to think about, too
<dimitern> if SetInstanceId fails, how come we'll have 2 instances having the same agent?
<rogpeppe> dimitern: we've started the instance
<rogpeppe> dimitern: but we haven't managed to set the instance id of the machine
<rogpeppe> dimitern: so the new machine comes up
<rogpeppe> dimitern: and starts running an agent
<dimitern> rogpeppe: but the MA is local to the instance, right? each instance will have its own MA
<rogpeppe> dimitern: but in the meantime, the provisioner sees that there's a machine without an instance id
<fwereade__> rogpeppe, the only one left over is the initial password-setting... I think we could possibly get an ugly race there, in which we have 2 machines running the agent but neither able to log in
<rogpeppe> dimitern: and starts another instance
<fwereade__> rogpeppe, but it would be *very* hard to trigger, I think
<rogpeppe> fwereade__: it could be mitigated if the agent checked the instance id *before* setting the password
<fwereade__> rogpeppe, oh, maybe not
<fwereade__> rogpeppe, yep
<dimitern> rogpeppe: yeah, a third one, while the other two (one with instid, other without) are still running
<fwereade__> rogpeppe, but wait... ok, I need to go chop vegetables and think about this
<dimitern> rogpeppe: and we'll have 2 valid running machines and one stray
<dimitern> rogpeppe: how does this translate to having the same agent on 2 machines?
<fwereade__> dimitern, +100 to rog's suggestion of making the UA resilient to this
<fwereade__> dimitern, two machines are both configured to run the agent for machine 3
<fwereade__> dimitern, both of them start running wordpress/0
<fwereade__> dimitern, everything goes to shit
<dimitern> fwereade__: ah! the machineid is the same, but one doesn't have instanceid!
<fwereade__> dimitern, yeah
<dimitern> got it finally :) cheers
<rogpeppe> fwereade__, dimitern: ha, it's easy to check the InstanceId before the password's set
<dimitern> rogpeppe: where?
<rogpeppe> dimitern: in MachineAgent.Entity
<dimitern> rogpeppe: shouldn't this be a separate CL?
<rogpeppe> dimitern: definitely
<fwereade__> dimitern, yes
<rogpeppe> dimitern: but i'd like a comment
<fwereade__> dimitern, sorry, I should have been clear about that
<rogpeppe> dimitern: in processMachines
<rogpeppe> dimitern: because this is subtle stuff
<fwereade__> dimitern, yeah, maybe best if you rewrite the explanation according to your understanding
<dimitern> rogpeppe: cool, write a review comment and I'll add a card to do it in a follow-up
<rogpeppe> dimitern: ok
<dimitern> fwereade__: sgtm, will just add the "same machine ID" stuff to the comment and it should be clear enough
<rogpeppe> fwereade__: of course, we are assuming that StopInstance is synchronous here
<rogpeppe> fwereade__: the machine agent should probably check that the instance id of the machine matches the instance id of the machine it's actually running on
<rogpeppe> fwereade__: in fact, with that check we *could* start new machines before stopping unknown ones, i think
<dimitern> rogpeppe: ok, noted down 2 changes for a follow-up: MA should ensure the instance id of the machine in state matches the one it's running on, and then set the password to connect to state
<rogpeppe> dimitern: sounds good
<dimitern> rogpeppe: sounds good?
<rogpeppe> dimitern: you've got a review BTW
<dimitern> :) great, I'll add a card
<dimitern> rogpeppe: tyvm
<dimitern> fwereade__: you're also fine with the changes I did?
<dimitern> rogpeppe: where's that MachineAgent.Entity you mentioned?
<rogpeppe> dimitern: in jujud/machine.go
<dimitern> rogpeppe: and when's the password being set - I can't see
<rogpeppe> dimitern: in RunAgentLoop (by openState)
<dimitern> rogpeppe: ok, thanks
<dimitern> fwereade__: ping
<dimitern> ok i'm off, good night all
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: - | Bugs: 2 Critical, 53 High - https://bugs.launchpad.net/juju-core/
<rogpeppe> niemeyer: i did the goyaml-as-rpc thing and it still crashes (earlier actually, but in a similar way)
<niemeyer> rogpeppe: Oh, "sweet"
<rogpeppe> lol
<rogpeppe> niemeyer: here's the rpc server BTW: http://paste.ubuntu.com/5677572/
<rogpeppe> niemeyer: i got a fair few of the standard goyaml tests passing but not all
<niemeyer> rogpeppe: Thta's neat!
<niemeyer> rogpeppe: Well, that's not necessary
<niemeyer> rogpeppe: We just need enough of it to get the juju tests passing
<rogpeppe> niemeyer: indeed. but it was useful to get a reasonable assurance that it was doing something right
<niemeyer> rogpeppe: +1
<niemeyer> rogpeppe: So there we go
<rogpeppe> niemeyer: yup
<niemeyer> rogpeppe: We should really raise a harder flag on that one
<niemeyer> rogpeppe: Did you increment that data on the issue yet?
<rogpeppe> niemeyer: it's consistently dying here now: http://paste.ubuntu.com/5677577/
<rogpeppe> niemeyer: just about to
<niemeyer> rogpeppe: Some weird addresses there
<rogpeppe> niemeyer: if put an "if nil" check and the problem moved elsewhere. darn heisenbugs!
<rogpeppe> s/if/i/
<niemeyer> rogpeppe: Okay, is that nil value still that in that field that is actually a by-value field?
<niemeyer> rogpeppe: If so, it's of course impossible for it to be nil without a GC error, so this might be a good case to raise
<rogpeppe> niemeyer: i'm checking for socket==nil in mongoSocket.Acquire
<rogpeppe> niemeyer: it looks like that can be nil
<niemeyer> rogpeppe: Okay, I'm thinking of that traceback on server.go
<rogpeppe> niemeyer: except i'd expect the first arg to Acquire to be 0x0 if that was the case
<niemeyer> rogpeppe: If it can be reproduced, that'd be an easier one
<rogpeppe> niemeyer: i just want to catch it in the act
<niemeyer> rogpeppe: Because it was claiming there was a nil value that was impossible to be nil without the GC being on crack
<rogpeppe> niemeyer: really? i'm not sure i see that
<niemeyer> (or an unsafe error, which we can't have anymor)
<niemeyer> rogpeppe: Do you have the old traceback around?
<rogpeppe> niemeyer: how old? :-)
<niemeyer> rogpeppe: The first one I saw you mentioning on that regard
<niemeyer> rogpeppe: So pretty old I suspect
<rogpeppe> niemeyer: this one is the first one i saw, i think: http://paste.ubuntu.com/5677624/
<rogpeppe> niemeyer: (as reported in the issue)
<rogpeppe> niemeyer: it looks fairly similar
<niemeyer> rogpeppe: Okay, it wasn't that one
<niemeyer> rogpeppe: Hmm
<niemeyer> rogpeppe: There's a race there
<niemeyer> rogpeppe: It may be an actual issue in mgo
<rogpeppe> niemeyer: FWIW i ran the tests with the race detector enabled ok
<niemeyer> rogpeppe: I don't know about that, but there's a logic error in the acquireSocket function
<niemeyer> rogpeppe: Open session.go in 2898
<niemeyer> rogpeppe: Invert the two Acquire calls so that RUnlock is done after they're the Acquire
<rogpeppe> niemeyer: 		s.masterSocket.Acquire() ?
<niemeyer> rogpeppe: Both slave and master
<niemeyer> rogpeppe: They both have the same mistake
<rogpeppe> niemeyer: ok, will do
<niemeyer> rogpeppe: It's entirely possible that in a concurrent scenario the sockets are niled out before the Acquire is done, because they're outside of the lock
<rogpeppe> niemeyer: yes
<niemeyer> rogpeppe: Hah.. on a unrelated note, check out this weird bug that was fixed in tip: http://play.golang.org/p/FceemIemVw
<rogpeppe> niemeyer: ah yes, i caught that one going through
<rogpeppe> niemeyer: apparently some people were relying on it
<niemeyer> rogpeppe: Indeed.. I got an error report about that :)
<niemeyer> rogpeppe: How's the test going?
<rogpeppe> niemeyer: just crashed that second
<niemeyer> rogpeppe: Where?
<rogpeppe> niemeyer: same place
<niemeyer> rogpeppe: Can I see the new traceback?
<rogpeppe> niemeyer: http://paste.ubuntu.com/5677661/
<rogpeppe> niemeyer: the line number's slightly different because the start of Acquire does this check:
<rogpeppe> niemeyer: http://paste.ubuntu.com/5677666/
<rogpeppe> niemeyer: so it really does look like corruption
<rogpeppe> niemeyer: otherwise the first panic would have been triggered
<niemeyer> rogpeppe: Wow.. yeah
<niemeyer> rogpeppe: What's the Go issue again? It scrolled out of view
<rogpeppe> niemeyer: 5193
<niemeyer> rogpeppe: Thanks
<rogpeppe> niemeyer: (what, no search?)
<niemeyer> rogpeppe: I'm lazy.. but if I have to debate that with you it doesn't work anymore.. :-)
<rogpeppe> lol
<niemeyer> rogpeppe: The fact mgo puts every socket on their own goroutine is probably helping to trigger the bug
<rogpeppe> niemeyer: yeah.
<niemeyer> rogpeppe: Or.. the reading side of the socket, anyway
<niemeyer> rogpeppe: I sent a private ping to Rob about the issue, just to make sure it won't be left behind
<rogpeppe> niemeyer: thanks
<niemeyer> rogpeppe: np.. usually I wouldn't be worried since rsc is CCd, but given he's away, I'm actually a bit concerned
<rogpeppe> niemeyer: it is marked as Priority-ASAP
<niemeyer> rogpeppe: It can easily be unmarked as well :)
<rogpeppe> right, that's me utterly done for the day
<rogpeppe> niemeyer: thanks for the assistance
<thumper> hi rogpeppe
<thumper> night rogpeppe
<rogpeppe> thumper: hiya
<rogpeppe> thumper: how's tricks?
<thumper> rogpeppe: good, was just thinking about code, then realised that today is the last day for peer reviews
<rogpeppe> thumper: anything you wanna chat about while we're online together? :-)
<thumper> so I have those to do instead
<thumper> not really...
<rogpeppe> thumper: oh frick
<thumper> reviews suck the life out of me
<thumper> I know they shouldn't
<thumper> but they do
<thumper> at least I'm not doing manager ones
<rogpeppe> thumper: code reviews or peer reviews... or both?
<thumper> I would have had eight extra to do otherwise
<thumper> just peer / manager / report reviews
<thumper> code reviews are fine
 * rogpeppe grabs a beer and settles down to do some reviews
<rogpeppe> thumper: where should i have found out about the peer review deadline, other than by word of mouth?
<thumper> rogpeppe: in the all hands email
<thumper> about reviews
<thumper> quite a few weeks back
<thumper> gave the timeline in it
<rogpeppe> thumper: ah, found it. i wonder if "by 5th April" is by end of day or end of previous day.
<thumper> it normally means by the end of the 5th in the west-most time zone
<thumper> :)
<rogpeppe> thumper: cool. tomorrow, then...
<rogpeppe> thumper: have a good day
<thumper> rogpeppe: keep the beer for it though
<thumper> rogpeppe: it helps
<rogpeppe> thumper: i certainly will
<niemeyer> rogpeppe: have a good night
 * thumper has put off reviews long enough, and goes to log into the system
<thumper> hi davecheney
<thumper> davecheney: https://code.launchpad.net/~thumper/juju-core/package/+merge/157020
<thumper> davecheney: and https://code.launchpad.net/~thumper/+recipe/juju-core-daily
<thumper> davecheney: you can see in the built packages that the files are there and the man page too
#juju-dev 2013-04-05
<davecheney> thumper: re last nights discussion of pacakging
<davecheney> can you outline the concerns of the packager's ?
<thumper> primarily it seemed to be that we weren't following company standards
<davecheney> of that I have no doubt
<davecheney> but that isn't very actionable
<davecheney> i'm guessing the lack of build reproducability is a red flag
<thumper> I'm going to email people concerned to see if we can get help from people who do know the standards
<davecheney> awesome
<thumper> one guy is even in sydney, so pairing might be good if you are interested
<davecheney> sure
<thumper> I'll keep you in the email loop
<thumper> davecheney: can I get you to merge that packaging branch of mine? then I can move the card to done
<bigjools> thumper: how was your foray into packaging?
<thumper> bigjools: brief
<davecheney> thumper: i have some questions about that change
<thumper> davecheney: shoot
<davecheney> see review
<thumper> kk
<thumper> davecheney: replied
 * thumper is EODing early due to overly long meeting last night
 * thumper will look back in later
<davecheney> kk
<davecheney> thumper: fair enough, that makes sense
<jtv> Anyone else getting this build error?  go/src/launchpad.net/juju-core/cmd/juju/constraints.go:66: undefined: results
<jtv> Looks like a :=/= typo.
 * thumper tries
<davecheney> jtv: which revno ?
<jtv> The latest.
<jtv> I'm also getting this one, which I guess is good news:
<jtv> constraints_test.go:283:
<jtv>     // A failure here indicates that goyaml bug lp:1132537 is fixed; please
<jtv>     // delete this test and uncomment the flagged constraintsRoundtripTests.
<davecheney> +1 for being unhelpful :)
<thumper> +1 for getting that
<thumper> davecheney: I get it with tip
<thumper> jtv: yes
<davecheney> confirmed, # launchpad.net/juju-core/cmd/juju
<davecheney> cmd/juju/constraints.go:66: undefined: results
<davecheney> cmd/juju/constraints.go:66: cannot assign to results
<davecheney> cmd/juju/constraints.go:67: undefined: results
<davecheney> will submit a fix
<jtv> Ah thanks.
<thumper> plz fix
<davecheney> what the fuck people
<thumper> we just talked about this last night
<thumper> it worked on my commit
<thumper> yep, last commit added that
 * davecheney sends a shittyram
<jtv> gram?
<thumper> jtv: perhaps he is sending it to mramm
<thumper> or he is sending a pooey male sheep
<jtv> thumper: that's why I asked :-P
<jtv> Confucius say, man-sheep eat from curry tree, he be shitty ram for a day
<davecheney> sorry, type
<davecheney> typo
<davecheney> i meant shittyHAM
<jtv> Oh!
<jtv> Why didn't you SAY so
<davecheney> it's my accent
<thumper> davecheney: I think the whole = / := thing is horrible
<thumper> and needs a rethink
<thumper> so many problems come about from it
<jtv> FWIW I guess you _can_ create this kind of bug just from concurrent commits.
<jtv> The shadowing is really horrible though.  Makes you wonder what's so horrible about a mere unused variable.
<jtv> foo, err := bar()
<jtv> if err != nil { panic(err) }
<jtv> if foo {
<jtv> sklurg, err := szot()
<jtv> Oops now I've created a second err.
<thumper> jtv: I don't think you have
<jtv> That's what I thought.
<jtv> It'll shadow quietly.
<thumper> it isn't shadowed
<thumper> it is using the same err
<thumper> a new sklurg is created though
<thumper> hmm, inside the if though, new scope and all...
<thumper> I've not tested...
<thumper> I don't actually know what is happening there
<thumper> perhaps davecheney does
<davecheney> davecheney: knows what ?
<jtv> thumper: I do know _this_ happens: http://play.golang.org/p/uV__rKVATq
<jtv> Woo!  Test suite completed with just 1 compile error and 1 test failure.
<thumper> davecheney: you have a local packaging branch...?
<thumper> davecheney: https://code.launchpad.net/~thumper/juju-core/package/+merge/157020 has instructions at the top
<thumper> davecheney: bzr merge ...
<thumper> davecheney: bzr commit... bzr push
<thumper> davecheney: done
<davecheney> thumper: oh, ok, it's that simple
 * davecheney wonders what lbox does ...
<thumper> davecheney: previously was referring to jtv's comment above about errors
<thumper> davecheney: lbox does that too, but slowly
<thumper> and with extra checking
<thumper> and many round trips
<davecheney> thumper: are you talking about shadowing ?
<thumper> davecheney: yeah, is the err a shadow or using the one from the previous scope?
<davecheney> it is what it is
<davecheney> it can't be changed now, it's in the spec
<jtv> thumper: just tried the sklurg/err thing and yes, it creates a new sklurg *and* a new err.
<davecheney> looks like others feel the same, https://twitter.com/GolangSucks/status/319999909866651648
<thumper> jtv: is that you @GolangSucks ?
<jtv> thumper: nope
<jtv> Bit strong for me...  You know what I'm like.  I'm trying to see the good things.  :)
<jtv> But I do notice a surprising similarity.  "for item := range x counts x. Unless it's a channel in which case it returns values."  Pretty much a literal match with something I wrote.
<jtv> The unnecessary choices are something I mentioned as well.  Lots of make-work.
<bigjools> Getting a compile error from trunk: http://paste.ubuntu.com/5678748/
<davecheney> bigjools: probably got versoin skew with openstack
<bigjools> davecheney: oh I assumed a go get -u would update that?
<davecheney> try go get -u launchpad.net/goose/...
<davecheney> it might
<bigjools> as in, I did a get -u on juju-core
<davecheney> ohhh, i wouldn't do that
<davecheney> it'll totally screw your bzr checkout
<bigjools> wha?
<davecheney> go get -u doesn't understand cobzr branches
<bigjools> I don't use cobzr
<davecheney> fair enough
<bigjools> that's the least of its problems anyway, I aliased my branch command so it doesn't use trees
<bigjools> which breaks go get
<davecheney> bigjools: probably easier to skip it and just to a bzr pull
<bigjools> yup!
<bigjools> anyway - still got that compile error
<bigjools> after goose updated
<bigjools> I am on raring if that makes any difference
<davecheney> bigjools: pls hold
<bigjools> davecheney: hlding :)
<bigjools> and holding
<davecheney> bigjools: fastest way to a fix
<davecheney> rm -rf $GOPATH/src/launchpad.net/goose
<davecheney> go get launcpad.net/goose/...
<davecheney> or whatever method you want to use to manage your source
<bigjools> ok
<bigjools> oh did it move?
<davecheney> it did not move
<davecheney> actually
<davecheney> that isn't strictly true
<bigjools> quickest way to fix that is:
<bigjools> bzr pull --remember lp:goose
<bigjools> aaaand done.  Loads of updates, crikey.
<davecheney> someone fucked a lot of things up when the kicked us all out of the ~gophers gropu
<bigjools> ok new errors
<bigjools> canonical/GO/src/launchpad.net/juju-core/cmd/juju/constraints.go:66: undefined: results
<davecheney> fix proposed
<bigjools> ah is this what you were talking about jtv?
<davecheney> https://codereview.appspot.com/8370047/
<davecheney> yup
<bigjools> davecheney: given that it's blocking everyone, are you going to land it right away or do you have to wait for 2 pairs of eyes?
<davecheney> bigjools: that is all the enchouragement I need :)
<bigjools> davecheney: that was the intention :)
<bigjools> *cough*
<davecheney> comitted
<bigjools> davecheney: compiles \o/
<bigjools> and the raring mongo seems to have ssl support \o/
<davecheney> bigjools: where is the lp project for mongo ?
<davecheney> ~mongodb looks stale
<bigjools> davecheney: not sure there is one - I am just using the latest package, I think jamespage packaged it
<bigjools> now, I am getting loads of test failures :/
<bigjools> [LOG] 92.72463 ERROR api: error receiving request: read tcp 127.0.0.1:38922: use of closed network connection
<bigjools> all over
<davecheney> bigjools: id suggest that ssl doesn't work
<bigjools> are you on raring?
<davecheney> nope
<bigjools> davecheney: I think raring's mongo (2.2.4?) is incompatible with the current juju
<bigjools> it definitely has ssl support
<bigjools> thumper: you're on raring?
<bigjools> hmm I have it working on a fresh raring VM.  I wonder what's up with my local env...
<rogpeppe> mornin' all!
<bigjools> evening
<TheMue> morning
<davecheney> error: Failed to load data for branch bzr+ssh://bazaar.launchpad.net/~dave-cheney/juju-core/111-add-go-build-check-to-lbox/: Server returned 502 and body: <!DOCTYPE html>
<davecheney> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<davecheney> thanks for coming in today, launchpad
 * fwereade_ -> shops, bbiab
<dimitern> rogpeppe: ping
<rogpeppe> dimitern: pong
 * fwereade_ slept badly, and is more than usually stupid today, and is going to lie down for a bit
<dimitern> rogpeppe: hey, let me pass an idea by
<rogpeppe> dimitern: ok
<dimitern> rogpeppe: how about adding Id() to AgentState, so the jujud/agent can find out which entity id it's associated with and check if it's sane, and then set the password?
 * rogpeppe goes to look
<rogpeppe> dimitern: i'm not sure i understand the motivation.
<dimitern> rogpeppe: it seems all implementations, except the upgrader are backed by a state object - machine or unit
<rogpeppe> dimitern: the code that sets the password first gets the entity
<rogpeppe> dimitern: there's already a method, Entity, to do that
<dimitern> rogpeppe: ah!
<rogpeppe> dimitern: if we make the Entity code return an error if something about it is bogus, then you've got what you want, no?
<rogpeppe> dimitern: that's what i was suggesting last night
<dimitern> rogpeppe: exactly
<dimitern> rogpeppe: for example how is a machine taken as an entity?
<rogpeppe> dimitern: i'm not sure i understand the question
<dimitern> rogpeppe: trying to find the Entity interface
<rogpeppe> dimitern: there's no Entity interface
<rogpeppe> dimitern: Entity returns an AgentState interface value
<dimitern> rogpeppe: ok, but where's the Id()?
<dimitern> rogpeppe: it's not in the AgentState
<rogpeppe> dimitern: Entity is implemented by the agent in question.
<dimitern> rogpeppe: and all I get back is an AgentState - should I cast it to something to get its Id?
<rogpeppe> dimitern: so we have MachineAgent.Entity and UnitAgent.Entity
<rogpeppe> dimitern: each of those knows the id
<dimitern> rogpeppe: ok, got you - you mean only return the entity if it's sane
<rogpeppe> dimitern: for instance, look at the implementation of MachineAgent.Entity
<rogpeppe> dimitern: yes
<rogpeppe> dimitern: there's already an error return
<dimitern> rogpeppe: that should work, cheers
<rogpeppe> dimitern: cool
<rogpeppe> dimitern: you might find this quite cool: i've been trying to isolate a go runtime bug that occurs when running the uniter tests against go tip. i wanted to eliminate the possibility that it was a problem with our use of unsafe and cgo (goyaml uses cgo), so i mocked up goyaml to make rpc calls instead. here's the "mock" goyaml implementation: lp:~rogpeppe/+junk/yamlserver
<rogpeppe> dimitern: it worked - i got uniter tests passing when using it, and i'm still seeing the runtime crashes.
<dimitern> rogpeppe: cool, I'll take a look
<rogpeppe> dimitern: i think it's nice that i can swap out an entire implementation like that and almost nothing needed to change in any of the other code (i just needed to change the uniter tests to register the expected types)
<dimitern> rogpeppe: so it uses goyaml on the rpc server
<rogpeppe> dimitern: yeah
<dimitern> rogpeppe: and the crash in uniter tests is no longer there?
<rogpeppe> dimitern: no, it still crashes
<rogpeppe> dimitern: which is what i was hoping
<dimitern> rogpeppe: so it's not our code then
<rogpeppe> dimitern: because it means it's (almost certainly) not a problem with our code
<rogpeppe> dimitern: yeah
<dimitern> rogpeppe: good to hear, but any idea is it in goyaml or is it go-tip related bug?
<rogpeppe> dimitern: it's a go-tip related bug. probably the new garbage collector.
<rogpeppe> dimitern: but perhaps the new scheduler.
<rogpeppe> dimitern: http://code.google.com/p/go/issues/detail?id=5193
<dimitern> rogpeppe: hmm.. it seems the closer we get to 1.1 release more nasty bugs appear
<rogpeppe> dimitern: they've shoved a lot of stuff in quite recently.
<rogpeppe> dimitern: i'm very concerned too.
<dimitern> rogpeppe: it seems at least they're looking into it, it's not just collecting dust in the issues list
<rogpeppe> dimitern: yeah, they're concerned too
<dimitern> rogpeppe: well, there are a lot of smart people there, so there's hope of fixing it
<rogpeppe> dimitern: yeah. it would be nice if i could replicate the problem with less than x00,000 lines of source code :-)
<dimitern> rogpeppe: definitely :)
<rogpeppe> dimitern: unfortunately the problem is so intermittent, that's not easy
<dimitern> rogpeppe: how often can you reproduce it?
<rogpeppe> dimitern: about once in every 3 or 4 runs
<rogpeppe> dimitern: it dies in quite a few different ways
<dimitern> rogpeppe: bugger
<rogpeppe> dimitern: see the collection of panics in my last message on the above issue
<dimitern> rogpeppe: in random places of the code or at least these are often the same?
<dimitern> rogpeppe: ah, ok
<dimitern> rogpeppe: nasty.. they're in at least 3 different places
<rogpeppe> dimitern: yeah. i'm pretty sure they're all symptomatic of something else (for instance a race or other bug in the garbage collector)
<rogpeppe> dimitern: i see other problems too which aren't panics, but are symptomatic of memory corruption
<dimitern> rogpeppe: so you nailed it down to r16008
<dimitern> (the link is broken there btw)
<rogpeppe> dimitern: i'm not sure.
<rogpeppe> dimitern: that might just be the change that made the garbage collector bug show up
<rogpeppe> dimitern: because 16008 is when the new scheduler was introduced
<dimitern> rogpeppe: in can be in either the new scheduler or the GC, both nasty internals
<dimitern> rogpeppe: oh well, we'll see how it goes
<rogpeppe> dimitern: yeah
<dimitern> rogpeppe: so if a machine doesn't have instid, is it correct to call EnsureDead() before returning it from the Entity()? That way it'll be detected in openState and the worker will die properly
<fwereade_> dimitern, hell no :)
<dimitern> fwereade_: why?
<fwereade_> dimitern, we don't want the machine to die -- there'll be another agent along soon to do the right thing
<fwereade_> dimitern, we just want the bad agent to go away and not come back :)
<rogpeppe> fwereade_: exactly
<dimitern> fwereade_: so we want the instance dead, not the machine
<fwereade_> dimitern, yeah, exactly
<rogpeppe> dimitern: and the agent will die immediately anyway
<dimitern> rogpeppe: not really
<fwereade_> dimitern, sorry about the terminology, it is annoying ;)
<dimitern> rogpeppe: it'll die (now) iff the machine is missing or dead
<rogpeppe> dimitern: because the run loop will terminate
<rogpeppe> dimitern: ah, you're right - it'll keep on trying
<fwereade_> dimitern, rogpeppe: how would you feel about just writing a flag somewhere local saying "stopped" or something
<dimitern> rogpeppe: I'll have to introduce a specific ErrUnprovisioned for example, and use that to amend the cases in which the worker dies
<rogpeppe> fwereade_: i really don't care about this case
<rogpeppe> fwereade_: it's a ghost machine
<rogpeppe> fwereade_: i don't care if it carries on trying
<rogpeppe> a ghost *instance*, rather
<dimitern> rogpeppe: but it'll be nicer to finish off the rouge MA as early as possible in this case, isn't it?
<fwereade_> rogpeppe, so long as we return nil from Run it'll only retry once per restart anyway I guess
<fwereade_> rogpeppe, but wait
<rogpeppe> dimitern: i don't want to introduce more logic for this case which is actually vanishingly unlikely
<fwereade_> rogpeppe, if we *don't* mark it stopped, then a badly-timed restart of its instance can fuck up the other machine, I think
<rogpeppe> fwereade_: how so?
<dimitern> fwereade_, rogpeppe: how about that specific error (ErrUnprovisioned) or something?
<dimitern> (returned from MA.Entity)
<dimitern> or maybe (nastier) return NotFoundf(), although it's clearly a lie, but it'll only affect the agent
<fwereade_> rogpeppe, agreed vanshingly unlikely, but: (1) bad machine logs in with old password (2) provisioner sets password for good machine and starts an instance (3) bad machine changes password and starts running
<fwereade_> rogpeppe, (4) provisioner takes down bad machine (5) good machine can't run
<dimitern> fwereade_: why is this at all so unlikely?
<fwereade_> dimitern, it requires pathologically bad timing
<dimitern> fwereade_: given infinite time and scenarios, everything is possible :)
<fwereade_> dimitern, exactly so
<fwereade_> dimitern, that is why I would prefer a little tweak to the agent running
<fwereade_> dimitern, first thing an agent should do is check its conf for a stopped flag; last thing it should do if it's returning nil from Run is to set the stopped flag
<rogpeppe> fwereade_: why would the bad machine ever get as far as changing the password?
<dimitern> rogpeppe: this happens first thing after running the MA, right?
<fwereade_> rogpeppe, because the provisioner set one at the worst possible time... say during a 5-second t1.micro sleep on the bad machine
<rogpeppe> fwereade_: the bad machine doesn't care - it looks at the instance id and sees that it doesn't match its own instance
<rogpeppe> fwereade_: i don't see that there's any way it can get past that barrier
<fwereade_> rogpeppe, how's it meant to find that out? we're planning to drop InstanceId from EnvironProvider
<dimitern> rogpeppe: it cannot know it's own instance id, only the machine id
<dimitern> rogpeppe: it can check is it "" or not
<rogpeppe> fwereade_: orly?
<fwereade_> rogpeppe, yesrly, it's caused problems for both maas and openstack
<rogpeppe> fwereade_: so how do we deal with the "provisioner unprovisions itself" problem?
<fwereade_> rogpeppe, and there's no reason for it except to prevent the provisioner from screwing itself
<fwereade_> rogpeppe, so, we special-case in the provisioner instead
<dimitern> fwereade_: I think MAAS guys figured it out, and in openstack it can be done through the storage
<fwereade_> dimitern, I know it can be done
<rogpeppe> fwereade_: how does that work?
<fwereade_> dimitern, but there is a different shitty wa of doing it in each case
<fwereade_> rogpeppe, if there's only one machine in state, grab the instance id from provider state... done. right?
<fwereade_> dimitern, note that the put-it-in-environ-state works for the bootstrap machine only -- it won't let us get an InstanceId on an arbitrary machine
 * dimitern keeps waiting for an answer on errUnprovisioned (locally in jujud only)
<rogpeppe> fwereade_: assuming the machine doesn't come up really fast, i suppose :-)
<rogpeppe> dimitern: we're getting there :-)
<dimitern> :)
<fwereade_> rogpeppe, even if it does, we fail out and get restarted in 5s
<rogpeppe> fwereade_: no, if it does, we unprovision ourselves
<rogpeppe> fwereade_: or... no, i see
<fwereade_> rogpeppe, this would happen before we do anything else, so I think it's safe
<rogpeppe> fwereade_: i'm not sure you can guarantee it happens before we do anything else
<rogpeppe> fwereade_: the provisioner is just another API client, right?
<fwereade_> rogpeppe, what's affected by this other than the provisioner?
<rogpeppe> fwereade_: someone external could jump in before the provisioner and add another machine
<fwereade_> rogpeppe, ah!
<fwereade_> rogpeppe, ok, so we special-case it to be machine 0 then ;p
<dimitern> fwereade_: how about HA state then?
<rogpeppe> dimitern: HA state is fine - we only have this problem at bootstrap
<fwereade_> dimitern, HA state is orthogonal, I still plan to bootstrap one machine and add HA later
<dimitern> ah, ok then
<fwereade_> dimitern, even if it's part of jujud bootstrap itself to add N more machines to state directly
<rogpeppe> fwereade_: ah, i've got an idea
<rogpeppe> fwereade_: the bootstrap init code marks machine 0 with an instance-id "pending"
<rogpeppe> fwereade_: when the provisioner comes up, if it sees machine 0 with "pending" instance id, it fetches it from the provider
<rogpeppe> fwereade_: otherwise i don't see how the machine-0 special casing works
<fwereade_> rogpeppe, not sure about a magic value in that field, I'd kinda rather it be separate
 * dimitern still doesn't quite get why we need to special-case machine-0
<rogpeppe> dimitern: because machine-0 is the *only* place that haven't got the state to write the new instance id to
<fwereade_> dimitern, we can't always know machine 0's instance id before we provision it
<fwereade_> dimitern, and we can't write it to state just after we provisioned it, because there's no state yet
<rogpeppe> fwereade_: yeah, an extra field in Machine would work as well
<dimitern> oh, I see now
<fwereade_> rogpeppe, I'm wondering whether it's actually a property of the environment
<rogpeppe> fwereade_: oh, doh!
<fwereade_> rogpeppe, Environment.BootstrapComplete() (bool, error) ?
<rogpeppe> fwereade_: it's something that can be done by bootstrap-init
<rogpeppe> fwereade_: the provisioner doesn't need to know anything about it
<fwereade_> rogpeppe, hmm
<rogpeppe> fwereade_: i mean bootstrap-state, of course
<fwereade_> rogpeppe, yeah, that's right
<fwereade_> rogpeppe, oh no wait
<fwereade_> rogpeppe, we need the user to have connected once before we have the keys that let us find out the instance id
 * dimitern goes for a run until the argument settles, bbi30m
<fwereade_> rogpeppe, that doesn't matter now
<dimitern> :)
<rogpeppe> fwereade_: hmm, i suppose so. unless the provider can make it available to anyone
<fwereade_> rogpeppe, but might it if the CLI were doing an API connection?
<fwereade_> rogpeppe, I think it's ok to put it in the provisioner anyway -- the locality of reference would help, I think
<rogpeppe> fwereade_: the code would be much simpler if it could go in bootstrap-state, but i'd forgotten about the provisioner keys issue
<fwereade_> rogpeppe, I know it would :(
<fwereade_> rogpeppe, but I honestly think it's not too bad
<fwereade_> rogpeppe, it exists to fix the provisioner
<rogpeppe> fwereade_: yeah, but the muck spreads into quite a few places
<rogpeppe> fwereade_: perhaps we change Machine.InstanceId to return, instead of a bool, one of InstanceIdNotSet, InstanceIdOk or InstanceIdPending, rather than add another bool.
<rogpeppe> fwereade_: then if the provisioner finds machine 0 with InstanceIdPending, it knows where to look
<rogpeppe> fwereade_: and it can then fill in the instance id and carry on as normal
<fwereade_> rogpeppe, it feels quite localized to me anyway though
<rogpeppe> fwereade_: well, it affects the provisioners and the state as well as the provisioner, so not *very* localized :-)
<rogpeppe> s/provisioners/providers/
<fwereade_> rogpeppe, I don't think it even has to affect the providers
<rogpeppe> fwereade_: don't they have to be able to return the instance id for machine 0 ?
<fwereade_> rogpeppe, they all have to list instances on demand, and those instances have an InstanceId method
<mattyw> fwereade_, rogpeppe sorry to interupt, I'm still having problems connecting to the api https://pastebin.canonical.com/88504
<rogpeppe> fwereade_: that doesn't help
<fwereade_> rogpeppe, meaning that we only have to worry about a single mechanism for determining instance id
<rogpeppe> fwereade_: we need to know which of those instances corresponds to machine 0's instance
<rogpeppe> mattyw: OpenID discovery error: HTTP Response status from identity URL host is not 200. Got status 503
<fwereade_> rogpeppe, how are those other instances going to get started without a provisioner? :)
<rogpeppe> fwereade_: bootstrap
<rogpeppe> fwereade_: and possibly by a previous environment
<rogpeppe> fwereade_: if we could assume that we'd only ever get one instance after bootstrap, the problem would be much easier
<fwereade_> rogpeppe, do you mean a previous environment that has not been properly shut down, or just an eventual-consistency phantom?
<rogpeppe> fwereade_: the former.
<fwereade_> rogpeppe, screw that, user error
<fwereade_> rogpeppe, if destroy-environment failed, run it again until it succeeds
<rogpeppe> fwereade_: but eventual consistency could make a properly shut down environment show the same symptom
<TheMue> aaaaaargh (facepalm)
<TheMue> found the failure, only had to move three loc a bit. didn't seen which value differs otherwise in all that debugging output. (hmpf)
<rogpeppe> fwereade_: the scenario that concerns me is when, somehow, the token that signifies that an environment has been bootstrapped has gone (perhaps someone removed all their buckets), so we bootstrap and find all the previous instances.
<fwereade_> rogpeppe, to be utterly explicit, this is when the env reports one terminated machine to be running and one running machine not to exist, right?
<rogpeppe> fwereade_: no, it's when the env reports more than one running instance, only one of which is the bootstrapped instance.
<mattyw> fwereade_, rogpeppe https://pastebin.canonical.com/88504/ should be working again now - it's trouble connecting to the api
<fwereade_> rogpeppe, meh, fail out when len(instances) != 1
<rogpeppe> fwereade_: that is a possibility, yeah. we could mark the bootstrap machine with an error status in that case.
<fwereade_> rogpeppe, not even that
<fwereade_> rogpeppe, just try again later
<rogpeppe> fwereade_: the user needs at least some feedback, otherwise they'd have no idea why "juju deploy" isn't working.
<rogpeppe> fwereade_: or... just don't unprovision any machines in that case, i guess
<fwereade_> rogpeppe, but wait I'm being stupid
<fwereade_> rogpeppe, we *always* set the instance id in the provider storage anyway
<rogpeppe> fwereade_: yes
<fwereade_> rogpeppe, provisioner, as soon as it has keys, calls ensureBootstrapComplete()
<rogpeppe> fwereade_: well, in the existing providers
<rogpeppe> fwereade_: we don't make it available though
<fwereade_> rogpeppe, agreed that without storage we will have a hard time
<rogpeppe> fwereade_: we had plans to move away from that storage in ec2
<rogpeppe> fwereade_: and use instance tags instead
<rogpeppe> fwereade_: ah!
<fwereade_> rogpeppe, well, that would be an alternative solution
<rogpeppe> fwereade_: this is a good reason why generating the env UUID on the client side would be good
<fwereade_> rogpeppe, tagging instances with uuid? yeah
<rogpeppe> fwereade_: yeah
<fwereade_> rogpeppe, it feels to me like storage is the tool we have available now though
<rogpeppe> fwereade_: that's true. but i'd like our solution to work with tags too.
<rogpeppe> mattyw: looking
<fwereade_> rogpeppe, something funny about `invalid entity name ""` given the `info.Tag = "user-admin"`
<rogpeppe> fwereade_: that's what i'm thinking
<rogpeppe> mattyw: is this on go trunk?
<rogpeppe> mattyw: i mean juju-core tip!
<mattyw> rogpeppe, no, it's 2 or 3 days old
<rogpeppe> mattyw: what revid?
<mattyw> rogpeppe, 1060 I think *double checks*
<mattyw> rogpeppe, just to make things worse, it's actually of our own branch https://code.launchpad.net/~cloud-green/juju-core/trunk so we had a stationary target to work on
<rogpeppe> mattyw: that's ok - i'll branch that and have a look
<fwereade_> rogpeppe, anyway, for maximum paranoia we can wait until there is a running instance with an id that matches the one in storage
<rogpeppe> fwereade_: i think just st.Machine("0").SetInstanceId(environ.InstanceIdOfBootstrapMachine()) should be fine
<fwereade_> rogpeppe, ok, sgtm :)
<rogpeppe> mattyw: ok, looks like you're on 1091. have you made any of your own changes to that branch?
<rogpeppe> mattyw: (if not, i'm not quite sure why you merged trunk rather than just pulling it)
<fwereade_> rogpeppe, btw did the terminated-flag-in-conf idea seem to hold water?
<rogpeppe> fwereade_: oh yes, i was meaning to get back to that
<rogpeppe> fwereade_: i'm not sure it eliminates the race entirely
<fwereade_> rogpeppe, hmm. "if there's an instance ID but an independent attempt to log in with my original credentials fails, it's not my instance id, so bomb out with errTerminating; otherwise go ahead and change it"?
<rogpeppe> fwereade_: sounds plausible
<rogpeppe> fwereade_: although a bit more heavyweight than i'd like
<rogpeppe> fwereade_: a simple nonce might be better
<fwereade_> rogpeppe, chosen by provisioner, set on machine, passed through StartInstance?
<rogpeppe> fwereade_: yup
<fwereade_> rogpeppe, nice
<rogpeppe> fwereade_: perhaps have it returned by Machine.SetInstanceId
<rogpeppe> fwereade_: which would increment it
<fwereade_> rogpeppe, we need to pick a nonce before we start the machine
<rogpeppe> fwereade_: doh!
<rogpeppe> fwereade_: just use a random number.
<rogpeppe> fwereade_: if we get the provisioner to pick a random number n when it starts, then n.seqno actually provides useful information about which provisioner (in an HA world) provisioned the machine.
<rogpeppe> fwereade_: and it's a nice consistent link between new machine and the state. i *think* i like it.
<rogpeppe> s/new machine/new instance/ of course
<fwereade_> rogpeppe, I don't follow the "seqno" bit, but if you mean $(provisioner-id)-$(random-number) I'm +1
<rogpeppe> fwereade_: hmm, mind you, the initial password is a pretty good link too
<fwereade_> rogpeppe, a prefix on the random password? that feels a bit off to me
<rogpeppe> fwereade_: i mean $(random-provisioner-id)-$(sequentially-incrementing-number)
<rogpeppe> fwereade_: no, i mean that if you manage to log in with the initial password, you've a pretty good idea that you're talking to the right state.
<fwereade_> rogpeppe, damn lunch
<rogpeppe> fwereade_: enjoy
 * dimitern is back
<mattyw> rogpeppe, no changes, the only reason I haven't pulled is my inexperience with bzr
<rogpeppe> mattyw: sorry, i'll take another look in a mo
<rogpeppe> dimitern: there's already a way of telling the run loop to terminate
<rogpeppe> dimitern: see isFatal in agent.go
<rogpeppe> dimitern: if you return errUnprovisioned and add errUnprovisioned to the isFatal cases, it should all just work.
<rogpeppe> dimitern: ha!
<rogpeppe> dimitern: in fact, just return &fatalError{"machine was not provisioned"}
 * rogpeppe feels a little bit smug
<rogpeppe> mattyw: are you bootstrapping with the same version as you're compiling your client against?
<dimitern> just finished reading through  the log
<dimitern> rogpeppe: sgtm, nicer
<dimitern> rogpeppe: unfortunately it doesn't work
<rogpeppe> dimitern: oh?
<dimitern> rogpeppe: isFatal is checked after we're in runLoop
<rogpeppe> dimitern: and?
<dimitern> rogpeppe: so it won't solve the issue about messing up the password by a bad machine
<rogpeppe> dimitern: the password is changed inside runOnce
<rogpeppe> dimitern: erm... i think :-)
<rogpeppe> dimitern: yeah
<dimitern> rogpeppe: istm it's in openState:SetMongoPassword
<rogpeppe> dimitern: yup
<rogpeppe> dimitern: and what's openState called by?
<dimitern> rogpeppe: by RunLoop's callback in runagentloop
<rogpeppe> dimitern: which is called?
<dimitern> rogpeppe: so it's too late then
<rogpeppe> dimitern: i don't think so
<rogpeppe> dimitern: runOnce calls openState
<dimitern> rogpeppe: why not just have Entity return a fatalError instead and add it to the conditions?
<rogpeppe> dimitern: what conditions?
<dimitern> 	if state.IsNotFound(err) || err == nil && entity.Life() == state.Dead { err = worker.ErrDead }
<dimitern> in openState
<dimitern> make that || isFatal(err) || ... and all done
<rogpeppe> dimitern: there's no point in doing that
<rogpeppe> dimitern: if the err is not nil, it returns in
<rogpeppe> s/in/it
<rogpeppe> dimitern: on the next line
<dimitern> rogpeppe: that's ater
<dimitern> rogpeppe: yeah, the first if is what i'm aiming for
<rogpeppe> dimitern: you want openState to return ErrDead?
<dimitern> rogpeppe: it already does, doesn't it?
<rogpeppe> dimitern: yeah, or a fatalError if Entity returns that
<dimitern> rogpeppe: ok, it seems I'm not explaining myself well enough
<dimitern> rogpeppe: err = worker.ErrDead is what I want to be the case, just like the other conditions, where the machine is missing or dead
<dimitern> rogpeppe: this causes the next if to return ErrDead
<dimitern> rogpeppe: and kills the worker before setting the password or anything bad happens
<rogpeppe> dimitern: even if you return a fatalError, the worker will be killed before that
<rogpeppe> dimitern: but...
<rogpeppe> dimitern: there's something to be said for returning ErrDead, because then the agent exits and never restarts
<dimitern> rogpeppe: yeah, actually.. but the test fails
<dimitern> rogpeppe: look at this http://paste.ubuntu.com/5679464/
<rogpeppe> dimitern: are you saying you're returning a *fatalError from Entity and the agent isn't exiting?
<dimitern> rogpeppe: this test succeeds when I used errUnprovisioned and checked for it in the first if, with fatalError it fails, saying it's still running
<rogpeppe> dimitern: could you paste your Entity implementation, please?
<dimitern> rogpeppe: http://paste.ubuntu.com/5679472/
<dimitern> rogpeppe: and now I'm getting "timed out waiting for agent to finish; stop error: <nil>" in the assert after runAgentTimeout
<mattyw> rogpeppe, no, I'm not bootstrapping using the same version
<rogpeppe> dimitern: hmm, that's weird.
<rogpeppe> dimitern: it *should* work. could you push your branch?
<dimitern> rogpeppe: ok, just a sec
<rogpeppe> mattyw: are you bootstrapping with a newer version, by any chance?
<rogpeppe> mattyw: the API has recently changed in a backwardly incompatible way
<mattyw> rogpeppe, I don't think so. My juju command is 1.9.12-precise-amd64
<rogpeppe> mattyw: in general, while we're developing stuff fast, you need to run exactly the same version of client and server.
<mattyw> rogpeppe, ok. I'll try that
<rogpeppe> mattyw: you can use juju bootstrap --upload-tools
<rogpeppe> mattyw: but currently any charms you deploy have to be from the same series as your local machine
<mattyw> rogpeppe, I forget, I've had a lot of problems trying to bootstrap at all recently
<rogpeppe> mattyw: every time you see a problem, add a bug!
<mattyw> rogpeppe, they're the same series
<mattyw> rogpeppe, I do :)
<dimitern> rogpeppe: lp:~dimitern/+junk/machine-agent-status
<rogpeppe> mattyw: (or add to an existing bug if it seems the same)
<rogpeppe> dimitern: ta
<mattyw> rogpeppe, is there a version of the repo you'd recomend running against at the moment?
<rogpeppe> mattyw: i'd try and keep in sync with tip, though it's a pain
<dimitern> rogpeppe: hmm.. for some reason the old change got pushed, not the one with fatalError
<rogpeppe> dimitern: perhaps you didn't commit
<dimitern> rogpeppe: ouch :( haven't saved it in emacs
<dimitern> rogpeppe: sorry, let me try again
<rogpeppe> dimitern: ah, that might have something to do with it!
<dimitern> rogpeppe: now it works with fatalError, sorry for the noise
<rogpeppe> dimitern: np. i was a bit confused :-)
<rogpeppe> dimitern: but...
<dimitern> rogpeppe: the only change is I needed to change the assert to check for the error after runAgentTimeout
<rogpeppe> dimitern: having said that...
<rogpeppe> dimitern: i'm wondering if you should return ErrDead anyway
<dimitern> rogpeppe: maybe upstart will mess it up if it's not ErrDead and restart it?
<rogpeppe> dimitern: exactly
<fwereade_> rogpeppe, mattyw: FWIW I landed --fake-series yesterday
<fwereade_> rogpeppe, mattyw: it seemed to work for me
<rogpeppe> dimitern: in fact, that's precisely the behaviour we *want* when upgrading
<rogpeppe> fwereade_: \o/
<dimitern> rogpeppe: ok, ErrDead it is then - directly from the Entity()
<fwereade_> rogpeppe, mattyw: `juju bootstrap --upload-tools --fake-series precise,quantal`
<dimitern> rogpeppe: or fatalError + isFatal() in the if -> ErrDead?
<rogpeppe> dimitern: i think so. although it's kind of a lie.
<fwereade_> rogpeppe, I'm -1 on reusing ErrDead
<rogpeppe> dimitern: nononono
<fwereade_> rogpeppe, it means something specific
<mattyw> rogpeppe, ok thanks, what does --upload-tools actually do?
<rogpeppe> fwereade_: yes
<dimitern> so we're back on errUnprovisioned :)
<rogpeppe> fwereade_: i think we're just using ErrDead as a convenience
<rogpeppe> fwereade_: i think we can change all instances of ErrDead to ErrDeadOrInvalid
<fwereade_> rogpeppe, dimitern: what's wrong with errTerminating? the top-level Run can set the conf to terminated and return nil; other conditions that indicate we should stop, like ErrDead, can do the same
<fwereade_> rogpeppe, call it ErrTerminateAgent and I'm fine
<rogpeppe> fwereade_: what do you mean by "set the conf to terminated"?
 * dimitern an there goes another 20m for 2 lines of code ;)
<fwereade_> rogpeppe, I mean, set a flag meaning "don't even try" that we can check on startup
<rogpeppe> fwereade_: why bother?
<dimitern> I'm fine to call it errTerminated instead of errUnprovisioned, although the former seems not quite right - do you intend to reuse it for something else?
<rogpeppe> dimitern: i think i'd have type terminalError {err string}
<rogpeppe> dimitern: then the message printed by the agent when exiting can be accurate
<dimitern> rogpeppe: lethalCase{} ? :D
<fwereade_> dimitern, I'm saying that Run at the top level should have a single error that it treats as "return nil, causing upstart to stop bothering"
<rogpeppe> fwereade_: agreed. currently that's just ErrDead.
<dimitern> fwereade_: we don't even have to get to run
<fwereade_> rogpeppe, maybe we don't, let me reload state
<rogpeppe> fwereade_:  but we'd change that to check for *terminalError
<rogpeppe> fwereade_: ah! it does need to check for ErrDead too
<rogpeppe> fwereade_: because that's what the workers return if the machine is dead.
<fwereade_> rogpeppe, yeah, exactly
<rogpeppe> fwereade_: but tbh why not just reuse it?
<rogpeppe> fwereade_: we're adding more code for a marginal case
<fwereade_> rogpeppe, I'm fine having the workers who need to return ErrTerminateAgent, I'm not so fine having an unprovisioned machine return ErrDead
<rogpeppe> fwereade_: the machine might as well be dead as far as the agent is concerned
<rogpeppe> fwereade_: ok, i'd be happy with that
 * rogpeppe has lunch
<fwereade_> rogpeppe, cool, cheers
<dimitern> fwereade_: how about having a isDeadOrTerminated(err) checking for both ErrDead and ErrTerminated and is it in place of err == ErrDead checks?
<fwereade_> dimitern, I'm just saying s/ErrDead/ErrTerminateAgent/ throughout
<dimitern> fwereade_: actually, I can just add ErrTerminateAgent and return in from Entity, make it work like ErrDead wrt upstart and draw the line there, changing all the workers can be a follow-up
<fwereade_> dimitern, forget ErrDead
<fwereade_> dimitern, a single magic value meaning "stop and don't come back" is all I'm really thinking about here
<fwereade_> dimitern, ErrDead exists, and is perfect, except it has the wrong name
<dimitern> fwereade_: i'm not comfortable changing something without knowing the repercussions
<fwereade_> dimitern, fix the name and we're fine :)
<dimitern> fwereade_: what is ErrDead used for - in all cases?
<dimitern> (for workers)
<fwereade_> dimitern, it is used, in all cases, to indicate that the running agent should exit 0
<dimitern> fwereade_: well, if it's only that, the renaming makes sens
<dimitern> sense
<fwereade_> dimitern, cool
<fwereade_> sorry, I definitely didn't communicate correctly
<dimitern> fwereade_: I'll do it as a prereq though, since it's trivial
<fwereade_> dimitern, sgtm -- but just to sync up, can we have a quick hangout?
<mattyw> rogpeppe, that seems to be working now thanks :)
<rogpeppe> mattyw: cool. sorry about that - it's been a problem for loads of people, because we're changing things in a backwardly incompatible way all the time without changing the major version number
<rogpeppe> mattyw: but that's dev versions for ya!
<mattyw> rogpeppe, one quick odd question
<rogpeppe> mattyw: ok
<mattyw> when a unit gets removed we get a unitinfo back with all the status about that unit? Is the plan to stay like that? The reason I ask is that in the pyjuju 'api' when a unit is removed we only get told the unit name of the removed unit
<rogpeppe> mattyw: yeah, it should stay like that.
<rogpeppe> mattyw: although it's kind of an unintended consequence of the way things are implemented
<mattyw> rogpeppe, ok thanks, some of my favourite consequences are the unintended ones
<mattyw> rogpeppe, once the api ships I guess any change we'll get told about?
<rogpeppe> mattyw: yup
<mattyw> rogpeppe, that's fine for me. When vds and I have a few more tests It would be good if you could take a look, will probably be next week though
<rogpeppe> mattyw: sure
<rogpeppe> fwereade_: do you know the PPA/name of the SSL-capable mongod package, by any chance?
<fwereade_> rogpeppe, sorry, I'm afraid not -- I always just grabbed it from the bucket and stuck in on $PATH
<rogpeppe> fwereade_: yeah, i did too. i'm trying to put some instructions together so that people can try to reproduce the go-runtime errors i've been seeing
<rogpeppe> fwereade_: and i seemed to remember someone had packaged mongod
<rogpeppe> fwereade_: i guess i'll just say "grab the bucket contents"
<rogpeppe> niemeyer: hiya
<dimitern> fwereade_, rogpeppe: ErrDead -> ErrTerminateAgent https://codereview.appspot.com/8416043
<fwereade_> dimitern, LGTM trivial
<dimitern> fwereade_: cheers
<rogpeppe> niemeyer: https://codereview.appspot.com/8367044 (not that it helped, in fact, but worth doing anyway)
<teknico> rogpeppe, you're possibly looking for https://launchpad.net/~julian-edwards/+archive/mongodb/+packages
<rogpeppe> teknico: thanks
<rogpeppe> teknico: though i've just gone with directing people to the public bucket for now
<rogpeppe> teknico: (with an accompanying sha1 sum)
<niemeyer> rogpeppe: Rob spent a good while last night looking at the issue
<niemeyer> rogpeppe: I've helped them setting up a juju environment so they could reproduce the issue
<niemeyer> rogpeppe: He wrote down notes by the end of his day, and I suppose Dmitry moved it on
<rogpeppe> niemeyer: thanks for that
<niemeyer> rogpeppe: np, let's hope good stuff comes out of it
 * rogpeppe crosses his fingers
<dimitern> cloudinit tests are a proper pain to change
<rogpeppe> dimitern: if you can think of a better way...
<rogpeppe> dimitern: they're better than they used to be
<rogpeppe> dimitern: a little script could probably help actually
<dimitern> :) i'm not sticking my finger in there any more than I need to for now
<rogpeppe> mgz: hey mr on-call :-) a quick trivial branch for you (code move only) https://codereview.appspot.com/8422043
<mgz> looking
<mgz> mega over usage :)
<mgz> are file-level comments a thing in go?
<rogpeppe> mgz: well, yeah
<rogpeppe> mgz: yes, we can do that though we tend not to
<mgz> like, triple quote at top of module saying roughly what it's about?
<mgz> or is the pre-function ///
<rogpeppe> mgz: usually the type declaration at the top gives a good idea
<mgz> // funcName
<mgz> the only special magic that the doc generation picks up on?
<rogpeppe> mgz: file-level comments are ignored by the doc tools
<mgz> thanks
<rogpeppe> mgz: that and comments just before the package decl
<rogpeppe> mgz: the doc tool picks up comments attached directly to top level declarations, essentially
<mgz> lgtm'd
<rogpeppe> mgz: ta!
<mgz> dimitern: ^if you have a moment and if rog wants two reviews
<rogpeppe> mgz: i'm not sure that i can say much in a file-level comment that the type decl and doc comment at the top don't already say
<rogpeppe> mgz: i think i'll leave it as is if that's ok
<mgz> that's a fair enough answer for one-struct files I think
<mgz> which this isn't quite, but nearly :)
<dimitern> mgz: oh, the reviewer showed up ;)
<mgz> I was expecting pokes
<dimitern> let me read through the log
<mgz> browsing randomly for stuff to do is painful with rietveld...
<mgz> dimitern: just click the codereview link, it's pretty clear
<dimitern> mgz: it is, but fortunately fwereade is keeping +activereviews neat now
<dimitern> looking, but it's submitted already
<mgz> that answers clause #2 then :)
<dimitern> what's clause #2?
<mgz> if rog wanted another review
<rogpeppe> mgz, dimitern: here's another fairly trivial one: https://codereview.appspot.com/8294044/
<dimitern> rogpeppe: just opened it while you're writing :)
<mgz> gaba?
<mgz> leading underscore?
<rogpeppe> mgz: python-style :-)
<mgz> so, as a hint internal to the package past the caps-vs-nocaps exposure?
<rogpeppe> mgz: yeah
<mgz> I guess that seems reasonable
<rogpeppe> fwereade: what do you think?
<dimitern> rogpeppe: why do you need this?
<fwereade> rogpeppe, that sounds sensible to me
<fwereade> dimitern, because package-level-only encapsulation is scary as hell once you're past... say... 1 file per package ;)
<rogpeppe> dimitern: because i'm essentially exposing the allInfo type as an API to the backing type. some methods are not supposed to be called by the backing.
<dimitern> rogpeppe: sure, but what will this solve?
<rogpeppe> dimitern: it just makes it easy to verify that the backing is only calling expected methods
<rogpeppe> dimitern: and if you call a _method from outside the type itself, you'll probably think twice
<dimitern> rogpeppe: how about putting really internal stuff in a subpackage?
<rogpeppe> dimitern: i'm not sure. it seems very intertwined with the allWatcher implementation
<rogpeppe> dimitern: and that need to be internal to state, i *think*.
<dimitern> rogpeppe: this *could* indicate code smell, but otherwise I'm fine with it
<rogpeppe> dimitern: actually, i think you're perhaps right - the allWatcher can trivially be moved into its own package.
<rogpeppe> dimitern: while the backing implementation remains inside state
<dimitern> rogpeppe: sgtm
<dimitern> fwereade, rogpeppe: machine nonce introduced https://codereview.appspot.com/8247045/
<rogpeppe> dimitern: cool; will look soon.
<rogpeppe> dimitern: actually, i'm not sure, peer reviews need doing by the end of day
<rogpeppe> dimitern: and i haven't done any yet
<dimitern> rogpeppe: what do you mean?
<rogpeppe> dimitern: the allhands stuff
<dimitern> rogpeppe: ah, yeah - I've done mine on the day
<rogpeppe> dimitern: v sensible!
<dimitern> rogpeppe: I know myself how forgetful I can get, so I try to cheat and do it right away, so I can forget it comfortably :)
<rogpeppe> dimitern: that's not cheating, that's the right thing to do!
<dimitern> rogpeppe: yeah, i meant cheating the lazyness :)
<fwereade> TheMue, reviewed
<fwereade> dimitern, why is MachineNonce required in Conf?
<dimitern> fwereade: that's what I asked earlier - should it be or not
<dimitern> fwereade: but I think it's better to be required and add tests for it
<dimitern> next one coming - state support for nonce provisioning - https://codereview.appspot.com/8429044/
<fwereade> dimitern, sorry, I thought you meant in state
<fwereade> dimitern, but it shouldn't be required for agent.Conf -- that has to work for unit agents too
<dimitern> fwereade: oops, I mean *environs*
<fwereade> dimitern, cool
<dimitern> fwereade: so no tests then? only in cloudinit perhaps\
<fwereade> dimitern, in cloudinit sounds good
<dimitern> fwereade: this will simplify things a lot
<fwereade> dimitern, and you should at least check that a Conf can be read/written both with and without a MachineNonce
<dimitern> fwereade: wasn't quite sure it'll be enough, but it's better to cut than to add ;)
<dimitern> fwereade: you mean add a no-error test with machinenonce in?
<dimitern> fwereade: and one without
<fwereade> dimitern, yeah, so really leave the rest and just add a single test that includes it I think
<dimitern> fwereade: deal
<dimitern> fwereade: i'm starting on state now
<rogpeppe> dimitern: allwatcher now factored into its own package. the tests weren't entirely trivial, but altogether fairly painless
<dimitern> rogpeppe: great to hear!
<niemeyer> rogpeppe: You mentioned yesterday that you reproduced the bug on socket.Acquire even after the fix was made, right?
<rogpeppe> niemeyer: yes
<niemeyer> rogpeppe: Okay, cool
<niemeyer> rogpeppe: Just want to make sure I'm not on crac
<rogpeppe> niemeyer: all the panics in my last post on that issue were with that fix made
<niemeyer> k
<rogpeppe> niemeyer: yeah, i've spent a fair amount of time trying to convince myself of the same thing
<niemeyer> rogpeppe: Oh, might be worth mentioning it in that thread
<niemeyer> rogpeppe: Were the tracebacks made with the rpc trick too?
<rogpeppe> niemeyer: yes
<rogpeppe> niemeyer: (i did mention that actually)
<niemeyer> rogpeppe: Yeah, it was Rob that seemed unaware in the thread
<fwereade> dimitern, reviewed
<dimitern> fwereade: tyvm
<niemeyer> fwereade: FYI, juju publish will be up for review in a few
<fwereade> niemeyer, awesome, sorry I've been lagging a bit on your reviews
<niemeyer> fwereade: It's fine.. I have all reviewed right now
<niemeyer> fwereade: Just have to submit
<niemeyer> fwereade: And the main piece is coming up in a moment
<fwereade> niemeyer, ah, fantastic :)
<niemeyer> fwereade: I still want to add a few features, but I want to get the core in before that
<fwereade> niemeyer, +1 :)
<dimitern> fwereade: why should CheckProvisioned(nonce) return an err ever? m.doc.Nonce == nonce should be enough, I think
<fwereade> dimitern, ha, yes, I'm on crack
<dimitern> fwereade: and it's because it can't be ever changed it'll either be that or emtpy
<dimitern> fwereade: so, perhaps m.doc.Nonce == nonce && nonce != ""
<fwereade> dimitern, but do check that InstanceId != "" as well, or make sure there's no way for it not to be (did we agree to panic on SetProvisioned with "" id?)
<dimitern> fwereade: yeah, already taken care of in SetProvisioned
<fwereade> dimitern, but you're absolutely right that we don't need to hit the network for that, cheers
<dimitern> fwereade: notTheSame := D{{"instanceid", D{{"$nin", []InstanceId{"", id}}}}}
<dimitern> fwereade: that's the extra assert in SetProvisioned
<dimitern> fwereade: and it has corresponding bunch of errAborted handling (i'm proud :) )
<fwereade> dimitern, I look forward to seeing it :)
<fwereade> although, everybody, I'm off for a bit now
<fwereade> I'll probably be back at some stage, I'm up to my elbows in environs again, but I'm out of go-juice ATM
<fwereade> happy weekends to those I miss
<dimitern> fwereade: you too!
<rogpeppe> it's that time of day. happy weekend to all and sundry
<TheMue> fwereade, rogpeppe: have a nice weekend
<TheMue> fwereade: will propose the latest changes later
<dimitern> rogpeppe, TheMue: both of you too ;)
<TheMue> dimitern: enjoy the spare time to recreate
<dimitern> TheMue: oh, i do, especially lately
<TheMue> so, final propose is in, time for the weekend. bye
#juju-dev 2013-04-07
<hazmat> anybody around..
<hazmat> i'd liike some vetting of my approach for deploy-to
<hazmat> in core
<fwereade_> hazmat, heyhey
<fwereade_> hazmat, didn't know you were planning to grab that, but I'm delighted if you are :)
<hazmat> fwereade_, twas assigned to me friday, and i did say i'd take it up.. so yeah.. diving in.
<hazmat> fwereade_, do you have a minute for a g+?
 * hazmat preps a diff
<fwereade_> hazmat, sure
<hazmat> fwereade_, here's a diff of the approach.. http://paste.ubuntu.com/5686584/
<hazmat> fwereade_, https://plus.google.com/hangouts/_/1a13f8d6e06fde8d8ce9f9f4a1219b62f75ee409?authuser=0&hl=en
<thumper> oh ffs
<thumper> trunk tests failing for me
<thumper> gah, in two places...
<thumper> hi davecheney
<thumper> davecheney: how are you doing?
<thumper> davecheney: as usual, I have questions :)
<davecheney> thumper: and you believe I have answers ?
<thumper> davecheney: for some at least :)
<davecheney> this is becoming increasingly untrue
<thumper> davecheney: firstly...
<thumper> davecheney: can I get you to pull trunk,
<davecheney> science says that you cannot be just an observer in a system, you are also a participant
<thumper> davecheney: and cd into the bzr package and run the tests
<davecheney> thumper: sure
<davecheney> two secs
<thumper> davecheney: I'm guessing it will fail
<davecheney> yeah, i saw that proposal
<davecheney> well, read the title
<davecheney> ... testing
<thumper> if it fails, then go `bzr merge lp:~thumper/juju-core/fix-bzr-test` and rerun the test
<davecheney> getting regex match
<davecheney> this whole multiple series thing is getting me down
<davecheney> either we all use one series
<davecheney> or we need build bots on every series
<thumper> davecheney: so you're tests pass/
<thumper> ?
<davecheney> they do not pass
<davecheney> match == fail
<thumper> ah..
<davecheney> bzr_test.go:69: c.Assert(string(output), Matches, "(?s).*revision-id: "+revid+"\n.*message:\n.*my log message\n.*added:\n.*myfile .*")
<davecheney> ... value string = "" +
<thumper> ok, can you merge my branch and rerun
<thumper> I'm happy to merge a test failure like this with one approval :)
<thumper> s/test failure/test failure fix/
<davecheney> thumper: tests pass
<davecheney> LGTM, please submit
<thumper>  https://codereview.appspot.com/8500043/
<thumper> wanna mark that
<thumper> and I'll submit
<davecheney> done
<thumper> submitting
<thumper> davecheney: worker/uniter/context.go around line 142
<thumper> davecheney: it seems to me that we are closing the outWriter pipe before waiting for the process to finish
<thumper> davecheney: this looks suspicious to me
<thumper> davecheney: am I missing something, or does it look weird to you too?
<thumper> my first assumption is that I'm missing something
<davecheney> thumper: that is the subject of literally months of arguing
<thumper> ah... wat?
<davecheney> beforewarned that digging in there involves interfacing deeply with roger and willam
<davecheney> thumper: are you fixing a test failure bug ?
<thumper> what was the arguing?
<davecheney> that one comes up over and over again
<davecheney> thumper: about the correct way to fix it
<thumper> davecheney: no, I was looking around the serialisation of hook execution on a machine
<thumper> so reading the uniter code
 * davecheney finds the bug
<davecheney> (s)
<thumper> I'm wonering why if this was after a long time of arguing, why there is no comment there
<davecheney> because most of our arguments end in a stalemate
 * thumper cracks open a can of worms
<thumper> davecheney: do you know the area of code where multiple hooks can be executed at one time?
<thumper> it seems to be related to subordinates
<davecheney> and this causes deadlocks on the apt cache etc ?
<davecheney> isn't this william's 'serialized hook execution'
#juju-dev 2014-03-31
<wallyworld_> thumper: pingy
<thumper> wallyworld_: hey
<wallyworld_> thumper: i'd like to be able to land the joyent provider code as i think william wants it in my tomorrow
<wallyworld_> i have it working
<wallyworld_> http://165.225.148.189/wp-admin/install.php
<wallyworld_> but it's a huuuuuuge branch
<wallyworld_> since it has been developed all in one go
 * thumper nods
<wallyworld_> and i've taken what was there and modified it so it works
<thumper> how much outside provider/joyent is there?
<wallyworld_> none
<thumper> ok, lets do it
<wallyworld_> i have another branch i'm doing
<wallyworld_> which does outside work
<wallyworld_> fixes some other stuff
<thumper> ok
<thumper> can we land it but not enable for the first cut?
<thumper> that way we can still release 1.18 off trunk
<thumper> but the code is a least there
<wallyworld_> thumper: yes, i want to land https://codereview.appspot.com/82050043/
<wallyworld_> and i will have the other work done today
 * thumper looks
<wallyworld_> which will allow the provider to work as per the link i pasted above
<thumper> do you want a real review
<thumper> or a cursory look?
<wallyworld_> the latter :-)
<thumper> heh
<wallyworld_> i know there's stuff to do
<thumper> ok
<wallyworld_> but we can iterate
<thumper> agreed
<wallyworld_> i have clean uop a lot
<wallyworld_> but i ran out of steam
 * thumper looks
<wallyworld_> a lot of the work is not mine
<wallyworld_> i branched off daniel's work and did stuff to get it going
<davecheney> wallyworld_: thumper i say if it commits cleanly an the bot gives it the green light
<davecheney> commit it
<wallyworld_> davecheney: and it works :-) http://165.225.148.189/wp-admin/install.php
<davecheney> wallyworld_: LGTM
<davecheney> lets get it landed
<wallyworld_> davecheney: also, i added a comment to the RT cause outgoing ssh did not work for me
<davecheney> wallyworld_: balls
<wallyworld_> i tried from rockne-03 with no luck
<davecheney> wallyworld_: we might have to put the breaks on that
<davecheney> arosales: said I should work on local and manual providers
<davecheney> and I guess maas
<davecheney> because those are what we would use to demo ppc
<wallyworld_> ok, i think ppc will work fine, just want to verify
<davecheney> wallyworld_: same
<davecheney> i want to verify as well
<davecheney> but i've been told a few times now not to proritise it
<wallyworld_> so i'm not doing any dev work as such, just testing
<davecheney> so I sohuld be smart and start listening
<wallyworld_> thats what my wife says
<wallyworld_> but less politely
<davecheney> wallyworld_: your wife sounds smart
<wallyworld_> she is, but not so smart she didn't marry me
<thumper> davecheney: are there bugs filed for the failing power tests?
<davecheney> thumper: i am raising them as I work on them
<thumper> ok, how many failures do we have?
<davecheney> thumper: i don't have an exact cound
<davecheney> less than we had last week
<davecheney> please hold
<davecheney> doing a test run at the moment
<axw> wallyworld_: in case you haven't seen this already: #1299802
<_mup_> Bug #1299802: upgrade-juju 1.16.6 -> 1.18 (tip) fails <juju-core:New> <https://launchpad.net/bugs/1299802>
<wallyworld_> oh :-( hadn't seen that
<axw> looks like an upgrade steps thing, maybe
<wallyworld_> could be, i'd have to trawl through the log
<wallyworld_> i think if something fails, the desired version remains as it was
<axw> ah ok
<davechen1y> _thumper_: http://paste.ubuntu.com/7182728/
<davechen1y> current state of play
<davechen1y> _thumper_: https://bugs.launchpad.net/juju-core/+bug/1299958
<_mup_> Bug #1299958: worker/peergrouper: test failure <ppc64el> <juju-core:Triaged by dave-cheney> <https://launchpad.net/bugs/1299958>
<davechen1y> working on this one now
<davechen1y> _thumper_: the big difference between gccgo/amd64 failures and gccgo/ppc64 failures is there are no test fixtures for ppc64
<davechen1y> _thumper_: I will raise an issue for this by COB
 * _thumper_ nods
<axw> wallyworld_: sorry, what was that branch again?
<wallyworld_> axw: lp:~wallyworld/uju-core/remove-provider-addr-methods
<mwhudson> davechen1y: hello, would it be more useful to run juju tests on arm64 from the latest release or bzr tip?
<axw> ta
<mwhudson> davechen1y: also, is the fix for that test linking bug in trusty yet?
<mwhudson> hm seems like it should be
<mwhudson> why am i still seeing linker errors then :(
<thumper> davechen1y: just proposing a fix for the bzr test failure
<thumper> davechen1y: https://codereview.appspot.com/82250045
<davechen1y> thumper: /me looks
<davechen1y> mwhudson: make sure you have gccgo-go 1.2.1
<davechen1y> then you're good
<davechen1y> thumper: +1
<thumper> axw: do you think your logging dir config changes would have fixed this: https://bugs.launchpad.net/juju-core/+bug/1298663 ??
<_mup_> Bug #1298663: juju debug-log broken in 1.17.6 <debug-log> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1298663>
 * axw looks
<axw> thumper: yeah I think so
<axw> thumper: I will find the bug and set as dupe
<mwhudson> $ dpkg-query -W gccgo-go
<mwhudson> gccgo-go        1.2.1-0ubuntu1
<davechen1y> mwhudson: yup
<davechen1y> there is one package that still fails to link
<davechen1y> it's on my list
<mwhudson> ok
<mwhudson> davechen1y: is your list online somewhere?
<davechen1y> mwhudson: i email it daily to a shittone of people
<mwhudson> davechen1y: feel free to add me to the list :-)
<davechen1y> mwhudson: https://docs.google.com/a/canonical.com/document/d/1aKWR3kDzS5Og6PXxe9m98Xea75ScVrGWIZ95rSQIdTM/edit
<davechen1y> all bugs are tracked in lp
<davechen1y> there is no separate bug list
<davechen1y> the list of bugs tracked in lp is not exhaustive
<mwhudson> thanks
<davechen1y> thumper: https://bugs.launchpad.net/juju-core/+bug/1299969
<_mup_> Bug #1299969: launchpad.net/juju-core/provider/manual: ssh tests are not properly isolated <ppc64el> <juju-core:Triaged> <https://launchpad.net/bugs/1299969>
<davechen1y> looks similar to the bzr bug
<axw> wallyworld_: we should be able to remove public/private address from the unit doc too, right?
<axw> wallyworld_: if we always wait for the machine to have addresses first
<wallyworld_> axw: yeah, when we can support schema changes
<axw> wallyworld_: true. we can just ignore it for now I suppose
<axw> though it is already, if the machine has addresses
<wallyworld_> yeah, i was going to remove the api first
<axw> sounds good
<wallyworld_> the thing i'm up against now - can subordinate units have addresses?
<wallyworld_> i'd like to say no
<wallyworld_> will make the refactoring simpler, otherwise i'll need to add a bunch of extra code
<axw> wallyworld_: from the docs, "Subordinate units inherit the public/private address of the principal service."
<axw> how that's implemented I don't know
<wallyworld_> it uses the provider addresses
<wallyworld_> the ones i want to delete
<wallyworld_> which is kinda sucky
<axw> I mean how the subordinate inherits from the principal...
<axw> same machine, so it'll just work I guess
<axw> wallyworld_: where's that code?
<wallyworld_> yeah, but the current assumption is the provider.PublicAddress() works
<wallyworld_> state/unit.go
<axw> wallyworld_: right, but there's nothign special about subordinates there... is there somewhere else?
<axw> wallyworld_: what extra code do you need to land?
<wallyworld_> sec
<wallyworld_> axw: i think it's in worker/unit/modes.go which calls unit.SetPrivateAddress() which it gets from the provider
<axw> wallyworld_: we may be able to get away without waiting for addresses. you may need to check with fwereade or someone else
<axw> wallyworld_: yeah but what's special about subordinates there?
<axw> wallyworld_: they still live on a machine, and they'll still get their addresses from the machine
<wallyworld_> axw: nothing, but that's how subords get the unit doc address set
<axw> that's only used if its machine doesn't have addresses
<wallyworld_> axw: the unitDoc for sub ords has machne id = ""
<axw> oh
<axw> right
<wallyworld_> so the machineAddresses() bt fails
<axw> so, we need to use its principal's machine rather
<wallyworld_> so i need to look up the principal unit
<wallyworld_> but the state apis return no error :-(
<axw> no error for what?
<wallyworld_> so i have to do it at the api level or chaneg the method
<wallyworld_> PrivateAddress()
<wallyworld_> so if i want to look up princiap unit, get assigned machine etc, i need to cater for errors
<axw> nor does addressesOfMachine if Machine() errors at the moment
<axw> I don't think this is any worse
<wallyworld_> true, still sucks though :-(
<wallyworld_> but yeah
<arosales> davechen1y: thanks for the for the work on manual
<wallyworld_> arosales: http://165.225.148.189/wp-admin/install.php
<arosales> wallyworld_: thanks for landing the joyent provider
<mwhudson> 105 of 141 launchpad.net/juju-core/... package tests fail :/
<arosales> wallyworld_: is that off joyent?
<wallyworld_> yep :-D
<arosales> wallyworld_: woot \o/
<arosales> well done
<arosales> wallyworld_: any work arounds in place or can I have folks start testing?
<wallyworld_> got a few follow up branches to land to fix juju core stuff
<arosales> ah ok
<arosales> wallyworld_: good stuff
<wallyworld_> arosales: i'll land the stuff by today or tomorrow
<arosales> wallyworld_: give me a mail when trunk is ready for general testing
<arosales> wallyworld_: thanks
<wallyworld_> sure, welcome
 * arosales returns to dinner
<axw> wallyworld_: in addressesOfMachine, you can just use AssignedMachineId instead of u.doc.MachineId
<axw> that'll do the right thing for subordinates
<wallyworld_> yeah
<axw> wallyworld_: deployed a charm to azure, it got addresses
<axw> wallyworld_: anything in particular you want me to test?
<wallyworld_> axw: nah, just a smoke test, that's great thanks
<wallyworld_> lots of code to delete \o/
<mwhudson> although
<mwhudson> (t-mwhudson)mwhudson@am1:~/juju-core-1.17.7$ date
<mwhudson> Thu May  7 09:01:27 UTC 2150
<mwhudson> ^ this may be responsible for some of the failures
<axw> wallyworld_: yeah, looks like a nice branch :)
<wallyworld_> will get better :-)
<davechen1y> mwhudson: sad trombole
<mwhudson> davechen1y: yay shared porter hardware
<davechen1y> da f
<davechen1y> 2150
<davechen1y> unix time goes that high ?
<davechen1y> well, I guess an int is 8 bytes big
<davechen1y> on mar64
<davechen1y> on arm64
<mwhudson> yeah, i guess it does on arm64?  i have no idea what this is about
<davechen1y> hyperactive real time clock
<mwhudson> fixing that makes 30 more packages' tests pass
<mwhudson> hmmf, lots of this:
<mwhudson> panic: runtime error: invalid memory address or nil pointer dereference [recovered]
<mwhudson>         panic: runtime error: invalid memory address or nil pointer dereference
<mwhudson> [signal 0xb code=0x1 addr=0xa0]
<mwhudson> which is a bit of a worry
<mwhudson> oh, it's some pointer being null inside mgo
<mwhudson> oh heh, helps to have juju-mongodb installed i imagine
<mwhudson> bah
<wallyworld_> thumper: thanks for review. i can land disabled for now but when i propose the followup branch to fix the juju-core address issue i should enable then as 1. i've been asked to get it into trunk so people can test 2. it's ment to go into 1.18
<mwhudson> hm, where do logger.Debugf messages end up when running tests?
<thumper> wallyworld_: ok
<thumper> mwhudson: into the gocheck log
<thumper> mwhudson: assuming that you are using something that has the LoggingSuite contained
<mwhudson> thumper: which is ... ?
<mwhudson> running with -gocheck.vv doesn't make anything appear
<mwhudson> is it going into some file somewhere?
<thumper> no, the log is only shown if a test fails
<mwhudson> well it's panicking?
<mwhudson> does that count?
<thumper> mwhudson: hmm...
 * thumper looks at the code
<thumper> mwhudson: c.GetTestLog()
<thumper> mwhudson: returns a string
<mwhudson> uh
<mwhudson> thumper: thanks
<mwhudson> although i think this is a silly bug
<mwhudson> http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/testing/mgo.go#L112 <- this debugf only makes sense if there was no error right?
<mwhudson> i.e. it should be in an } else { from the preceding test
<mwhudson> because if inst.server is null it goes bang
<mwhudson> err
<mwhudson> oh do i have to put the juju-mongodb binaries on $PATH explicitly?
<mwhudson> ... yes
<thumper> yes
<thumper> although I think perhaps the test harness should fix that for you IMO
<mwhudson> the failure mode is certainly impressively obscure :)
<mwhudson> ok the tests are taking much longer now, that's a good sign :-)
<mwhudson> down to 20 failures
<mwhudson> much better :-)
 * mwhudson goes home
<wallyworld_> axw: do you know if instance polling works as expected for the manual provider? I would assume so
<axw> wallyworld_: it won't do anything for machines other than machine-0, since hte manual provider does not manage instances
<axw> wallyworld_: the machiner will update machine addresses though
<wallyworld_> cool, just checking that removing those methods off manual env provider won't brek stuff
<axw> wallyworld_: actually, just a moment. it might.
<axw> wallyworld_: ah no, addresses are recorded at provisioning time too
<wallyworld_> so all good?
<axw> wallyworld_: and the hostname is recorded as public
<axw> yeah should be good
<wallyworld_> i'm going to test local provider
<wallyworld_> i think maas should be ok
<mattyw> is anyone seeing this error on trunk? http://paste.ubuntu.com/7168714/?
<mattyw> ^^ I'm guessing not as things seem to be landing - but I've not changed anything in my branch that 'should' have affected this
<hazmat> anybody know windows?
<jam> hazmat: "this is unix, I *know* this". but yes, I have some familiarity
<hazmat> jam, so i've got a user trying to use the digital ocean plugin on windows.. and the path the plugin code thinks juju is at doesn't quite line up .. i'm just using os.path.expanduser("~/.juju") (taking into account JUJU_HOME)
<hazmat> jam, https://github.com/kapilt/juju-digitalocean/issues/16 and https://github.com/kapilt/juju-digitalocean/issues/15
<mischief> juju is not very go-gettable is it
<hazmat> jam, going through the juju-core code at the moment trying to see the delta.. ic.. HOMEDRIVE and HOMEPATH..
<jam> hazmat: I'm pretty sure we don't use $HOME on Windows for our .juju dir, but use the %APPDATA% magic. So probably we need a helper in juju-core that gives you the path to look in
<hazmat> mischief, it is.. but go dep management needs help..
<jam> hazmat: juju/osenv/home.go APPDATA
<hazmat> mischief, you go get.. cat dependencies.tsv.. update the various branches
<mischief> yea, i just tried to go get and some package api has changed
<mischief> ah
<hazmat> mischief, there's some tool that will read dependencies.tsv and do it for you
<hazmat> jam, thanks
<mischief> i would like that :)
<hazmat> mischief, go get launchpad.net/godeps .. see bottom of CONTRIBUTING.txt
<hazmat> er.. minus the .txt
<hazmat> hmm.. interesting thats docs on how to generate but now how to use
<hazmat> jam, so reading through home.go .. its a bit unclear are the functions in  in osenv/var_windows.go  used.. else it just looks like return os.environ['APPDATA'] but that looks like its some how being  setup by magic
<hazmat> and in this context the plugin is in a separate process.. not clear if its gets it own APPDATA or if it inherits.
<hazmat> hmm
<jam> hazmat: so Home() != JujuHome()
<jam> hazmat: APPDATA is windows place to put your application stuff
<jam> it is C:\Users\$USER\AppData\Roaming\
<jam> hazmat: and then we put our own "Juju" under that
<hazmat> jam, right.. but JujuHome() calls Home() on linux.. but not
<jam> hazmat: right
<hazmat> on windows
<jam> hazmat: on Windows we don't put it in $HOME
<jam> so osenv.JujuHomeDir() is what you should be using.
<hazmat> but we have functions to determine Home() on windows from other env vars
<hazmat> k
<hazmat> yup.. that should do it
<hazmat> thanks
<jam> hazmat: we also support $HOME for some other reason
<hazmat> hmm.. not sure this is going to work.. juju docean depends on an ssh binary
<mischief> hazmat: ok finally done
<mischief> now i am finally building jujud :)
<mischief> i never used godeps before, but it certainly does solve the dependency tracking problem
<mischief> there are many tools like it
<hazmat> mischief, yup.. lack of leadership ..  fragemented ecosystem tooling for basic problems.. i think there's roughly a dozen different paradigms and tools for this issue.
<jam> hazmat: well, I have ssh on my windows box
<jam> you can certainly get one
<hazmat> jam, putty, etc.. but not openssh i presume
<jam> hazmat: both git and cygwin give you openssh
<hazmat> jam, i recommended they use cygwin..
<hazmat> yeah
<jam> and you *can* build it natievly somehow
<hazmat> fair enough.. but that's not happening (be building it for users) i can't really support that effectively..  and afaics neither does openssh.. http://www.openssh.com/windows.html
<hazmat> s/be/me
<hazmat> better would be if i could get digital ocean to support userdata/cloudinit and drop the ssh entirely.. but need them to implement it.. slowly getting more votes on it.. http://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/3736274-support-cloudinit-instance-metadata
<mischief> hazmat: it would still appear there is a problem, after use of godeps -u
<mischief> http://sprunge.us/GAAV
<mischief> i guess i'll use ubuntu ._.
<jpds> As most people do.
<dimitern> fwereade, jam, i'd appreciate a review on this so i can land it https://codereview.appspot.com/80600044/
<jam> dimitern: the first thing that comes to mind is that I thought we specified it as "--network/--exclude-networks" for the Juju deploy command line. 'no-networks' being a MaaS API name, but not as user-friendly.
<dimitern> jam, maas'es is actually not_networks, but fair enough --exclude-networks it is
<dimitern> jam, and you mean --networks right, not --network for the other one?
<jam> dimitern: well, they should be the same plurality
<jam> *I* like plural form (networks)
<dimitern> jam, btw is our 1-1 in 15m or in 1h 15m ?
<jam> I think fwereade was asking for singular
<jam> dimitern: 1h15m
<dimitern> jam, ok
<dimitern> jam, i don't recall that
<jam> I certainly recall it, because I remember disagree on this case. We have "--constraints" which is a plural for something that might be one but can hold many
<jam> I think --networks fits well in the same vein
<dimitern> +1
<waigani> thumper: https://codereview.appspot.com/77970043/
<dimitern> jam, i found a bug 1299114 in maas when adding networks
<_mup_> Bug #1299114: 'ValidationError' object has no attribute 'error_dict' when creating a network <api> <cli> <MAAS:Triaged> <https://launchpad.net/bugs/1299114>
<dimitern> jam, now I'm in the process of exporting and uploading to u1 21GB disk image
<dimitern> (now my 100mbps fiber will come in handy :)
<dimitern> jam, re what fwereade said about mocking api requests to test 1.16 compat code path - any ideas?
<jam> dimitern: I did not, I just did manual testing for most of the cross version compat code.
<dimitern> jam, yeah, me too; i was thinking of trying to mock it, but there are too many levels of indirection to make it cheap to do
<jam> yeap
<jam> If we had it in place before, then I would certainly use it.
<mattyw> fwereade, rogpeppe1 does one of you have a spare moment to help me out with a test that's failing?
<rogpeppe1> mattyw: sure
<rogpeppe1> mornin' all
<mattyw> rogpeppe1, morning!
<rogpeppe1> mattyw: how's tricks?
<dimitern> morning!
<fwereade> dimitern, jam: sorry, I must have misremembered the mocking -- and I'm fine with --networks/--exclude-networks, I think that was what we agreed? if my preference for singular seems insane to you both then let's go with plural
<dimitern> fwereade, plural seems more appropriate
 * fwereade has another public holiday, yay malta, and so I have laura at home, and will not be getting much work done
<fwereade> but fwiw I will be reviewing things flagged in the channel when laura is otherwise occupied
<axw> rogpeppe1: taking it over here
<axw> rogpeppe1: ok, understand doing it at bootstrap-state because peergrouper isn't working. for #2, the only address will be machine--0 right? then the client already has the address...?
<axw> machine-0 rather
<wallyworld_> fwereade: this already has  a +1 but just in case there's something that raises any red flags, it would be great if you did get to look at https://codereview.appspot.com/82470043/
<rogpeppe1> the client already has the address it used to dial, but there might be other addresses too
<rogpeppe1> axw: ^
<axw> rogpeppe1: when would you need another address for the same machine?
<rogpeppe1> axw: perhaps you might want to dial it within the cloud
<rogpeppe1> axw: and perhaps the public address isn't valid in the cloud
<axw> rogpeppe1: we already have api-addresses for that?
<rogpeppe1> axw: also, it means we don't need any special casing for the addresses returned by Login
<rogpeppe1> axw: it just seems right to me that we should ensure from the very start that APIHostPorts is valid
<rogpeppe1> axw: especially since it's user-visible
<axw> yes, I suppose so
<rogpeppe1> axw: also, there are other things in the agent that watch it
<rogpeppe1> axw: and it would be nice not to need to special-case them
<axw> rogpeppe1: ok, I will get back to that one now then. now that we have a fully valid config at bootstrap time, it's straight forward to do without any changes to environs/cloudinit and so on
<rogpeppe1> axw: yeah
<rogpeppe1> axw: the code to set up the replica set already needs the address anyway tbh
<fwereade> wallyworld_, I have not reviewed it but I heartily endorse what you did
<wallyworld_> fwereade: i thinks it's all ok, stuff works
<wallyworld_> just wanted to be sure i hasn't missed any subtle issues
<wallyworld_> i need this to land for the joyent provider to work
<wallyworld_> i like all the red in the diff
<dimitern> jam, i'll be 5m late for 1-1, sorry
<jam> dimitern: np
<fwereade> wallyworld_, I might review it anyway just to see the red, those CLs do always make me happy
<fwereade> wallyworld_, but don't wait on me ;)
 * fwereade bbs
<wallyworld_> fwereade: sure, np. i have a filing status test to fix anyway
<wallyworld_> failing
<wallyworld_> fwereade: my main concern is just to check that it is 100% ok to remove the SetAddress calls from the uniter startup in ModeInit(). I'm sure it is but....
<dimitern> jam, i've joined
<rogpeppe2> axw: i'm trying to understand the comment in https://codereview.appspot.com/81780043/diff2/1:20001/juju/apiconn_test.go?column_width=90
<rogpeppe2> axw: i'm not sure what you mean by "we can only create the zero value"
<rogpeppe2> axw: the zero value of what?
 * axw looks
<axw> rogpeppe2: we can only create the  zero value of api.State, because all of its members are private
<axw> sorry, not very clear
<axw> rogpeppe2: the point is, without a real call to Login we can't change the result of HostPorts
<fwereade> wallyworld_, I will be most sad if we are not ready to do that -- they'reonly there as a fallback anyway, we should always be deriving unit addressesfrom machine addresses these days
<rogpeppe2> axw: ah yes. hmm. i wonder if we should mock out api.State hre
<rogpeppe2> here
<rogpeppe2> axw: we're relying on it not crashing when methods are called on its zero value
<rogpeppe2> axw: that seems a bit wrong to me
<rogpeppe2> axw: it was kind of ok before because we weren't calling any methods on in
<rogpeppe2> it
<axw> rogpeppe2: sure, I'll look into doing that
<rogpeppe2> axw: i think that'll mean you'll have to create an internal version of NewAPIFromStore that returns the possibly-mock api.State, then a thin wrapper that type asserts the returned value back to api.State
<rogpeppe2> axw: then in tests you can call the internal version
<rogpeppe2> axw: i suppose another possibility would be to actually create a genuine api.State to return.
<axw> rogpeppe2: that might be less painful :)
<axw> I don't want to create a Mongo test just because though
<rogpeppe2> axw: i actually don't think doing the mock thing will be that much hassle
<axw> I'll see how hard it is to create an interface here
<rogpeppe2> axw: thanks
<rogpeppe2> axw: the test was always slightly dodgy (for which i'm fully responsible) but i think the latest changes push it over the boundary into crackfulness.
<axw> fair enough :)  I was being a bit too lazy, I admit
<wallyworld_> fwereade: that's what i thought, justed wanted some extra eyes cause of the scope of the change
<jamespage> anyone know who's working on the joyent cloud provider?
<jamespage> fwereade, rogpeppe2 ^^
<fwereade> jamespage, wallyworld_ has been doing so most recently, and mgz before him
<wallyworld_> jamespage: i have it working. one more branch to land
<jamespage> wallyworld_, fwereade: am I right in thinking that introducing this feature is fairly isolated in terms of impact on other code ares?
<jamespage> (just assessing for the Feature Freeze Exception)
<fwereade> jamespage, yes, it shouldn't be able to affect anything that's not directly joyent-related
<wallyworld_> jamespage: yes, but there some old methods need to be deleted
<wallyworld_> cause the joyent provider does not implement them
<jamespage> great - thanks!
<fwereade> jamespage, and indeed some dead code elimination
<voidspace> morning everyone
<rogpeppe2> voidspace: hiya
<voidspace> rogpeppe2: thanks for your emails
<voidspace> rogpeppe2: ah, one email and you assigned me a card
<voidspace> anyway :-)
<rogpeppe2> voidspace: i think it was a card that you were already working on
<voidspace> rogpeppe2: yeah
<rogpeppe2> voidspace: perhaps slightly changed
<voidspace> oh
<voidspace> I'd better check :-)
<voidspace> that's quite a few cards for HA
<voidspace> not changed I don't think
<voidspace> weeeee, conflicts in merge from trunk
<voidspace> happy Monday morning
<rogpeppe2> voidspace: sorry about that
<voidspace> heh
<voidspace> ah, "someone" moved the declaration of an interface method I've removed
<voidspace> easy enough to fix
<voidspace> rogpeppe2: ah, the ticket is slightly changed - you want SetStateServingInfo on the ConfigSetter now
<rogpeppe2> voidspace: yup
<rogpeppe2> fwereade, dimitern: i'm concerned about this bug, that i discovered when live-testing my agent config changes: https://bugs.launchpad.net/juju-core/+bug/1299802
<_mup_> Bug #1299802: upgrade-juju 1.16.6 -> 1.18 (tip) fails <juju-core:New> <https://launchpad.net/bugs/1299802>
<rogpeppe2> there's something very odd going on there
<dimitern> rogpeppe2, is it possible the api server wasn't upgraded first?
<dimitern> rogpeppe2, hence DesiredVersion returns 1.16
<rogpeppe2> dimitern: no, i don't think so
<rogpeppe2> dimitern: note that the unit server had already upgraded to 1.18
<dimitern> rogpeppe2, have you investigated why it returns 1.16?
<rogpeppe2> dimitern: and *then* downgraded
<rogpeppe2> dimitern: i've looked at the code and i can't see how it could possibly happen
<rogpeppe2> dimitern: the desired version comes from the agent-version field in the env config
<rogpeppe2> dimitern: and an earlier log message confirms that that's previously changed to 1.18
<rogpeppe2> dimitern: so there's something very odd happening
<dimitern> rogpeppe2, well, a good point to start from is add more debug logging in SetEnvironAgentVersion - that's what get's called (and only that should be called) to change "agent-version" in env config
<rogpeppe> dimitern: also, regardless of the api server version, the desired version should always return the same thing
<rogpeppe> dimitern: (it just returns what's in the environ config)
<dimitern> rogpeppe, i'm not quite clear on what's desiredversion supposed to do
<rogpeppe> dimitern: it's supposed to return the desired agent version
<rogpeppe> dimitern: which is just the agent-version as stored in the env config
<dimitern> rogpeppe, why do we need an api call for that, if we can get if from env config?
<dimitern> rogpeppe, the issue seems to be a race is happening changing agent-version
<rogpeppe> dimitern: i don't see how that could happen
<rogpeppe> dimitern: the environment is stable. we change the agent version once. the environment reacts.
<rogpeppe> dimitern: where's a race?
<dimitern> rogpeppe, if i knew :)
<rogpeppe> dimitern: the reason for an API call is that not all agents are allowed to see the environment config
<rogpeppe> dimitern: oh, i thought maybe you had a theory for why it might be a race condition
<dimitern> rogpeppe, i'd pull 1.16, add logging around SetEnvironAgentVersion (if it was there in 1.16) and setting environ config in state and try the upgrade
<rogpeppe> dimitern: i suspect *some* kind of race somewhere (because the issue isn't entirely deterministic) but i doubt it's when changing the agent version
<jam> rogpeppe: 1:1 ?
<rogpeppe> jam: i'm there...
<jam> rogpeppe: check your calendar entry again, I think I updated the hangout link
<jam> https://plus.google.com/hangouts/_/canonical.com/john-roger?authuser=1
<jam> dimitern: https://code.launchpad.net/~dimitern/juju-core/370-cli-deploy-networks/+merge/212860 LGTM
<dimitern> jam, cheers
<mgz> mornin' all
<jam> morning mgz
<mgz> so, is the alendar right, that everything is gmt still, so it's an hour later for me?
<mgz> *calendar
<wallyworld_> fwereade: in juju status output, do we want to show public-address of subordinate units? we don't currently in many tests but my change exposes such addresses because we now navigate to the assigned machine. i could just suppress public address output for subords
<mgz> wallyworld_: I don't really see why we should
<wallyworld_> why we should suppress public address display for subords?
<mgz> just because it's the same as the er... what word are we using, main unit. that might not be a good enough reason
<mgz> especially for backwards charms that expose via a sub rather than the reverse
<wallyworld_> mgz: so the status tests are written wrongly then i think, as they don't set unit addresses directly like what would happen with the provider.PublicAddress() call. But for real deployments we would show them. So I'll just update the tests
<fwereade> wallyworld_, IMO we should not show subordinate addresses in status, it's duplicate info and the output is bloated enough already
<wallyworld_> fwereade: balls, i submitted the branch. i can do a followup. note that we do show subordinate addr now if set. it's just that some tests didn't set it
<wallyworld_> fwereade: mgz also had a concerm about leving it out
<voidspace> restarting
<fwereade> mgz, the addresses of the subordinates can/should be the same as the principals' in every respect, because they should both just be derived from the machine's address
<fwereade> mgz, in relations things get much more interesting
<fwereade> mgz, so we'll end up with various addresses per unit, on different networks, and need to bind to, and advertise, the right ones
<wallyworld_> anyone for a real quick review? https://codereview.appspot.com/82480043/
<wallyworld_> fwereade: so you want a branch to explicitly exclude display of subordinate address info?
<jam> wallyworld_: what do we gain by not validating comments here? Is it just to support user keys that are already present that don't have a comment?
<wallyworld_> jam: yes. and comments are validated further up the chain anyway
<wallyworld_> when keys are added to juju they are validated
<jam> mgz: ping
<jam> wallyworld_: then LGTM with a comment so that people don't come back later and just re-add the comment checking.
<wallyworld_> sure
<jam> so a comment on the test that we are explicitly testing the behavior when you don't have a comment
<wallyworld_> ok
<mgz> jam: hey
<jam> mgz: 1:1 ?
<voidspace> godeps: cannot parse "dependencies.tsv": cannot find directory for "github.com/joyent/gomanta": not found in GOPATH
<voidspace> do I need to manually install the missing dependencies?
<mgz> voidspace: or run go get again
<voidspace> mgz: yeah, that's what I'm doing - but my branch is currently in flux, so I need to get that compilable first
<voidspace> rogpeppe: is the creation of ConfigSetter new?
<rogpeppe> voidspace: i'm not sure i understand the question
<rogpeppe> voidspace: wanna hang out?
<voidspace> rogpeppe: did you add the ConfigSetter interface recently?
<voidspace> rogpeppe: sure
<rogpeppe> voidspace: yes
<voidspace> rogpeppe: right, now the compiler doesn't know about fields on what was the configInternal type because it's using the interface instead
<voidspace> rogpeppe: and I need access to the fields
<perrito666> morning
<voidspace> coffee before standup
<jam> fwereade: mgz: standup https://plus.google.com/hangouts/_/canonical.com/juju-core
<jam> axw: are you still around for today, or are you done?
<dimitern> jam, mgz, fwereade, rogpeppe, https://codereview.appspot.com/82530043 - provisioner api for machine networks, PTAL
<wwitzel3> rogpeppe: https://codereview.appspot.com/82550043 .. short one, when you have a moment.
<jam> wwitzel3: you're adding a public function, but not adding any tests for that public function, nor updating callers to use that function. I'm not quite sure the utility of the patch
<wwitzel3> jam: I must of accidently torched the test, I will get it re-added, the purpose is so that the HA APIs and things like the replicaset worker use the same selection behavior.
<axw> jam: I am around and still working (eating atm tho)
<jam> wwitzel3: sure, I just would have expected to see something other than just a 3 line change :)
<wwitzel3> jam: it was a card from rogpeppe that I started Friday that I was just wrapping up
<jam> axw: so we'd like to make sure your stuff lands, I'm happy to hand it off to nate and wayne, but I want to make sure things are moving forward for everyone
<axw> jam: nps, I aim to wrap up all my in-progress HA stuff tonight
<wwitzel3> jam: when the ensuremongo branch got set back to WIP we added some cards that could be done without having to worry about how that implementation would change.
<wwitzel3> jam: so that is the reason for such a trivial implementation
<axw> if someone is free to review, there's https://codereview.appspot.com/82450043/ and https://codereview.appspot.com/82520043/ waiting
<axw> fixing up https://codereview.appspot.com/81780043/ now
<jam> rogpeppe: fwiw, I can't reproduce bug #1299802
<_mup_> Bug #1299802: upgrade-juju 1.16.6 -> 1.18 (tip) fails <juju-core:Triaged> <https://launchpad.net/bugs/1299802>
<jam> upgrade works smooth here
<wwitzel3> jam: review updated, thanks
<jam> axw: does that mean you're actually landing the code, or should nate/wayne be doing the review feedback?
<axw> jam: 1/3 is LGTMd and I'll land when I've fixed it
<axw> 2/3 (the two I pasted before) need reviews
<axw> not sure if they came through because my wifi is a bit dodgy
<axw> axw> if someone is free to review, there's https://codereview.appspot.com/82450043/ and https://codereview.appspot.com/82520043/ waiting
<dimitern> jam, rogpeppe, fwereade, mgz: please, I really need a review on https://codereview.appspot.com/82530043
<mgz> I'll do some reviwings
<fwereade> dimitern, LGTM
<dimitern> fwereade, thanks!
<mgz> dimitern: does the Network result want to include the machine id?
<dimitern> axw, both reviewed
<axw> dimitern: thanks
<mgz> otherwise, if there are multiple machines passed, do you need to rely on order to know which networks go with which machines?
<dimitern> mgz, no, it's just like Constraints or other calls
<wwitzel3> rogpeppe: https://codereview.appspot.com/82550043
<dimitern> mgz, yes, as all the other bulk calls do
<mgz> dimitern: thanks
<rogpeppe> wwitzel3: bzr+ssh://bazaar.launchpad.net/~rogpeppe/juju-core/natefinch-030-MA-HA/
<rogpeppe> wwitzel3: func (m *Machine) IsMaster() (bool, error)
<jam> hey fwereade, I thought you were off today
<jam> fwereade: dimitern said it was a public holiday
<dimitern> jam, if you scroll back ~5h you'll see his comment
<hazmat> mischief, what distro where you on there?... you can manually specify --series="precise, trusty" to workaround that one
<rogpeppe> wwitzel3: http://paste.ubuntu.com/7184551/
<rogpeppe> wwitzel3: http://paste.ubuntu.com/7184555/
<perrito666> natefinch: out of curiosity, what kind of laptop are you using?
<rogpeppe> wwitzel3: func IsMaster(session *mongo.Session, addrs []instance.Address) (bool, error) {
<wwitzel3> rogpeppe: +1
<jam> rogpeppe: I thought the idea was to have code that took a generic "my address", so that it could be used if you had a direct session, or if you had an API connection ?
<jam> wwitzel3: ^^
<rogpeppe> jam: i've come round to a slightly different point of view
<rogpeppe> wwitzel3: http://paste.ubuntu.com/7184597/
<rogpeppe> http://paste.ubuntu.com/7184602/
<axw> jam: re layer violation, yes I think you're right. not sure if changing it at this stage is helpful though - how about I create a tech-debt bug and fix it once the MVP is done?
<rogpeppe> func IsMaster(session *mgo.Session, m *state.Machine) (bool, error) {
<rogpeppe> wwitzel3: ^
<rogpeppe> wwitzel3: http://paste.ubuntu.com/7184668/
<rogpeppe> wwitzel3: func (m *Machine) State() *state.State
<rogpeppe> m.State().MongoSession()
<natefinch> perrito666: I'm  on a Dell XPS 15, 2013 haswell revision (9530 model number).  Worked great until umm... yesterday, when the screen started flaking out after I updated.
<natefinch> speaking of which, I'm going to reboot to see if that helps
<voidspace> finally got the InitializeState tests passing
<voidspace> so lunch
<fwereade> jam, I am off, but occasionally laura dashes off to do something on her own
<natefinch> updated, sort of fixed... at least I *have* a laptop screen now.
<perrito666> negronjl: thank you, just wanted to know if upgrading my other laptop :p
<Valduare> hi guys
<Valduare> got an interesting problem for ya http://pastebin.com/qhK1HJ9Y
<wwitzel3> natefinch: I am working on the IsMaster stuff that roger and I had a discussion about, but let me know when you're up and running and want to hangout.
<natefinch> Valduare: is juju-wordpress a hostname you can otherwise ssh to?
<natefinch> wwitzel3: now is good
<Valduare> yes
<Valduare> set it up in .ssh/config
<Valduare> and iâve previously add-machine this method
<Valduare> im on manual provision setup
<Valduare> I even tried blowing away one of the vmâs and reinstalling fresh ubuntu server but still cant
<Valduare> then I tried blowing away my local juju installation after destroy-environment manual
<Valduare> and reinstalling juju
<axw> Valduare: do you have juju-wordpress in /etc/hosts?
<Valduare> no its ssh config
<Valduare> juju add-machine ssh:juju-wordpress
<Valduare> that type of thing
<axw> ok
<axw> so that may be something we need to improve, but you currently must specify something that can be resolved to an IP (not using ssh)
<Valduare> reason being - I have a different port for each vm
<Valduare> my juju bootstrap is port 22 at one of my public ipâs
<Valduare> then the other vmâs are each on their own ssh port
<Valduare> they can all talk to eachother locally no problem
<axw> ah, no public IP?
<Valduare> juju bootstrap vm is on a public ip
<axw> I mean the other machines
<Valduare> ah those are NAT
<Valduare> I had this all working the other day
<Valduare> but catastrophic failure juju status showed a machine I tried to remove as just dead
<Valduare> and couldnt re-add it
<Valduare> so I reinstalled the vm from scratch - fresh ubuntu server installed and still couldnt add it
<axw> fyi you can "juju destroy-machine --force <machine>" to remove things from status if they won't budge
<Valduare> it didnt work
<Valduare> just left it there as life: dead
<axw> huh, ok
<Valduare> any ideas how I can fix this
<axw> Valduare: if you haven't already, please file a bug with that pastebin - I at least haven't seen that before, and hadn't considered the scenario of an address known to ssh but not to the resolver
<Valduare> ok
<Valduare> what is the resolver in this case?
<wwitzel3> rogpeppe: https://codereview.appspot.com/82550043/
<axw> i.e. the hostname->IP resolver
<natefinch> axw: do you have stuff that needs to get landed that I can help with?
<rogpeppe> axw: if you're around, i've just LGTM'd https://code.launchpad.net/~axwalk/juju-core/bootstrapstate-addresses/+merge/213483
<rogpeppe> axw: if you're not, i'll land it anyway
<axw> natefinch: not just at the moment thanks
<axw> rogpeppe: cheers
<axw> just saw
<axw> that was quick :)
<rogpeppe> axw: ha, just noticed you're still active
<rogpeppe> axw: i'm trying :-)
<rogpeppe> wwitzel3: looking
<natefinch> rogpeppe: what's the state of the config changes you were working on?  Are you planning to merge those into my branch, or put them in trunk first and then merge?
<rogpeppe> natefinch: the former
<rogpeppe> natefinch: i pushed a branch which gets your branch working again
<rogpeppe> natefinch: ~rogpeppe/natefinch-030-MA-HA
<natefinch> rogpeppe: great, I can merge that into mine.
<rogpeppe> natefinch: well, i ran the cmd/jujud tests, and not any others :-)
<natefinch> rogpeppe: ok, I'll run all the tests after merge to make sure
<Valduare> axw any suggestions for bug name?
<rogpeppe> natefinch: cool
<axw> "Valduare: manual provisioning requires target hostname to be directly resolvable"?
<axw> err, move the quotes, you get the idea ;)
<Valduare> ok wanted to make sure it was something you guys understood lol
<axw> Valduare: yeah that'll mean something to me at least ;)
<axw> I'll try to take a look in the morning
<Valduare> https://bugs.launchpad.net/juju-core/+bug/1300264
<_mup_> Bug #1300264: manual provisioning requires target hostname to be directly resolvable <juju-core:New> <https://launchpad.net/bugs/1300264>
<Valduare> wow I have the most important bug in the world filed right there :P
<Valduare> kinda gives me a warm fuzzy feeling in side
<axw> Valduare: thanks for filing that
<Valduare> np
<Valduare> I currently have one host box, a gigabyte gae350n mobo with 16 gigs of ram (amd e350 proc)  running esxi and a freenas box serving iscsi to it for about 17 vmâs
<axw> Valduare: btw, how do the VMs refer to each other? is "juju-wordpress" a usable address between the VMs, or must they use IPs?
<Valduare> iâd like to eventually move over to a juju, maas openstack setup
<Valduare> I have a smoothwall router vm with 2 nicâs one that holds the public ip address and port forwards to an âinternal nicâ then all of the vmâs are on that internal nic network
<Valduare> I havnt setup ssh configs at all on the vmâs
<Valduare> just from workstation to vm
<axw> okey dokey
<axw> thanks
<axw> Valduare: are you set up to build juju from source?
<Valduare> not atm
<Valduare> I just updated the brew juju.rb the other day to point devel to 1.17.7
<Valduare> for mac
<axw> nps. there's a bit of code in the manual provisioning path that sets up the machine's addresses. we could just warn if it can't resolve the hostname, and not record any external addresses
<axw> ok
<Valduare> how long does juju-core take to compile - im on a macbook pro 7.1   2.66 dual core proc 4 gigs of ram (barely any ram available as its all used up by greedy mavericks)
<hazmat> axw, fwiw, my manual provider usage.. i stopped bothering recording addresses when injecting machines.. the agent will come up and do the right thing
<hazmat> s/recording/passing
<axw> Valduare: it should be in the seconds range
<axw> hazmat: yeah I figure we can just rely on that if the hostname's not resolvable
<axw> hazmat: only thing you don't get then is a "public" address
<axw> hazmat: but in this case there really isn't one
 * hazmat nods.. 
<Valduare> btw - does my setup sound sane?
<axw> Valduare: yeah, I think it does
<axw> you'll need to manage exposing service ports yourself, but I guess you know that already
<Valduare> aye
<Valduare> thats where smoothwall has been nice for me in this low power hardware setup heh
<Valduare> I have not been able to get a clear answer to how many physical machines are needed for a juju,maas,openstack setup?
<axw> Valduare: sorry, I'm not going to be useful there
<axw> I'd suggest #juju
<Valduare> ok
<natefinch> rogpeppe: after that code is merged in, do we need to wait on anything else to get this branch landed?  Just verified all tests pass.
<rogpeppe> natefinch: i think there's some commented out code there that can only work when StateServingInfo in the config is landed
<rogpeppe> natefinch: the branch doesn't really make sense unless the mongo secrets are coming from the agent config
<natefinch> rogpeppe: ok, right.  Is that something you can land?  Is there anything I can do to help?
<rogpeppe> natefinch: voidspace is not far off it
<natefinch> rogpeppe: awesome
<rogpeppe> natefinch: i'd really like to see [HA: agent stores API addresses after api.Open] happen, if wwitzel3 isn't already on it
<natefinch> rogpeppe: yep, that's next on my list.  Wayne is finishing up the IsMaster API stuff since he was already in the middle of it.
<rogpeppe> axw: apiclient-open-parallel isn't quite right yet
<axw> rogpeppe: bugger, it just landed. howso?
<rogpeppe> axw: (i know it's too late, but just saying, it needs a little bit of work)
<rogpeppe> axw: if one of the attempts succeeds really fast, the dial will fail
<rogpeppe> axw: because Try.Start returns ErrStopped if the try has already succeeded
<axw> wat
<rogpeppe> axw: (this is deliberate, to avoid making excess attempts)
<rogpeppe> axw: otherwise if you're going to start 50 dial attempts and the first one succeeds, you're going to do all 50 dials regardless
<axw> rogpeppe: I think I'm too tired to understand, would you mind commenting on the CL?
<rogpeppe> axw: am doing
<axw> I'm going to crash, will take a look in the morning
<rogpeppe> axw: thanks hugely for your work
<rogpeppe> axw: i can fix the code
<natefinch> axw: definitely, huge amount of work done, super awesome.
<axw> rogpeppe: ok cool, but leave it if it's too distracting and I can take a look
<rogpeppe> axw: it's possible that Start should return nil, but we could provide another method, say Completed to find out if the try has completed
<rogpeppe> axw: that might be less wat-ish
<axw> rogpeppe: ohhh, I get it now
<axw> rogpeppe: no that makes sense
<axw> ErrStopped, that is
<rogpeppe> axw: cool. it's always difficult to know when an API is bad or just unfamiliar
<axw> rogpeppe: I should try reading doc comments sometimes
<rogpeppe> axw: :-)
<axw> I expected Start to succeed but then the stopped channel to be closed upon entry
<axw> but anyway, now I know
<axw> anyways, nighty night
<wwitzel3> rogpeppe: thanks for the review, updated
<mgz> dimitern: if we propose some maas provider wip stuff, can you give us api feedback
<dimitern> mgz, sure thing
<mgz> dimitern: ta, proposing now with messy bits left in
<perrito666> dimitern: hey, could you take a look to https://codereview.appspot.com/82690043/
<perrito666> ?
<dimitern> perrito666, will look in a moment, thanks
<perrito666> tx
<arosales> quick question on code URL for juju core (ie to hand out in printed material.  Would folks prefer https://code.launchpad.net/juju-core or https://code.launchpad.net/~go-bot/juju-core/trunk
<mgz> the former
<arosales> I prefer the first as it is shorter, but thought I should get input here
<mgz> or just lp:juju-core where appropriate
<arosales> mgz: agreed, thanks :-)
<dimitern> mgz, perrito666, was it live-tested on maas?
<arosales> mgz: I would be feedback is most folks aren't as familiar with lp :-/
<mgz> arosales: right, but if doing sample commands and such like, the short form should be used
<mgz> dimitern: nope, not yet
<dimitern> mgz, ok
<natefinch> mgz: if I didn't work for canonical, I'd think lp:juju-core was a typo or something... but definitely for bzr commands, at least, it's fine (does it work with things besides bzr?)
<dimitern> perrito666, mgz, lgtm + a live test
<mgz> dimitern: does the maas provider even do live tests?
<mgz> or do you just mean it should be checked that it actually does summat useful?
<dimitern> mgz, I mean run the GetNetworks code against a maas environment with networks support
<mgz> right :)
<dimitern> :)
<mgz> dimitern: also our naming sucks a bit and should get changed, but that method should provide roughly what we need on provisioning
<arosales> mgz: ack on sample commands
<dimitern> mgz, that's ok for now
<perrito666> mgz: dunno, GetChanged is a pretty bad name too
<mgz> natefinch: other launchpaddy tools probably understand the short form
<perrito666> :p
<mgz> it's time to go swimming! GetChanged()
<natefinch> lol
<perrito666> mgz: and there you are, awkwardly looking next to a copy of yourself, changed for swimming and json encoded
<natefinch> perrito666, mgz: changed is bad, it's an adjective, not a noun
<motter>    /win 2
<motter> sorry
<mgz> hm, no sinzui online currently?
<perrito666> mgz: I was looking for him too :) has not been here on friday either
<perrito666> holiday?
<mgz> he sent mail to the list ealier today I wanted to respond to
<rogpeppe> jeeze, g+ really doesn't like me today
<mgz> rogpeppe: mumble ftw
<mgz> rural broadband can't screw it up
<rogpeppe> mgz: i like being able to the screenshare thing without using a tty emulator...
<rogpeppe> s/to/to do/
<perrito666> rogpeppe: vnc?
<rogpeppe> perrito666: maybe, haven't used vnc in years
<perrito666> rogpeppe: no one else has :p
<rogpeppe> if anyone wants to provide input on the singular worker package design, here's what i'm thinking of going with: http://paste.ubuntu.com/7185512/
<perrito666> rogpeppe: but, given a way to publish the port tightvncserver should be more than enough
<rogpeppe> actually, this is more accurate: http://paste.ubuntu.com/7185532/
<rogpeppe> dimitern, fwereade, jam, natefinch, wwitzel3, voidspace, wallyworld_: ^
<natefinch> perrito666, rogpeppe: I use VNC to do remote desktop support.  Free, works great, both people can see and control.
<rogpeppe> natefinch: how well does it work with two very differently proportioned displays?
<natefinch> rogpeppe: not entirely sure.  I know it supports scaling, but since my screen is always bigger than the other person's, it hasn't come up.
<natefinch> rogpeppe: btw, on the Conn interface, IsMaster is ambiguous to me.  I can't tell if it's telling me if I'm the master, or if some other person who is master happens to have the connection right now.
<rogpeppe> natefinch: the doc comment is suppose to make that clear
<natefinch> rogpeppe: the doc comment is what confused me ;)
<rogpeppe> natefinch: if i changed "the connection" to "this connection", would that help?
<natefinch> rogpeppe: yes :)  I was trying to figure out why I was confused. That's it.
<rogpeppe> natefinch: cool
<natefinch> rogpeppe: is "IsMaster reports whether this connection is to the master of the resource" accurate?  "Held by" makes it sound like the master is me, holding the connection to something else, but I assume this is actually a connection to something that is master... right?
<rogpeppe> natefinch: no, that's not accurate
<rogpeppe> natefinch: we want precisely "held by" semantics
<rogpeppe> natefinch: because with mongo, everyone is connected *to* the master
<rogpeppe> natefinch: but what we're interested in is whether we're on the same machine as the master
<natefinch> rogpeppe: ok, I see.  I find it a little weird to get that information from a connection.  It seems like the connection is just an implementation detail about how we decide if we're master.
<rogpeppe> natefinch: well, maybe Conn is the wrong name
<rogpeppe> natefinch: other name suggestions?
<voidspace> in a full test run I got 6 panics due to "unreachable servers"
<rogpeppe> voidspace: all in the same package?
<voidspace> running all the tests for each package with a failing test and they all passed
<voidspace> is that "normal"?
<rogpeppe> voidspace: kinda :-\
<voidspace> rogpeppe: mostly in replicasets
<voidspace> five out of six I think
<rogpeppe> voidspace: that's pretty usual, unfortunately
<voidspace> rogpeppe: thanks
<rogpeppe> voidspace: (we need to do more investigation)
<rogpeppe> voidspace: what was the 6th?
<voidspace> rogpeppe: it was in store
<voidspace> TestBlitzKey
<rogpeppe> voidspace: ha, store is another unreliable one
<voidspace> lovely :-)
<voidspace> rogpeppe: so I'm at the point where the code for this change is "complete" (I think)
<voidspace> rogpeppe: just some missing tests
<rogpeppe> voidspace: yay!
<voidspace> well...
<rogpeppe> natefinch: this is what my implementation turned out like. no tests yet, mind. http://paste.ubuntu.com/7185691/
<natefinch> rogpeppe: sorry, got pulled away.  looking
<voidspace> any equivalent of setattr for a struct?
<voidspace> except through reflection I guess
<natefinch> voidspace: there's reflection, but there's usually a better way.  What are you trying to do?
<natefinch> voidspace: the short answer is no ;)
<voidspace> natefinch: I want to write a test that asserts that a particular function returns false until given a struct with all members populated
<mgz> voidspace: see rog's three (!) excellent answers to our question on that last week
<mgz> I'll find the irclog
<voidspace> I can manually set them one by one
<voidspace> but that's tedious :-)
<natefinch> voidspace:  there's really no way to do that except the long way.  Note that because Go initializes everything to a zero value "populated" may be ambiguous.
<mgz> voidspace: http://irclogs.ubuntu.com/2014/03/26//%23juju-dev.html#t17:59
<voidspace> sure, I'll be checking that the "non-zero value" is present
<voidspace> mgz: thanks
<mgz> and the pastebins from rog under
<voidspace> mgz: thanks
<rogpeppe> voidspace: i'm not sure those suggestions will help you
<natefinch> yeah, I was going to say thatr
<voidspace> it turns out to be a philosophical question rather than a practical one
<voidspace> the code is actually only testing one field to determine "availability"
<voidspace> so I only need one test rather than a bunch
<natefinch> voidspace:  well there you go :)
<rogpeppe> voidspace: ha ha
<voidspace> hah, indeed
<voidspace> rogpeppe: so I'm back at the point where all that is missing is the unmarshaller tests
<rogpeppe> voidspace: FWIW, in some similar type of situation, i wouldn't be too averse to a bit of reflection
<voidspace> rogpeppe: but there's also (now) a conflict with trunk
<natefinch> voidspace: really, reflection is what you'd use if you really wanted to do something like that, but reflection is cumbersome (likely on purpose)
<voidspace> rogpeppe: I have to go to Krav Maga now, but I can hopefully pick it up again on my return
<voidspace> would be nice to get it ready for CL
<rogpeppe> natefinch: actually, i don't think that reflection is any more cumbersome than it needs to be
<voidspace> well, I'm sure it could do with a helper layer...
<rogpeppe> i dunno what that might look like
<voidspace> well, without generics it might be hard
<voidspace> but you could use reflection to write the helpers
<rogpeppe> voidspace: type parameters wouldn't really be that helpful here
<voidspace> if there isn't already direct getattr and setattr equivalents
<natefinch> rogpeppe: I just mean that it could be a lot more integrated into the language, and it's not.
<voidspace> rogpeppe: I've not looked at reflection at all
<voidspace> natefinch: a type declaration of "dynamic" that defers member lookup to runtime reflection automatically
<voidspace> C# has that
<rogpeppe> voidspace: reflect.NewValue(v).FieldByName("foo") is fairly simple
<rogpeppe> voidspace: which is pretty much getattr
<voidspace> rogpeppe: right
<voidspace> rogpeppe: maybe it's easy enough then
<voidspace> but that sounds like fun to defer for another day...
<rogpeppe> voidspace: i think natefinch is overstating a little
<rogpeppe> natefinch: it would make for a much bigger language
<voidspace> right, off to Krav Maga.
<voidspace> back later
<rogpeppe> natefinch: i like the fact that it's just a normal package
<rogpeppe> voidspace: ttfn
<voidspace> rogpeppe: if you get bored you could look at what I've done and pick out any obviously glaring errors...
<voidspace> rogpeppe: https://code.launchpad.net/~mfoord/juju-core/stateservinginfo/+merge/212874
<rogpeppe> voidspace: have you pushed it somewherE?
<voidspace> but I'm sure have more pressing things to do
<rogpeppe> voidspace: great, will take a look
<voidspace> see you later all
<natefinch> rogpeppe: I'm happy not to have it integrated into the language, don't get me wrong.  I wouldn't want it integrated into the language.
<rogpeppe> natefinch: i know what might be quite cool - a package that used go/ast and go/types and parsed go expressions at runtime and generated closures that did appropriate reflection operations from the go expressions.
<rogpeppe> natefinch: e.g.
<natefinch> rogpeppe: I may be overstating it some.  The API for it is (necessarily) very large, and code that uses it extensively can be hard to read, since everything is a method call instead of just code.  I've done some with it, and it's always easier than it seems (though I wish they would have called Elem() something different)
<rogpeppe> accessor, err := reflecthelper.Accessor("x[p1].Foo.Bar()")
<rogpeppe> barResult := accessor(someValue)
<natefinch> rogpeppe: our very own eval()
<rogpeppe> natefinch: indeed :-)
<rogpeppe> natefinch: we already have it, actualy
<rogpeppe> natefinch: kinda
<rogpeppe> afk
<rogpeppe> natefinch: are you around for a quick chat?
<natefinch> rogpeppe: yep
<rogpeppe> https://plus.google.com/hangouts/_/canonical.com/juju-core?authuser=1
<rogpeppe> natefinch: or i can join you if you're already in one
<natefinch> rogpeppe: you still around?
<rogpeppe> natefinch: just...
<natefinch> rogpeppe: quick question.  I was looking at the "Save api addresses to agent config" and realized I probably was misinterpreting what it was asking.   Where is that code supposed to live?  It says after we call api.Open, but I'm not sure where we do that.  (I had misread it as state.Open)
<rogpeppe> natefinch: we do that in cmd/jujud
<wwitzel3> rogpeppe: you in a hangout atm?
<rogpeppe> wwitzel3: no
<rogpeppe> wwitzel3: you?
<wwitzel3> rogpeppe: have a question, yeah, I can invite you
<natefinch> https://plus.google.com/hangouts/_/72cpj1cktoghcmpks6aar56570?hl=en
<natefinch> rogpeppe: I guess the question is, is this correct?  It's using state.ApiAddressesFromMachines()  https://codereview.appspot.com/82780043/diff/1/cmd/jujud/machine.go?context=&column_width=100
<rogpeppe> wwitzel3: api.auth.GetAuthEntity.(*state.Machine)
<rogpeppe> wwitzel3: api.auth.GetAuthEntity().(*state.Machine)
<bodie_> is there a way to list keys that can be set by juju set?
<fwereade> bodie_, `juju get` should describe what's available
<bodie_> excellent
<bodie_> bits3rpent, jcw4
<jcw4> cool
<thumper> morning
<thumper> hmm... seems like I forgot to close this yesterday
<thumper> alexisb: how's your interwebs now?
<alexisb> thumper, good
<thumper> alexisb: weren't we going to move the call to be 30 minutes earlier?
<thumper> alexisb: so it doesn't clash with my later call?
<alexisb> thumper, sure :)
<alexisb> but I forgot
<alexisb> need a few minutes
<thumper> that's fine
<thumper> I'll join the hangout from the meeting, join when you're ready
<natefinch> mornin' thumper
<mwhudson> ... value *errors.errorString = &errors.errorString{s:"cannot upload bootstrap tools: environment \"only\" of type dummy does
<mwhudson> not support instances running on \"arm64\""} ("cannot upload bootstrap tools: environment \"only\" of type dummy does not supp
<mwhudson> ort instances running on \"arm64\"")
<mwhudson> what makes that happen and how do i stop it?
<natefinch> mwhudson: sounds like you're running tests on arm64?
<mwhudson> yes
<mwhudson> that is the intent
<mwhudson> so "don't run tests on arm64" is not a useful answer, even if accurate :)
<natefinch> mwhudson: somewhere in provider/dummy/environs.go there's probably something with a hardcoded list that needs updating
<natefinch> mwhudson: that is an error about the environment that gets created with the SampleConfig that you can see at the top of the aforementioned file (environment of type testing, name is "only")
<natefinch> mwhudson: I'm not 100% sure what's causing the error, however.
<mischief> hazmat: i am using debian.
<mischief> hazmat: now, http://sprunge.us/aaDB XD
<hazmat> mischief, can you do that with --debug
<hazmat> i'd like to see where that's getting raised from
<hazmat> mischief, also what provider are you working with?
<mischief> local
<mischief> http://sprunge.us/dShP
<hazmat> mischief, hmmm. interesting.. so with --upload-tools i think the host would need to be ubuntu.. if you do without upload-tools what happens?
<mischief> it says with --series i must use --upload-tools
<mischief> so.. i used it!
<hazmat> mischief, yup.. sorry.. so without upload-tools and series it also bombs?
<hazmat> its creating tools 1.17.7.1-unknown-amd64
<hazmat> cause it can't identify the distro series.. but if you have default-series: precise for the provider and the lxc package there has ubuntu-cloud template (dpkg -L lxc) then it should pull the tools down from the global bucket/cdn
<mischief> yea it just says
<mischief> error: --series requires --upload-tools
<hazmat> mischief, right.. if you drop --series and drop --upload-tools what happens?
<mischief> the original error from yesterday, seen here with --debug http://sprunge.us/VaUG
<hazmat> hmm.. that's also trying to upload tools
<hazmat> there's an implicit fallback to upload-tools
<hazmat> mischief, i'd suggest filing a bug
<hazmat> https://bugs.launchpad.net/juju-core
<mischief> haha
<mischief> i guess i have two bugs to file now
<mischief> one to support plan 9 and one to support debian :-D
<hazmat> mischief, hmm.. can you try going back to the 1.17.7 tag
<hazmat> mischief, your on trunk and thats not available from the global bucket/cdn
<mischief> um
<hazmat> mischief, if your client matches up though it can pull those from the cdn global bucket instead of hitting the issue/bug that your running into re uploading from a different distro
<hazmat> mischief, cd $GOPATH/src/launchpad.net/juju-core
<mischief> i am using https://launchpad.net/juju-core/trunk/1.17.7/+download/juju-core_1.17.7.tar.gz
<hazmat> oh.
<hazmat> hmm
<mischief> i did not use the source from go get because i wasn't able to line up all the dependencies
<hazmat> strange its coming out as version 1.17.7.1
<mischief> maybe i missed a step like sacrifice a goat to the juju-god
 * hazmat checks the dev bucket
<mischief> juju version says '1.17.7-unknown-amd64'
<hazmat> k, yeah.. that causes issues  on upload.. but if you have default-series: precise it should pick up the right tools from http://streams.canonical.com/juju/tools/streams/v1/com.ubuntu.juju:released:tools.json
<hazmat> i gotta run.. bbiab
<mischief> ok, thanks for the tips
<mischief> oh btw i do i have 'default-series: precise' in ~/.juju/environments.yaml under local :)
<mischief> i just got a dedicated server though, i'm gonna set up openstack there and worry about a local provider later.
<mwhudson> heh there appears to be a bootstrap test that explicitly checks arm64 is unsupported
<thumper> ?!
<mwhudson> grep arm64 src/launchpad.net/juju-core/cmd/juju/bootstrap_test.go
 * mwhudson recommends ia64 for that test instead
<davecheney> morning all
<davecheney> morning all
<davecheney> waigani: do you have your own ppc vm ?
<waigani> hang on - chatting with tim
<davecheney> thumper: maybe it would be faster if you added waigani 's keys to your vm
<thumper> davecheney: I was thinking that too
<thumper> waigani: how about this one ?https://bugs.launchpad.net/juju-core/+bug/1300032
<_mup_> Bug #1300032: charm: gccgo test failure <gccgo> <ppc64el> <juju-core:Triaged> <https://launchpad.net/bugs/1300032>
<thumper> davecheney: you aren't doing that one are you?
<davecheney> thumper: do that, i'll ask mr moser for more vm's
<davecheney> thumper: waigani that is a good bug
<davecheney> probably related to http_proxy not being isolated in the environment
 * thumper nods
<thumper> we shouldn't be hitting the store in the tests
<thumper> the entire test suite should run disconnected
<davecheney> i'm glad that wasn't juju-core/store
<davecheney> i would have thrown a shoe
<davecheney> waigani: thumper http://paste.ubuntu.com/7182685/
<davecheney> i'll raise a bug, if i haven't already done so after this morning's run
<davecheney> waigani: thumper https://docs.google.com/a/canonical.com/document/d/1m9R2n6LPLNLGjdopcNkQYVG8D5V4FTyvc1vvn-9ZifM/edit
<davecheney> you'll need this
<davecheney> https://bugs.launchpad.net/bugs/1300321
<_mup_> Bug #1300321: manual provider bootstrap fails if curl isn't installed <juju-core:New> <https://launchpad.net/bugs/1300321>
<davecheney> this looks like something we should fix
<davecheney> and it shouldn't be hard
<davecheney> curl is usually installed, so it'll be a noop
<davecheney> and we can just add it to the cloud-init add-package stanza
 * mwhudson has now gotten to the point where the juju-core tests take a long time on arm64, at least
<davecheney> mwhudson: then everything is working as expected :)
<davecheney> mwhudson: takes ~30 mins on a dual core vm
<davecheney> for me
<davecheney> (ppc64)
<mwhudson> i've not been timing, but it's around that i think
<mwhudson> machine is also building glibc
<mwhudson> ah
<mwhudson> eglibc build was spinning due to yesterdays time fun
<davecheney> :(
<davecheney> mwhudson: is this real tin
<davecheney> or the fast model ?
<thumper> davecheney: what is the other login that waigani needs for power access? the jump off point?
<davecheney> batuan
<davecheney> i was just going to raise the RT
<mwhudson> real
<davecheney> thumper: are you doing it ?
<davecheney> mwhudson: orly
<thumper> I'll go poke on #is
<davecheney> thumper: right o, probably faster
<davecheney> mwhudson: can you tell me about this arm64 kit
<davecheney> or is it sekrit ?
<mwhudson> davecheney: probably not
<mwhudson> not on freenode anyway :)
<davecheney> mwhudson: another day then
<thumper> davecheney: I'll file it if I need it
<davecheney> thumper: roger
<waigani> davecheney: lunch and finish up current branch - then I'll jump into gccgo test failures
<davecheney> waigani: okie dokes
<thumper> davecheney: cc'ed you on the RT
<davecheney> thumper: thanks mate
<thumper> is being actioned now(ish) AFAICT
<mwhudson> davecheney, thumper, waigani: current status: http://paste.ubuntu.com/7187184/
<mwhudson> (this is with two hacks: one to not strip tools, one to make the dummy provider support arm64)
<davecheney> mwhudson: that matches what I see
<mwhudson> cool
<davecheney> i have fixes for line 15 in review
<davecheney> line 13 i'm going to dummy spit
<davecheney> line 9 will be hard
<davecheney> 3 and 4 will be medium
<davecheney> many fail because there are no text fixtures for ppc64
<davecheney> or arm64 for that matter
<mwhudson> yeah, that seems to be a theme
<mwhudson> "no tools available" messages or similar
<davecheney> line 7 is worrying, that might be a compiler error
<davecheney> mwhudson: yeah, followed by a hundred lines of debug
<davecheney> mwhudson: my big item for today is to figure out how to add fixture data
<davecheney> once that is done I can copy pasta it for arm64
 * davecheney goes to kick up a stink about the store tests
<thumper> line 2 is what waigani is about to fix
<davecheney> cool
<thumper> davecheney: those failres with simple stream data are test isolation failures
<mwhudson> the error for rpc is "panic: interface conversion: interface is nil, not error"
<thumper> not simple stream failures
<thumper> please don't fix test ioslation bugs with data for the local environ
<thumper> s/environ/arch/
<davecheney> thumper: orly
<mwhudson> anyway it sounds like you guys have things under control, and that fixing ppc is mostly
<mwhudson> fixing arm64
<davecheney> wallyworld_: said they were because there were no test fixtures
<davecheney> mwhudson: yup
<davecheney> thumper: this is going to make things harder
<davecheney> because 'precise' is probably baked into a lot of places
<thumper> davecheney: hmm...
<thumper> davecheney: there are ways to handwave over it
<thumper> for example, patching version.Current
<thumper> anyway, I have to go and drop gym gear off for my daughter before my gym class
<thumper> catch soon
<davecheney> ok
<davecheney> http://paste.ubuntu.com/7187301/
<davecheney> ^ useful ppc aliases
<mwhudson> davecheney: i hate src/cmd/go/build.go
<davecheney> mwhudson: i feel you
<davecheney> thumper: /var/lib/juju/tools/1.17.8.1-trusty-ppc64/jujud: error while loading shared libraries: libgo.so.5: cannot open shared object file: No such file or directory
<davecheney> 2014-03-31 23:16:03 ERROR juju.environs.manual bootstrap.go:101 bootstrapping failed, removing state file: rc: 1
<davecheney> did someone recently change the way --upload-tools works
<davecheney> say, to make it *always* rebuild local tools ?
<davecheney> hmm, looks like there are stale tools on that instance
<davecheney> 2014-03-31 23:23:28 DEBUG juju.environs.tools build.go:223 forcing version to 1.17.8.9001
<davecheney> ITS OVER 9000!
<davecheney> Whoot
<davecheney> manual provider on ppc
<davecheney> http://paste.ubuntu.com/7187355/
<wallyworld_> davecheney: that is good news. i tried again on the power vm to bootstrap into ec2 because they said that more ports were opened but no luck. so i'll park that
<davecheney> wallyworld_: yup, put it on the back burner
#juju-dev 2014-04-01
<davecheney> sinzui: ping
<waigani> thumper: you about?
<thumper> ya
<waigani> http://pastebin.ubuntu.com/7187528/
<waigani> the test passed for me
<waigani> just ran it locally, not ppc obviously
<davecheney> wallyworld_: which gccgo ?
<waigani> but i thought you said that just using gccgo would cause it to fail
<davecheney> sorry
<davecheney> waigani:
<waigani> davecheney: gcc version 4.9.0 20140330
<davecheney> waigani: your ppc details are incoming
<thumper> waigani: now we need to get you set up on the ppc machine
<waigani> wallyworld_: I'm stealing your identity ;)
<thumper> waigani: your login has been setup...
<wallyworld_> nothing worth stealing really
<thumper> waigani: I can add you as an ssh user to my vm
<davecheney> thumper: waigani got a new vm for waigani
<thumper> davecheney: already?
<waigani> thumper: okay. Didn't you say it failed for you on your local machine?
<thumper> yeah...
<waigani> davecheney: nice :)
<thumper> waigani: run the entire package
<davecheney> waigani: what lp is this again ?
<waigani> thumper: all pass
<thumper> hmm...
<thumper> waigani: definitely need to get you running that on power
<waigani> davecheney: https://bugs.launchpad.net/juju-core/+bug/1300032
<_mup_> Bug #1300032: charm: gccgo test failure <gccgo> <ppc64el> <juju-core:Triaged> <https://launchpad.net/bugs/1300032>
<thumper> davecheney: what is that line to import ssh keys from lp?
<davecheney> waigani: yeah that will pass on your local macine
<davecheney> disconnect from your network
<waigani> ah
<davecheney> or export http_proxy="www.microsoft.com"
<davecheney> or something
<davecheney> thumper: ssh-copy-id
<davecheney> ssh-import-id
<davecheney> i forget
<davecheney> i think the latter
<davecheney> ssh-import-id $LAUNCHPAD
<thumper> kk
<davecheney> waigani: your machine is winton-09
<davecheney> instructions are here -> https://docs.google.com/a/canonical.com/document/d/1m9R2n6LPLNLGjdopcNkQYVG8D5V4FTyvc1vvn-9ZifM/edit
<davecheney> 11:40 < davecheney> waigani: your machine is winton-09
<davecheney> 11:40 < davecheney> instructions are here -> https://docs.google.com/a/canonical.com/document/d/1m9R2n6LPLNLGjdopcNkQYVG8D5V4FTyvc1vvn-9ZifM/edit
<waigani> davecheney: cheers. I've got a screen full of errors now :) yay
<Valduare> hows this coming https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-arm-service-orchestration
<Valduare> and could i use devices such as http://www.amazon.com/Rikomagic-Android-Cortex-A9-External-Miracast/dp/B00GPJLVQW
<davecheney> Valduare: wrong channel made
<davecheney> mate
<davecheney> sorry
<Valduare> this is where the developers of juju are?
<Valduare> the guys who are implementing juju for arm or is there a #juju-arm channel
<davecheney> Valduare: we write juju
<davecheney> we don't know anything about ubuntu on arm
<davecheney> specfically
<davecheney> try #server
<davecheney> or #ubuntu
<Valduare> ok
<davecheney> Valduare: sorry, i can't really tell you who to talk to, only that we're not the right people
<Valduare> someone here has to be interested in testing juju on arm?
<Valduare> doesnt make sense there wouldnt lol
<thumper> Valduare: there is...
<thumper> Valduare: mwhudson looks at arm of some form
<thumper> Valduare: depends what you are wanting to know
<thumper> axw: hey, here on time?
<axw> thumper: yo, I am in fact
<thumper> cool
<Valduare> thumper: im interested in some suggestions for arm servers that will be supported well
<Valduare> i only have experience with mk808 style hdmi stick devices heh
<waigani> hmm... I'm getting: ssh_exchange_identification: Connection closed by remote host
<davecheney> waigani: add a -vv on there
<axw> thumper: sorry, closed wrong tab
<waigani> davecheney: emailed you output
<davecheney> waigani: something between you an batuan is blocking port 22
<davecheney> waigani: is tim using the internet again
<waigani> heh
<davecheney>     c.Assert(a, gc.DeepEquals, []string{"amd64"})
<davecheney> ... obtained []string = []string{"i386", "amd64"}
<davecheney> ... expected []string = []string{"amd64"}
<davecheney> OOPS: 81 passed, 1 FAILED
<davecheney> --- FAIL: TestMAAS (11.60 seconds)
<davecheney> FAIL
<davecheney> FAIL    launchpad.net/juju-core/provider/maas   11.699s
<davecheney> ffs
<mwhudson> Valduare: there is still (!) no really compelling arm server product
<davecheney> mwhudson: highbank ?
<mwhudson> davecheney: calxeda went bust
<mwhudson> so if you have one, sure
<mwhudson> but you can't get any more...
<Valduare> mwhudson: though not a lot of ram ie 2 gigs each, these mk902 devices look pretty neat
<davecheney> Valduare: when the ubuntu server team look at those arm boards
<davecheney> the lack of an onboard LOM or IPMI controllre
<davecheney> pretty much knock them out of contention
<mwhudson> Valduare: just check that the ethernet isn't some usb2 rubbish
<mwhudson> yes, and that
<Valduare> ah
<Valduare> I was talking to the linux-sunxi guys about a u-boot that could pause and wait for the kernel over network
<davecheney> Valduare: sure
<davecheney> but there is a difference between being able to do that in software
<davecheney> and being able to do it in hardware
<davecheney> and it's that distinction that is what draws the line between consumer grade and server grade
<davecheney> at least in my mind
<Valduare> aye
<mwhudson> if you want to solder things and play around and have fun, then yes, go for it
<mwhudson> but it's not something you put in a data centre
<Valduare> i dream of running my small DC on solar one day lol
<davecheney> mwhudson: except in our data center :)
<davecheney> i've heard that is *exactly* how the lp arm builders work :P
<mwhudson> davecheney: not any more, we have some highbanks now :-)
<mwhudson> lucky we got them in time
 * davecheney doffs hat
<mwhudson> but yes, we did have panda boards in our dc
<mwhudson> is _really_ hated them
<davecheney> mwhudson: yeah
<davecheney> mwhudson: i love my panda
<davecheney> i've never had a more reliable builder
<Valduare> what do you think of panda board vs mk902 type device
<mwhudson> although probably not as much as some of the strange things we had before
<davecheney> Valduare: I don't have much experience with mk902s
<mwhudson> Valduare: panda is better supported for running ubuntu-type distros on i think
<davecheney> i've used the A20's from cubie
<davecheney> imx6's
<davecheney> Ti's
<davecheney> and the exegons
<davecheney> whatever
<davecheney> stupid name
<davecheney> -1 for marketing a product that nobody can spell
<Valduare> lol
<Valduare> then i was looking at these little beasts http://www.ebay.com/itm/FREE-SHIP-Supermicro-A1SAM-2750F-O-Intel-Atom-C2750-DDR3-SATA3-V-4GbE-/191091952279?pt=LH_DefaultDomain_0&hash=item2c7df7ca97
<Valduare> 8 core atom - 64 gigs ecc ram
<Valduare> not enough money in the world hwen your buying for yourself heh
<Valduare> on your icydocks what kind of drives are you running in them
<davecheney> Valduare: i appreciate you really want to talk about arm
<davecheney> but this isn't the channel
<Valduare> aye -
<thumper> wallyworld_: hangout?
<wallyworld_> sec
<thumper> wallyworld_: https://plus.google.com/hangouts/_/76cpj3ag8c2517af97k8drl72c?hl=en when you are ready
<waigani> thumper: I'm back
<thumper> wallyworld_: https://plus.google.com/hangouts/_/7acpj3620q4qsuh0smb7157iqg?hl=en
<thumper> nope
<thumper> waigani: https://plus.google.com/hangouts/_/7acpj3620q4qsuh0smb7157iqg?hl=en
<thumper> wallyworld_: sorry
<wallyworld_> np
<waigani> thumper: packages are all installed now
<thumper> waigani: oh, good
<waigani> davecheney: I'm in! But ... trying to install golang, it has unmet dependencies which can't be installed
<davecheney> waigani: paste ?
<waigani> davecheney: http://pastebin.ubuntu.com/7187924/
<davecheney> waigani: where did you get those instructions ?
<davecheney> waigani: instructions are here -> https://docs.google.com/a/canonical.com/document/d/1m9R2n6LPLNLGjdopcNkQYVG8D5V4FTyvc1vvn-9ZifM/edit
<davecheney> waigani: thumper mwhudson http://paste.ubuntu.com/7187946/
<davecheney> current state on ppc64
 * thumper looks
<thumper> wow, joyent tests suck
<davecheney> thumper: is that why they pass ?
<davecheney> or the whole, 90% chance of timing out
<thumper> davecheney: I was just looking at the time
<waigani> davecheney: what am I missing? Can't install go on ppcvm: http://pastebin.ubuntu.com/7188020/
<wallyworld_> thumper: yeah, i never got to fix the tests run time
<wallyworld_> didn't look into it
<waigani> also, testing bug 1300032 locally, gccgo without network, I get a pile of linker errors: http://paste.ubuntu.com/7187960/
<_mup_> Bug #1300032: charm: gccgo test failure <gccgo> <ppc64el> <juju-core:Triaged> <https://launchpad.net/bugs/1300032>
<waigani> I rebuilt pkg, updated and upgraded via apt-get - still get the same errors
<waigani> thumper: ^
<thumper> wallyworld_: ok, we can put it on the TODO list
<davecheney> waigani: where did you read those instructions ?
<thumper> waigani: hmm... I don't know
<davecheney> waigani: lets fix one problem at a time
<waigani> davecheney: trying to follow yours, go get ..., no go, so trying to install go
<davecheney> waigani: can you please show me where in the instructions that it it says to do the line that you are having trouble with
<waigani> $ go get -v launchpad.net/juju-core/â¦
<davecheney> waigani: which document
<waigani> davecheney: the one you sent me: https://docs.google.com/a/canonical.com/document/d/1m9R2n6LPLNLGjdopcNkQYVG8D5V4FTyvc1vvn-9ZifM/edit#
<davecheney> what does the line directly preceeding that one say ?
<waigani> $ sudo apt-get install gccgo-4.9 gccgo-go bzr git
<davecheney> did that command work ?
<waigani> davecheney: nop
<davecheney> ok, so lets fix that one
<davecheney> then following commands might work
<waigani> okay
<davecheney> waigani: http://pastebin.ubuntu.com/7188020/
<davecheney> ^ this paste does not match the command you said you entered
<davecheney> can you check please
<waigani> davecheney: that was my attempt to install go
<waigani> davecheney: http://pastebin.ubuntu.com/7188045/
<davecheney> ok, so those are all installed
<davecheney> apt is complaing because a prevoius installation failed
<davecheney> what happens if you follow its advice ?
<davecheney> it'll probably tell you to uninstall something, probably the 'golang' meta package
<waigani> apt-get -f install..
<waigani> yep removed
<davecheney> you should be good to go
<waigani> yep, reran install and I've got go. Thanks
<davecheney> cool
<davecheney> /usr/bin/go is probably provided by an alternative
<davecheney> so it won't be present til the post install of gccgo-go runs
<davecheney> and that doesn't run if there are apt errors
 * thumper taps fingers waiting for lbox
 * davecheney plays a few hands of solitare
<thumper>  for someone... simple test tweak https://codereview.appspot.com/82940044
<davecheney> thumper: you need a defer to close that listenre
<davecheney> well, need is a bit strong
<davecheney> maybe should
<davecheney> protip: if you've been running juju tests all day, check /tmp
<rogpeppe> mornin' all
<axw> morning rogpeppe
<rogpeppe> axw: hiya
<axw> rogpeppe: I have an LGTM from fwereade on the fixes to parallel open, did you want to take a look before I land?
<rogpeppe> axw: just looking
<axw> fwereade: no rush, just checking: did you see my email about InstanceDistributor?
<rogpeppe> axw: TestDialWebsocketStopped looks a little dubious to me
<rogpeppe> axw: doesn't it run the risk of panicking?
<axw> rogpeppe: I don't see how, can you please expand?
<rogpeppe> axw: you're passing websocket.Config into newWebsocketDialler
<rogpeppe> axw: s/passing/passing a nil/
<rogpeppe> axw: istm that you're only lucky that it doesn't get into websocket.DialConfig before it receives the stop notification
<axw> rogpeppe: no luck involved, it's intentional that it should not use the config if the channel is stopped. but I can pass in a non-nil config if you feel strongly
<rogpeppe> axw: ah, of course, you close the channel before calling the function.
<rogpeppe> axw: doh! sorry, ignore me
<axw> rogpeppe: no worries :)
<rogpeppe> axw: LGM
<rogpeppe> axw: LGTM even :-)
<axw> cheers
<fwereade> axw, not yet
<axw> rogpeppe: what's wrong if "else if"?
<axw> fwereade: okey dokey
<rogpeppe> axw: it makes me look to see if there's some reason that the if is necessary
<rogpeppe> axw: s/if is/else is/
<rogpeppe> axw: the only reason that i can see that it's necessary here is to save a line, but i don't think that's a great reason
<axw> rogpeppe: ok. I tend to do it not so much to save lines, but to group related comparisons
<axw> related tests
<axw> whatever
<rogpeppe> axw: yeah, fair enough. i guess whereever i see an else after a break or return, i wonder if there's been a mistake
<rogpeppe> axw: but if you feel strongly about it, keep it
<axw> not particularly :)
<vladk> good morning
<axw> morning vladk
<dimitern> morning all
<axw> morning dimitern
<axw> rogpeppe: isn't "HA: agent cache current API addresses" (i.e. with a worker) pointless if we keep provider-state up-to-date in storage?
<rogpeppe> axw: only if the agent can get access to provider-state
<rogpeppe> axw: (which it can't currently)
<axw> ah right
<mattyw> rogpeppe, fwereade when you both get a moment can you take another look at https://codereview.appspot.com/75600044/. fwereade: It's changed since you LGTMed it
<rogpeppe> mattyw: will do
<axw> rogpeppe: https://codereview.appspot.com/83050045 - jujud generates shared secret & calls SetStateServingInfo
<rogpeppe> axw: brill, looking
<rogpeppe> axw: voidspace is shortly to propose a CL which adds a SetStateServingInfo to agent config.
<rogpeppe> axw: (and a StateServingInfo getter too)
<axw> ah ok
<rogpeppe> axw: but actually, that should merge ok with your branch
<rogpeppe> axw: isn't the "between 6 and 1024 chars and base64" stipulation funny?
<axw> rogpeppe: it is a bit, not sure what the deal is there
<axw> rogpeppe: it's not clear on whether it's inclusive/exclusive either, but mongo doesn't complain with 1024 at least
<rogpeppe> axw: good
<rogpeppe> axw: 1024 seems a bit like overkill though
<rogpeppe> axw: especially as the randomness won't compress and cloudinit files are limited in size
<rogpeppe> axw: although... it actually never goes in a cloudinit file, does it?
<rogpeppe> axw: so it probably makes no odds
<axw> rogpeppe: right, it doesn't. it only goes to disk and mongo
<rogpeppe> axw: i'm just looking at MongoUpstartService. I *think* that's never used to generate an upstart conf that goes across the network. does that seem right to you?
<rogpeppe> axw: in which case filepath would be more appropriate than path, but then again, this is *upstart*, so path will be fine in fact.
<axw> rogpeppe: MongoUpstartService is used inside environs/cloudinit
<axw> for how long I don't know
<rogpeppe> axw: that needs to go away though
<axw> I assume once this is all done, we'll generate the mongo upstart service in the agent
<axw> sure
<rogpeppe> axw: when EnsureMongoService is called by jujud
<rogpeppe> axw: yeah, there's a long-standing CL that will do that
<jam1> axw, thumper: hopefully I requeued the right branches to land. I had to do some bot surgery to get 1.18 available, and I noticed we were out-of-disk-space, which is probably why you were resubmitting them earlier.
<axw> jam1: thanks, sorry if I was interfering
<jam1> axw: I didn't do my normal safety checks to see if it was running anything and grab the fslock, but hopefully I didn't break anything too badly.
<voidspace> morning all
<foiegras> g'morning
<rogpeppe> voidspace: hiya
 * fwereade will be a few mins late to the meeting to allow the nearby hoovering to complete
<fwereade> don't wait for me
<mgz> fwereade: it's an hour later
<fwereade> so much the better then :)
<rogpeppe> voidspace: https://code.launchpad.net/~axwalk/juju-core/jujud-bootstrap-mongo-sharedsecret/+merge/213610
<jam> fwereade: that's a lot of hoovering :0
<fwereade> haha
<voidspace> rogpeppe: I'm not muted
<voidspace> rogpeppe: I can hear
<rogpeppe> voidspace: hmm, you just went ultra-quiet
<jam> wwitzel3: I'm just grabbing a coffee, then I'll be in our 1:1 hangout
<perrito666> good morning
<wwitzel3> jam: sounds good
<jam> good morning perrito666
<natefinch> morning all
<wwitzel3> morning natefinch
<voidspace> natefinch: morning
<voidspace> wwitzel3: morning
<wwitzel3> voidspace: morning
<rogpeppe1> voidspace: environs/cloudinit/cloudinit.go
<voidspace> rogpeppe1: ~mfoord/juju-core/stateservinginfo
<voidspace> so running tests is pooing in my tmp directory
<wallyworld_> fwereade: will you have a moment after the standup to discuss SetPrivate/PublicAddress?
<jam> axw: re: https://code.launchpad.net/~axwalk/juju-core/jujud-bootstrap-mongo-sharedsecret/+merge/213610
<jam> axw: what happens if you pass --keyFile when we don't use replSet, especially on a Mongo that was initialized differently ?
<fwereade> wallyworld_, ofc
<axw> jam: I tested with the local provider, it just worked
<axw> jam: I created another card to create the keyfile on upgrade
<jam> axw: thx. I think the idea is that EnsureMongoServer code (that hasn't landed yet) is intended to "make the state consistent"
<jam> which would be writing that file
<jam> and rewriting the Upstart file
<axw> makes sense
<axw> I will update the card to reflect that
<natefinch> voidspace: about the tmp directory. That can happen if you kill the tests.  In theory it shouldn't ever happen if you don't kill the tests.  The problem with killing them is that deferred statements don't happen if the application dies, and that's how we do all our cleanup.
<natefinch> (note the "in theory" ... we seem to leak stuff in tmp occasionally on the bot, which shouldn't be killing anything)
<jam> perrito666: I think someone changed canonical admin, because I just got emails for 5 holiday requests from you. Approving them now.
<perrito666> jam: sarah did
<perrito666> jam: I was under the wrong person
<voidspace> natefinch: right, thanks
<hazmat> fwereade, post call.. ran into a strange bug around proper garbage collection of machines in status ... seems to be consistent around the 150 machine point..  https://bugs.launchpad.net/juju-core/+bug/1299584 .. was curious if you might be able to identify src location so i could poke at a  bit more.
<_mup_> Bug #1299584: dead machines stuck in status <destroy-machine> <juju-core:Triaged> <https://launchpad.net/bugs/1299584>
<fwereade> hazmat, that sounds like a provisioner bug, but I can't see why it only shows up after a while
<fwereade> hazmat, the provisioner is responsible for the last step of machine cleanup -- the cleanup actually removes other stuff, and leaves the machines dead for the provisioner
<hazmat> fwereade, ic, thanks
<hazmat> rogpeppe1, which tool is that?
<hazmat> rogpeppe1, re deps and go get
<rogpeppe1> hazmat: https://github.com/tools/godep
<rogpeppe1> hazmat: but we should go the api stabilisation route too
<wwitzel3> rogpeppe1, natefinch: https://codereview.appspot.com/83150043 IsMaster API review
<rogpeppe1> wwitzel3: will take a look after the meeting
<wwitzel3> rogpeppe1: yep, thanks
<wallyworld> fwereade: who is the relevant landscape guy?
<perrito666> wwitzel3: just a personal opinion, I would like a less pythonic way to mock SeectPeerAddress :) but it its completely personal and with no justification
<wwitzel3> perrito666: comment on the review with an example and I'd be happy to consider it
<rogpeppe1> voidspace: shall we move into another hangout?
<voidspace> rogpeppe1: sure
<voidspace> rogpeppe1: ah, wrapping up
<rogpeppe1> voidspace: or... we could stay, yeah
<perrito666> wwitzel3: done, I am not sure if mine is better :) It could actually be worse
<perrito666> local coffee substitute beverage time, brb
<rogpeppe1> wwitzel3: you have a review
<rogpeppe1> perrito666: i made an alternative suggestion
<perrito666> rogpeppe1: I dont fully understand your suggestion (although I sense is better than mine)
<voidspace> rogpeppe1: I'm going on lunch - if you produce a branch that fixes the config flow, or some test code to generate config files, can you email me the details please
<bodie_> epic - http://0value.com/my-Go-centric-Vim-setup
<rogpeppe1> bodie_: see also http://blog.gopheracademy.com/vimgo-development-environment
<perrito666> rogpeppe1: I definitely need to read that in depth
<rogpeppe1> it's not surprising i've got problems with hangouts. my internet speed is currently terrible. (0.74/0.18 Mbps)
<perrito666> rogpeppe1: measured how?
<sinzui> jam, I think you just beat me to make an MP to merge 1.17.7 into 1.18
<rogpeppe1> perrito666: speedtest.net (usually fairly reliable)
<perrito666> rogpeppe1: 15/1.2 :| I did not see that coming, being in the internet equivalent to congo
<rogpeppe1> perrito666: that's better than i usually get
<rogpeppe1> perrito666: but your effective speed will depend on routers out of your country too
<perrito666> well I do live in a neighborhood where internet is only used by me during work hours
<mgz> I'm pretty sure the internet equivalent of the congo is the congo
<perrito666> mgz: well, I dont know, our topology is rather shameful :p but you might be right there jaja (the most used example outside is argentina)
<perrito666> mgz: the issue here is that I live on the country usually used as bad example
<perrito666> sinzui: good morning, dont hate me, did you see my email? :)
<sinzui> Not yet
<rogpeppe1> mgz: lol
<bodie_> rogpeppe1, very nice :) I'm still using Sublime mostly because I'm lazy.
<bodie_> the gosublime package is pretty handy.  a little bloaty, perhaps.
<rogpeppe1> bodie_: i'm an outlier when it comes to editor usage :-)
<bodie_> it's lonely at the top ;)
<natefinch> bodie_: yeah, I use sublime because I like having mouse support and rational hotkeys.  Gosublime does have a lot of stuff I don't need.
<rogpeppe1> bodie_: i did use vi once upon a time though
<bodie_> I'm really comfortable with vi; so, "vintage mode" in sublime is great! ;)
<rogpeppe1> i wrote a vi-mode command line editor once
<TheMue> natefinch: I left ST3 now and moved back to the good old vim
<bodie_> fun
<bodie_> I'm slowly transitioning off my training wheels, but for now it helps to be able to click around and see the filetree at a glance
<jam> sinzui: :). I'm still sorting out the bot, but it should be good now.
<jam> I believe Ian wants to get the joyent stuff into a 1.17.8 release.
<sinzui> thank you jam. I saw that in the log. We will see if I configured the joyent env properly for testing
<dimitern> mgz, jam, fwereade, https://codereview.appspot.com/83200043 - provisioner starting machines with networks specified
<dimitern> mgz, poke re status of that getnetworkslist branches?
<mgz> dimitern: I'll get it landed now-ish I think, and tweak after
<dimitern> mgz, great, thanks!
<rogpeppe1> voidspace: here's a 1.16 agent config: http://paste.ubuntu.com/7189587/
<voidspace> rogpeppe1: awesome
<voidspace> rogpeppe1: just updating my coffee - thanks
<mgz> your coffee has revision numbers?
<mgz> who's branch of coffee are you using?
 * fwereade collecting laura
<fwereade> dimitern, in the provsioner, shouldn't we just accept the error from the provider? StartInstance errors shouldn't take down the task, they should be recorded as machine errors
<rogpeppe> my internet connection is dodgy currently
<rogpeppe> my provider's running tests on the line
<perrito666> hey, is anyone working on "CLI: Ensure deploy --to and add-unit --to reports an error when the selected machine's provisioned networks match the service's" or can I take it?
<jam> sinzui: so we have a logical conflict about 1.17.7 in the 1.18 branch. Probably some test that needed to be updated for new 3rd party lib locations. I won't be able to get to it tonight, but will work on it first thing tomorrow.
<jam> wwitzel3, natefinch, perrito666: to help sinzui get it done, is it possible to look into this: https://code.launchpad.net/~jameinel/juju-core/1.18-merges-1.17.7/+merge/213615
<jam> It looks like merging the juju/1.18 branch with my branch causes a problem with a bad import
<jam> I'm guessing we just moved it to a 3rd party lib.
<jam> you should be able to reproduce it locally, as it looks like a build failure.
<natefinch> jam: I'm starting an interview in 5 minutes, or I would look into it.
<jam> np, it might still work better for you, since I'm EOD
<jam> but don't pick it up unless nobody else steps up
<jam> natefinch: ^^
<natefinch> jam: sure
<wwitzel3> jam, natefinch: I can look as well just want to finish a thought.
<wwitzel3> natefinch: we can pair on it?
<natefinch> wwitzel3: sorry, doing an interview, but possibly after, though that may be after noon.
<perrito666> I can look at it too also, wwitzel3 let me know if that thought becomes too long
<wwitzel3> perrito666: if you want to hangout while I wrap this up, then we can pair on it
<wwitzel3> perrito666: I glanced at it, but didn't have any quick ideas
<perrito666> well, if for a hangout you need my screen shared it will be a problem :) my linux pc is not hangoutable :p
<voidspace> rogpeppe: so I've pushed the test for 1.16 StatePort parsing based on the data you gave me
<rogpeppe> voidspace: cool
<perrito666> wwitzel3: branching 1.18 to test it locally
<voidspace> rogpeppe: just tweaking the test to write out a 1.18 config file from it so I can push the 1.18 test for the same thing
<rogpeppe> voidspace: i'm working on changing environs/cloudinit to use StateServingInfo
<voidspace> rogpeppe: that will be the only missing piece for my branch
<voidspace> subject to exhaustive review of course
<rogpeppe> voidspace: i got the data by bootstrapping a 1.16 local environ, BTW
<rogpeppe> voidspace: so you could do the same thing with 1.18 potentially
<voidspace> rogpeppe: ok
<wwitzel3> perrito666, rogpeppe: pushed up dates for https://codereview.appspot.com/83150043/ when you have time for another review. Thank you.
<wwitzel3> perrito666: I pulled down jam's branch and will see what I can get from that locally
<dimitern> fwereade, agreed
<dimitern> fwereade, but i haven't changed that - just added an extra check before StartInstance
<fwereade> dimitern, cool
<fwereade> oh wait
<fwereade> dimitern, why would we do that though?
<dimitern> fwereade, to save time?
<fwereade> dimitern, it's a whole new code path specifically to avoid setting StartInstance errors in the usual place where people will see them
<dimitern> fwereade, ok, i see your point
<dimitern> fwereade, will drop the check and just call start instance
<fwereade> dimitern, that's great, tyvm
<fwereade> dimitern, if we want to save provider calls at some point we can do basiacl
<fwereade> dimitern, actually
<fwereade> dimitern, if yu can make it clean, I endorse what you're doing -- but please just make sure the errors end up on the machine status as they would have done had you called StartInstance
<fwereade> dimitern, do not feel obliged though
<fwereade> dimitern, threading it nicely through the provisioner task might easily not be worth the complexity
<voidspace> ERROR cannot use 37017 as state port, already in use
<voidspace> when I use netstat it reports that the port is open
<voidspace> but for pid it reports "-"
<voidspace> ah, but "sudo netstat" gives me the real answer
<perrito666> wwitzel3: do you know anything about  dummy environ state tests must be run with MgoTestPackage ?
<wwitzel3> perrito666: nope
<voidspace> rogpeppe2: so I get an error trying to bootstrap with trunk
<voidspace> rogpeppe2: https://pastebin.canonical.com/107549/
<voidspace> error: --instance-id option must be set
<rogpeppe2> voidspace: that means you've got a jujud that's not in the same directory as your juju executable, i think
<rogpeppe2> voidspace: how did you bootstrap?
<voidspace> rogpeppe2: see the pastebin
<rogpeppe2> voidspace: ah, sorry. will get me 2-factor auth key
<rogpeppe2> 526487
<rogpeppe2> ha ha
<voidspace> hah
<voidspace> rogpeppe2: ah, I've done a "go install" instead of a "go build"
<voidspace> rogpeppe2: and it might now be working...
<rogpeppe2> voidspace: ah, right
<rogpeppe2> voidspace: go build isn't useful for much, generally
<voidspace> rogpeppe2: yeah, this is taking much longer!
<voidspace> sorry for the noise...
<rogpeppe2> voidspace: this change is proving a little invasive. i think it might be better to do it as a followup to yours.
<voidspace> rogpeppe2: right
<voidspace> rogpeppe2: except mine has a conflict with trunk
<voidspace> rogpeppe2: so we can't land mine without it
<voidspace> still bootstrapping...
<rogpeppe2> voidspace: it does take ages to bootstrap - it downloads a whole image, i think
<rogpeppe2> voidspace: although, this is the local provider and on trunk, right?
<voidspace> rogpeppe2: I might have an agent.cof though
<voidspace> rogpeppe2: yes
<rogpeppe2> voidspace: hmm, that generally completes quite quickly for me
<voidspace> "Bootstrapping Juju machine agent"
<jamespage> sinzui, around?
<voidspace> rogpeppe2: if it's downloading anything it will be sloooow
<voidspace> rural internet
<jamespage> sinzui, I have some juju-core CI questions for the Ubuntu MRE
<voidspace> I think I can just use this conf though
<rogpeppe2> voidspace: sgtm
<voidspace> rogpeppe2: ok to put the real certs straight into the test file? they'll be regenerated next time I bootstrap, right
<sinzui> jamespage, I just added my first comment, I need to add more
<jamespage> sinzui, thanks
<wwitzel3> mgz: ping
<rogpeppe2> voidspace: yeah, i think so.
<voidspace> rogpeppe2: hah, the existing test data for 1_18 is for machine-0
<voidspace> so I actually need a config *without* the secrets
<voidspace> hmmm... and it's still bootstrapping
<voidspace> ah, and this is why
<voidspace> a million log lines saying
<voidspace> 2014-04-01 14:31:22 DEBUG juju.state open.go:101 connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused
<dimitern> mgz, ping
<rogpeppe2> hmm, does anyone else see a test failure of state/api in trunk?
<rogpeppe2> the test looks wrong to me
<voidspace> rogpeppe2: passes for me
<voidspace> well, now trying api/...
<voidspace> yep - all passes
<rogpeppe2> voidspace: ah, i think it's probably to do with talktalk
<rogpeppe2> hmm, not sure actually
<rogpeppe2> voidspace: could you paste me the output of running go test -gocheck.vv -gocheck.v 'TestOpenMultiple$' launchpad.net/juju-core/state/api
<rogpeppe2> voidspace: please
<rogpeppe2> oops
<rogpeppe2> s/-gocheck.v /-gocheck.f /
<rogpeppe2> voidspace: ^
<rogpeppe2> i can't see how it can work - the address from Listen isn't ok to dial AFAICS
<mgz> wwitzel3, dimitern: hey
<voidspace> rogpeppe2: yep
<dimitern> mgz, i'll need that branch soon ;)
<voidspace> rogpeppe2: 0 passed
<perrito666> wwitzel3: I got it to fail, that is for sure
<perrito666> :p
<mgz> dimitern: just done some fiddling on the maas code, merging it now
<dimitern> mgz, thanks!
<dimitern> mgz, did you manage to live test it?
<voidspace> rogpeppe2: however, if I do
<rogpeppe2> voidspace: oh, frick. go test launchpad.net/juju-core/state/api -gocheck.vv -gocheck.f 'TestOpenMultiple$'
<voidspace> go test launchpad.net/juju-core/state/api -gocheck.vv -gocheck.f 'TestOpenMultiple$'
<voidspace> I get ok  	launchpad.net/juju-core/state/api	0.325s
<voidspace> and no other output
<rogpeppe2> voidspace: weird
<rogpeppe2> voidspace: what if you cd to state/api and do go test -gocheck.vv -gocheck.f 'TestOpenMultiple$'  ?
<fwereade> dimitern, I am confused... we have StartInstanceParams which has a Networks field; and a MachineConfig field, which itself has Networks fields
<mgz> dimitern: no, not yet
<fwereade> dimitern, which one counts? why does the other exist?
<voidspace> rogpeppe2: a lot of output but  a pass
<voidspace> rogpeppe2: want a pastebin?
<rogpeppe2> voidspace: please
<dimitern> fwereade, StartInstanceParams had this added initially, but the machineConfig one will be used for the cloudinit setup
<voidspace> rogpeppe2: https://pastebin.canonical.com/107557/
<fwereade> dimitern, can we drop it from StartInstanceParams then? otherwise it's just a bug waiting to happen
<dimitern> fwereade, and maas provider uses StartInstanceParams one to call acquireNode with networks, when set
<voidspace> brb
<dimitern> fwereade, i'd like to do that in a follow-up, when integrating with mgz's branch
<rogpeppe2> voidspace: weird
<rogpeppe2> voidspace: [LOG] 36.85478 INFO juju.state.api connection established to "wss://[::]:35729/"
<rogpeppe2> voidspace: that doesn't seem to work on my machine
<fwereade> dimitern, btw, what led us to try to do network setup in cloudinit? is it *really* easier that an one-shot job in the machine agent?
<rogpeppe2> voidspace: ahhh, perhaps because i've got ipv6 disabled
<dimitern> fwereade, it's easier for me at least
<dimitern> fwereade, and less code i think
<fwereade> dimitern, what's easier?
<wwitzel3> mgz: wondering how I would pull down a remote branch and switch to it? without making a whole new folder
<dimitern> fwereade, do i need to test anything wrt provisioning machines with networks when we have a test that errors from StartInstance are transformed to StatusError?
<fwereade> dimitern, "easier" is a valid argument, I just can't see how it applies here :)
<wwitzel3> mgz: can't seem to remember or find the syntax
<dimitern> fwereade, I need to add 1 API call and a few scripts and everything can be done in the provisioner and cloudinit
<fwereade> dimitern, don't think so, there's already a test for that
<dimitern> fwereade, otherwise we'll also need a worker
<dimitern> fwereade, ok, thought so
<mgz> wwitzel3: `bzr branch --switch lp:PATH/TO/BRANCH co:BRANCH` in the dir with the colo branch setup
<wwitzel3> mgz: co: .. that is what I kept forgetting
<wwitzel3> mgz: thank you
<rogpeppe2> mgz: what is supposed to happen if you make a tcp connection to an all-zeros IP address?
<mgz> the socket library should give you an error
<fwereade> dimitern, honestly I'm not seeing the complexity in a one-shot worker that ignores Stop() and just uses a tomb for error transmission
<rogpeppe2> mgz: well, it doesn't (on voidspace's machine, at any rate, and it looks like the gobot machine too)
<wwitzel3> perrito666: I'm running the tests now, I was accidently merging trunk which was fixing what ever issue this merge is having
<dimitern> fwereade, i have it mostly done already
<fwereade> dimitern, whereas every little bit of weight we add to cloudinit worries me
<dimitern> fwereade, it's a temporary solution until we have the worker
<fwereade> dimitern, the bulk of it should be identical, right?
<fwereade> dimitern, it's just when those same scripts happen to run?
<perrito666> wwitzel3: it blows when merged to jam's branch, running testsuite now, bbl
<perrito666> Ill go lunch
<dimitern> fwereade, yeah, and a new api facade and methods
<dimitern> fwereade, and the worker itself
<fwereade> dimitern, it's a one-method facade, though, right?
<dimitern> fwereade, so you're against setting up networks in cloudinit in general?
<mgz> rogpeppe2: you can use a known-invalid hostname instead optionally
<rogpeppe2> voidspace: i'm presuming this program passes if you run it on your machine: http://play.golang.org/p/1TD2_F1NTd
<fwereade> dimitern, somewhat against it, yeah
<rogpeppe2> mgz: in this case, the tests are relying on it being valid
<dimitern> fwereade, if you're really feeling that way, i can go with the worker
<mgz> (still vulnerable to bad dns servers... ideally we don't want bogus connections getting out at all)
<rogpeppe2> mgz: which is troubling
<fwereade> dimitern, where are you getting the info about what networks actually exist at cloudinit time?
<rogpeppe2> mgz: does this code run ok on your machine? http://play.golang.org/p/1TD2_F1NTd
<dimitern> fwereade, but i can't guarantee the whole lot will be ready by tomorrow eod, as we talked
<fwereade> dimitern, I'm still talking it through and may yet be convinced
<dimitern> fwereade, provisioner gets that and passes the needed information to render the appropriate cloudinit
<mgz> fwereade: from maas /api/1.0/networks/?node=<systemidofnode>
<mgz> dimitern: sending to bot with version dep bump
<dimitern> mgz, ah, dependencies.tsv needs updating yes
<fwereade> dimitern, mgz: so, I may be missing something -- what's the difference between the method on the provisioner facade vs the one on the mooted new one?
<voidspace> rogpeppe2: trying
<mgz> dimitern: right, that's why it was a bit more of a dance
<dimitern> fwereade, so the provisioner one is called before StartInstance to get the networks and pass them in StartInstanceParams/MachineConfig, from which the cloudinit scripts get their params
<dimitern> fwereade, and the networker api is basically the same thing, but prepares and runs the scripts at startup
<dimitern> fwereade, in the latter case we don't have the provisioner api call, in the former we don't have the worker or its api
<fwereade> dimitern, I'm not convinced yet I'm afraid -- that StartInstanceParams/MachineConfig thing feels like a pretty strong sign we're DIW
<dimitern> fwereade, and also, in the latter case if you specify invalid networks (unknown or not available on the machine) you'll get an error after MA starts and no status error, whereas in the former case the provisioner can set statuserror in these cases
<voidspace> rogpeppe2: seems to work
<voidspace> [::]:48575 &net.TCPAddr{IP:net.IP{0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, Port:48575, Zone:""}
<voidspace> accepted
<voidspace> dialled
<fwereade> dimitern, surely not? those networks still go into StartInstanceParams, and the provider barfs then if it can't give them to us
<dimitern> fwereade, DWI=Direct Inside Wire ? :)
<fwereade> dimitern, Doing It Wrong ;p
<dimitern> ah
<rogpeppe2> voidspace: right, thought so. otherwise tests would've failed on your machine
<rogpeppe2> voidspace: but tests were passing on my machine, so i guess something's changed.
<dimitern> fwereade, well, acquireNode either gives us a node with these networks or returns an error
<fwereade> dimitern, yeah
<dimitern> fwereade, so i stand corrected, with a worker we should still have startinstance-time errors, which will be recorded in status
<fwereade> dimitern, should be, I think
<mgz> rogpeppe2: well, that does the same on a canonistack machine as it does for voidspace
<voidspace> godammit, still can't bootstrap on my machine
<voidspace> 2014-04-01 15:15:23 DEBUG juju.state open.go:101 connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused
<fwereade> dimitern, my big concern with the worker approach is that machine agent tests will remain a godawful fucking nightmare to test by side-effect, and doing it right *there* really will push us past allmanner f deadlines
<rogpeppe2> mgz: yup, i'm not surprised
<voidspace> rebooting, something's futzed
<rogpeppe2> mgz: but AFAICS it should not be working, right?
<mgz> I'm pretty sure if I write it in C, it doesn't
<dimitern> fwereade, not sure I'm following you there - why MA tests will suffer?
 * rogpeppe2 tries to remember his rusty sockets skills
<fwereade> dimitern, it's hell testing anything in the machine agent because there's no indirection layer -- we can't test that it starts a Fooer, we need to start the agent and hang around watching other stuff until we get evidence roughly aligned with the notion that it might have done so
<fwereade> dimitern, and this will try to rewrite config that expects sudo access, I would imagine
<dimitern> fwereade, yeah right
<fwereade> dimitern, so all the other tests will start barfing in really weird ways
<dimitern> fwereade, correct
<fwereade> dimitern, not necessarily reproducible, etc etc
<dimitern> fwereade, we can mock IsRootUser or something though, like for the local provider
<fwereade> dimitern, it still sucks doing that at arm's length
<fwereade> dimitern, ok, I have convinced myself
<dimitern> fwereade, :) so?
<fwereade> dimitern, go ahead with the cloudinit approach, but *please* make sure the code at the sharp end is so nicely isolated you can just move it and be done
<fwereade> dimitern, and we need to have networks on *one* of MachineConfig and StartInstanceParams :)
<dimitern> fwereade, ok, will try doing it sensibly
<fwereade> dimitern, if it happens in a followup I'm not too bothered, so long as it does happen -- add a card maybe?
<fwereade> dimitern, actually add a followup card for the worker
<dimitern> fwereade, i'll poke it around some more and might do it now actually
<fwereade> dimitern, this is mr.right-now, not mr.right
<dimitern> fwereade, there are several cards re the worker
<fwereade> dimitern, great :)
<fwereade> dimitern, I find myself wishing for dependency graphs in kanban and stuff
<voidspace> didn't help, still can't bootstrap trunk with the local provider
<voidspace> 2014-04-01 15:21:29 DEBUG juju.state open.go:101 connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused
<dimitern> fwereade, cheers
 * fwereade bbiab again
<dimitern> fwereade, i still need the review though ;)
<voidspace> rogpeppe2: final test pushed
<rogpeppe2> voidspace: brill
<voidspace> so only resolving the APIServerDetails / StateServingInfo conflict left for my branch
<voidspace> rogpeppe2: want a review on your branch?
<rogpeppe2> voidspace: please - trivial: https://codereview.appspot.com/83090044
<voidspace> rogpeppe2: yep, looks good to me
<rogpeppe2> voidspace: ta
<wwitzel3> another for good measure
<rogpeppe2> mgz: apparently it does work in C (try telnet 0.0.0.0 22)
<voidspace> :-)
<mgz> rogpeppe2: even gethostbyaddr doesn't complain, which surprises me
<dimitern> fwereade, I dropped the networks from startinstanceparams and now only the ones inside machineconfig are used
<perrito666> wwitzel3: ping
<mgz> dimitern: branch landed
<dimitern> mgz, awesome
<rogpeppe2> voidspace: lp:~rogpeppe/juju-core/mfoord-stateservinginfo
<jam> wwitzel3: perrito666: I think it is just that the 1.18 branch had a test case in it that needs to be updated to use a new import
<jam> I would think you could just change to that dir, run "go test" directly, and it should print out the bad imports
<perrito666> jam: I got two failing here, replicaset and ..
<perrito666> machine
<jam> so, for example :FAIL	launchpad.net/juju-core/cloudinit [build failed]
<jam> cd cloudinit
<jam> go test
<jam> should just show a bad import
<perrito666> jam: sadly, here they work
<jam> perrito666: did you take the 1.18 branch and merge it with mine?
<perrito666> jam: nope, merge had failed
<jam> I think I found the problem.... It looks like the build process had created a library for a directory we had deleted, if I just nuke $GOPATH/pkg it works
<voidspace> rogpeppe2: merged, now running tests
<voidspace> rogpeppe2: I see a SharedSecret failure already
<jam> at least, on the bot
<perrito666> jam: let me check
<perrito666> jam: same here
<jam> perrito666: so that isn't what *you* will see. I think the steps to reproduce are: "checkout the 1.18 branch, install it, merge my branch, try to run the test suite". The initial build will have left some cruft behind that go doesn't realize is stale.
<perrito666> jam: it what i did
<perrito666> since i first tried 1.18
<perrito666> a rm of pkg fixed it
<perrito666> brb
<dimitern> mgz, fwereade, updated https://codereview.appspot.com/83200043/ - should be much more straightforward now
<bloodearnest> heya, does anyone know a way to fake a public-address with the local provider?
<wwitzel3> perrito666: was grabbing some lunch
<wwitzel3> perrito666: I must be doing something wrong because I pulled down jam's branch and all the tests passed for me after running godeps -u
<rogpeppe2> mgz: looks like there might've been a failure to update dependencies.tsv
<wwitzel3> rogpeppe2: when you get a chance, if you could have another look at https://codereview.appspot.com/83150043/
<rogpeppe2> mgz: i see these failures running tests in provider/maas
<rogpeppe2> ./environ_whitebox_test.go:342: suite.providerSuite.testMAASObject.TestServer.NewNetwork undefined (type *gomaasapi.TestServer has no field or method NewNetwork)
<rogpeppe2> ./environ_whitebox_test.go:538: suite.providerSuite.testMAASObject.TestServer.ConnectNodeToNetwork undefined (type *gomaasapi.TestServer has no field or method ConnectNodeToNetwork)
<jam> wwitzel3: it appears to be a Go issue. If you branch juju-core/1.18 and then "go get" it to build the dependencies, and *then* merge my branch, your $GOPATH/pkg will have some libs in it
<jam> that should be rebuilt
<jam> but it would seem are not
<jam> and then it can't link properly
<jam> wwitzel3: perrito666: I cleaned out the dir on the bot, and the branch looks to be landing now.
<wwitzel3> jam: I wonder if we should make that part of the build process for the bot?
<mgz> rogpeppe2: I messed up the edit, only the revno change was applied, not the revid
<natefinch> mgz: for shame!
<rogpeppe2> mgz: ah
<rogpeppe2> mgz: in general, it's a not a bad idea to generate the whole file automatically
<rogpeppe2> mgz: i.e. godeps -t $(go list ./...) > dependencies.tsv
<rogpeppe2> (-t should probably be the default actually)
<rogpeppe2> (as should ./...)
<mgz> rogpeppe2: stamp on cr 83060044 please
<mgz> rogpeppe2: that would be a bad idea, because I have serv
<mgz> *several, branches on other revs
<mgz> or non-trunk
<rogpeppe2> mgz: link?
<mgz> take and
<mgz> *take an existing code review link and replace the number
<rogpeppe2> oh, ok then :-)
<mgz> https://codereview.appspot.com/83060044
<mgz> there was one up the screen a bit
<rogpeppe2> mgz: LGTM
<jam> sinzui: it has now landed
<sinzui> thank you jam
<jam> sinzui: so we just need to land the joyent stuff there
<sinzui> jam, no rush...it doesn' pass qa. I wont accept it unit it does
<perrito666> jam: wwitzel3 sorry, was having a second lunch
<perrito666> :p
<voidspace> rogpeppe2: branch proposed
<voidspace> https://codereview.appspot.com/82960044/
<jam> wallyworld: when you can, land your stuff into the lp:juju-core/1.18
<sinzui> wallyworld, Juju CI doesn't love the provider. We found several bugs preventing CI from passing. https://bugs.launchpad.net/juju-core/+bugs?field.tag=joyent-provider
<sinzui> We are blocked by bug 1300877
<_mup_> Bug #1300877: joyent fails to bootstrap due to missing shared-secret <bootstrap> <joyent-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1300877>
<mgz> sinzui: having a look as wallyworld is likely not on yet
<sinzui> mgz, It's 3:25 AM for him. If he is up, he wont be comprehensible
<sinzui> mgz, This issue might be more crucial to some devs. trunk is broken: bug 1300889
<_mup_> Bug #1300889: azure and hp cannot deploy as of r2524 <azure-provider> <hp-cloud> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1300889>
<hazmat> why are we instance polling against the provider?
 * hazmat forgot
<voidspace> see you all tomorrow
<voidspace> g'night
<voidspace> EOD
<rogpeppe2> EOD for me too
<rogpeppe2> hazmat: because a) we don't know when an instance gets an address without polling and b) addresses can change
<rogpeppe2> g'night all
<natefinch> night rogpeppe2
<hazmat> rogpeppe2, all of which is discoverable from the instance.. yes?
<rogpeppe2> hazmat: yes
<hazmat> so no need to poll.
<hazmat> the provider.. the instance already knows and can update.
<hazmat> rogpeppe2, thanks
<rogpeppe2> hazmat: the state needs to know the instance addresses
<hazmat> rogpeppe2, machine agents can update state
<rogpeppe2> hazmat: how does the machine agent find its own addresses without calling a provider method (the instance Addresses method in fact)?
<hazmat> rogpeppe2, depends on which environment its brought up in.. it can talk to the metadata source in most of those environments.. or it can query its nics addresses.
<rogpeppe2> hazmat: ah, by discoverable from the instance you mean "discoverable by code running on the instance", not "discoverable from the Instance value" :-)
<hazmat> rogpeppe2, yes
<hazmat> metadata servers are live data streams in openstack, ec2 between instance and underlying iaas
<rogpeppe2> hazmat: i have no problem with getting machines to update their own addresses - it's compatible with the current model.
<hazmat> rogpeppe2, and stops some of silliness of dos'ing the user's cloud account on rate limits.
<rogpeppe2> hazmat: yeah. we do make some effort to avoid making lots of calls now, BTW.
<rogpeppe2> hazmat: although the constants should probably be checked for reasonableness
<hazmat> rogpeppe2, its an inherent problem imo to how we're creating iaas resources..
<hazmat> rogpeppe2, creating machines individually, polling them, creating security groups per machine, checking them all the time ..
<hazmat> rogpeppe2, working on sprint topics for later this month..
<rogpeppe2> hazmat: right
<rogpeppe2> hazmat: creating machines individually probably isn't *too* much of a problem, as you don't create machines that often. but polling them definitely can be.
<hazmat> rogpeppe2, you may not.. but i do..
<hazmat> rogpeppe2, which is how i ended up finding the provisioner bug that garbage collecting machines after 150..
<hazmat> still want to source dive on that one.. but in meetings all day..
<hazmat> rogpeppe2, your right though its not as much of an issue as the instance polling or security group polling/per server stuff
<rogpeppe2> hazmat: i think the provisioner is wasteful because it assumes that something else may be actively messing with the machines under its control
<rogpeppe2> hazmat: if it assumed an environment largely static apart from through its own intervention, i think it could be a lot better
<hazmat> rogpeppe2, the entire iaas interaction model hasn't changed from pyjuju days .. i wrote that code at the first juju sprint at my house..
<rogpeppe2> hazmat: but that's definitely an assumption we'd have to think hard about
<hazmat> we've just copied the model forward..
<rogpeppe2> hazmat: yup
<rogpeppe2> hazmat: didn't want to reinvent everything...
<natefinch> hazmat: but at least you're admitting it's your fault ;)
<hazmat> natefinch, well some of it.. there were quite a few regressions nonetheless..
<hazmat> i autoretried transient provider errors for example.
<hazmat> natefinch, and i never polled provider for addresses, i had the machine agent do it in provider specific manner (ifconfig, metadata) etc.
<hazmat> natefinch, but sure i'll take responsibility for my mistakes :-)
<natefinch> hazmat: I was really just joking.  There's definitely stuff we need to improve. It's just a matter of prioritizing it.
<hazmat> natefinch, but i can't talk all the blame for those decisions..
<hazmat> we had quite some 'discussions'
<hazmat> yup
<natefinch> hazmat: once we get the newbies up to speed, we'll have a lot more throughput.  And once this damn HA stuff lands...
<perrito666> speaking of newbies going up to speed, I am trying to do "CLI: Ensure deploy --to and add-unit --to reports an error when the selected machine's provisioned networks match the service's" but I am not sure what is it about, hints?
<wwitzel3> trying to bootstrap trunk and I am getting Unable to locate package juju-mongodb .. what does that seem like I should know about that
<perrito666> wwitzel3: broken soething when switched to 1.18 and back?
<wwitzel3> perrito666: yeah, looks like one of the machines in the maas was dirty
<fwereade> perrito666, heyhey
<fwereade> perrito666, this'll be inside the state package
<natefinch> perrito666: I presume that is supposed to be "Report an error when the networks *do not* match".  Basically, if you have a machine on a specific network, and the service has a *different* network it requires, we shouldn't let you try to deploy the service to that machine
<fwereade> perrito666, yeah, what nate said
<jam> sinzui: what do you need to get a 1.17.8 out the door? *I'm* not aware of the QA failures that we should be fixing.
<perrito666> fwereade: natefinch thank you
<fwereade> perrito666, in particular take care of the fact that machines have two different sets of networks -- the include/exclude with which they were created, and the *actual* set of networks they're on
<sinzui> jam, Bug #1300889 is serious for trunk. The brokenness delays CI from testing 1.18. 1.17.8 can be any set of passing revisions. I am not demanding anything new be landed after 1.17.7
<_mup_> Bug #1300889: azure and hp cannot deploy as of r2524 <azure-provider> <hp-cloud> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1300889>
<perrito666> fwereade: I presume we are speaking about the actual set
<fwereade> perrito666, yeah, desired service networks need to match actual machine networks
<jam> sinzui: so, AIUI, we'll want to cherrypick wallyworld's Joyent provider changes into the 1.18 branch, and then not create it from trunk.
<jam> which is why I moved 1.17.7 over to the 1.18 branch.
<fwereade> perrito666, you might be able to draw inferences about possible matches based on requested machine networks alone,for the situations where the machines don't yet have actual networks, but I don't think that's a particularly major concern
<wwitzel3> Ok, new issue bootstrapping trunk .. the shared-secret for mongo in /var/lib/juju doesn't seem to be getting created.
<wwitzel3> "mongod.37017[8686]: Tue Apr  1 18:07:38.932 error getting file /var/lib/juju/shared-secret: No such file or directory"
<jam> sinzui: which brings us back to r2499 on trunk
<jam> and then a couple patches on top of that
<fwereade> wwitzel3, rogpeppe2 was going to move where that was stored?
<jam> rather than everything in trunk today
<sinzui> jam, I could do that. But as I said. the joyent test doesn't pass.
<wwitzel3> fwereade: ok, I will investigate that
<wwitzel3> fwereade: thaks
<fwereade> wwitzel3, he said it would be in the agent confg
<sinzui> jam, CI will not bless the joyent provider in its current state. We have marked the test as not required. I would claim it works
<jam> fwereade: do you know the source of why we are saying "Joyent should be in 1.18" ?
<jam> *I'm* personally ok with blessing 1.17.7 as 1.18, but there seem to be conflicting requirements
<fwereade> jam, so long as we get it into 14.04 it's not a big deal -- the theory was that it was close enough to complete to go in without stress and hassle
<jam> fwereade: from what I can tell there is stress and hastle :)
<fwereade> jam, sinzui: this is plainly not the case, so let's not block 1.18 on it
<jam> fwereade: sinzui: are *you* both ok if we bless 1.17.7 as 1.18.0 ?
<jam> should we be marshalling the troops into testing it as such?
<jam> I know of bug https://bugs.launchpad.net/juju-core/+bug/1299802 but I wasn't able to reproduce it
<_mup_> Bug #1299802: upgrade-juju 1.16.6 -> 1.18 (tip) fails <juju-core:Triaged> <https://launchpad.net/bugs/1299802>
<sinzui> jam I am okay with that
<sinzui> jam, I think we need to address bug 1299802 to say we have 1.18.0
<_mup_> Bug #1299802: upgrade-juju 1.16.6 -> 1.18 (tip) fails <juju-core:Triaged> <https://launchpad.net/bugs/1299802>
<jam> sinzui: if I could reproduce it, yes. But upgrade just worked for me.
<sinzui> jam, CI never saw this issue. Clould the bug be invalid
<jam> sinzui: I was following up on it for rogpeppe2 who filed the bug. I haven't been able to reproduce it (though I've only tried one time) .The symptoms are baffling (as we have 2 requests in a row and the second one is returning an old value.)
<fwereade> jam, anything that gets us a stable release with the last cycle's goodness in gets my approval
<fwereade> jam, +1
<jam> sinzui: so it is sort of "do we run the test N times and see if we can trigger it"? That is what CI has been doing, right?
<sinzui> jam, right it does.
<jam> sinzui: https://bugs.launchpad.net/juju-core/+bug/1300877 looks like something new from axw
<_mup_> Bug #1300877: joyent fails to bootstrap due to missing shared-secret <bootstrap> <joyent-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1300877>
<jam> at least, I didn't think we needed shared-secret until the recent HA changes.
<jam> sinzui: which implies it isn't the Joyent provider's fault
<sinzui> jam, well we will see when 1.18 is tested.
<sinzui> oh, well we will see when the additions are merged
<jam> sinzui: well.... do we want to delay 1.18 for the additions?
<jam> there is some doubt that it will be worthwhile
<jam> and we can fix trunk and just have it there.
<jam> it sounds like fwereade is happy to let the Joyent provider slip
<jam> I don't know of a specific stakeholder requirement for Joyent in 1.18
<jam> I'd rather just call 1.17.7 1.18.0 if we are happy.
<sinzui> jam, The only reason I think we want to extra revisions is because we promised something would be in 1.18
<sinzui> cmars, does bug 1290824 have to be in 1.18.0
<_mup_> Bug #1290824: juju should ask the charm store to decide the default series for a charm <juju-core:In Progress by cmars> <https://launchpad.net/bugs/1290824>
<jam> sinzui: "somebody promised someone" but I don't know who to put in those blanks.
<jam> and it sounds like fwereade isn't one of those people
<jam> and *I'm* not.
<jam> so we can wait for Ian to find out where his requirements are coming from.
<fwereade> jam, arosales cares very much that it lands for 14.04, but that is the only specific stakeholder I am aware of
<jam> fwereade: right. 14.04 is separate (IMO)
<jam> because all the stuff we're doing is critical for 14.04 :)
<sinzui> jam, It might be fair to say that 1.18.0 docs is the blocker. I think I need to get the collated release notes together, and update the docs. for the release. I need a day at least. I think 2 days is more realistic
<jam> sinzui: then we're not in a rush and can sort out the release stuff. There is bug #1282690
<_mup_> Bug #1282690: ensure joyent provider gets included in 1.18 release <joyent-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1282690>
<jam> but I have the feeling that is "it must be in trusty"
<jam> not "it must be in 1.18"
<sinzui> jam, That is my feeling too
<sinzui> 1.18.1 is easy to make
 * arosales reads back scroll
<sinzui> jam, are stopping odd-even versions with the 1.18.0 release? What do I update trunk to 1.19.a1...1.19.b1...1.19.0
<jam> sinzui: we have to do a 1.20, because 1.18 doesn't know that 1.19 would be a "stable" release.
<arosales> jam fwereade: I think this may be some building blocks that cmars is working on. But we can get around it by specifically having users state what the preference is.
<fwereade> arosales, ah, Iwas talking about joyent
<sinzui> jam, understood
<arosales> jam, fwereade: the only issue is when a charm lives in both precise and trusty and the user does not make a statement on what their preference is.
<arosales> fwereade: ah joyent, yes we need that :-)
<fwereade> arosales, cmars is hard at work on default-series as we speak :)
<arosales> fwereade: ack
<cmars> yep
<arosales> jam what are the concerns with joyent?
<jam> arosales: does it have to be in 1.18
<jam> we have a 1.17.7 release that looks nice and stable
<jam> but doesn't have it
<fwereade> arosales, joyent has no *specific* 1.18 requirement, though? AIUI it's 14.04, and we hoped it was already good enough to slot in, but it's not
<jam> do we delay 1.18 to get it in.
<arosales> can we land the majority, and bug fix post?
<arosales> wallyworld: had suggested we don't "turn it on" and land bug fixes post 1.18 to "turn it on"
<arosales> but we would need the majority of code to land, or SRU paperwork is a lot harder
<arosales> jam: better question, what is blocking Joyent?
<sinzui> jam, arosales, we might need to call joyent 1.20.0 if the additional code is not "like* a bug fix to the eyes of Ubuntu
<jam> arosales: it landed in trunk, trunk is not stable, it did not land in an otherwise-stable branch.
<jam> so it is "unknown" if there are problems
<jam> though we haven't gotten it to work in trunk
<arosales> sinzui: that is my point for landing it in 1.18. SRU'ing it in will be a lot more since it is a feature, but we can call it enablment
<arosales> jam: work required to test joyent in current stable is how much?
<sinzui> arosales, we have a test
<sinzui> arosales, the test failed because of another bug introduced into trunk a few hours ago
<sinzui> arosales, when wallyworld merged joyent into the 1.18 branch, CI will test it. We will know if it works or not
<arosales> ok, as I understand it that is the issue for landing joyent in 1.18 is the testing
<arosales> current tests are failing due to a bug outside joyent, that perhaps joyent provides
<arosales> so if we take out joyent the bug is still there
<arosales> jam: do you have a bug # ?
<arosales> s/provides/exposes/
<sinzui> Juju code and features really grew in the last 5 months. Can I say "Juju is 20% more fucking awesome" in the release notes
<arosales> ha :-)
<arosales> jam sinzui sorry for being dense here, but I'll try to summerize
<arosales> 1. There is a question of landing Joyent in 1.18
<arosales> 2. The reason is Joyent tests are not passing atm
<arosales> 3. Test aren't passing due to a new found bug which Jam is referencing that may or may not be dependant on joyent
<jam> arosales: so, I think the bigger thing is "why does it have to be in 1.18" vs "it needs to be in trusty"
<arosales> jam, sinzui ^ is this correct?
<sinzui> arosales, yes.
<arosales> if 1.20 is in trusy before final freeze I am ok with that
<sinzui> jam, 1.18.0 entered CI. I expect CI to love it like it loved 1.17.7
 * arosales was the understanding 1.18 was the final juju relase before trusty GA
<jam> arosales: we have a bunch of stuff that is also meant to be for trusty GA
<arosales> jam: to your point joyent does not have a hard dep for 1.18, but does have a hard dep for trusty GA
<jam> sinzui: fwereade: so if it is going to be ~2 days to get the docs together, we can take that time and try for a 1.17.8 w/ Joyent, but be ready to pull the plug and go with 1.17.7, does that sound fair?
<jam> arosales: I respect that getting it in early if everything looks good is better PR wise
<sinzui> jam, +1
<arosales> so as long as we have  plan in place for trusty GA I am ok with that.  Now we should be really transparent to the Ubuntu Archive Admins and let them know what is still planning on being delivered so they are not surprised with the branch post 1.18.
<fwereade> jam, sinzui: sgtm
<sinzui> jam, CI really tells us yes or no. It is easy to revert if we get a no
<jam> sinzui: r
<jam> right.
<arosales> fwereade: jam: sinzui: thanks for trying to get all the stake holder issues in. I know its a tough job.
<jam> I just mean, 1.18 isn't *delayed* if we try to get Joyent in. If it looks like it would be, we don't delay we just go with 1.17.7d
<jam> sinzui: another question for you
<jam> sinzui: arm vs armhf
<jam> do we know why the tools we build have armhf in them, but juju internally wants to call them arm
<jam> https://code.launchpad.net/~jason-hobbs/juju-core/fix-armhf/+merge/212014 is a patch towards fixing it
<jam> but we have to decide if "the tools must be right"
<jam> so we have to conform to them
<jam> or if we can change the naming on the tools.
<jam> sinzui: because I might be wrong, but if you untar one of those juju-1.17.6.1-trusty-armhf.tgz files, and have it run jujud --version
<jam> I *think* it would spit out juju-1.17.6.1-trusty-arm
<sinzui> jam, I have never understood the internal names. The tool naming script is convention/guess. Not reason
<jam> and not juju-1.17.6.1-trusty-armhf
<jam> jhobbs: do you have an Arm board that can give us an answer?
<jam> jhobbs: I *can* say that simplestreams uses armhf: http://juju-dist.s3.amazonaws.com/tools/streams/v1/com.ubuntu.juju:released:tools.json
<sinzui> jam http://bazaar.launchpad.net/~juju-qa/juju-core/ci-cd-scripts2/view/head:/assemble-public-tools.bash
<sinzui> jam, The see the get_arch() rule
<jhobbs> does this log help answer?
<jhobbs> https://code.launchpad.net/~jason-hobbs/juju-core/fix-armhf/+merge/212014/comments/503262
<jhobbs> this is from a local bootstrap on an armhf
<jhobbs> running juju-1.17.6-trusty-arm
<jam> jhobbs: that just tells me the "juju" client thinks it is 1.17.6-trusty-arm, but not what the jujud binary thinks it is inside the tarball.
<jam> However, I think given simplestreams, and other sources of information into this system
<jam> it is easier to rename all the internal-to-juju stuff to call it armhf
<jam> so the function
<sinzui> jam, Ubuntu spits out archs, the script has to decide what to do when it finds one in an archive. The script used to abort. I removed it because powerpc is supposedly legitimate from ubuntu's perspective. I assume if we made a package for the arch, it is fine to make the same tool. But juju/go has it's own thoughts on the matter
<jam> ubuntuArch() which maps from 386 => i386
<jam> needs todo the same for "arm" => "armhf"
<jam> sinzui: and somewhere it is ppc64le and somewhere ppc64el, I haven't quite sorted all that out
<sinzui> jam, sorry. I mean to say the script used to abort when it found an unknown arch. Now It warns
<sinzui> jam, exactly the issue that made me choose to warn.
<sinzui> The difference looks like a typo
<jam> jhobbs: so I think the answer is. The path of least resistance is to get "juju version" to report "juju-1.17.6-armhf", and then tool lookup, etc can just continue using armhf
<jhobbs> jam ok cool
<jhobbs> jujud --version?
<jam> jhobbs: well, they both use the same logic
<jhobbs> or juju version? or are they same thing?
<jam> so yes, both of them.
<jhobbs> ok cool, i will try to do that and resubmit the patch
<jam> sinzui: my understanding is "ppc64el" stands for Power PC 64 Little Endian
<jam> jhobbs: so it *should* be changing it in juju/arch/arch.go
<sinzui> jam. I need to increment the rev of the 1.18 branch. CI knows the version is less than what we are working on. I can use 1.17.8 or 1.18.0. I favor the latter.
<jam> and tracking down any other constants that we're missing (hopefully few)
<jam> sinzui: I think we're going to try for Joyent, so 1.17.8
<sinzui> jam, so "le" means "endian little"?
<sinzui> okay
<jhobbs> jam yeah, the patch i submitted just changed it in juju/arch/arch.go (and unit tests), which was enough to have it find the right tools
<jhobbs> but i didn't check output of juju version
<jam> jhobbs: so we used to have an "ubuntuArch" function
<jam> in version/version.go IIRC
<jam> I thought that moved to juju/arch/arch.go
<jhobbs> that maps go arch to ubuntu arch it sounds like
<jhobbs> i have to get on a call, thanks for the help!
<jam> jhobbs: NormalizeArch has a bunch of regexes, one of them maps "386" to "i386", and we have "armv.*" mapping to ARM. We just need to map "arm" to ARM
<bodie_> quick question about this diagram http://blog.labix.org/wp-content/uploads/2013/06/config-changed.png
<bodie_> we're trying to understand how Set works
<bodie_> my understanding is that apiclient Call triggers stuff on the state server
<bodie_> but it's not clear how it gets to Machine 2 and more importantly the unit
<bodie_> I'm also not certain my understanding is correct
<bodie_> I thought the units / services query the state server for changes, and download them if there are changes
<natefinch> bodie_: sorry, I don't know that part of the code well
<natefinch> bodie_:  I presume they must poll for changes
<bodie_> we touched on some of it in my email thread, but how the unit knows when there's new content on the stateservice is unclear.  I believe you are correct
<natefinch> bodie_: charms have hooks, which are just executable files, which get called when things happen.  Config-changed is a hook that gets called when the config changes.
<bodie_> I see, so the state service triggers config-changed on the unit?
<natefinch> bodie_: I'm not sure of the exact mechanism that goes from {data updated in mongodb} to {config-changed hook runs}
<sinzui> natefinch, do you have a minute to review a branch that increments the 1.18 branch version https://codereview.appspot.com/83300043
<sinzui> natefinch, nm, wrong target
<natefinch> sinzui: let me know when/if you need me to do that
<thumper> o/
<natefinch> thumper: yo
<natefinch> thumper:  what's accounts.conf?
<thumper> natefinch: the idea that we don't have configuration for environments, just accounts, like amazon or hp-cloud
<thumper> you then name the environment during bootstrap and use an account
<thumper> I'm sure there is a blueprint somewhere
<natefinch> thumper: I get it.  so separating the name from the provider info
<thumper> acj
<thumper> ack
<wallyworld> fwereade: i notice in the backscroll there is an issue with the joyent provider? i'd like to know what it is as 1. units tests pass, 2. i tested live and it worked fine with wordpress/mysql
<natefinch> thumper: so almost like extending what we have to allow you to bootstrap multiple copies of what we now consider a single environment defined in environments.yaml, just giving it an extra name on top of that name.
<mwhudson> sinzui: hi, i wanted to ask you about the status of getting juju ci going on arm64
<thumper> natefinch: kinda a bit *waves hands*
<natefinch>  thumper: lol, good enough
<sinzui> natefinch, https://codereview.appspot.com/83310043 is correct
<natefinch> sinzui: lgtm
<sinzui> mwhudson, The experience has been dismal. The AMI is under powered. 2 in 5 attempts to start it and run tests fail because the instance dies while were are using it. 3 out of 5 attempts fail because we cannot compile it. And one of the reasons it takes forever is because we need to update the image with the correct tool chain
<sinzui> thank you natefinch
<mwhudson> sinzui: AMI?
<sinzui> mwhudson, yes, http://ec2-54-84-137-170.compute-1.amazonaws.com:8080/job/walk-unit-tests-arm64-trusty/66/console
<mwhudson> oh, you are using the fast model?
<mwhudson> er foundation model
<sinzui> mwhudson, I cannot say. I am using the AMI that was built by danf
<mwhudson> oh
<mwhudson> hmf
<sinzui> ^ that instance has been up for 50 minutes and we still haven't been able to ssh in to it to do apt upgrades and installs
 * mwhudson CANNOT WAIT for hw that is not nda-ed up the ass
<mwhudson> 50 minutes seems appalling
<sinzui> mwhudson, The test can accept ssh credentials to an instance that is up or start an AMI
<sinzui> mwhudson, I haven't been able to keep an instance alive for more than 18 hours. I cannot reuse one that has the current tools :(
<mwhudson> ok
<mwhudson> sinzui: are you managing to run the tests on ppc64 ?
<mwhudson> sinzui: also, do you test amd64 but built with gccgo?
<sinzui> mwhudson, yep they are great. The same test is run by sshing to an instance
<mwhudson> cool
<mwhudson> so if i can scare some hw up, you could use that?
<sinzui> yep
<mwhudson> which is probably not likely in the short term but oh well
<mwhudson> i wonder if qemu system is there enough yet
<mwhudson> export INSTANCE_TYPE=m1.xlarge
<mwhudson> that does seem underpowered
<mwhudson> sinzui: could you try, i dunno, c3.8xlarge?
<wallyworld> sinzui: do you know anything about the discussion in the backscroll about joyent and 1.18? there's a claim joyent tests aren't passing. does that refer to CI tests? unit tests pass cause otherwise it wouldn't have landed. and I tested live with wordpress/mysql. so is the discussion just around CI setup?
<sinzui> wallyworld, good that you asked.
<sinzui> wallyworld, the main bug is also the bug that broke hp and azure deploy. joyent may be fine
<wallyworld> ah ok. is that a recent bug in trunk?
<sinzui> wallyworld, I am merging the version inc into 1.18 now. You can gather your joyent changes and merged them. The joyent test is already setup and it will run
<sinzui> wallyworld, yes r2524 landed 12 hours ago is the problem
<wallyworld> sinzui: i was expecting to be asked to merge joyent into 1.18 once 1.18 was updated with 1.17.7 revision. joyent is pretty much standalone
<wallyworld> i was xpecting that we would ship 1.18 with joyent
<wallyworld> i will merge joyent into 1.18 after breakfast
<sinzui> wallyworld, we are waiting for gobot to merge my branch. you can prepare merges now
<wallyworld> ok, will do. i was concerned when i saw what seemed to be a joyent problem (or what people were saying was a joent problem)
<sinzui> wallyworld, so was I. abentley happened be looking at both issues as I was reporting them in IRC. He reported the root cause in a different channel.
<wallyworld> sinzui: ok, np. i was worried when stakeholders like arosales might have thought joyent was broken also
<wallyworld> sinzui: do you have the link for your fancy CI dashbaord? i have misplaced it
<sinzui> wallyworld, CI is currently at http://ec2-54-84-137-170.compute-1.amazonaws.com/
<wallyworld> sinzui: i found that one. you also had a summarised one
<sinzui> wallyworld, http://ec2-54-84-218-58.compute-1.amazonaws.com:6543/ci summarises an older version we just ran
<sinzui> wallyworld, It it is several weeks behind what CI does since jcsackett has been working on other reporting issues
<wallyworld> ok, np. i liked looking at it :-)
<wallyworld> i'll use the standard jenkins one
 * thumper rants
 * thumper takes a deep breath...
<sinzui> wallyworld, any test/job running with -devel means we know it can fail, but it wont curse the revision
<wallyworld> ok
<thumper> anyone know how to have gnuflags accept the same arg multiple times?
<thumper> like the python "append" type
<thumper> so we can go "juju debug-log --include foo --include bar ..."
 * thumper wants to match pyjuju
<wallyworld> thumper: no idea. but i fear it may not be possible
<thumper> fuzz bucket
<wallyworld> rog is the best person i think
 * thumper ignores for now
<thumper> and works on the api server side
<alexisb> hehe fuzz bucket, I am going to start using that
<sinzui> wallyworld, Do you have a moment to review a branch that increment trunk to 1.19.0 https://codereview.appspot.com/83060045
<wallyworld> sure
<wallyworld> jeez, that was a big one
<wallyworld> thumper: this is is a backport of joyent into 1.18 so sinzui can run the CI tests https://code.launchpad.net/~wallyworld/juju-core/joyent-1.18/+merge/213724
 * thumper looks
<wallyworld> it's a cherry pick of 3 trunk revs
<thumper> wow
<thumper> wallyworld: lgtm
<wallyworld> thumper: sorry :-(  it's essentiall bzr merge -r 2515..2516 trunk
<wallyworld> 3 times
<wallyworld> for rev 2512, 2515, 2516
<thumper> wallyworld: cherry pick is fine IMO
<thumper> do it
<wallyworld> ok ta :-)
 * thumper goes back to debug-log
<thumper> rogpeppe2: I don't suppose you are around?
<thumper> hmm... half 10 at night
<thumper> perhaps a bit hopeful here
<thumper> natefinch: done anything with web sockets?
<natefinch> thumper: not really, sorry
<thumper> hmm...
<thumper> I'm not sure this code works...
<thumper> ah...
<thumper> found it
<thumper> that elusive line that connects everything
<sinzui> perrito666, I got the backup test to work by selecting a slower env/region.
<sinzui> perrito666, I think speed is the issue. I am going to change CI to run the test itself with my new Hp env
<ahasenack> guys, have you seen this error before?
<ahasenack> 2014-04-01 21:41:49 INFO juju runner.go:262 worker: start "lxc-provisioner"
<ahasenack> 2014-04-01 21:41:49 ERROR juju runner.go:220 worker: exited "lxc-provisioner": permission denied
<ahasenack> I used juju add-machine to add a machine, got it, then I tried to deploy services to it using lxc
<ahasenack> and it's looping on that error
<ahasenack> juju 1.17.7
<ahasenack> and then
<ahasenack> 2014-04-01 21:41:49 INFO juju runner.go:254 worker: restarting "lxc-provisioner" in 3s
<ahasenack> and it just loops
<ahasenack> https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1299588
<_mup_> Bug #1299588: LXC permission denied issue with 1.17.7 <micro-cluster> <juju-core (Ubuntu):Confirmed> <https://launchpad.net/bugs/1299588>
<hazmat> why do we still have m1.* instances defined for ec2..
<perrito666> sinzui: hey I was answering to you
<perrito666> sinzui: now I wonder if the problem is in the testing script or in the actual restore
<perrito666> if it is the second we have another.. bug
<sinzui> perrito666, The failure is in the juju-restore. I have run just it repeatedly in the past.
 * perrito666 curses out loud in spanish
<perrito666> ok, as much as I am tempted to add a 1st world problems meme on the bug I will add the new info so the bug is addressed properly and the information remains there
<thumper> ahasenack: with maas?
<thumper> sinzui: do we have maas in CI yet?
<sinzui> thumper, no.
<thumper> sinzui: is there an ETA with that?
<thumper> or are we still missing the hardware?
<sinzui> possibly next month when either hardware or a cloud that lets me run vmaas comes into existence.
<wallyworld_> sinzui: 1.18 branch now has joyent provider merged in
<rick_h_> wallyworld_: is that the last bit required to use the joyent provider or is there more to come?
<wallyworld_> rick_h_: it works. there's some followup needed to make it "perfect"
<rick_h_> wallyworld_: ok, but we should be able to grab the 1.18 branch and bootstrap a joyent env?
<wallyworld_> rick_h_: yep. i tested in trunk
<rick_h_> wallyworld_: cool thanks
<sinzui> wallyworld_, fab. 1.18 as 1.17.8 is completing tests now
<wallyworld_> rick_h_: while i have you - for a while, trunk has has public/private addresses moved off units and onto their assigned machines, even though there's a method on unit that delegates through to the machine to get the info
<wallyworld_> rick_h_: i'm doing some clean up in trunk, and now i need to change some megawatcher tests
<wallyworld_> to formalise the fact that the setter methods are now redundant
<rick_h_> wallyworld_: k, I think frankban had a little heads up but let us know and we'll keep an eye out and see if it effects the api stuff we need for machine view
<wallyworld_> which means that the tests need to change because there's no event published for units when the underlying machine address changes
<wallyworld_> i'll send an email - i think it's all good, just want to be sure
<rick_h_> wallyworld_: yea, not sure without looking into stuff more. If the proxy method is there we should be good
<wallyworld_> ok
<ahasenack> thumper: no, manual provider
<thumper> ahasenack: I'll ask axw when he starts
 * thumper goes to hit things and think how to fix his filtering problem
<ahasenack> ok
<ahasenack> thumper: I added a comment and logs to https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1299588
<_mup_> Bug #1299588: LXC permission denied issue with 1.17.7 <landscape> <micro-cluster> <juju-core (Ubuntu):Confirmed> <https://launchpad.net/bugs/1299588>
<ahasenack> thumper: news: same thing happened with aws, so no weird setup is needed
<ahasenack> I'll append to the bug
#juju-dev 2014-04-02
<davecheney> sigh, i guess I can't put off looking at simple streams bugs any longer
<davecheney> waigani: how you doing today?
<waigani> hi davecheney, well after blowing up my vm, I'm now back on track.
<waigani> so just starting to look at the tests now
<waigani> davecheney: I noticed you start your branches with 106, 111 etc - what is that?
<waigani> is there a convention I should follow for branch names?
<davecheney> waigani: we all started doing that years ago
<davecheney> for me it was because i couldn't remembver what I had comitted and what I hadn't
<davecheney> you can do whatever makes sense
<davecheney> waigani: for me the branch name is entirely to remind me
<davecheney> so they tend to be long
<davecheney> and descriptie
<waigani> okay, including the bug no. makes sense
<waigani> davecheney: you might want to add installing mercurial to your tl;dr
<davecheney> waigani: everyone has permission to update those deps
<davecheney> I think when i wrote it code.google.com was blocked bythe firewall
<davecheney> so I had to copy those deps in by hand
<davecheney> waigani: everyone has permission to update that install doc
<waigani> okay, I'll add it in
<Valduare> hows it going guys
<davecheney> Valduare: good
<davecheney> and yourself
<Valduare> doing well
<Valduare> doing photoshoot this week at the wifeâs dance studio - on irc in between :P
<Valduare> looks like few updates to my bug https://bugs.launchpad.net/juju-core/+bug/1300264
<_mup_> Bug #1300264: manual provisioning requires target hostname to be directly resolvable <manual-provider> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1300264>
<davecheney> Valduare: axw is will be in an hour or so
<Valduare> ok
<perrito666> if anyone has a moment to spare https://codereview.appspot.com/83370043
<davecheney> perrito666: quick review, please fix the typos in the descriptoin
<davecheney> you can use
<davecheney> lbox propose -edit
<perrito666> davecheney: thank you
 * perrito666 should not propose during night
<perrito666> davecheney: thank you, reproposed, if any typo is still there it might be poor English grammar on my behalf
<davecheney> https://bugs.launchpad.net/juju-core/+bug/1301085
<_mup_> Bug #1301085: state/apiserver: login_test.go intermittent failure <juju-core:Triaged> <https://launchpad.net/bugs/1301085>
<davecheney> this one is concerning
<perrito666> davecheney: thank you for the comments, will address them
<davecheney> mwhudson: how are you doing today ?
<mwhudson> davecheney: i am mostly getting distracted
<davecheney> HURRY THE GUCK UP JUJU
<davecheney> SHIT
<davecheney> these god damn tests take hours!
<jpds> davecheney: Hi.
<davecheney> jpds: speaking of frustration
<jpds> davecheney: Quite.
<davecheney> sinzui: http://paste.ubuntu.com/7192347/
<davecheney> shit, results are the same as yesteday
<davecheney> i don't understand
<davecheney> [LOG] 36.85478 DEBUG juju.environs.configstore Making /tmp/gocheck-1976235410884491574/0/home/ubuntu/.juju/environments
<davecheney> ... Panic: cannot share a state between two dummy environs; old "dummyenv"; new "dummyenv" (PC=0x3FFFB02F3E4F)
<davecheney> :0
<davecheney> brilliant :(
<stokachu> hazmat: https://github.com/liris/websocket-client/issues/73 - im going to work with upstream to get python2/3 into one codebase so we can package a python3 version easily
<axw> davecheney: I think that means two tests are trying to Prepare a dummy env without calling dummy.Reset() first
<hazmat> stokachu, awesome!
<axw> davecheney: are you just running make check, or what?
<stokachu> hazmat: looks like i can ping andreas once thats done to have a python2 and python3 package
<stokachu> i didnt see it in debian
<axw> thumper: oops, sorry, I gave you bad advice about using listener.Addr() yesterday apparently
 * thumper shrugs
<thumper> it passed the test
<thumper> :)
<thumper> interestingly when I logged it out
<thumper> it was ipv6 as a value
<thumper> http://[::]:1234
<hazmat> stokachu, tick tock on trusty, i'll merge in 2/3 support to jujuclient its a pretty tiny diff.. deployer might need a little more work
<stokachu> ok ill work on it this week, the maintainer is in japan though so time differences will be difficult
<davecheney> axw: nope
<davecheney> go test
<axw> davecheney: in just the configstore directory?
<davecheney> axw: nopt
<davecheney> nope
<davecheney> go test launchpad.net/juju-core/...
<axw> oh sorry that's from the log, not the test that's being run
<davecheney> axw: i have no idea what you're talking about
<davecheney> sorry
<davecheney> oh
<axw> davecheney: " [LOG] 36.85478 DEBUG juju.environs.configstore Making /tmp"
<davecheney> it's the package name
<davecheney> right
<thumper> wallyworld_: https://launchpad.net/bugs/1299588
<_mup_> Bug #1299588: LXC permission denied issue with 1.17.7 <landscape> <micro-cluster> <juju-core (Ubuntu):Confirmed> <https://launchpad.net/bugs/1299588>
<thumper> davecheney: is there a test memory thing I can use for an io.ReaderSeeker?
<thumper> davecheney: like bytes.Buffer
<thumper> or somthing
<thumper> or do I need to write a file
<perrito666> davecheney: thanks for your help, I rewrote a part of the script and looks definitely cleaner now :D
 * thumper writes a file...
<axw> thumper: bytes.Reader?
<wallyworld_> axw: thumper: you guys used an aws environment lately? the shared credentials i've been using appear to have been revoked
<thumper> I've not used shard creds
<axw> wallyworld_: I haven't, but I use my own account
<wallyworld_> mmmm ok. i'll dig up som other creds
<wallyworld_> after lunch. nom nom
<davecheney> thumper: bytes.Reader ?
<thumper> nm
<sinzui> wallyworld_, CI failed failed the first attempt of joyent
<sinzui> I am running it again
<waigani> so a test on ppc64el needs zip, but it is not installed by default.
<davecheney> waigani: add it to the Makefile
<davecheney> for the install-deps section
<davecheney> this is a server image
<davecheney> most people test with the desktop image
<davecheney> which has gnome fileroller
<davecheney> so I guess it has zip
<waigani> davecheney: okay, will do
<waigani> hmm, it's already there
<wallyworld_> sinzui: i'll look at the error
<sinzui> wallyworld_, I am just reporting a bug about the issue
<sinzui> wallyworld_, You can see the config for the env in cloud-city
<wallyworld_> ok. i wonder why it worked for me
<wallyworld_> i'll look at the bug
<wallyworld_> what's cloud-city?
<wallyworld_> sinzui: i see th error says quota exceeded - i had to hog smash wordpress and mysql onto the one machine cause the credentials i had only allow 2 machines
<wallyworld_> sinzui: so if your test deploys wordpress an my sql, use the --to option for the second charm
<sinzui> wallyworld_, Our test wont like exceptions. It needs 3 machines.
<wallyworld_> :-(
<sinzui> I will ask someone to give us proper resources
<wallyworld_> won't work for joyent unless we get more quota
<wallyworld_> ok
<sinzui> We have a similar problem with azure. CI failed during the release because the release + revision testing + cloud health checks can exceed the cpu limit
<sinzui> wallyworld_, At least I don't need to report a bug
<wallyworld_> sinzui: and at least it looks like stuff would have worked hopfully :-)
<sinzui> wallyworld_, yep.
<waigani> hmm so if I install zip by hand it works. If I run make install, it doesn't get installed?
<axw> wallyworld_ thumper: so, I can delete 1.16 compat stuff right?
<wallyworld_> YES!
<axw> wheee
<wallyworld_> have fun, i'm jealous
<axw> :)
<axw> I'm just making changes in cmd/juju/ssh.go, figured I'll delete the compat stuff while I'm there
<wallyworld_> yep
<sinzui> wallyworld_, I hacked the test to make an exception for the joyent provider. http://ec2-54-84-137-170.compute-1.amazonaws.com:8080/job/joyent-deploy-devel/6/console
<sinzui> ^ same error even though --to 1 was used for mysql
<sinzui> any other ideas?
 * wallyworld_ looks
<wallyworld_> sinzui: is there another orphaned machine running in that account? use the joyent daskboard to check
<sinzui> nothing in the dashboard
<wallyworld_> that happened to me and once i shut down the extra machine it worked
<sinzui> but wallyworld_ I never even saw the juju machine show up
<wallyworld_> sinzui: i can pm you the cred i used
<sinzui> there was a machine there earlier today. I deleted it
<thumper> fuckity fuck fuck
<davecheney> thumper: ?
<thumper> trying to write a test
<davecheney> :)
<davecheney> no, wait
<thumper> however the behaviour is full of async
<davecheney> :(
<davecheney> wow. such fuck
<thumper> multiple go rountines started
<thumper> I kinda need to wait to know that the tailer has started listening for new lines before I have the test write a few more
<thumper> not sure how
 * thumper thinks...
<wallyworld_> sinzui: there's a showstopper bug in 1.17.7 which i'm fixing :-(
<wallyworld_> i just confirmed it
<wallyworld_> so 1.18 will need to be held off till i fix it, which will be today
<sinzui> wallyworld_, I found the instance. The old UI doesn't show it. The beta does
<wallyworld_> ah
<wallyworld_> well that kinda sucks
<sinzui> wallyworld_, I need to get the docs completed. I wont release tomorrow
<wallyworld_> yay, gives me time to fix
<sinzui> this run gets farther, but I wonder how far this will go with just 2G ram
<wallyworld_> should be enough to bring up wordpress/mysql you'd hope
<sinzui> wallyworld_, PASS. I am going to sleep. I will find someone tomorrow to address 1 machine to test and release with
<wallyworld_> \o/
<wallyworld_> good night :-)
<thumper> wallyworld_: what was the problem?
<wallyworld_> thumper: i don't want to tell you
<wallyworld_> it was my fault :-(
<wallyworld_> permisison error ivoking new api from container provisioner
<wallyworld_> works fine from env provisioner
<thumper> ah
<wallyworld_> our logging/error reporting kinda sucks
<wallyworld_> we need to get this errgo stuff integrated and used
<wallyworld_> axw: we would expect destroy-env --force to remove the jenv file right?
<davecheney> join #go-nuts
<davecheney> oh hai!
<thumper> wallyworld_: yes we would
<wallyworld_> thumper: i'll have to see if i can reproduce later, but on trunk i did a --force and the jenv file stuck around
<axw> wallyworld_: sorry, afk. the .jenv file should be removed if destroy-env succeeds
<axw> wallyworld_: regardless of --force
<axw> wallyworld_: but --force *should* always succeed
<wallyworld_> np. yeah, it seems like it wasn't. i'll have to try and reproduce
<axw> obviously that's an ideal though
 * axw goes back afk
<thumper> OH FFS
 * thumper looks for someone to stab
<thumper> ..
<thumper> oops
 * thumper sighs
<thumper> ran 'go test' instead of 'go test -gocheck.f ...'
<thumper> oh well, all tests passed
<thumper> yay
<thumper> now for step 27
 * thumper is done for now
<jam1> axw: I'm just testing the bot for a second, I'll set your branch back to approved when I'm done
<axw> jam: okey dokey
<axw> jam: do you know what that error was about?
<jam> axw: well, I killed it once
<jam> but we also seem to have a new intermittent failure in TestRunStop
<jam> https://bugs.launchpad.net/juju-core/+bug/1301198
<axw> yay :(
<_mup_> Bug #1301198: jujud Provisioner TestRunStop no activity detected <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1301198>
<jam> and AddRemoveSet still causes problems from time to time...
<jam> not *quite* as often as it used to
<wallyworld_> jam: is the bot stalled?
<jam> wallyworld_: I was poking at it, it should be back up now
<wallyworld_> log file lasted updated 11 mins ago
<wallyworld_> doesn't *appear* to be working
<rogpeppe3> mornin' all
<axw> morning rogpeppe3
<axw> jam: did you notice this? "listen unix @/tmp/juju-core-test.ARliJS/gocheck-6334824724549167320/18/var/lib/juju/agents/unit-wordpress-0/agent.socket: invalid argument"
<axw> jam: I wonder if the TMPDIR change has broken something
<jam> I had not seen that.
<jam> axw: one thing comes to mind, the /tmp/XXX dir starts with 700 permissions.
<jam> but doesn't everything have to be running as the tarmac user anyway?
<axw> yeah, I thought the same thing and had the same conclusion...
<axw> it won't/can't change user
<axw> jam: I think we may have exceeded the path length.
<axw> max path length
<axw> max path length is 108, that is exactly 108 - I'm guessing it needs to include the null byte
<jam> axw: odd. We also had a problem where we rm -rf /tmp
<jam> :)
<jam> which I'm fixing now
<axw> :o
<jam> axw: if something before we set TMPDIR ran and failed, it would still hit the rm -rf TMPDIR
<axw> ah heh :)
<jam> so I'm setting it in another var, and only removing that one.
<jam> axw: I didn't realize normal users could rm tmp
<jam> axw: but that is why the bot stopped working, because it couldn't get /tmp access.
<axw> does it not just remove all the files they own within and then fail?
<axw> yikes, ok
<jam> axw: well /tmp was gone
<jam> I had to mkdir it
<jam> axw: I don't think that is why the original failure occurred.
<axw> jam: tmp being gone, or the invalid argument/max path limit?
<jam> axw: you're probably right about the socket thing: https://bugs.launchpad.net/unity-scopes-api/+bug/1252588
<_mup_> Bug #1252588: UNIX domain socket path name limit <unity-scopes-api:Fix Released by michihenning> <https://launchpad.net/bugs/1252588>
<axw> mk
<jam> axw: so I can make my TMPDIR prefix a bit shorter, but we were only just lucky that it was working before.
<axw> indeed, if ever moved away from /var/lib/juju...
<jam> axw: like with the namespacing work?
<jam> /var/lib/juju-jameinel-local ?
<axw> namespace only affects the log dir
<axw> data-dir is in $HOME for machine-0 in the local provider
<axw> but that does not allow units
<jam> axw: so, I can reproduce directly by making TMPDIR really long and running that test.
<jam> I made them shorter, but it still seems like we're going to get bitten sometime.
<axw> yeah. I dunno how we're going to fix that one... perhaps the socket should be in /var/run or something
<axw> that's no good for tests, but we could override it for tests
<vladk> dimitern: morning
<dimitern> morning vladk
<jam> morning vladk and dimitern
<vladk> jam: morning
<dimitern> morning jam
<jam> axw: did you see the bug about rev 2524 ?
<axw> not yet
<axw> oh
<jam> axw: https://bugs.launchpad.net/juju-core/+bug/1300889
<_mup_> Bug #1300889: azure and hp cannot deploy as of r2524 <azure-provider> <hp-cloud> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1300889>
<axw> eh
<jam> no shared-secret file
<jam> error getting file /var/lib/juju/shared-secret: No such file or directory
<axw> gah, because it doesn't exist during cloud-init
<jam> axw: at the least, your patch should probably have included a logger.Debugf() when we were writing the file.
<jam> axw: ah, because we write the Upstart during cloud init, but we don't run the rest of bootstrap stuff until we ssh into the machine.
<axw> yeah, that was a bit dumb. I'll fix it...
<jam> axw: so I think that means we just need to back out your patch until EnsureMongoServer is writing the file at a later time
<jam> because we *don't* want to write the contents of shared-secret to cloud-init
<axw> jam: yeah. I'll just take the --keyFile bit out of the upstart script for now?
<jam> axw: that's probably ok
<jam> axw: I'll note, changes during bootstrap is something that you should probably test live
<axw> jam: I did run with local, but have no idea why it worked now
<jam> axw: local is special
<jam> for a lot of things
<jam> machine-0 is your $HOST
<jam> so not brought up via cloud-init
<axw> mongo is still started before the machine agent though
<jam> axw: I'm pretty sure we also don't "ssh localhost"
<jam> axw: sure but the bootstrap steps probably happen at a different time.
<axw> jam: we don't ssh localhost, but we run the same script via bash
<axw> it's now very similar to cloud bootstrap
<axw> anyway
<axw> I will investigate, and test with azure
<jam> kk
<jam> I have the feeling it is broken on EC2 as well, but I haven't tested that
<jam> I don't see any reason why it would be special
<jam> wallyworld_: did you get your Joyent changes backported to the 1.18 branch?
<wallyworld_> jam: yep, and CI tests passed ok \o/
<jam> wallyworld_: nice, so we get a 1.17.8 today ?
<wallyworld_> as soon as my bug fix gets backported but i need to get in landed in trunk first
<jam> wallyworld_: that's what you're landing now?
<wallyworld_> yep
<jam> p:~wallyworld/juju-core/container-provisioner-retrywatcher
<jam> k,
<jam> Bot is running it again
<jam> you had a test suite timeout
<wallyworld_> great
<wallyworld_> as soon as it lands, i'll backport, probably after dinner
<jam> the other failures were probably just my changes, so I'll keep an eye on it.
<wallyworld_> which is imminent
<voidspace> morning all
<rogpeppe> voidspace: mornin'
<rogpeppe> voidspace: hangout?
<axw> morning voidspace
<axw> rogpeppe: https://codereview.appspot.com/83500043 when you're free
<rogpeppe> axw: looking
<voidspace> rogpeppe: sure, in a minute or two
<rogpeppe> axw: reviewed
<voidspace> rogpeppe: coffee first :-)
<axw> thanks
<axw> rogpeppe: so, using State and it working is just lucky (racy)?
<axw> I never quite State vs. BackingState
<axw> I never quite understood
<rogpeppe> axw: how long did the tests take to run?
<axw> I never quite English
<rogpeppe> axw: it's really a failure of vision
<rogpeppe> axw: because you talk to a specific State to sync it, but in this case we've got several
<rogpeppe> axw: so you need to prod the right one into action
<rogpeppe> axw: for a while now, i've wanted to change the syncing scheme so it's global
<axw> rogpeppe: didn't take particularly long to run. it makes sense to change it, anyway
<jam> wallyworld_: your patch has landed.
<wallyworld_> jam: the one in 1.18? i submitted that just before dinner
<wallyworld_> almost finished eating :-)
<wallyworld_> i hadn't checked back
<jam> wallyworld_: no, the one in trunk, I guess you were faster than I :)
<wallyworld_> yeah, i am keen to get 1.18 fixed
<wallyworld_> so i can relax
<jam> wallyworld_: bot is currently processing axw's gocrypto change, probably will do yours next
 * wallyworld_ taps fingers impatiently
<voidspace> rogpeppe: I'm in the hangout
<frankban> morning all, is the joyent provider working in trunk? I am trying it and bootstrapping hangs on "Bootstrapping Juju machine agent"
<rogpeppe> voidspace: i suspect my net connection may be working even less than yesterday...
<voidspace> rogpeppe: that's impressive :-)
<rogpeppe> voidspace: and there's a BT van outside, so it's quite possible it'll go away completely soon
<rogpeppe> fwereade: what's the deal with utils.IsNotExist ?
<axw> frankban: there's a bug on trunk that affects all providers, I'm fixing it right now
<fwereade> rogpeppe, exactly what it looks like: if foo is a file, statting foo/bar does not give an error that satisfies IsNotExist :/
<fwereade> os.IsNotExist, that is
<frankban> axw: cool, FYI 1) ec2 works well and 2) bootstrapping joyent panics if key-file is not specified in the environments.yaml file
<frankban> panic: interface conversion: interface is nil, not string on /provider/joyent/config.go:121
<axw> frankban: ec2 worked? ok. I think there's a race condition. key-file is something specific to joyent... over to wallyworld_ :)
<frankban> axw: yes, I was able to bootstrap that correctly earlier (saucy, revno 2535)
<frankban> axw: ec2 I mean
<rogpeppe> i'm just losing internet connection while an engineer works on the line
<rogpeppe> back soon i hope
<axw> frankban: if you want to get unstuck quickly, then try merging lp:~axwalk/juju-core/lp1300889-disable-mongo-keyfile
<axw> (still uploading...)
<jam> wallyworld_: bot is running your 1.18 branch now
<jam> started 14 min ago
<jam> fwereade: because ENOTDIR != ENOEXIST ?
<jam> wallyworld_: bots done
<frankban> axw: trying joyent with your branch
<jam> wallyworld_: looks like it was happy with your patch
<jam>  2253 Ian Booth	2014-04-02 [merge]
<jam>       [r=wallyworld],[bug=1299588] Backport r2536 to fix container provisioner retry issue.
<jam> rogpeppe: I did end up going with "godeps before the bot runs", thanks for the suggestion.
<jam> I trust godeps enough now, I'm still not sure about a go get -u in there, though.
<rogpeppe> jam: i thought i'd already changed it to do that actually
<jam> rogpeppe: if you did, it didn't end up in the config I saw
<jam> rogpeppe: maybe you did but didn't push the config back into swift ?
<rogpeppe> jam: ah, yes, you're right, i didn't
<rogpeppe> jam: so i guess you (or someone) overwrote the config i'd done
<rogpeppe> jam: oh well
<jam> rogpeppe: I did, as I needed to update it, so I updated my local copy from swift
<rogpeppe> jam: i've got a program that enables you to do a juju set with the same data that juju get returns
<jam> frankban: joyent panic is bug #1300846, right?
<_mup_> Bug #1300846: Juju crashes bootstrapping joyent <bootstrap> <joyent-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1300846>
<frankban> jam: yeah it seems to be that bug
<rogpeppe> voidspace: MgoInstance.Port returns the same port that is inside MgoInstance.Addr
<voidspace> rogpeppe: right
<rogpeppe> voidspace: so no need to parse
<voidspace> rogpeppe: cool, that's nicer
<voidspace> rogpeppe: so one of your suggestions (agent/agent.go:528)
<voidspace> rogpeppe: you suggest gating on SharedSecret == "" instead of StatePort == 0
<rogpeppe> voidspace: i can hear you pretty well BTW
<voidspace> rogpeppe: how is that any better or different
<frankban> axw: after merging your branch, bootstrapping joyent succeeded, thank you!
<axw> frankban: cool, no worries
<voidspace> rogpeppe: if you're talking I can't hear you :-)
<rogpeppe> voidspace: ok, i'll give up on the hangout :-)
<voidspace> rogpeppe: if StatePort == 0 but SharedSecret != "" we're just as screwed as StatePort != 0 but SharedSecret == ""
<rogpeppe> voidspace: so, i see SharedSecret as slightly more fundamental, but you're probably right that it doesn't matter much
<voidspace> rogpeppe: so they seem directly equivalent checks
<rogpeppe> voidspace: the other possibility i thought of was to store a *StateServingInfo instead
<voidspace> rogpeppe: I'm happy to make the change
<voidspace> rogpeppe: that would be less arbitrary
<rogpeppe> voidspace: then the test could be "if not nil"
<voidspace> rogpeppe: yep
<rogpeppe> voidspace: yeah, otherwise they're both pretty arbitrary
<voidspace> but think of the performance hit we take from the extra level of indirection!
<voidspace> rogpeppe: ok, I'll look at making that change
<wallyworld_> frankban: axw: key-file is supposed to be optional and default to ~/.ssh/id_rsa. if it doesn't do that, then that's a bug :-(
<rogpeppe> voidspace: ha ha
<frankban> wallyworld_: yeah, it seems to be  bug #1300846
<_mup_> Bug #1300846: Juju crashes bootstrapping joyent <bootstrap> <joyent-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1300846>
<jam> wallyworld_: sounds like we have a bug :)
<wallyworld_> we can still release 1.18 with that unresolved but documented in the release notes
<wallyworld_> just ensure key-file is set
<wallyworld_> it will be fixed for 1.20
<frankban> wallyworld_: so, the mandatory fields are sdc-user, sdc-key-id, manta-user and manta-key-id, correct?
<wallyworld_> from memory yes
<wallyworld_> in oractice key-file will also be set
<wallyworld_> practice
<frankban> wallyworld_: yeah
<wallyworld_> because you don't necessarily want to use your default private key with joyent
<wallyworld_> you want to generate one for the purpose
<wallyworld_> hence the bug got missed also in CI
<voidspace> rogpeppe: made all those changes except switching to *params.StateServingInfo
<frankban> wallyworld_: agreed
<voidspace> rogpeppe: pushed and running tests
<rogpeppe> voidspace: cool
<wallyworld_> frankban: so yeah, not a show stopper :-)
<wallyworld_> but will be fixed
<frankban> wallyworld_: ack, thank you
<wallyworld_> np, sorry about the bug
<wallyworld_> i was a bit rushed to make the 1.18 release
<jam> wallyworld_: the bug seems pretty trivial to fix, even for 1.17.8
<jam> just the line that looks at private-key and then at key-file needs to be aware that key-file may be empty
<wallyworld_> jam: yes, but if we wnt to ship real soon now i may not get it done as it's way pat my EOD
<wallyworld_> past
<jam> wallyworld_: k, I'll poke at it.
<wallyworld_> jam: i'd normally look at it but am way tired tonight
<wallyworld_> if you get stuck let me know and i'll do it after the standup
<jam> np
<jam> wallyworld_: so *should* it default to ~/.ssh/id_rsa ?
<jam> because internally it defaults to ""
<jam> ah I see
<jam> they have a bunch of logic to pull it from the ENV or use a different default
<jam> they just reference it before they've done those steps
<wallyworld_> yeah
<wallyworld_> it got messy
<wallyworld_> it needs to be "" so the env can override if necessary
<wallyworld_> or something like that
<jam> wallyworld_: right, they just fix it up in validateConfig, but apparently we call prepareConfig without validating first.
<wallyworld_> jam: i did a fair bit of refactoring in that area to bring stuff into line with other providers, so i likely was complicit in the bug
<wallyworld_> maybe a call to validate is all that is required, not sure
<wallyworld_> bbiab, got to put the kid to bed
<rogpeppe> voidspace: here's the followup to your branch: https://codereview.appspot.com/83530043
<axw> rogpeppe: is "HA: make APIAddresses use state.APIAddresses, not state.APIAddressesFromMachines" still relevant?
<rogpeppe> axw: yes
<rogpeppe> axw: it should be a totally trivial change
<axw> what uses APIAddresses rather than APIHostPorts?
<rogpeppe> axw: nothing should be using APIAddressesFromMachines any more
<rogpeppe> axw: ah, i may well be talking about APIHostPorts here :-)
<axw> ah, so uniter and deployer use it for initial addresses... yeah ok.
<axw> I can take a look at that next if nobody else does
<axw-afk> can someone please take a look at https://codereview.appspot.com/83270045/, which fixes https://bugs.launchpad.net/juju-core/+bug/1300889
<_mup_> Bug #1300889: azure and hp cannot deploy as of r2524 <azure-provider> <hp-cloud> <regression> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1300889>
<rogpeppe> axw-afk: i'm on it
<voidspace> rogpeppe: yep, looks good
<rogpeppe> voidspace: have you proposed yours yet?
<voidspace> rogpeppe: about to
<rogpeppe> BT engineer found the problem with my phone line
<rogpeppe> a intermittent break in a copper line at the top of the telegraph pole opposite the house
<voidspace> good he found it
<rogpeppe> voidspace: yeah
<rogpeppe> voidspace: now i'll just need to phone talktalk and get them to reset the SNR on the line, and hopefully should be back to normal
<voidspace> rogpeppe: just switching to using *params.StateServingInfo
<voidspace> it's not much work
<voidspace> just a couple of changes
<rogpeppe> voidspace: cool
<dimitern> fwereade, mgz, https://codereview.appspot.com/83070047/ quick review adding machine NICs?
<rogpeppe2> yay, internet now fixed
<jam> rogpeppe2: now we just have to figure out who your doppleganger is :)
<fwereade> dimitern, couple of tweaks -- just add a separate collection/doc for configured networks and different types for internal/external usage
<fwereade> dimitern, hum, another thought
<dimitern> fwereade, i forgot to add NetworkName to the struct
<fwereade> dimitern, mgz: how does this stuff interact with mgz's Network type?
<fwereade> dimitern, mgz: I am worried that there should be some link between the two
<voidspace> rogpeppe2: I think this change makes one code path untestable
<voidspace> rogpeppe2: or very hard to test
<dimitern> fwereade, what's that type?
<dimitern> mgz, around?
<fwereade> dimitern, mgz: sorry, I think I mean instance.Address -- I just feel like there probably ought to be some connection that isn't just coincidental, but maybe it's not the time quite yet
<dimitern> fwereade, I think it's not the time yet
<fwereade> dimitern, mgz: in particular the scope stuff feels like it ought to be reflected somehow
<fwereade> dimitern, mgz: but I'll accept that suggestion if mgz concurs ;)
<dimitern> fwereade, and what do you mean by "different types for internal/external usage" ?
<perrito666> good morning
<fwereade> dimitern, if we use the same struct in the DB and in the exported methods, then it's hard to track the scope of changes to that type
<dimitern> fwereade, ok, I'll add a separate networkInterfaces collection linked to a machine
<fwereade> dimitern, if there's a translation layer we have a place to deal with schema changes as they happen, if there isn't it's way too easy to make schema changes without knowing
<fwereade> dimitern, eg changing charm.Meta should not magically change our schema, but it does :/
<dimitern> fwereade, I see, good point!
<voidspace> rogpeppe2: so making configInternal.servingInfo into a *params.StateServingInfo
<voidspace> rogpeppe2: leaves one code path untestable
<voidspace> rogpeppe2: but only because it's not possible for that code path to be triggered
<voidspace> rogpeppe2: so I'm removing the test
<voidspace> rogpeppe2: and I'm also going to ignore the "ok" return value from config.StateServingInfo()
<voidspace> rogpeppe2: because it's not possible for it to return false in InitializeState
<rogpeppe2> voidspace: ah, i have internet again!
<voidspace> rogpeppe2: cool
<voidspace> rogpeppe2: proposal updated
<voidspace> https://codereview.appspot.com/82960044/
<rogpeppe2> voidspace: lookin
<rogpeppe2> g
<wwitzel3> updated proposal https://codereview.appspot.com/83150043/ .. if someone can take a look
 * perrito666 curses hi decaf coffee and its lack of ... well caf :p
<wwitzel3> rogpeppe2, perrito666 ^
<perrito666> wwitzel3: looking
<rogpeppe2> wwitzel3: will do
<fwereade> jam, standup?
<wallyworld_> fwereade: mgz: as far as i can see, there is no remote API on machine to get Addresses() so that would need to be added before we ship 1.18
<fwereade> wallyworld_, yeah, I think we'd need that, dammit
<wallyworld_> so a blocker for 1.18, needs to be done post haste
<rogpeppe2> axw-afk: this branch fixes your test failure: lp:~rogpeppe/juju-core/axwalk-lp1300889-disable-mongo-keyfile
<axw-afk> rogpeppe2: thanks, I was about to look into it.
<axw-afk> rogpeppe2: will you be sending an MP?
<rogpeppe2> axw-afk: i suggest just pulling it into your branch and reproposing
<jam1> axw-afk: if you have time now, do so, otherwise rogpeppe2 I would just suggest you push it up, mark it for merging and approve it.
<jam1> At least, if the changes are obvious
<axw-afk> rogpeppe jam1: right, will do. just about to have dinner, will do that later
<jam1> sure, just setting a general policy that if it is after-hours for someone, and you can fix their patch, its fine, unless you think it is controversial, go ahead and propose and land the fixed versio.n
<rogpeppe> axw-afk: i could easily propose it as a separate branch - it's independent of yours
<rogpeppe> axw-afk: TestAddressChange was quite broken before
<rogpeppe> axw-afk: (i should've picked it up)
<wallyworld_> jam: i +1'ed your key-file branch
<jam1> wallyworld_: thx, want to do a quick followup on :https://code.launchpad.net/~jameinel/juju-core/1.18-private-key-path-1301315/+merge/213818
<wallyworld_> sure
<axw-afk> rogpeppe: finished dinner, I'll merge it in now.
<rogpeppe> axw-afk: you don't need to - i'm just proposing it as a separate fix
<axw-afk> ok
<wallyworld_> jam: done, perhaps with a comment fix
<perrito666> brb
<rogpeppe> axw-afk: https://codereview.appspot.com/83590043
<natefinch> fwereade: aren't we working on getting rid of using git with charms?  re: the fat charm thread in email?
<axw-afk> rogpeppe: thanks for that. reviewed
<rogpeppe> axw-afk: ta
<jam1> natefinch: it won't be in 1.18 for sure, it may not be in trusty
<jam1> there is some code out there that fwereade might get done.
<natefinch> jam1: ok, I remember he'd mentioned working on it, but didn't know the status.
<wwitzel3> natefinch: https://codereview.appspot.com/83150043/ when you can
<jam1> wallyworld_: you mentioned changing the MANTA_KEY_FILE env var.
<jam1> should we?
<jam1> or is that coming from Joyent as the recommended way of setting it?
<wallyworld_> jam: nah, that was us. i think it needs to be consistent
<jam1> (like we just use the standard OS_ENV* for openstack/ec2, we didn't come up with our own.)
<jam1> wallyworld_: k, if we created it, I'm happy to set it to something else.
<wallyworld_> i created it :-) to match the attr name
<jam1> wallyworld_: MANTA_PRIVATE_KEY_PATH or MANTA_PRIVATE_KEY ?
<wallyworld_> path i think to match the attr?
<rogpeppe> axw-afk: are you doing "HA: make APIAddresses use state.APIAddresses, not state.APIAddressesFromMachines" ?
<jam1> wallyworld_: yeah, I'm not really sure what a standard env var would be, so I'll go with just matching the var name.
<jam1> wallyworld_: PATH in env vars tends to be a list of paths to search
<jam1> but , meh
<wallyworld_> i'm hopeless at naming things
<wallyworld_> hmm, maybe just MANTA_PRIVATE_KEY_FILE
<wallyworld_> i sorta with the ca stuff used -file as well
<wallyworld_> wish
<mgz> dimitern: I need to pick something up on the vlan work, what do you want me to do?
<dimitern> mgz, well, the thing is most of what's left depend on changes around StartInstance
<dimitern> mgz, except maybe the add-machine card
<dimitern> mgz, that's can be done in parallel with the other related CLI card
<axw-afk> rogpeppe: not tonight, but I will tomorrow if it's still up for grabs
<mgz> I can take that one
<rogpeppe> mgz: if you have a moment to do it, that would be great
<mgz> rogpeppe: I'll have a quick look
<rogpeppe> mgz: it *should* be fairly trivial, but it may affect tests
<mgz> rogpeppe: whihc APIAddresses?
<rogpeppe> mgz: common.APIAddresses.APIAddresses
<rogpeppe> mgz: in state/apiserver/common
<mgz> k
<jam1> wallyworld_: proposal updated, care to have another pass ?
<wallyworld_> sure
<jam1> wallyworld_: https://codereview.appspot.com/83530044/
<wallyworld_> jam: land it i reckon
<jam1> wallyworld_: done, thanks
<jam1> sinzui: if you have a CI test for Joyent, you'll need to update your config. the config entry "key-file" is now named "private-key-path".
<jam1> (at least, once this branch lands in the bot)
<sinzui> thank you. I will
<jam1> That will be in the 1.17.8 release, and I'll merge it into 1.19
<sinzui> jam, is private-key still valid
<jam1> sinzui: yes
<jam1> the rename was just to make it more consistent with other "youcan specify the file or the content"
<mgz> rogpeppe: something like http://paste.ubuntu.com/7194149/
<mgz> running tests now
<bodie_> greetings
<mgz> hey bodie_
<mgz> tyop...
<mgz> rogpeppe: actualy compiles http://paste.ubuntu.com/7194162/
<rogpeppe> mgz: that's the general idea
<rogpeppe> mgz: it's not quite right though
<rogpeppe> mgz: i think it should be addrs := make([]string, 0, len(apiHostPorts))
<mgz> do we want multiple addresses per state server if they exist?
<rogpeppe> mgz: good question.
<rogpeppe> mgz: well, we don't need them currently, and we want to deprecate APIAddresses
<rogpeppe> mgz: so i'd say just stick with the existing semantics from APIAddressesFromMachines
<mgz> good call on make, legacy of first version where I forgot "" was a valid return value but not something we wanted to pass down
<jam1> can I get a review of the trivial patch: https://code.launchpad.net/~jameinel/juju-core/1.18-always-ensure-curl-1300321
<mgz> jam: looking
<mgz> noooooo
<mgz> not again
<jam1> mgz: ?
<mgz> I wish we could just freakin' apt
<mgz> jam1: dimitern had that line, I told him to remove it as it's in the base image, and hey, without apt sanity that turns out to have been bad advice
<jam1> mgz: well, we're apt installing all of them
<jam1> mgz: :)
<jam1> mgz: note that "juju-local" doesn't depend on curl, because we didn't realize we needed it (being installed in base)
<jam1> mgz: as such, we *still* would have been broken for manual
<mgz> right, but we can fix that dep in the juju-local package :)
<jam1> mgz: and we can fix this dep in the place where it is given :)
<mgz> jam1: lgtm'd
<jam1> thx
<jam1> I guess I need to go get a drobox account now: http://blog.canonical.com/2014/04/02/shutting-down-ubuntu-one-file-services/
<mgz> why am I getting test functions not defined...
<mgz> http://paste.ubuntu.com/7194249/
<ahasenack> is there a scenario where config-get would fail with "settings not found"?
<ahasenack> http://pastebin.ubuntu.com/7194251/
<ahasenack> that is inside config-changed (!)
<natefinch> jam1, mgz: what do we use curl for?
<jam1> natefinch: downloading the juju .tgz
<natefinch> jam1: ahh, yeah
<mgz> anyone got any idea on my test build error with trunk above? ^
<natefinch> mgz: this, I think: https://github.com/juju/testing/blob/master/patch.go
<natefinch> I think we've moved to only using github for that package?
<mgz> ...why does godeps not complain...
<natefinch> I think the problem is that godeps only knows what dependencies you tell it about
<natefinch> you're using a dependency it doesn't know about
<natefinch> (launchpad.com/juju-core/testing)
<mgz> but it's trunk, I've not touched anything about this...
<natefinch> oh weird
<natefinch> ok, so trunk is still using the one from launchpad
<natefinch> mgz: is that on your local machine?  Try blowing away $GOPATH/pkg ... sometimes old stuff gets stuck in there
<mgz> sounds like a good plan
<mgz> r2448 seems like a lie
<wwitzel3> rogpeppe: https://codereview.appspot.com/83150043/
<natefinch> wwitzel3: sorry I missed that review earlier
<rogpeppe> fwereade, dimitern, wwitzel3, natefinch, mgz: here's the singular worker implementation. reviews much appreciated:  https://codereview.appspot.com/83300047
<natefinch> rogpeppe:  looking
<wwitzel3> natefinch: np
<rogpeppe> voidspace: lp:~rogpeppe/juju-core/536-machineconfig-stateservinginfo
<wwitzel3> https://codereview.appspot.com/83130045/ reviews welcomed from anyone with a moment, pretty straightfoward.
<rogpeppe> natefinch: how's tricks?
<voidspace> rogpeppe: https://pastebin.canonical.com/107661/
<natefinch> rogpeppe: sorry, had to do an early lunch, because I'm doing an interview in 3 minutes.  So.... yeah.  I updated the namespace proposal to include the changes to check the contents of the upstart config instead of using a version.
<natefinch> rogpeppe: https://codereview.appspot.com/81980043/
<natefinch> rogpeppe:  I didn't get a chance to totally review the singeular stuff... I'll finish up after the interview
<rogpeppe> natefinch: ta
<sinzui> jam, fwereade, juju-gui see this bug as a blocker for 1.18.0 1301464
<sinzui> bug 1301464
<_mup_> Bug #1301464: The mega-watcher for machines does not include containers addresses <addressability> <api> <juju-gui> <juju-core:Triaged> <https://launchpad.net/bugs/1301464>
<sinzui> I will also invite thumper to comment on it when he comes online
<perrito666> I am supposed to implement a failure if a requested service machine does not have the networks requested in the networks/not-networks params, but I cannot know that until the machine is up, what should I do with the machine in case it fails?
<perrito666> (I feel I might be missing something)
<mgz> perrito666: so, add-unit and deploy are both in the context of a service, where we have networks/exclude-networks as context
<mgz> and with --to we are specifying a machine
<mgz> which, now in the case of maas, we can look up the networks it actually has
<perrito666> ahh, indeed
<mgz> beccause that machine must already exist for --to to make sense
<mgz> I agree it's a bit confusing without add-machine having the networks/exclude-networks params yet, so there's no clear two-step process
<bodie_> I don't understand why state/api/client_test.go is so different from client.go
<bodie_> is it just not fully implemented?
<bodie_> oh, this bug is mentioned
<bodie_> https://bugs.launchpad.net/juju-core/+bug/1217282
<_mup_> Bug #1217282: api.Client tests should be in api not state/apiserver/client/ <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1217282>
<mgz> bodie_: yeah, it's mostly just an arrangement thing
<fwereade> sinzui, do you overlap with wallyworld_?
<fwereade> sinzui, we talked about that a little bit this morning with him, I think he's poised to do more tonight
<sinzui> fwereade, I do. I will show him the bug
<fwereade> sinzui, brilliant, tyvm
<jam> sinzui: so for bug #1301464... I'm pretty sure we've never had it working the way they described, so it doesn't seem like a regression.
<_mup_> Bug #1301464: The mega-watcher for machines does not include containers addresses <addressability> <api> <juju-gui> <juju-core:Triaged> <juju-core (Ubuntu):Triaged> <juju-quickstart (Ubuntu):Triaged> <https://launchpad.net/bugs/1301464>
<jam> I can see why it could be important, but it is a little bit late, unless someone other than myself has an obvious way of fixing it.
<fwereade> jam, isn't the problem that we *used* to have unit addresses... but now that we don't, the lack of machine addresses is a stark and serious problem
<rick_h_> jam: fwereade this is the bug frankban is going to work on. We need it for quickstart. This has broken quickstart
<jam> rick_h_: so i'd like to understand what the regression is
<jam> what *was* working that now isn't
<frankban> fwereade, jam: that's my understanding. either we reinstate unit addresses (for local envs, ec2 seems to have them) or we include containers addresses in the MachineInfo AFAICT
<rick_h_> frankban: it was the lxc ip address fetching right?
<frankban> we used to have PublicAddress on the UnitInfo: with the 1.18 branch it seems an empty string is returned by the mega-watcher if the local provider is used
<frankban> rick_h_, jam, fwereade: from our perspective, reintroducing them on unit info is ok for now. IIUC the path is to remove the addresses from the UnitInfo though. So the problem might be solved including containers addresses in the MachineInfo.
<frankban> rick_h_, jam, fwereade: I am not sure about that, but I guess the problem there is that MachineInfo.Addresses only include addresses obtained from the provider. I'd expect containers ones to be included if we also merge in the slice the machine addresses (in a way similar to what's done in *state.Machine.Addresses()).
<fwereade> frankban, am I right in thinking you were already in communication with wallyworld_ about this general issue?
<frankban> fwereade: yes
<fwereade> frankban, I'm hoping it's easier, because we can now get lxc containers' addresses from the provider, iirc
<fwereade> frankban, lxc-ls --fancy
<fwereade> or whatever it is
<rick_h_> fwereade: yes, wallyworld sent an email on the matter last night and he and frankban have been in communication on requirements
 * rick_h_ checks what list that thread was in
<fwereade> frankban, just to be clear: if all machines reported all their addresses in the AllWatcher (including scope, ie public/private), that would be sufficient?
<frankban> rick_h_: is in the private emails
<frankban> fwereade: I think so, at that point we need to fix quickstart and the GUI to use the new source of information if available. The important thing is that info to be available to API clients in some way. MachineInfo already has an Addresses field as a slice of instance.Address, so merging all the addresses there should be sufficient
<fwereade> frankban, ok, that is *hopefully* a relatively trivial bug then
<fwereade> frankban, ...or maybe not so much, gaah
<frankban> fwereade: I am checking my assumption wit this change: http://pastebin.ubuntu.com/7195189/ (that's not a fix, just a check for the contents of MachineAddresses)
<fwereade> frankban, yeah, the issue appears to be that local instances still don't report addresses
<bodie_> can anyone help me understand what's going on in state/apiserver/client/ ?
<frankban> fwereade: with that change the watcher reports the ipv4 address for machine 1 (lxc): http://pastebin.ubuntu.com/7195204/
<bodie_> I think I get that the api client is using 'call' to trigger methods from those files on the apiserver, but I'm not following how that relates to state/api/client
<voidspace> g'night all
<voidspace> EOD
<fwereade> bodie_, state/api/client is the minimal implementation necessary to get the CLI to work
<frankban> fwereade: the real fix could be something like: 1) have a function receiving a machine doc and returning the merged addresses, 2) make Machine.Addresses use that function (passing m.doc) and 3) update the megaewatcher to use that function (passing the backingMachine)
<fwereade> frankban, ha, yes, ofc, that sounds like exactlythe right thing to do
<fwereade> frankban, I'd forgotten we stored machine-reported addresses separately from provider-reported addresses
<fwereade> frankban, the plan was basically to grab all the info we can and do our best to merge the two into something sane
<fwereade> bodie_, sorry, actually, I'm not 100% sure I understand your question, would you restate please?
<bodie_> thinking about how to do so
<fwereade> frankban, clearly that last step got missed somehow :/
<frankban> fwereade: yeah, the only change seems to be: dong that at the document level and not at the state.Machine level.
<fwereade> frankban, I'm not keen on discarding any of that info, I think it's a matter of a func for the megawatcher rather than something at machineDoc level
<wwitzel3> natefinch: you free?
<bodie_> I see a bunch of methods in /state/api/client.go which are used by Commands in /cmd/juju/ via their 'call' method to signal the API server to do things
<frankban> fwereade: I was just thinking about having a function that can be used both by Machine.Addresses and by the megawatcher, the former at that point being just a wrapper
<fwereade> bodie_, yeah; they map to methods on the Client type in apiserver
<fwereade> frankban, ah, gotcha: yes, that sounds ideal
<bodie_> OK
<jam> fwereade: frankban: you realize the reason we store them separately is because otherwise you'd only end up with private addresses (what you can read from eth0 != public address).
<bodie_> so the files in /state/apiserver/client/* are where those Client functions are defined
<bodie_> I think I'm confused between the apiclient "Client" and the apiserver "Client"
<jam> bodie_: so state/apiserver/* is the server-side of an RPC, and state/api/* is a wrapper around those RPCs to make them look like just function calls.
<fwereade> jam, yes, we definitely need to store those differently-sourced addresses separately
<jam> bodie_: so cmd/juju/add.go makes a "myconnection.GiveMeSomething()" which under the covers does a RPC Call() to 'MyObject.GiveMeSomething'
<jam> bodie_: it is called "Client" because it is the API for GUI/CLI Clients, not because it is the actual client portion of a client-server relationship.
<bodie_> OK.  so if, for example, I want to understand how Set works, I would start in /cmd/juju/set.go -- which calls /state/api/client.go 's "ServiceSet" function, which calls NewServiceSetForClientAPI via RPC on the apiserver
<frankban> jam: yeah, I know that. My proposal would only merge them when they are sent by the mega-watcher. API client can then just ignore the address they are not interested in by looking at the NetworkScope
<bodie_> jam, I see.  I think that helps clarify things for me in terms of what "Client" means
<jam> bodie_: (may not be the greatest example because we had to do bad things with the RPC names there, but yes)
<bodie_> heh
<jam> frankban: right, that seems fine. I don't think we need to expose it externally as separate.
<jam> we just need to not overwrite them
<bodie_> jam: since the remote function is being called by name, do I just need to find the function of that name in apiserver/client/* ?
<bodie_> er, by string
<jam> bodie_: in general the state/api/client is going to map 1:1 with state/apiserver/client. It happens that we couldn't do that for SetService, but the string in the Call() is always the exact name on the apiserver.
 * fwereade needs to spend a bit of time with his family, will bbl
<bodie_> gotcha, which in the case of "Set" (or rather NewServiceSetForClientAPI) is defined in apiserver/client/client.go
<bodie_> but in other cases, might be defined in one of those other files in client
<bodie_> thanks
<natefinch> wwitzel3: just got off the interview, will write it up and then be free
<wwitzel3> natefinch: sounds good
<frankban> fwereade, jam: something like this? http://pastebin.ubuntu.com/7195287/
<jam> frankban: for genericity, would it make sense to just have a mergeAddresses(...[]addresses) ?
<jam> otherwise seems ok to me
 * rogpeppe is done for the day
<rogpeppe> g'night all
<natefinch> night rog
<wwitzel3> see ya rogpeppe
<frankban> jam: sounds good yeah, that's just a quick prototype. it seems to work. the only problem I see is that NetworkScope is empty: http://pastebin.ubuntu.com/7195357/  This is a local env and I expected the scope to be "public"
<frankban> jam, fwereade should we assume empty scope == public? Or this is a bug?
<natefinch> wwitzel3: want to hang out, or was there something specific you wanted to talk about?
<wwitzel3> natefinch: hangout, catchup on HA, etc
<natefinch> ok
<sinzui> I think we have user backlash over the changes to juju-local and juju-mongodb. Most victims are canonical staff too. They don't have juju-local installed, they didn't get the new deps, they blame juju to for not telling them what the deps are.
<sinzui> I suggest juju checks is juju-local is installed when bootstrapping the juju local env. stop and tell the user to install the right packages before reporting bugs or complaining to the release manager
<natefinch> heh, that seems like a reasonable position, sinzui
<bodie_> I'm trying to understand this ServiceSetYAML method in /state/api/client.go
<bodie_> I think it's for the "set" command which sets config options on a remote service or unit
<bodie_> but there's also ServiceSet
<bodie_> and I noticed ServiceSetYAML is reading its values from the command context
<bodie_> but I'm assuming that's just for set --config=file.yaml
<natefinch> bodie_: IIRC, the only difference is that one takes YAML and one takes key value pairs
<bodie_> I just don't want to leave it out if it's important for setting up flags on the command in a general sense or some such
<natefinch> bodie_: it probably gets used by somebody, yes.
<bodie_> so not just Set.
<bodie_> I think I'll leave it out and see what happens.  ^_^
<natefinch> Depends on what you mean by "leaving it out".  If this is for new code (actions), it's probably fine to leave it out. No one likes yaml.
<jcw4> natefinch there are no plans to move away from yaml on the backend though right?
<natefinch> jcw4: define backend and I can answer the question (possibly)
<jcw4> haha
<jcw4> natefinch my keyhole view of the world separates the UI as the front end, and everything else (jujud as well as workers) as backend
<jcw4> UI === Web GUI in this case
<jcw4> natefinch, as I understand it the config for each charm is held in a yaml file... that's not going to change any time soon right?
<natefinch> jcw4: there's no plans to change that, no.  We were just disappointed in the difference between the ease of hand editing that yaml promotes and how it actually works in practice.
<jcw4> natefinch interesting.  That makes sense.  I initially thought that plans were afoot to move to JSON, but then realized that the migration of all the existing Charms would be impractical.
<natefinch> Right. We don't mind parsing the yaml in the code, that's trivial.  It's more from a end user perspective, it's not very fun to try to write correct yaml in a text editor.... which is honestly true of pretty much any structured text file.
<jcw4> I see.
<marcoceppi> why move to json? yaml is wayyyy easyer. It's like moving from python to php
<thumper> fwereade: are you around?
<natefinch> marcoceppi: we're not
<marcoceppi> natefinch: okay, cool
<natefinch> marcoceppi: I actually prefer json, personally.  there's a little less magic around the edges, it's a little more uniform, even if it's a little more cumbersome in general. There definitely are benefits to yaml, the main one I like is support for comments.
<marcoceppi> natefinch: I love json for a machine format, but to type it out by hand it pisses me off
<natefinch> marcoceppi: heh, typing out any structured format pissed me off :)
<natefinch> marcoceppi: the one thing I'm thinking about in particular with yaml is getting bitten by the fact that you don't need to put key names in quotes.... unless you run into a keyword, like null, which bit us several times with the null provider.
<marcoceppi> natefinch: well, the name null for a provider wasn't the best choice ;)
<marcoceppi> immho
<natefinch> marcoceppi: well, yes, definitely.  but that's not the point :)
<marcoceppi> sure
<mwhudson> there is a need for something kinder to humans than json
<mwhudson> and yaml is kinder to humans, mostly
<mwhudson> but, man, it has it's screwy bits
<mwhudson> -'
<natefinch> yep
<mwhudson> (i do _not_ want my configuration language to support recursive objects!)
<natefinch> yaml is a lot easier to read and somewhat easier to write than json
<marcoceppi> why not an ini file
<jcw4> or a properties file
<mwhudson> jcw4: what's a properties file?
<jcw4> java
<mwhudson> oh right
<jcw4> some.long.scoped.variable=value
<natefinch> ini is pretty good, actually, though no support for lists of things
<rharper> is there a way to set default-series as a constraint instead of configuring multiple environments with different series values ?
<fwereade> rharper, would you explain your use case? it can be specified at env level, like constraints, but if you want services to run on a particular series you'll probably want to just explicitly name a charm that uses that series
<fwereade> rharper, I'm not sure how multiple environments come in?
<mwhudson> natefinch: yeah, it feels like there is a venn diagram with an empty set where i want there to be something :/
<natefinch> mwhudson: same here.  I want it to be all powerful, but somehow super easy to read and write.
<mwhudson> yaml with some of the crazy filed off would be ok i /think/
<natefinch> I might be ok with ini style key value pairs and yaml style lists
<natefinch> EOD, kid is bugging me for food.  Swear I fed her yesterday.
<rharper> fwereade: I have a jenkins setup which bootstraps environments for openstack installs, the ubuntu releases is one of the parameters;   if I need to change which series is used (precise or trusty) then I have to two entries in environments.yaml which differ only in the default-series value (and name)
<rharper> if I add additional releases, then I need to update the environment yaml on jenkins; if it were a parameter passed to bootstrap, then I don;'t have keep updating each time we add a new release to the tests;
<fwereade> rharper, ah, got you
<fwereade> rharper, I don't suppose it'd be easier to ignore default-series and just be explicit about what charms you're running?
<fwereade> rharper, (I am not pooh-poohing your use case, just uncomfortably aware that I don;t think I'll be fixing it in the next few weeks)
<rharper> fwereade: we have control over the charm names; I'm new to juju stuff, so, if I specified the charm location in such a way that would force the image that is booted on the allocated node to run a specific release?
<rharper> fwereade: and it's OK to have say a precise bootstrap node, but then trusty "service" nodes?
<fwereade> rharper, cross-series environments should be fine, yeah
<fwereade> rharper, charms are series-specific
<fwereade> rharper, so you should be fine to just `deploy precise/foo` or `trusty/foo` or whatever
<fwereade> rharper, assuming you have charms for the series you care about, which I think you must :)
<rharper> hrm, ok
<fwereade> thumper, ping
<thumper> fwereade: hey
<rharper> yeah, charms for both (openstack)
<thumper> fwereade: wondering if you read my email
<fwereade> thumper, I did, and hoped to look at the code, but didn't
<perrito666> hey, suppose I have a ToMachineSpec, how can I get an instance of the machine from that?
<fwereade> thumper, my only comment on the mail was that I think we *do* need lines-of-context, but I will not be overly bothered if it only searches back so far
<thumper> the problem is that it doesn't make sense when combined with filteres
<thumper> if you don't care, then that's fine
<thumper> I was going to keep the 'replay' function from pyjuju
<thumper> that replayed the entire log
<fwereade> thumper, it's mainly a gui use case
<thumper> also keeping --lines to mean "output that number and stop"
<thumper> yeah, but that is still wrong
<thumper> lets say the gui has debug log for 'machine-1'
<thumper> and wants previous 2000 lines
<fwereade> thumper, I am aware that we can't guarantee N lines of output when filtering
<thumper> it is possible that none of the previous 2000 lines are for machine-1
<thumper> if you are fine with that, then ok
<thumper> we can keep it
<thumper> I'm trying to work out why the stream isn't dying when I think it should be
<fwereade> thumper, which branch again? I can take a quick look now
<thumper>  lp:~thumper/juju-core/debug-log-api
<fwereade> thumper, so, I'm not sure why closing the file you're writing to would be expected to stop the stream
<thumper> fwereade: oh fuck
<thumper> you are right
<thumper> hang on
<thumper> let me test something
<fwereade> thumper, closing the reader gives all sorts of exciting errors
<thumper> thanks
<thumper> I wondered WTF was going on...
<thumper> a hang over from when I was trying to read on the writing file
<thumper> that didn't work either
<thumper> why is it a "bad file descriptor" when it is a closed file?
<thumper> is there a way to check for closed?
<fwereade> thumper, hm, not sure
<fwereade> thumper, I feellike having the file closed underneath yu is ground for an error though, in general
<thumper> I guess...
<thumper> from the reader point of view sure
<thumper> I guess I was trying to simulate how it would happen
<thumper> normally the user will hit ctrl-c
<thumper> which will close the websocket
<thumper> I think
<thumper> which would cause an error on the *next* write
<thumper> so it would clean up *eventually*
<fwereade> thumper, hmm, ofc, we can't register it for cleanup in the usual way
<thumper> yeah...
<thumper> i think it'll be ok
<thumper> my test is now good
<thumper> so I'm happy
<thumper> ish
<fwereade> cool
<fwereade> thumper, and about the lines-of-context -- we're *never* guaranteed to have N lines available for a given target anyway
<thumper> fwereade: any pointers on testing the actual websocket bit?
<fwereade> thumper, I think it's fine to explicitly say that it means "up to N lines"
<thumper> or just more boiler-plate
<thumper> and auth?
<fwereade> thumper, and iterate on less sucky implementations
<thumper> do we have tests somewhere?
<thumper> ack re liens
<thumper> fwereade: hmm... thought about an interesting implementation detail, but it is kinda crazy
<fwereade> thumper, I would hope you'd be able to reuse the tests for the auth stuff used in charm.go in that package, butmaybe context differs annoyingly
<thumper> but it can wait until later
<thumper> ok...
<thumper> I'll muddle along
<fwereade> thumper, don;t have much to offer re websockets I'm afraid
<fwereade> thumper, but I'm sorta falling asleep, so I might bow out now
<thumper> kk
<thumper> night
<fwereade> thumper, when he's online, please poke ian re lp:1301464 -- there's a big chunk of context about 4-5hours back in this channel that would be easily missed
<fwereade> thumper, I think he knows about the bug anyway though
 * fwereade away
<thumper> ack
<perrito666> go question, can I know if a group of elements (in this case in an array) is subset of a larger group (also in an array) without iterating them ? (something like set.issubset in python)
<sinzui> wallyworld_, is bug 1301464 also bug 1301331?
<_mup_> Bug #1301464: The mega-watcher for machines does not include containers addresses <addressability> <api> <juju-gui> <juju-core:In Progress by wallyworld> <juju-core (Ubuntu):Triaged> <juju-quickstart (Ubuntu):Triaged> <https://launchpad.net/bugs/1301464>
<_mup_> Bug #1301331: Remote machine addresses API required <api> <juju-gui> <juju-core:Triaged> <https://launchpad.net/bugs/1301331>
<wallyworld_> sinzui: maybe
<wallyworld_> the latter may not be required
<wallyworld_> i'll know more soon
<sinzui> wallyworld_, okay
<wallyworld_> sinzui: it all got messed up with the move to machine addresses instead of unit addresses i think
<wallyworld_> sinzui: also, one of the bugs i fixed yesterday only got exposed when deploying to a container on say ec2. it would be good to include such a test in CI
<davechen1y> this PSA was about to you by the words "killall mongod"
<davechen1y> s/about/bought/
<sinzui> wallyworld_, Can you describe the situation in more detail in an email after you have sorted out the bug?
<davechen1y> waigani: how you doing today ?
<davechen1y> waigani: do you need help with your charm fix ?
<thumper> davechen1y: waigani has just left my house, he'll probably be online again after lunch
<thumper> 'tis thumpen time
 * thumper heads to the gym
<davechen1y> thumper: right o
<davechen1y> you guys buddy breathing the internet ?
<thumper> wallyworld_: <fwereade> thumper, when he's online, please poke ian re lp:1301464 -- there's a big chunk of context about 4-5hours back in this channel that would be easily missed
<thumper> wallyworld_: <fwereade> thumper, I think he knows about the bug anyway though
<thumper> davechen1y: we are in the same city, so it makes sense to get together periodically
<thumper> a bit of pairing this moring
<wallyworld_> thumper: yep, saw it :-) otp
<thumper> sharing knowledge and all that
<thumper> wallyworld_: ack
<perrito666> sinzui: if you want to chime in https://codereview.appspot.com/83370043/ there is an interesting debate going on there :)
#juju-dev 2014-04-03
<perrito666> sinzui: btw, most likely I will be trying to fix restore failing from good connections issue :)
<arosales> wallyworld_: I got the limits lifted on Joyent if you want to give it another try, when you have time.
<wallyworld_> arosales: otp, sec
<arosales> wallyworld_: ack
<wallyworld_> arosales: thanks for that. curtis ran into the same issue originally as well but the CI tests were wteaked to deploy into lxc containers instead of a new instance and it all looks good :-)
<arosales> wallyworld_: yup that was on two different accounts too so I am checking with Joyent if we need to include that in our instructions of if the could lift that globally to at least 10 instances or something reasonable like that
<wallyworld_> sure
<arosales> wallyworld_: would be nice to get confirmation you can add-unit or deploy more than 1 service (without colocating)
<arosales> incase I need to ping Joyent again
<wallyworld_> ok, i'll try it out as soon as i can today
<arosales> wallyworld_: ack and no rush just wanted to let you know before I grabbed some dinner
<arosales> wallyworld_: and again thanks for getting that landed wouldn't have happend with out you chipping in
<wallyworld_> np, that's what we're here for
<davechen1y> waigani: thanks for lookin into that issue
<davechen1y> is the problem that the code is tryin to consume the body without checking the status code ?
<waigani> yep, just writing something up now
<davechen1y> kk
<davechen1y> https://bugs.launchpad.net/bugs/1301663
<_mup_> Bug #1301663: cmd/juju: panic during bootstrap <juju-core:Triaged> <https://launchpad.net/bugs/1301663>
<waigani> davechen1y: lboxing..
<davechen1y> waigani: right o
<davechen1y> on da phone
<waigani> ha, can't lbox because of proxies
<stokachu> anyone tested juju 1.17.7 on trusty with kvm in local provider?
<stokachu> i can get it to bootstrap but when i deploy none of the vms are being created
<waigani> davechen1y: https://codereview.appspot.com/83310044
<stokachu> oh interesting looks like im getting a connection refused over the websocket connection
<stokachu> lemme fix that first
<stokachu> so it just takes a minute to get the connection and then fails with : http://paste.ubuntu.com/7196827/
<stokachu> seems to just repeat that warning about no instances found
<stokachu> lxc also seems to work just fine
<thumper> stokachu: yes, kinda
<thumper> stokachu: I tested kvm with saucy when I did it
<thumper> but not trusty yet
<davechen1y> thumper: i'm very concernred at the number of unchecked interface conversions in watcher/watcher.go ~400
<davechen1y> lots of shit to go wrong there
<davechen1y> i have a stack trace from hazmat that is very worrying
<thumper> that certainly is a lot of conversions
<davechen1y> i'd like to remove all the v, _ 's
<davechen1y> this code behaves as if the conversion cannot fail
<davechen1y> so we should assert that by not using the two arg version
<davechen1y> for example
<davechen1y>                         dr, _ := c.Value.(bson.D)
<davechen1y> if this isn't a bson D, then what the fuck is it ?
<thumper> and this is just one more reason why I like generics :P
<thumper> however...
<thumper> I agree, blind type assertions are wrong
<davechen1y> there are a few cases in the codebase where they make sense
<davechen1y> but I don't think this is one
 * davechen1y logs issues
<davechen1y> what the complete fuck
<davechen1y> ... value *errors.errorString = &errors.errorString{s:"cannot assign unit \"s0/0\" to machine 1: machine \"1\" cannot host units"} ("cannot assign unit \"s0/0\" to machine 1: machine \"1\" cannot host units")
<axw> wallyworld_: did your unit address changes get into the 1.18 branch?
<axw> wallyworld_: just about to add a comment to #1259908
<_mup_> Bug #1259908: juju status of units report private address (172.x.x.x) instead of public fqdn <add-unit> <addressability> <ip> <juju-core> <status> <juju-core:Triaged> <https://launchpad.net/bugs/1259908>
<wallyworld_> axw: the ones aligned with jyent provider, yes
<axw> right, they had to - thanks
<wallyworld_> so the uniter doesn't set unit address on start up anymore
<axw> yup
<thumper> davechen1y: have you played much with web sockets?
<thumper> davechen1y: I'm trying to work out how to write a test that needs to read from a web socket
<davechen1y> thumper: i haven't
<davechen1y> not at all
<davechen1y> sorry
<thumper> np
<thumper> I'll keep poking with a stick from a distance
<hazmat> thumper, do you need to talk websocket to it?
<hazmat> thumper, its start of as http 1.1.. then does an immediate upgrade.
<hazmat> off
<thumper> yes, I think I do, as this is how debug-log is streamed back to the client from the api
<davechen1y> yup, that is about all I know
<hazmat> thumper, just using an existing websocket client and setup the server on a high socket for test... its separate from the api server afaicr.
<thumper> no...
<thumper> it is part of the apiserver
<thumper> but I have it working so far
<thumper> at least tests for the error conditions are good
<thumper> perhaps I just make a client like the client would :-)
<hazmat> cool
 * thumper goes to read more code
<waigani> davechen1y: the proxy nuke lines were not meant to be there sorry, taken out now: https://codereview.appspot.com/83310044
<davechen1y> waigani: thanks
<davechen1y> waigani: let me test it
<davechen1y> does anyone else have time for a review ?
<axw> davechen1y: I can probably spare some time, what needs reviewing?
<davechen1y> https://codereview.appspot.com/83310044
<davechen1y> looks pretty staight forward
<davechen1y> waigani: LGTM, passes for me
<davechen1y> thank you
<waigani> sweeeet :)
<axw> waigani: please fix Body.Close before landing
<axw> waigani: I added a comment
<waigani> axw: yep, will do
<axw> ta
<davechen1y> axw: thanks, good catch
<waigani> axw: moved Body.Close to above if, logged the body (debug level), checked log and test on ppc.
<waigani> shall I push to lp, or do you want another lbox?
<waigani> axw: ^
<davechen1y> waigani: lbox propose
<waigani> okay
<axw> waigani: thanks
<waigani> just give lbox half an hour ...
<davechen1y> :)
<waigani> axw: davechen1y: https://codereview.appspot.com/83310044
<axw> shipit
<waigani> :D
<davechen1y> hodl up
<davechen1y> one more thing
<axw> yeah, good point about Errorf
<axw> waigani: ^^ dontshipit
<waigani> haha
<waigani> I had my finger on the button
<waigani> davechen1y: oh nice. That looks a lot better!
<davechen1y> http://paste.ubuntu.com/7197095/
<davechen1y> umm, this is bad
<waigani> I'll just push that last one to lp right davechen1y?
<davechen1y> waigani: lbox propose
<waigani> oh shit, I missed the log as error, sorry hang on
 * thumper goes to make dinner
<thumper> back later tonight for meeting
<thumper> hoping to catch rogpeppe before meeting to talk about testing websockets
<waigani> my girl just got off the ice so I'm going to have to disappear
<waigani> back later tonight
<waigani> davechen1y: https://codereview.appspot.com/83310044
<davechen1y> ok
<waigani> davechen1y: just taking off skates etc so I can ship it if I get an lgtm from you
<davechen1y> waigani: i'll review in a sec
<davechen1y> i'll mark the review as approved and make sure the bot lands it
<waigani> davechen1y: great. Thank you.
<davechen1y> oh crap, the joyent test take > 10 minutes
<davechen1y> and get killed by the watchdog
<wallyworld_> davechen1y: what's the issue with stripping the jujud binary? i didn't add that bit in, just curious
<davechen1y> striping go binaries breaks them
<davechen1y> we don't strip them in the release build
<davechen1y> but I found a place in environs/tools where building local tools it still strips
<wallyworld_> yeah. i guess it still works somewhat cause i think that's what upload tools uses
<wallyworld_> and people have been running ok with that
<davechen1y> wallyworld_: only on amd64
<wallyworld_> ah
<davechen1y> it really really doens't work for arm
<wallyworld_> rightio
<wallyworld_> i've assigned it to me to fix
<davechen1y> i've already got a fix
<davechen1y> will propose in a sec
<davechen1y> just running tests
<wallyworld_> mark the bug as in progress then!!
<davechen1y> ffs
<davechen1y> i only just logged it
<davechen1y> hold your horsees
<wallyworld_> i was trying to be hepful :-P
<davechen1y> i know
 * davechen1y pats wallyworld_ in a fatherly way
<wallyworld_> i saw a few bugs, all raised by you and thought you may need some extra hands on deck :-)
<davechen1y> good thinking
<davechen1y> wallyworld_: if you have time
<davechen1y> i'm really getting nowhere with the simplestreams problems
<davechen1y> juju doesn't even build on 386
<davechen1y> sorry, i mean the tests don't pass on 386
<wallyworld_> which one?
<davechen1y> so there is a lot of fixture data
<davechen1y> wallyworld_: http://paste.ubuntu.com/7197153/
<davechen1y> i'm sorry i can't get better reports
<davechen1y> it takes fucking forever to run these tests
<wallyworld_> these tests are running inside a 386 vm?
<davechen1y> wallyworld_: http://cloud-images.ubuntu.com/releases/14.04/beta-2/
<davechen1y> cloud images, just push the button
<wallyworld_> oooh. nice
<davechen1y> yeah
<davechen1y> really nice
<davechen1y> need a ubuntu image
<davechen1y> push the button
<wallyworld_> ok, i have a wip branch i need to get done but i can look at the tests after that
<davechen1y> ok
<davechen1y> thanks
<davechen1y> axw: got a sec ?
<axw> davechen1y: yup?
<davechen1y> afk for a bit
<fwereade> gaah it just took me *far* too long that filepath.Walk does not follow symlinks
<fwereade> s/long/long to realise/
<axw> fwereade: heh :( been there
<rogpeppe> thumper: i'm here if you want me
<rogpeppe> fwereade: did you want it to?
<fwereade> rogpeppe, I wouldn't usually, but I was passing it a symlink unawares and totally baffled as to why it wasn't walking any further :)
<rogpeppe> fwereade: ah...
<fwereade> davecheney, ping
<rogpeppe> fwereade: early morning amusing reading, BTW, if you hadn't seen it: https://www.usenix.org/system/files/1403_02-08_mickens.pdf
<fwereade> rogpeppe, I like that guy's stuff, don't think I've seen that one, thanks :)
<rogpeppe> fwereade: me too, and me too
<axw> fwereade: do you want to do any final review before I land this? (grouping is not enabled until azure-mode lands)    -- https://codereview.appspot.com/73910043
<fwereade> axw, I'll do a quick pass now, if you haven't heard from me in 20 mins don't let me block you
<axw> fwereade: okay, thanks
<rogpeppe> "So, yes, it would be great if fixing your browser involved actions that were not semantically equivalent to voodoo. But, on the bright side, things could always be worse. For example, it would definitely be horrible if your browserâs scripting lan- guage combined the prototype-based inheritance of Self, a quasi-functional aspect borrowed from LISP, a structured syntax adapted from C, and an aggressively asynchronous I/O model that
<rogpeppe> requires elaborate callback chains that span multiple generations of hard-working Americans. OH NO IâVE JUST DESCRIBED JAVASCRIPT. What an unpleasant turn of events! People were begging for a combination of Self, LISP, and C in the same way that the denizens of Middle Earth were begging Saruman to breed Orcs and men to make Uruk-hai."
<axw> fwereade: main change after merging is that it now uses DistributionGroup and takes the cloud-service name from the first instance.Id belonging to Azure, whereas the old code would use labels based on principal units
<axw> rogpeppe: he's hilarious. I wish more people wrote like him; I might learn more :)
<rogpeppe> axw: +1
<fwereade> axw, LGTM
<axw> fwereade: thanks
<axw> fwereade: do you want https://codereview.appspot.com/81340043/ in before I enable azure? bear in mind that azure-mode will not allow add-machine or --to
<axw> *enable azure-mode
<axw> fwereade: btw, availability-sets-enabled is a bit wordy, do you think we should actually call it azure-mode?
<fwereade> axw, sorry, I'm hitting dangling pointers in my brain
<axw> no worries :)
<axw> it's a bit twisty
<fwereade> axw, so, that CL appears to lack tests a bit
<axw> fwereade: yeah, it was just a WIP to get your thoughts
<axw> I meant, do you want me to flesh it out and continue on with it before calling azure done. This one really is about ec2 and others where you would be allowed to add-machine and --to
<fwereade> axw, so AFAICT they won't interact -- unless azure-mode allows for assignment to clean/empty machines, but IIRC it doesn't
<axw> right
<axw> fwereade: you made a comment on the DistributionGroup CL: "LGTM. Taking DG into account when choosing pre-existing instances is not
<axw> in scope for this CL, but please make sure it's on your list of
<axw> necessary-features-before-done-done."
<fwereade> axw, ok, I think we should get that in, because we want to enable service distribution in the other providers: once we have the interface in place, it becomes a "simple" matter of adding bugs for individual providers
<axw> fwereade: agreed, but can I go ahead and land the remaining azure stuff first?
<fwereade> axw, certainly
<axw> cool
<fwereade> axw, sorry slow to catch up :)
<axw> no problemo
<voidspace> morning all
<fwereade> frankban, can I get your +1 on https://code.launchpad.net/~wallyworld/juju-core/watcher-address-issues/+merge/213968 please?
<fwereade> frankban, (or not ofc ;))
<frankban> fwereade: sure, looking and qaing it
<frankban> fwereade: does the comment at line 8-9 reflect reality?
<fwereade> frankban, wait, yeah, I think that's crack
<fwereade> wallyworld_, ^ -- what about instancepoller?
<fwereade> wallyworld_, it doesn't workin the local provider but it should do everywhere else
<voidspace> rebooting
<frankban> fwereade: commented on the MP
<vladk> dimitern: I have a problem with MAAS on VirtualBox
<vladk> LXC from MAAS node can not get IP address from DHCP on MAAS cluster controller, because DHCP Request is sent w/o 'broadcast' flag and unicast DHCP Offer is not delivered inside of VirtualBox.
<vladk> May be the problem related to VirtualBox, but I suggest to run DHCPD on MAAS with 'always-broadcast' option.
<vladk> Does it make sense?
<dimitern> vladk, I have very little knowledge of setting up dhcp internals and details - it seems you might be on a right track there
<jam> vladk: #maas would be the place to bring it up, I think
<vladk> dimitern: LXC container inside MAAS choose their MACs automatically and may even have different MACs on each lxc-start.
<vladk> I offer to add some option to 'juju add-machine' to specify either MAC of LXC container or CIDR+GW.
<fwereade> vladk, dimitern: I really don't want MAC addresses leaking into the UI, but I'm just fine with uspicking one and sticking to it
<fwereade> s/uspicking/us picking/
<vladk> dimitern, but in this case it will be impossible to have a predictable external IP address bound to LXC
<mattyw> fwereade, rogpeppe quick question for one of you (sorry if I'm repeating - I got disconnected soon after asking the first time so I don't think I got through)...
<thumper> rogpeppe: got time for a hangout? I need help
<mattyw> I've started a branch for getting the current user set as the service owner when juju deploy is called. The wip mp is here: https://codereview.appspot.com/83060049/. I've added a test: https://codereview.appspot.com/83060049/patch/1/10004 but what I should do in the test is actually change the current user (as defined in the .jenv file) but I couldn't work out how to do it
<rogpeppe> thumper: sure
<thumper> rogpeppe: thanks https://plus.google.com/hangouts/_/7acpj31hohv230rlfvf7d3jqec?hl=en
<rogpeppe> mattyw: are you around for a while?
<mattyw> rogpeppe, I am yes - no hurry
<rogpeppe> mattyw: cool, will answer after talking with thumper
<fwereade> mattyw, I don't think that owner should be in the args over the API -- it's implicit in the connection
<mattyw> fwereade, I guessed that would be the case but I couldn't see it
<fwereade> mattyw, I think you just need to get the current tag off the auth object and pass that through
<mattyw> infact - idiot - of course it is
<mattyw> will do
<fwereade> mattyw, it may not currently be exposed but it's definitely there
<fwereade> mattyw, cheers
<mattyw> sorry - should have seen that
<mattyw> and how should I switch the current env in the tests?
<fwereade> mattyw, that should then leave cmd/juju and state/api untouched, I think
<fwereade> mattyw, so long as the apiserver tests check that it works with a different connected user, I don't think yu need to touch those other packages at all
<mattyw> ok
<axw> fwereade: we can haz HA azure now - all merged
<fwereade> axw, w00t!
<vladk> dimitern: is any way in MAAS api to understand what MAC address is of PRIMARY interface. you may suggest the first one, but if I remove and recreate the first MAC, it become the last one
 * axw tests that it works once more to be sure
<fwereade> axw, much appreciated :)
<jam> fwereade: can I have an ear for a sec?
 * fwereade listens
<jam> fwereade: arm vs armhf
<jam> the tool building process is generating simplestreams with armhf and tarballs with armhf in them
<jam> but AFAICT the binaries inside them have "arm"
<fwereade> jam, yeah, I pinged davecheney, I don't understand his objection to calling it armhf inside juju
<jam> fwereade: all *I* care about is that they are consistent, and I feel it is easier to fix juju-core at this stage than fixing stuff outside of juju-core
<jam> if only because we have a patch :)
<fwereade> jam, and (from my perspective at least) it's a hell of a lot easier to fix juju than to fix the tool-building
<fwereade> jam, yeah
<fwereade> jam great minds ;)
<fwereade> davechen1y, davecheney: ping again?
<axw> uh oh, spaghetti oh. I broke something
<fwereade> axw, change your name to max power and try again
<wwitzel3> lol
<davechen1y> fwereade: ack
<dimitern> vladk, maas doesn't enforce ordering of macs - what you enter is what you can use to link to networks
<jam> fwereade: I'm thinking we need james' patch to land on the 1.18 branch as well, right?
<jam> frankban: I believe LXC has an empty scope because we can't tell whether it is public or private.
<jam> It is just the address we got from eth0
<jam> on Clouds that is actually a private address
<jam> for LXC it is probably the "most public address we can get"
<jam> though still since it is on LXCBR0 it is probably a private address.
<mgz> there's no real public at all for the local provider, and lxc on other clouds will give you a machine-local address from that
<frankban> jam: yeah, I am just concerned about client logic. From the client perspective, an internal eth0 address of an LXC in a local env could be also be considered "public", meaning reachable.
<jam> mgz: well for MaaS it is a public-ish address, but for where we end up with EC2 it would be private.
<mgz> right, maas is special
<jam> frankban: so I'm pretty sure it means "we need to do more coding to parameterize this on where the LXC is running"
<jam> which is... Is it worth it for now?
<frankban> jam: I just want to make sure the logic I described in the bug is what must be implemented by clients
<fwereade> davechen1y, what's the objection to calling it armhf inside juju? it feels like the cleanest way to get consistency
<wallyworld_> fwereade: sorry, was at soccer, missed your ping
<fwereade> wallyworld_, I forget what it was about now ;p
<wallyworld_> goo :-)
<wallyworld_> good
<fwereade> wallyworld_, oh, yeah, instancepoller
<fwereade> sorry brb
<jam> wallyworld_: so there is a bug that frankban noticed, and the question about what to do with "unknown" networks.
<jam> (appending to a list that we preseed with length)
<jam> trivially fixed with "addresses = ... 0, len(merged))"
<axw> fwereade: quick one when you have a moment https://codereview.appspot.com/83940043
<wallyworld_> fwereade: ok, i'll look. btu all i'm doing is exposing the exisitng address getters on unit
<jam> mgz: I think frankban's logic for "use the first public address, otherwise fall back to the first unknown address" is the logic we're going to have to go with for now.
<jam> it will still be wrong in the ec2 case
<wallyworld_> so if they're wrong then it's also wrong elsewhere
<jam> but hopefully by then we can do the "oh private address X maps back to public address Y" and shove that in the information for the container
<jam> which means the logic will still be correct.
<jam> wallyworld_: the other code didn't do "make"
<dimitern> fwereade, jam, rogpeppe, meeting?
<axw> fwereade: integration testing fail - actually works with this change
<frankban> jam: why  is it wrong in the ec2 case?
<jam> it just started with the nil slice and appended to it.
<jam> frankban: because if you have an LXC on EC2 it can *only* ever see its machine private addres.
<jam> you have to go back to the provider
<jam> and lookup "what is the actual public address assigned to the outer machine that matches the private address inside the LXC"
<wallyworld_> jam: i needed to return an empty slice rather than a nil slice cause that's what the mega watchr wants
<jam> wallyworld_: that is fine, the problem is that you do "make([]foo, len(merged)" and then append
<jam> just change that to
<jam> make([]foo, 0, len(merged))
<jam> I have to switch machines,
<wallyworld_> oh ok
<frankban> jam: so, is it ok to use the logic I described in the bug (public + fallback)?  Do you think that work for all providers?
<jam1> frankban: that works as well as we can do right now
<jam1> when we fix EC2 to know about how to do that mapping, we can put a public address for those LXC containers
<jam1> and have it continue to work
<frankban> jam1: ok, so, when that branch lands, we can go ahead with quickstart and the GUI, using that logic to retrieve the reachable address
<frankban> jam1: sounds ok?
<jam1> frankban: sgtm
<fwereade> hazmat, do you have the paste that davecheney linked with the casts in the watcher code?
<hazmat> fwereade, i don't..   i  have the tracebacks..
<fwereade> hazmat, sorry, it was that to which I referred
<hazmat> fwereade, here's the watcher one.. http://pastebin.ubuntu.com/7198067/
<hazmat> i'll forward the rest via emial
<perrito666> good thing I am not joining near a major release.. ah, wait :|
<perrito666> :p
<stokachu> thumper: yea saucy works with kvm
<jam1> fwereade: I looked at https://codereview.appspot.com/81110043/ (manifestDeployer)
<jam1> it seems ok, though the SetAbortWait is confusing for me.
<fwereade> jam1, I tried to make it clear, but clearly failed
<jam1> fwereade: well, I sort of understand what it is doing, but it took a bit because the function has side effects *and* returns an object.
<jam1> It also wasn't clear why we needed it.
<jam1> fwereade: is that just part of the interface?
<jam1> it seems like without the wait form, the other function can't return at all.
<jam1> ah, it just always ignored abort before
<fwereade> jam1, it's really just a way of checking that the abort chan is passed through to the bundle reader
<fwereade> jam1, better ways of doing it greatly appreciated :)
<jam1> fwereade: sure, I actually see the side effect, but it isn't very straight forward
<jam1> so *if* you called SetWaitAbort
<jam1> then we will wait on <-abort
<fwereade> jam1, because it certainly felt unhelpfully convoluted to me
<jam1> otherwise we just always fall through with the <br.waitAbort because it is a closed channel
<fwereade> jam, yeah, exactly
<jam1> doing the "create one and close it" looks strange.
<jam1> I'll propose something
<fwereade> jam1, cool, thanks
<voidspace> rogpeppe: you there? the hangout is awfully quiet :-)
<jam1> fwereade: suggestion sent
<jam1> you certainly don't have to pick it up, and it is more verbose
<jam1> but I feel it is a bit easier to read
<jam1> voidspace: I'm sorry, you're not allowed to go on vacation, ever.
<voidspace> jam1: ah, ok - that must be a new policy...
<jam1> voidspace: certainly not to something so seedy as a place to Con people with Pie
<voidspace> jam1: what about if I promise to proselatyse Juju?
<voidspace> (forgive the spelling)
<natefinch> If I'm going to be conned, I hope I get pie
<jam1> voidspace: approved!
<voidspace> jam1: thanks :-)
 * natefinch brings fork to pycon, is disappointed.
<voidspace> natefinch: silly man :-)
<jam1> natefinch: should have brought a spork
<jam1> fwereade: is there actually anything blocking https://code.launchpad.net/~fwereade/juju-core/filetesting-package/+merge/212811 other than rogpeppe didn't actually give it an LGTM ?
<jam1> it looks like you did all of his suggestions.
<voidspace> so yesterday, whilst attempting to print, I discovered that Ubuntu has a keyboard shortcut for "change my resolution, futz with my screen layout and disable the mouse"
<voidspace> *really* useful
<rogpeppe> ah, i had a couple of draft comments
<voidspace> all you have to do is press <Super-P> instead of <Ctrl-P>
<wwitzel3> there will be enough juju people at pycon that we could do an openspace
<wwitzel3> though the last thing I need is one more thing to coordinate
<jam1> voidspace: mess-with-displays enough that Pidgin can't find its window anymore :)
<wwitzel3> maybe tvansteenburgh will do it :)
<jam1> voidspace: apparently it is "detect displays" which changes it from separate to mirrored
<jam1> so if you have different sized screens (as I do) it gets messed up
<voidspace> nice
<jam1> it also messes up the "my second screen is on the left"
<jam1> settings
<jam1> http://askubuntu.com/questions/20113/how-to-stop-mod4-p-from-switching-the-display and http://askubuntu.com/questions/68463/how-to-disable-global-super-p-shortcut
<jam1> voidspace: you're not the only one that dislikes it
<voidspace> yeah, apparently it's a *feature*
<voidspace> I'm actually impressed with trusty multi monitor support in general though
<jam1> I'm guessing this is "I connected to a Projector, help!"
<natefinch> wow, yeah, that's terrible
<voidspace> "just works" (mostly)
<natefinch> it would be fine if it just toggled from mirror display to <whatever I had set before>
<jam1> so having a command sequence to switch to Mirrored displays isn't that uncommon
<jam1> it used to always be a Fn key on laptops
<natefinch> it's just forgetting what I had set up before
<jam1> natefinch: yeah, not remembering the previous setting is a bit bad.
<jam1> natefinch: I take it you tried it as well
<jam1> It remembered I only wanted 1 task bar
<jam1> but it swapped my displays left to right again
<natefinch> someone says "hey I did this and it messed everything up" and I have to try it.  Masochistic I guess
<jam1> and made my right-hand screen the primary
<wwitzel3> natefinch: lol
<jam1> natefinch: something about the fuck-up made it so 3 of my windows so far are just *gone*
<jam1> I'm guessing they ended up in massively negative offsets
<natefinch> the only major thing I see wrong is that my laptop thinks it's on the left of my other two screens rather than the right. but maybe that's just because my settings were already close to what it just resets them to
<jam1> but I can't grab them to move them back on the screen
<wwitzel3> it seems like every other display setting change results in a Keep/Revert dialog. super-p should do the same
<natefinch> jam1: that happens to me all the time for no apparent reason
<jam1> on Windows you could meta-something to get the menu drop down and select move and then arrow key them
<natefinch> jam1: hah, yeah, I am well versed in that manuever
<voidspace> :-)
<voidspace> sorry guys
<natefinch> right-click, select move, tap an arrow key, then it sticks to the mouse so you can move it on screen.
<natefinch> obvious, really
<jam1> natefinch: If I Alt+Tab Unity shows me that it still knows what the window looks like, but no indication that it knows where the fuck it is :)
<jam1> natefinch: you can Meta key to get it as well
<jam1> Meta, release, M
<jam1> natefinch: and clicking on the dashboard shows that the windows are *really* far to the right of my right-hand screen
<jam1> because they "swoosh" into center view
<jam1> but still no way to move them :(
<voidspace> fortunately when I did it the screen with the launcher was still visible so I could run the displays app to restore things
<wwitzel3> jam1: Alt+F7 then the arrow keys after selecting them with Alt+Tab
<natefinch> voidspace: not your fault jam and I are idiots :)
<voidspace> natefinch: I'm very sorry, but I'm finding it hard not to laugh
<natefinch> jam1: ubuntu just had a "serious error" when I went into the display settings to move my monitor back
<jam1> wwitzel3: so Alt+F7 binds the mouse to move them
<jam1> but they are so far off the screen I have to move it 2 times :)
<wwitzel3> hah
<jam1> natefinch: it works, but it doesn't have the "first move brings it back onto the screen"
<jam1> that the Windows arrow did
<jam1> wwitzel3: bringing the mouse to an edge causes the snap-to-edge which at least brings it back
<wwitzel3> jam1: well, that's something at least :)
<natefinch> jam1: thanks for the alt-f7 thing, that'll help the next time I mysteriously lose a window
<natefinch> now if I could only get the workspace switching hotkeys to work
<jam1> wwitzel3: and when you move it off the snap to, it remembers its original size
<jam1> so it actually works pretty well
<wwitzel3> oh, nice, yeah
<jam1> natefinch: ctrl+alt+arrow doesn't work? (I didn't reenable it myself)
<natefinch> jam1: nope.  No matter what I bind the action to, hitting that hotkey doesn't do anything
<natefinch> jam1: all the workspacey hotkeys do nothing for me for some reason
<jam1> natefinch: you know about the Enable Workspaces in Appearance, right?
<natefinch> and yes I have workspaces enabled (and the button works to show the workspaces and stuff)
<natefinch> :)
<jam1> I tested it, and Ctrl+Alt+Arrows is working for me, sorry
 * natefinch shrugs
<natefinch> never had workspaces before, so I don't miss them, just feel like it could be useful for context switching
<jam1> natefinch: on my laptop, I used it for "email on this wkspace, coding on another"
<jam1> but with dual monitors, that is just right and left monitor
<wwitzel3> yeah I tend to only use them when I am stuck on one monitor
<wwitzel3> voidspace just has a monitor for each application, makes things simple
<natefinch> yeah, definitely would be useful for when I'm stuck on one monitor... just might be nice to have work stuff on this workspace, and non-work stuff on another workspace, instead of playing terminal roulette
<natefinch> terminal roulette sounds a lot more dire than it is
<fwereade> jam, re filetesting, don't think so
<jam1> natefinch: you shouldn't be doing non work stuff, clearly
<wwitzel3> natefinch: depends on the command? .. I'm not above copying and pasting a sudo command from the internet
<natefinch> lol
<wwitzel3> in fact, just the other day I copy and pasted one that was wgetting and executing a shell script ...
<voidspace> hah
<wwitzel3> sure np, why not
<jam1> fwereade: sure. if you *want* I can give it another review, but whatever seems the best way to get you unstuck
<natefinch> wwitzel3: mostly it's "switch to terminal, damn, wrong history, switch to another terminal... what was I even doing here?  switch to another terminal... wait, maybe the first one was right"
<wwitzel3> it was on my raspberrypi though, so not as bad as it sounds
<jam1> natefinch: http://unix.stackexchange.com/questions/1288/preserve-bash-history-in-multiple-terminal-windows
<jam1> shopt -s histappend
<jam1> Its in my .bashrc
<natefinch> I don't know that I Want that. I like separate histories... I don't want actions I do in one munging the history in another.... I like being able to switch to a terminal, hit up enter and redo the last thing it did (often go build or go test in the correct directory), while still being able to futz with stuff in another terminal
<wwitzel3> yeah, I use that as well so that i have access to my history across all my tmux panes/windows
<natefinch> It's just when I forget which was which that is the problem :)
<jam> my big "which window" right now is that I started using gmail web interface instead of Thunderbird
<jam> so now when I alt Tab  Ihave to figure out which of these 5 windows looks like a mail program
<natefinch> haha yeah, that is a drawback.
<jam> natefinch: I tried using the "Install this as an App" but that seems to start it in a non-standard browser, and it doesn't work very well
<natefinch> natefinch: I was just going to suggest that.  It should still be chrome, just without the URL bar
<natefinch> talking to myself evidently
<wwitzel3> lol
<natefinch> jam: works ok for me.  *shrug*  It is nice that it then gets the gmail icon (even if it is a grossly blown-up version of the favicon)
<jam> well, I did it from Firefox
<wwitzel3> natefinch: I use Chrome users, so the install as app thing gets a little wonky for me.
<natefinch> jam: ahh, yeah, that's probably the problem.  I have no idea what firefox does.  Chrome works nicely though.  Maybe that's a fix, too, just run mail in chrome and everything else in firefox
<natefinch> wwitzel3: ahh, yeah, I can see that being a problem
<jam> natefinch: yeah, I was just trying that out
<wallyworld_> fwereade: jam:  i tested juju-gui with my branch under review and it correctly shows the unit public ip addresses when using local provider
<frankban> wallyworld_: yes, I tested it here too, the lxc addresses are correctly included both in the unit and machine info. FWIW I approved the branch
<frankban> wallyworld_: thank you for working on that
<wallyworld_> frankban: yeah,saw that thanks
<wallyworld_> just wanted be sure sure i tested it before landing
 * fwereade cheers at wallyworld_ and frankban
<fwereade> jam, I'd absolutely accept another review, especially if it comes with an lgtm ;)
<jam> natefinch: ah, now I remember. the webapp thing works, but then it acts like a mobile app, where double clicking zooms on various parts of the screen, and the font is clearly "rescaled" (changing the size of the window changes the size of the font, rather than rewrapping the elements)
<jam> so it works ~ok at full screen, but still acts a bit different
<natefinch> jam: weird.  chrome's is much better, just a separate browser window sans address bar with a different icon.  Otherwise works just like a normal browser window.
<jam> natefinch: I'm pretty sure the web app thing is Trusty's webapp which is based on Chrome
<jam> As the menu items for what will be prompted is in Chrome settings, and not Firefox's
<natefinch> huh
<jam> natefinch: the window title is "Ubuntu Web Browser"
<natefinch> wacky
<jam> natefinch: http://discourse.ubuntu.com/t/theres-a-ubuntu-browser-in-trusty/1594/7 "Ubuntu browser will be used for webapps"
<jam> Oxide is a library that allows you to embed a Chromium-powered webview in QML applications.
<natefinch> interesting
<jam> natefinch: are you on Trusty?
<vladk> dimitern, sorry for delay. I'm ready for hangout. I prepared a doc with my thoughts: https://docs.google.com/a/canonical.com/document/d/1Fq1JKyuN8PlAeXdt98DN8Wy-WRgrXg-cHmuCqIeO9g0/edit#
<natefinch> jam: yep
<jam> hm. anyway, it works better in Chrome and makes it easier to Alt Tab, good enough :)
<natefinch> jam:  are you using tools-> create application shortcut, or something else?
<natefinch> (in chrome)
<dimitern> vladk, go ahead and join with mgz and perrito666, i'll come shortly
 * perrito666 feels summoned
<dimitern> perrito666, :) vladk wanted to have a quick chat about what he discovered for maas+vlans
<mgz> dimitern: where at?
<perrito666> ah cool, hold until I make the magic "go to the computer where hangout works" dance :p
<perrito666> our usual channel?
<vladk> perrito666: it's busy
<dimitern> vladk, will you create a hangout and send links to me, mgz and perrito666 please?
<vladk> https://plus.google.com/hangouts/_/76cpim0b0s5qihkhpi9vh8qlso
<vladk> perrito666, dimitern, mgz: https://plus.google.com/hangouts/_/76cpim0b0s5qihkhpi9vh8qlso
<voidspace> lunch
 * voidspace lurches
<mgz> can one of you invite my g+ account to that, there's an option in the tools to the right
<mgz> *left
<perrito666> mgz: I just had to mail me the link :p
<perrito666> vladk: dimitern says I dont have access to that videocall
<perrito666> (It says it in spanish, but error in english must be pretty much the same"
<dimitern> perrito666, mgz, I invited you both
<mgz> dimitern: ta
<jam> mgz, dimitern: can one of you give a quick summary of where you guys are at?
<mgz> jam: overall, or right now?
<jam> mgz: just a "this is what we've gotten up to and what we're on next". the same summary that you'd give at a regular standup
<mgz> horacio is doing error report on --to with incompatible networks
<mgz> I'm going to start on add-machine --network  params
<mgz> dimitern is doing the cloudinit vlan bits
<dimitern> jam, i'm finishing off state changes to add networks and NICs for machines
<perrito666> jam: I am doing what mgz said and also trying to tie up the restore issue (finally it actually was caused by a too good connection to the server)
<jam> perrito666: technically caused by a race condition :)
<perrito666> jam: yes :) just very hard/impossible to reproduce in south america
<perrito666> so I am replicating my env in an aws machine so I can find the race condition
<bodie_> morning all
<rogpeppe> bodie_: hiya
<rogpeppe> ha ha ha! that's quite funny. i was wondering why my singular worker logic wasn't working, expecting all kinds of mongo weirdities, but instead just found that i wasn't actually *using* the singular worker wrapper at all
<bodie_> I try to live by this adage: "It's always a layer 0 problem"...
<rogpeppe> bodie_: except when it isn't...
<bodie_> right, ha!
<bodie_> just, i always find myself spending hours trying to work out something that just doesn't seem right, and then something's literally wired wrong, or i'm being dumb in some way
<bodie_> on that note
<rogpeppe> bodie_: yeah, assumption is the mother of all fuck ups
<bodie_> I'm trying to understand what Command's SetFlags method is exactly for
<rogpeppe> bodie_: it's so that common flags can be added without the command knowing about it
<bodie_> I see that it's defined in cmd/environmentcommand.go and then each command adds to it
<bodie_> ok
<rogpeppe> bodie_: with the flag parsing logic defined outside of each command
<dimitern> perrito666, http://paste.ubuntu.com/7198669/
<perrito666> dimitern: tx
<bodie_> oh, actual environment variables, rogpeppe?
<rogpeppe> bodie_: no, command-line arguments
<bodie_> ok, that's what I thought...
<rogpeppe> bodie_: our documentation on cmd.Command should really be better, but it is at least a start
<bodie_> okay, I think that's what I was looking for but not finding
<wwitzel3> natefinch: ping
<rogpeppe> wwitzel3: i haven't seen anything so far
<wwitzel3> rogpeppe: http://paste.ubuntu.com/7198781/
<natefinch> wwitzel3: here now
<wwitzel3> natefinch: hey, rogpeppe helped me out :)
<natefinch> sweet
<sinzui> jam, fwereade Can I retartget bug 1301663 to 1.19.0.
<_mup_> Bug #1301663: cmd/juju: panic during bootstrap <juju-core:Triaged> <https://launchpad.net/bugs/1301663>
<mattyw> rogpeppe, ping?
<rogpeppe> mattyw: ah, you're right to ping me, sorry
<mattyw> (shouldn't take long)
<mattyw> am I?
<mattyw> can you see into the future or something?
<mattyw> I want to get at the current user for a state - which I believe is st.info.Tag
<fwereade> sinzui, yes, let's
<mattyw> there doesn't seem to be a way of getting it out of state - can/should I write a GetTag which does return st.info.Tag?
<rogpeppe> mattyw: well, you asked me a question earlier & i said i'd get back to you...
<hazmat> the azure stuff.. that implies/means the provisioner knows the workloads its deploying now when allocating machines as well?
<mattyw> rogpeppe, ah yes - I forgot
<fwereade> mattyw, rogpeppe: can't we get it off the auth object?
<fwereade> mattyw, rogpeppe: we might need to add a method to expose it, but it should be right there in the api
<rogpeppe> mattyw: which state are we talking about here?
<fwereade> mattyw, rogpeppe: I don't think we should be thinking about the user for a *state* at all
<rogpeppe> fwereade: +1
<rogpeppe> fwereade: unless we're talking about api.State
<rogpeppe> mattyw: you can get it from st.auth.Tag()
<rogpeppe> mattyw: and possibly st.auth.AuthEntity.(*state.User), if it must be a user
<rogpeppe> mattyw: actually, i probably mean st.auth.AuthEntity().Tag() and st.auth.AuthEntity().(*state.User)
<rogpeppe> mattyw: although i still haven't actually looked at the code, so that's probably wrong too
<rogpeppe> :-)
<mattyw> rogpeppe, are we talking about state from apiclient?
<rogpeppe> mattyw: no
<rogpeppe> mattyw: i'm not sure what code you're wanting to test here...
<jam> sinzui: looks like just-a-bug to me, so not critical for 1.18
<fwereade> mattyw, rogpeppe: it's setting the user that creates a service
<sinzui> thank you jame and fwereade
<rogpeppe> mattyw: could you explain in a bit more detail what you're trying to do, please?
<mattyw> rogpeppe, sure - quick hangout?
<rogpeppe> mattyw: sure
<sinzui> jam, fwereade I will propose the version change to 1.18.0 in the next hour. When bug 1285410 is fixed and tested by CI, I will start the release.
<_mup_> Bug #1285410: juju names arm arch 'arm' internally, but 'armhf' in tools <armhf> <armhf-hwe> <constraints> <server-hwe> <juju-core:In Progress by jason-hobbs> <juju-core 1.18:In Progress by jameinel> <https://launchpad.net/bugs/1285410>
<fwereade> sinzui, awesome... but, jam, didn't we have a bunch of failures in the patch for that?
<fwereade> jam, or did you fix them already? :)
<jam> sinzui: fwereade: yes, there were test failures from jhobbs's patch
<jam> I did not get a chance to fix them
<jam> I backported his patch, but since we have failures, I can't land it.
<jam> hopefully jhobbs will be on soon to address them
<sinzui> thank you jam
<wwitzel3> rogpeppe: http://bazaar.launchpad.net/~wwitzel3/juju-core/030-saveapiaddresses/revision/2523
<sinzui> natefinch, wwitzel3 Do you have a minute to review https://codereview.appspot.com/84090043
<natefinch> sinzui: LGTM (and wwitzel3 - I was too slow)
<wwitzel3> natefinch: after discussing with rogpeppe some more, we can propose 030 as is. The new code itself is asserted by the TestMachineAgentRunsAPIAddressUpdaterWorker test.
<natefinch> wwitzel3: ok
<dimitern> fwereade, mgz, perrito666, I'd appreciate a review on the state networking model changes for machines: https://codereview.appspot.com/83070047
 * fwereade looks
<fwereade> dimitern, surely the exclude bit of LinkedNetworks is meaningless?
<fwereade> dimitern, oh ok, LinkedNetworks is the requested, not the actual?
<fwereade> dimitern, that would make sense with include/exclude, but the name feels a bit odd
<mattyw> fwereade, rogpeppe if one of you could take a look at this I'd appreciate it https://codereview.appspot.com/83060049
<dimitern> fwereade, yeah, LinkedNetworks comes from the service
<natefinch> wwitzel3: is there anything I need to pull from your branch?
<dimitern> fwereade, i chose that because the collection name is "linkednetworks"
<wwitzel3> natefinch: no, I reverted everthing I did :/
<wwitzel3> natefinch: so there is absolutely nothing to show for my effort
<wwitzel3> natefinch: to fair what I did just eneded up being a duplicate of what Andrew already did
<wwitzel3> natefinch: I just noticed it too late
<natefinch> rogpeppe: do we need to merge anything into my version of the branch for the config changes?
<natefinch> voidspace: is your config stuff landed on trunk?
<voidspace> natefinch: yes
<natefinch> voidspace: cool
<natefinch> bzr merge lp:juju-core ..... 12 conflicts encountered.    *sigh*
<rogpeppe> natefinch: trunk has everything you need to merge...
<natefinch> rogpeppe: yeah, doing that now..... where did agent/agent.go  go?
<rogpeppe> natefinch: i can work with you to resolve the conflicts if you like - i think i know what kinds of thing need to be done
<rogpeppe> natefinch: agent/agent.go is still there AFAIK
<natefinch> rogpeppe: weird, yeah, I retried the conflict and it showed up.... bzr bug or something
<voidspace> rogpeppe: for Conn.Ping (for singular workers to ping the master) where should I get the address
<natefinch> rogpeppe: actually the conflicts are pretty easy... most of them seem to be for me to just take what's on trunk
<voidspace> rogpeppe: I notice that State (which has the IsMaster call) has a private addr
<voidspace> rogpeppe: "addr is the address used to connect to the API server."
<rogpeppe> voidspace: i don't think you need an address for the Ping
<voidspace> rogpeppe: doesn't it need to ping *somewhere*?
<rogpeppe> natefinch: the main thing that you need to do is write out the data from the StateServingInfo into files for mongo to use, rather than creating them in cloudinit
<rogpeppe> natefinch: but perhaps you've done that already
<rogpeppe> voidspace: it should call state.Session().Ping
<voidspace> ah...
<voidspace> rogpeppe: fair enough :-)
<natefinch> rogpeppe: mostly.  I think it'll be obvious where we need to change things, since stateserving info is replacing some of the info we were using
<natefinch> it's times like these when I thank the development gods for a good three way merge tool (in my case, Beyond Compare)
<natefinch> hey! someone got labix.org in my stdlib includes!
<natefinch> hm.... should we be grouping github.com/juju stuff with launchpad.net/juju-core stuff?
<fwereade> natefinch, IMO github.com/juju is separate from github.com/juju/core (juju-core? I forget what we decided)
<natefinch> fwereade: that seems logical, since there may be stuff under github.com/juju that isn't necesarily core stuff, whereas /juju/core definitely is core stuff.
 * natefinch expels github.com/juju/loggo to the external packages section
<rogpeppe> rebooting now. this machine is unusable
<voidspace> natefinch: got a minute?
<natefinch> voidspace: sure
<voidspace> ok, folks
<voidspace> G'night all
<voidspace> EOD
<sinzui> natefinch, or anyone with gobot and version knowledge. The lander hates my branch that updates the 1.18 branch to 1.18.0 https://code.launchpad.net/~sinzui/juju-core/inc-1.18.0/+merge/214053
<natefinch> sinzui: looking
<natefinch> sinzui: sorta looks like the tmp directory is messed up again
<natefinch> sinzui: I don't actually know how to get onto the bot to poke at it... but usually it's the tmp directory filling up, and since there's a bunch of stuff in /tmp that seems to be missing, that would be my guess
<sinzui> natefinch, thank you
<rogpeppe> i've just upgraded my machine and it's now trashed
<natefinch> trashed how?
<rogpeppe> am currently using a terminal-emulation-based irc client
<wwitzel3> rogpeppe: me too
<rogpeppe> natefinch: no windows appear
<wwitzel3> well not the trashed part
<natefinch> windows are for the weak
<rogpeppe> natefinch: i can't appear to do anything at all
<wwitzel3> but I used a terminal client ;)
<rogpeppe> i guess i can just go back to the vi dark ages
<natefinch> heh
<wwitzel3> have you tried Super+P ?
<rogpeppe> but no web browser might be a bit of a problem
<rogpeppe> ha ha bloody ha
<rogpeppe> i get the top menu bar ok
<natefinch> too good for lynx, rog?
<wwitzel3> rogpeppe: can you get your dmesg and syslog pasted somewhere some how?
<wwitzel3> .. maybe with curl to paste.ubuntu.com , the fields are poster, content, format
<rogpeppe> with suspend/shutdown on the tool menu, calendar on the time menu, but i still see the Guest Session and Remote Login graphics on the screen, tho they don't react
<rogpeppe>  /var/log/dmesg.log ?
<wwitzel3> rogpeppe: yeah, that's good to see if any hardware failed to initalize
<rogpeppe> wwitzel3: paste.ubuntu.com/7199828
<rogpeppe> wwitzel3: paste.ubuntu.com/7199830
<rogpeppe> wwitzel3: all the hardware *seems* like it's working ok
<wwitzel3> rogpeppe: yeah, I don't see any of the obvious errors of failing to load a specific video module or anything of that nature that has caused me similar issues before
<wwitzel3> rogpeppe: you could always try doing an update/upgrade from the command line and see if some new configuration files get written that fix your problem.
<natefinch> honestly, when my machine blows up, I just reboot until it works again.... so far it hasn't failed me, though sometimes it has taken a couple reboots to get there
<rogpeppe> the video seems to work ok
<wwitzel3> like I say, when you have a problem, add more variables
<rogpeppe> even the second monitor is working (kinda - it shows the terminal, duplicated)
<wwitzel3> hrmm
<rogpeppe> i will try rebooting a third time, i guess
<wwitzel3> rogpeppe: unplug everything and reboot
<rogpeppe> wwitzel3: if in doubt...
<wwitzel3> rogpeppe: and then readd the devices after you're up
<rogpeppe> wwitzel3: read the devices?
<natefinch> re-add
<rogpeppe> wwitzel3: i'm afraid my linux device-fu is fairly non-existent.
<rogpeppe> wwitzel3: do you mean doing some mknods?
<wwitzel3> rogpeppe: no no, I mean any physical things plugged in to your laptop .. USB, HDMI/DVI
<wwitzel3> rogpeppe: reboot with just the laptop, that works for me sometimes when my display gets all wonky
<rogpeppe> wwitzel3: ah, physical... usb + rgb out + headphones + wired ethernet
<wwitzel3> rogpeppe: yep
<rogpeppe> ok, i'll give it a go. see you the other side.
<rogpeppe> wwitzel3: fail
<rogpeppe> frick
<natefinch> time to reinstall
<rogpeppe> i wonder if "failed to spawn atd main process" is something to do with the problem
<natefinch> rogpeppe: can you talk to IS?  It's sorta their job, right?
<jhobbs> trying to run tests on lp:juju-core and I see this everytime http://paste.ubuntu.com/7199854/. any ideas what's going on?
<natefinch> jhobbs: interesting
<natefinch> jhobbs: oddly, it's a log line dereferencing some data the rest of the function doesn't even use
<jhobbs> natefinch: the logger.debugf("started mongod... line ?
<rogpeppe> i have no idea how to approach solving this problem
<jhobbs> natefinch: if i comment that out it changes quite a bit but still fails: http://paste.ubuntu.com/7199919/
<natefinch> jhobbs: that's the line.... that second panic is.... weird
<jcastro> Can we get someone to reconsider priority on https://bugs.launchpad.net/juju-core/+bug/1233497
<natefinch> jcastro: I'll bring it up with jam and fwereade.  It does seem like it would be good to fix, and probably not too too hard.
<jhobbs> natefinch: blah, i just had to install mongodb-server
<jhobbs> natefinch: thanks
<natefinch> jhobbs: oh, huh.... well we should probably have a better error message than that
<jhobbs> i agree :)
<natefinch> ..... or you know, like any message at all would be nice
<bac> hi bodie_, i'm trying to bootstrap a joyent env for the first time.  i'm using the latest 1.18 (r2257).  i'm getting this failure: http://paste.ubuntu.com/7199773/  -- any ideas?
<ValDuare> hi guys - im on a manual provision setup here - I cant destroy-machine 2   just goes to life: dead
<ValDuare> someone said try remove-machine 2   but no effect
<ValDuare> is this a bug I should report
<bodie_> bac: I'm pretty new here, and I've never worked with Joyent.  but it looks like you might have a malformed environment file.
<bodie_> perhaps someone else has something to add.
<natefinch> ValDuare: remove-machine and destroy-machine are the same thing, just aliases.  try destroy-machine 2 --force
<fwereade> ValDuare, is the machine running or has it been shut down?
<ValDuare> it is running
<fwereade> ValDuare, hmm, can you pastebin /var/log/juju/machine-2.log from that machine?
<ValDuare> ok
<fwereade> bac, would you try removing (or just moving?) ~/.juju/environments/joyent.yaml and trying again? might not help, but might help to eliminate some possibilities
<bac> fwereade: i have done that and get the same error
<bac> fwereade: at first i thought my ssh key might be too long as i created a 4096 bit key.  re-did with a 2048 bit and got the same error.
<fwereade> jcastro, will you still be on when thumper gets online? I think his debug-log work will eliminate that problem, but it might be good to check (and make sure he knows to mark it fixed)
<jcastro> ack, I'll ambush him
<ValDuare> http://pastebin.com/p7n9iFk0
<fwereade> bac, I *think* that is complaining about the joyent keyfile, not the ssh key
<bac> fwereade: i don't know what the joyent keyfile is
<bac> is it not trying to create a bucket to put the upload-tools?
<fwereade> ValDuare, so it *looks* like the machine agent should have stopped running -- is that correct?
<ValDuare> yes juju status says it is
<ValDuare> is stopped
<ValDuare> agent-state: stopped
<fwereade> ValDuare, if that's the case, you can safely destroy-machine --force -- but we'd really appreciate a bug report there, because I'm pretty sure it should also have told the API server to remove it
<ValDuare> ok
<fwereade> mgz, I don't suppose your joyent experience can be applied to bac's problem above?
<ValDuare> juju destroy-machine 2 --force has no effect
<fwereade> ValDuare, it might take a couple of seconds to do the cleanups, but if it's still around after say 10s there's something wrong
<ValDuare> ok
<bac> fwereade: i may have my 'algorithm' setting wrong.  it is an rsa key with DEK-Info: AES-128-CBC.  do you know how i should specify the algorithm for that setting?
<ValDuare> still there after 10s
 * fwereade is being called for supper with some impatience
 * fwereade will bbiab
<fwereade> ValDuare, a bug report with that log, and status output, would be awesome
<ValDuare> ok
<fwereade> bac, will you still be around in a couple of hours? wallyworld_ is your best hope for a quick solution there, I think
<bac> fwereade: i will.
 * fwereade really bbiab now
<stokachu> is it worth creating a bug about destroy-environment requires <provider> even if only one is listed in the environments.yaml?
<stokachu> for example, this is my environments file: http://paste.ubuntu.com/7200308/
<natefinch> stokachu: I don't think the inconsistency is worth saving the typing
<natefinch> stokachu: destroy environment is intentionally wordy because it is very destructive
<stokachu> natefinch: cool thats what i kinda figured, glad i ran it by you first
<natefinch> stokachu: it's ok, it was somewhat controversial... but if it saves one person from destroying their production environment by accident, it's probably worth it
<stokachu> definitely
<fwereade> natefinch, are you around for a bit? I need to get some sleep -- can I ask you to shepherd jhobbs' branch through to 1.18, or to hand over to someone in NZ?
<natefinch> fwereade: I'm here, but only for another half hour or so.  But I'll do what I can and try to hand off
<fwereade> natefinch, awesome, tyvm
 * fwereade away
<natefinch> jhobbs: what's going on?
<jhobbs> natefinch: https://code.launchpad.net/~jason-hobbs/juju-core/fix-armhf/+merge/212014
<jhobbs> natefinch: everything is passing tests now, not sure what to do next
<jhobbs> natefinch: sinzui is helping; i need to get a mp for 1.18
<natefinch> jhobbs: do you have lbox?
<jhobbs> lbox propose -cr --for=lp:juju-core/1.18
<jhobbs> yeah
<natefinch> right, yes, do that :)
<thumper> jcastro: o/
<jcastro> hey so debug-logs for local, would be really nice
<natefinch> ...and so the lion, after patiently lying in wait for its prey, pounces.
<jcastro> we're doing a bunch of local development lately and it's becoming really annoying to not have that
<thumper> jcastro: yeah, on it
<thumper> jcastro: so... anything else, or just complaining about missing features ;-)
<sinzui> jcastro, I admire your talking technique, but it need improvement. I think dimitern was given the feature
<thumper> sinzui: I'm working on debug-log
<thumper> sinzui: dimitern is working on vlan
<sinzui> thumper, do you have access to kick gobot? I think it is ill
<jcastro> thumper, no I just wanted to say that before we didn't  think it was important, but lately we're noticing that it's more important to us than before
<jcastro> sorry I am typing with one hand, on a call, but want to talk to thumper at the same time. :)
<thumper> jcastro: ack
<thumper> heh
<thumper> sinzui: yeah...
<jhobbs> natefinch: https://code.launchpad.net/~jason-hobbs/juju-core/1.18/+merge/214115
<thumper> sinzui: I have a shell alias 'gobot' that ssh's to the machine
<jhobbs> natefinch: it asked me to authenticate on google, i didn't know what to do there, so it failed to send the patch set to codereview
<sinzui> thumper, https://code.launchpad.net/~sinzui/juju-core/inc-1.18.0/+merge/214053 is a trivial change, but the same tests fail
<thumper> sinzui: hmm... v strange
<natefinch> jhobbs: the easiest thing to do is use your regular google credentials (assuming you have them)  like your gmail credentials.  Sometimes canonical creds work, but often not
<natefinch> jhobbs: do you have google credentials?
<jhobbs> natefinch: yeah
<jhobbs> natefinch: should i run that again then, with my google credentials?
<natefinch> do you use 2 factor auth?  that complicates things - you'd need an application-specific password (that's what I have to do)
<jhobbs> not on my private account
<natefinch> ok, then yeah, just re run it and use your home account info
<jhobbs> k cool
<natefinch> the account you use doesn't really matter as long as we can tell it's you.  I used my home account because I couldn't get my canonical creds to work
<jhobbs> yeah it should be pretty clear
<jhobbs> first.last, email should be listed on launchpad too
<natefinch> that's all mine is too
<natefinch> it's not like you need to prove it's you, just like, if it was foobar@gmail.com, people might get confused
<natefinch> sweet
<thumper> sinzui: nfi why that is failing
<jhobbs> guess you saw it, but https://codereview.appspot.com/84210043/
<thumper> sinzui: sorry, perhaps wallyworld_ could help when he starts
<sinzui> thank you thumper
<natefinch> jhobbs: yeah, got the email
<natefinch> jhobbs: ok, I gave it the LGTM, so now you go to the merge proposal on launchpad, add a commit message (copying the change description is fine) and then set the status to approved
<natefinch> and the bot takes care of the rest
<jhobbs> ok cool, i can't set it to approved though - not an option for me
<jhobbs> ditto for the original MP for trunk
<natefinch> huh weird, must be some permission issue.  I can do it
<jhobbs> thanks
<natefinch> welcome
<jhobbs> can you mark the trunk one approved too please? https://code.launchpad.net/~jason-hobbs/juju-core/fix-armhf/+merge/212014
<natefinch> done
<jhobbs> awesome!
<natefinch> unfortunately, there's no notification when your branch gets picked up by the bot, only when it finishes, so it can take a while, since it has to merge it into the branch and run the tests.  But there should be an email in 20-ish minutes saying if it worked or not (which it should, assuming the tests pass and there's no conflicts)
<perrito666> sinzui: rest of the world, if you would be so kind to review this shamefully short patch https://codereview.appspot.com/82280045
<jhobbs> natefinch: ok cool, i'll keep an eye out
<natefinch> perrito666: LGTM'd
<perrito666> tx natefinch
<natefinch> EOD, night all
<perrito666> natefinch: nites
<sinzui> thumper, is no-proxy a string (not a yaml list)? eg no-proxy: localhost,10.0.3.1
<ValDuare> https://bugs.launchpad.net/juju-core/+bug/1302132
<_mup_> Bug #1302132: manual provisioning destroy-machine fails - stuck at life: dead <juju-core:New> <https://launchpad.net/bugs/1302132>
<thumper> sinzui: correct, a string
<sinzui> thumper, fab.  I am writing a doc for it
<thumper> kk
<thumper> thanks
<sinzui> wallyworld, Do you have super powers to beat gobot into submission. It has rejected jhobbs and my branches repeatedly. My branch just changes the version to 1.18.0
<davechen1y> morning juju
<davechen1y> such that it is
<perrito666> davechen1y: yay one of those mornings at 19:43 :p
<davechen1y> perrito666: every day mate, every day
<perrito666> does anyone knows of a setup for go that prints build errors in color?
 * thumper rages at his own stupidity
 * thumper leaves in disgust
<davechen1y> waigani: morning
<davechen1y> how's today looking ?
<davechen1y> http://paste.ubuntu.com/7201087/
<davechen1y> slowly getting there
<davechen1y> hazmat: ping
#juju-dev 2014-04-04
<cmars> wallyworld_, i'm trying to write a standalone juju plugin (for fun & to learn) with the cmd.Command framework, connect to the state server, etc.
<cmars> thing is, when i try to connect, i get error: Unable to connect to environment "foo": no registered provider for "openstack"
<wallyworld_> "for fun"
<wallyworld_> ha
<cmars> :)
<cmars> to scratch an itch, actually
<cmars> what do i need to do to initialize those providers
<wallyworld_> you need to import from providers so the init() gets run
<cmars> ah, ok
<wallyworld_> use a _ at the start
<wallyworld_> so it doesn't complain about unused imports
<wallyworld_> grep for it and you'll see where else it's done
<mischief61507> davechen1y: how hard do you think it would be to remove all use of non-portable syscall imports from juju-core/cmd/juju and its deps? :)
<cmars> wallyworld_, that did the trick, thanks
<wallyworld_> np
<davechen1y> mischief61507: not hard
<davechen1y> mischief61507: can you raise and issue with the syscalls that are missing
<davechen1y> i'm assuming its the usual TCSET/TCGET
<davechen1y> ictls
<mischief61507> nono
<mischief61507> it's mainly use of nonportable signal names
<mischief61507> i would like to run juju-core/cmd/juju on plan 9 you see, and once i hacked out the references to nonportable signal names from syscall, it seemed to run ok
<davechen1y> mischief61507: i'm sure we can do some kind of conditional compilatoin
<mischief61507> yea, having _unix and _plan9.go files would likely work
<davechen1y> mischief61507: https://bugs.launchpad.net/juju-core/+filebug
<davechen1y> if you would be so kind
<sinzui> wallyworld_, Do you have an experience unfucking gobot. we have a backlog of branches that cannot merge in 1.18.
<wallyworld_> sinzui: i have and i will
<wallyworld_> sinzui: bot is running
<wallyworld_> must be something else
<wallyworld_> i'll look
<wallyworld_> it says no approved proposals for 1.18
<sinzui> wallyworld_, jhobbs and I stopped after a while
<sinzui> wallyworld_, This is mine https://code.launchpad.net/~sinzui/juju-core/inc-1.18.0/+merge/214053
<wallyworld_> sinzui: gotbot claims that one is not approved
<sinzui> I will approve it again
<sinzui> done
<wallyworld_> sinzui: and tests running
<sinzui> wallyworld_, gobot failed the version change to 1.18.0 again https://code.launchpad.net/~sinzui/juju-core/inc-1.18.0/+merge/214053
<wallyworld_> :-(
<wallyworld_> do you need me to check anything?
<wallyworld_> hmmm.
<wallyworld_> looking at the errors, looks like it fails to upload and/or find tools
<wallyworld_> sinzui: i can look into it
<waigani> thumper: juju-mongodb was installed but mongodb was not. If tests rely on mongodb, should it be added to the makefile as a dependency?
<thumper> yes probably
<thumper> but the real problem is that on trusty, the tests should rely on juju-mongodb
<waigani> thumper: okay, as a temp patch, should I add it in?
<thumper> add what where?
<waigani> thumper: to the makefile - install dependencies
<thumper> https://bugs.launchpad.net/juju-core/+bug/1301353
<_mup_> Bug #1301353: juju test suite should use juju-mongodb <tech-debt> <trusty> <juju-core:Triaged> <https://launchpad.net/bugs/1301353>
<thumper> waigani: no
<thumper> waigani: perhaps fix that bug
<waigani> ah
<thumper> waigani: also, there is the test to make sure that juju-mongodb is installed for the local provider prechecker
<thumper> waigani: that would be a good thing to fix too
<davechen1y> thumper: isn't juju-mongodb a dep of juju-local now ?
<thumper> davechen1y: I believe so
<thumper> davechen1y: but many people don't have juju-local installed when trying to use the local provider
<thumper> we should tell them
<sinzui> davechen1y, thumper. It appears NO juju users install the juju-local package
<sinzui> I have had 5 complaints from canonical staff in 2 weeks alone. Juju local is broken they say. They have not installed juju-local to get the correct deps
<davechen1y> sinzui: shitballs
<sinzui> I amended the release note to make it clear juju-local is required https://docs.google.com/a/canonical.com/document/d/1h13ZT7dB-Ajl2MHUJA2Qt0BKGPTZq2pFXqAVKGYSinQ/edit?disco=AAAAAJTTWP8
<davechen1y> and there isn't a file path that we can hang the usual check off
<davechen1y> dumb suggestion: juju-1.18 depends on juju local
<davechen1y> i think that is a less worse solution that making it optional
<davechen1y> actually
<davechen1y> scrap that
<davechen1y> i can see the complains about mongodb already
<davechen1y> shit, sam left something at home
<davechen1y> back in 10 mins, gotta go drop it off
<sinzui> davechen1y, I think jamespage mulled that suggestion in the past. We don't want lxc on the servers in many cases, but for many people, local provider is the first env they test before sending a stack to a cloud that costs moneyh
<sinzui> waigani, thumper, maybe juju shouldn't check for mongodb-server or cpu-checker or rsyslog-gnutls. Just check for juju-local. No package, then stop and demand it
 * thumper nods
<waigani> okay
<davechen1y> sinzui: agreed
 * thumper does a little dance
<davechen1y> thumper: pics or it never happened
<thumper> wow... I think I am finally happy with the apiserver tests for this...
 * thumper just needs a pile of number eight wire
<thumper> and we can move this thing forwards
<waigani> provider/local has checks for rsyslog-gnutls. Should this be replaced with a check for juju-local?
<thumper> waigani: yes
<thumper> axw: do you know if juju-local depends on rsyslog-gnutls?
<axw> thumper: I raised a but about it a while ago, I think sinzui or jamespage did it
<axw> thumper: apt-cache says yes
<sinzui> thumper, It does
<thumper> cool
<thumper> waigani: so, yes, that is your answer
<waigani> ah, this is what I've done: lp:~waigani/juju-core/1301353-mongodb-dep
<waigani> just pushing it up to pull down and test on ppc vm
<thumper> simple review for someone:  https://codereview.appspot.com/84290045/
<axw> thumper: looking
<axw> thumper: how do you intend to use StartedTailing?
<thumper> axw: I have it in a test where I need to wait until the back looking seeking is done
<thumper> so I wait on a channel
<thumper> that the StartedTailing closes
<thumper> then I write more
<thumper> I wish we had some form of signals and slots built into the language
<thumper> that'd work too
<thumper> but no
<axw> you provide a ReadSeeker - why not just do it there?
<axw> in the Seek()
<thumper> because I don't seek
<thumper> and I'm just providing it a real file
<thumper> Although I think I see what you are getting at
<axw> if there's no seek, fine, but otherwise you can override
<axw> I don't like exposing things like this for testing
<thumper> hmm...
<thumper> ok
<thumper> I think I just got another form of 'no reachable servers'
<thumper> panic: interface conversion: interface is nil, not *websocket.Conn,  home/tim/go/src/launchpad.net/juju-core/state/api/apiclient.go:140
<thumper> I'll look to see if I can rewrite the test
<axw> thanks
<thumper> axw: ok, I got it working, but only because that test doesn't seek backwards from the end
<thumper> but I guess it is sufficient
<axw> thumper: cool. see my comment on the CL, let me know what you think
<thumper> hmm... I really want to avoid messing around with tailer too much
<thumper> ok, that's it
<thumper> I'm done
<thumper> night all
<waigani> eod wip(am I on the right track?): https://codereview.appspot.com/84360043
<dimitern> morning all
<axw> morning dimitern
<dimitern> hey axw
<davechen1y> EOW => til next week gentlemen
<wallyworld> fwereade: instance type constraint https://codereview.appspot.com/84310044
<wallyworld> fwereade: also, tests fixes for 1.18 https://code.launchpad.net/~wallyworld/juju-core/fix-tools-tests-1.18/+merge/214159
<fwereade> wallyworld, I'm just reviewing it, but I have to pop out for an hour shortly
<fwereade> wallyworld, I'll send what I have in a mo, there's one significant thing
<wallyworld> fwereade: i'm off to soccer so no hurry
<wallyworld> jst wanted to let you know they were there
<fwereade> wallyworld, in particular, what instance-type implies varies by provider
<wallyworld> especially the 1.18 fix
<wallyworld> fwereade: sure, it varies, so for ec2 you say instace-type=m1.small, for openstack something else
<fwereade> wallyworld, eg in ec2 having a root-disk constraint override an inherited instance-type constraint is definitely wrong -- they're independent -- but in ec2 root-disk is part of the instance type
<fwereade> wallyworld, different vocabularies== np at all, we have varying arches across clouds today
<wallyworld> oh i see
<fwereade> wallyworld, we have to delegate fallback handling to the providers I think
<wallyworld> right, i didn't get that subtlety
<fwereade> wallyworld, it might be easiest to do this by storing everythying as stacks of constraints and handing over both of those at startinstance time
<fwereade> wallyworld, but that implies schema changes
<wallyworld> yeah, was thinking our current approach won't work now
<wallyworld> well
<wallyworld> we could defer the fallback behaviour
<fwereade> wallyworld, so axw/waigani's policy stuff might be the way to make those calculations at the time we do currently
<wallyworld> sure, the provides can always read the env constraints as needed
<fwereade> wallyworld, we could defer, but we have to capture the inputs at the same time we currently do the fallbacks
<wallyworld> np, i'll take a look
<wallyworld> do we have the rules documented for how to fall back?
<wallyworld> for each rpovider?
<fwereade> wallyworld, it's pretty much "what does an instance type imply" in this particular context
<wallyworld> that's what i'm no sure of. i can read the ec2 docs
<wallyworld> anyways, gotta run to soccer
<fwereade> wallyworld, ec2 is potentially misleading
<fwereade> wallyworld, indeed, we can chat later
<wallyworld> fwereade: if you want to put a few thoughts down, drop me a line or we can chat
<wallyworld> but apprt from the fallbac, i think the approavh works
<wallyworld> or seems to work fine
<wallyworld> code change to use the constraint itself was quite small
<fwereade> wallyworld, yeah, I don't think it's devastatingly complex
<fwereade> wallyworld, tyvm for this :)
<wallyworld> np, we really need it
<wallyworld> like last year
 * fwereade winces gently
<wallyworld> fwereade: highest priority now though is the 1.18 test fix
<wallyworld> to unblock the release
<rogpeppe> well, at least i've got my second monitor working again now, kinda
 * rogpeppe doesn't trust trusty any more
 * rogpeppe tries to work out how to use lubuntu
<rogpeppe> here's an interesting mongod failure: http://paste.ubuntu.com/7202291/
<rogpeppe> i thought that most of the replicaset test failures were due to socket address clashes, but the above makes it look like mongod crashes might also be a contributor
<axw> that doesn't look great
<fwereade> wallyworld, when you're back, can we talk a bit about upload-tools? as, indeed, a higher priority than the instance-type stuff
<axw> rogpeppe: I managed to bootstrap local provider with natefinch's branch, with a few modifications - I added some comments to the CL
<axw> EnsureMongoServer that is
<rogpeppe> axw: great, thanks
<voidspace> morning all
<rogpeppe> voidspace: morning!
<dimitern> fwereade, hey, just updated https://codereview.appspot.com/83070047/ with your suggestions and I think it should be ready to land if you can take a look
<fwereade> dimitern, will do
<fwereade> dimitern, rogpeppe, I would appreciate thoughts on https://code.launchpad.net/~wallyworld/juju-core/fix-tools-tests-1.18/+merge/214159 -- I am concerned that disallowing upload-tools will screw customers in isolated environments -- I guess I'm behind on something here?
<rogpeppe> fwereade: looking
<dimitern> fwereade, so --upload-tools will be allowed only for dev versions?
<ev> jcastro: you were going to add me to the regular charmers call, but either I lost the invite or never got one. When is it?
<fwereade> dimitern, it looks like that's already happened but it scares me -- clients use the ehh-just-use-the-local-jujud-it's-probably-good-enough functionality in upload-tools
<fwereade> dimitern, rogpeppe: do you recall when that changed? I know it's something we're working towards but I'm not sure all the other pieces to support it nicely are in place yet
<fwereade> I'll ask wallyworld when he comes back :)
<rogpeppe> fwereade, dimitern, voidspace, mgz, axw: i'd appreciate a review of this fairly involved test that tries to sanity-check our singular worker approach: https://codereview.appspot.com/84470043
<dimitern> rogpeppe, looking
<dimitern> fwereade, oww..
<rogpeppe> fwereade: sorry, i got distracted finishing up this proposal. will really look now :-)
<fwereade> rogpeppe, I know the feeling
 * fwereade is trying to do about three things at once
<rogpeppe> fwereade: it seems weird that upload-tools is disabled for release versions. i hadn't noticed it.
<rogpeppe> fwereade: and i certainly managed to upgrade-juju with --upload-tools recently, although that was from a 1.16 environment (tho using 1.18 juju) so might not count
<rogpeppe> fwereade: my thoughts are that it scares me too
<fwereade> rogpeppe, I think it'll have to be a standup topic
<rogpeppe> fwereade: yeah
<fwereade> rogpeppe, please remind me if I forget :)
<rogpeppe> fwereade: have you got a moment to discuss Ping?
<fwereade> dimitern, LGTM with a couple of tweaks, ping me if anything's surprising
<fwereade> rogpeppe, I expect so, which one?
<fwereade> rogpeppe, the keepalive thingy?
<rogpeppe> fwereade: well, as part of the singular worker stuff, we need to be able to ping the state session to make sure that mongo hasn't changed masters
<perrito666> morning everyone
<rogpeppe> fwereade: for the StateWorker, that's easy because we've got access to the *state.State and thence its mgo.Session
<jam> fwereade: if we disabled upload-tools, but enable the ability to use the local jujud as a simplestreams source (juju bootstrap --source=/usr/lib/juju/local-tools) ?)
<jam> I don't think we can just disable it, either.
<rogpeppe> fwereade: but for the APIWorker, there's no easy way, because the api Ping doesn't actually check that the underlying mgo.Session is still alive
<rogpeppe> fwereade: i'm considering making api.State.Ping do a ping of the underlying mgo.Session if the connected agent is an environ manager
<jam> rogpeppe: I thought you didn't need to ping mongo as we expected the connection to break and bounce the API servers
<rogpeppe> jam: we have to know when the connection breaks
<fwereade> rogpeppe, yeah, I thought we were relying on operations failing?
<jam> fwereade: I guess the issue is that since environ-provisioner is on the other side of the API, then every API facade call should technically check IsMaster
<jam> otherwise between API calls master could change... ?
<rogpeppe> fwereade: we can rely on that for the master, but the secondaries need some way of knowing too
<jam> though I thought we also bounce the API server which bounces the provisioner
<rogpeppe> jam: we don't need to check on every call, because if isMaster changes, then the API call will fail
<fwereade> rogpeppe, sorry, I'm having difficulty swapping context
<rogpeppe> the problem i'm considering is: when an agent is *not* master, it doesn't run any of the singular workers, but it needs to know when the master has changed, so it can't do exactly nothing
<jam> rogpeppe: don't all connections get bounced when the master changes?
<rogpeppe> so i make it ping the connection periodically to make sure that the status is as before. when the ping fails, it knows the master might have changed, so it reconnects
<jam> certainly replsetReconfig bounces all connections.
<jam> rogpeppe: and I thought everything actually just connects to the master to do any Write operation, so it will also bounce
<jam> it just needs to know if the connection is "local"
<rogpeppe> jam: only if the API server is actually doing something
<rogpeppe> jam: the only way we know if the master has changed is if some operation fails
<rogpeppe> jam: but there might not be any operations happening.
<jam> rogpeppe: so we don't notice a disconnect by itself?
<rogpeppe> jam: how would we?
<jam> rogpeppe: Presence pingers are very likely to be triggering all the time
<jam> that writes to the Presence DB
<jam> \
<jam> but if an API server didn't have any clients
<jam> it would still have its own pinger?
<fwereade> rogpeppe, jam: can we force state servers to connect to their own api server? would that resolve it?
<rogpeppe> jam: hmm, it's possible that an agent, by virtue of being connected, has a presence pinger that will kill the connection if it dies
<rogpeppe> fwereade: not really
<jam> fwereade: I'm pretty sure we already do by writing "localhost" into agent.conf
<fwereade> rogpeppe, jam: that'd guarantee at least one connection with a presence pinger for each state server?
<rogpeppe> fwereade: hmm, i see what you're getting at.
 * rogpeppe thinks
<dimitern> fwereade, cheers!
<voidspace> natefinch: morning nate
<natefinch> howdy-ho neighbors
<rogpeppe> natefinch: hiya
<wwitzel3> hey natefinch
<rogpeppe> fwereade, jam: i haven't yet found anything that would imply that a presence-pinger failure would cause an api connection teardown
<rogpeppe> and we might actually have a problem, because i'm not sure that *anything* will cause the API server to fail when the state connection fails.
 * rogpeppe wonders about a decent way to do that
<fwereade> rogpeppe, hmm -- yeah, looks like the pinger's just left lying around -- but it doesn't seem like it would be too bad to have a goroutine waiting for pinger failure, and using that condition to tear down the connection
<natefinch> axw: thanks for all the comments on the EnsureMongoServer branch.  It was tested and working last week with the local provider, but we've done some significant refactoring since then, so it's entirely possible we messed some stuff up.  I'll be doing live testing today.  I'll apply your suggestions as we go.
<rogpeppe> fwereade: i wonder about a single goroutine started in apiserver.Server.run which periodically pings the underlying state, and if that fails, kills the Server.
<fwereade> rogpeppe, that's probably cleaner
<fwereade> rogpeppe, shorter chain of dependencies to get amusingly broken at surprising times
<rogpeppe> fwereade: yeah
<rogpeppe> fwereade: right, i'll make a ticket for it
<rogpeppe> jam: does that sound reasonable to you?
<dimitern> rogpeppe, reviewed
<dimitern> perrito666, standup?
 * perrito666 having computer problems, ill be right there
<jam> rogpeppe: sgtm
<rogpeppe> jam: cool
<rogpeppe> jam: standup?
<jam> rogpeppe: not working today :)
<jam> "not" working
<rogpeppe> jam: ah, of course. what are you doing here then? :-)
<jam> rogpeppe: "not" working, certainly
<natefinch> he just misses us
<wwitzel3> jam: lol
<perrito666> question, how many lgtms I need on this to merge it? https://codereview.appspot.com/82280045
<rogpeppe> perrito666: just one, assuming you're happy with the reviewer's knowledge of the code
<perrito666> rogpeppe: I think you wrote the code originally :) so yours woud be appreciated, you will find it really really short
<rogpeppe> perrito666: i don't understand the change
<rogpeppe> perrito666: why is 2 seconds too short?
<perrito666> rogpeppe: when there is lag, the wait time is 2 sec + whatever it takes for the server to answer
<perrito666> when you are next to the machine however, that time is almost inexistent
<perrito666> so the time waited is not enough and the operation times out
<rogpeppe> perrito666: isn't this script always running on the machine itself?
<rogpeppe> perrito666: also, this sleep is inside a loop anyway, so i don't see why it makes a big difference
<perrito666> rogpeppe: it is a seq loop, it will basically wait up to 120 secs, which is not enough in some cases (you make a point on that running remotely, strange)
<rogpeppe> perrito666: if you want to increase the overall timeout, then it would be better to increase the seq, to say (seq 1 300)
<perrito666> rogpeppe: I see, why? (I changed the time bc It made more sense to me to wait a bit between retries intead of hitting a lot more times)
<dimitern> fwereade, updated https://codereview.appspot.com/83070047/
<rogpeppe> perrito666: it depends how long it usually takes
<rogpeppe> perrito666: how about a 5 second delay and 100 reps?
<perrito666> sounds like a good compromise :)
<wwitzel3> brb
<perrito666> rogpeppe: thanks for your input man :) I added the change
<perrito666> s
<rogpeppe> perrito666: np
 * perrito666 wonders if he can teach his vi to do bash coloring for bash inside go
<rogpeppe> perrito666: ha ha, that would be a nice trick
<voidspace> rogpeppe: so this is my basic approach https://code.launchpad.net/~mfoord/juju-core/wrapsingletonworkers/+merge/214208
<voidspace> rogpeppe: I know you'd *rather* we were calling agentState.Ping() - but that won't work *yet*, right?
<rogpeppe> voidspace: it will soon. i'd prefer it if this just used that, please.
<voidspace> rogpeppe: ok
<voidspace> rogpeppe: in which case, does the agent.State fulfill the singular.Conn interface
<voidspace> let me find out
<rogpeppe> voidspace: hmm, not quite
<rogpeppe> voidspace: as it doesn't have Ping
<rogpeppe> voidspace: we could just add Ping to agent.State though
<rogpeppe> voidspace: alternatively (and perhaps better) just make your type be: type myConn struct {*agent.State; *api.State}
<rogpeppe> voidspace: and i think *that* should fulfil the interface
<voidspace> rogpeppe: duplicate field State
<voidspace> oh
<rogpeppe> voidspace: ha
<voidspace> anyway, that aside
<voidspace> I have a lunch date apparently
<voidspace> so I have to go
<rogpeppe> voidspace: there's a cunning way around it though
<voidspace> back in a bit
<rogpeppe> voidspace: enjoy!
<voidspace> rogpeppe: I will hear your cunning plan on my return
<BjornT_> could someone please help me debug why juju can't connect to the bootstrap node when bootstrapping? i'm trying to bootstrap a maas environment (using vms). the bootstrap node comes up, but juju can't seem to be able to connect to it.
<BjornT_> the debug log is showing that juju is trying to do this: http://pastebin.ubuntu.com/7202991/
<BjornT_> if i run that ssh command manually, i'm able to connect to the machine, but juju can't for some reason, and i'm not sure how to figure out why
<rogpeppe> dimitern: i responded to your review, BTW:  https://codereview.appspot.com/84470043/
<dimitern> rogpeppe, http://play.golang.org/p/IVDHjlYPXf
<dimitern> rogpeppe, that's re your answer to my question about simplifying that line of code
<perrito666> BjornT_: ist it giving more details on the connetion failure?
<rogpeppe> dimitern: ah yes, i see
<dimitern> :)
<rogpeppe> dimitern: now i come to think of it, i remember deliberately leaving the +1-1 in there
<BjornT_> perrito666: the juju log doesn't say it fails, it just keeps retrying all the time, it seems
<rogpeppe> dimitern: otherwise i think the logic is more obscure
<rogpeppe> dimitern: logically, we're adding one to get the next in sequence, subtracting one to make it into a zero-based index, then modulo, then add one again
<rogpeppe> dimitern: so i *think* i'd rather leave that logic explicit
<dimitern> rogpeppe, ok, but please add a comment
<rogpeppe> dimitern: ok
<rogpeppe> dimitern: (although i'd *definitely* need a comment if i went with your suggestion - it's not that obvious what it's doing :-)
<rogpeppe> )
<rogpeppe> dimitern: done
<dimitern> rogpeppe, ta!
<BjornT_> perrito666: now it finished, and shows this error: http://pastebin.ubuntu.com/7203035/
<dimitern> rogpeppe, LGTM
<perrito666> BjornT_: have you tried removing the key from the keyfile?
<rogpeppe> dimitern: ta!
<BjornT_> perrito666: yes, didn't help
 * perrito666 scratches head
<BjornT_> perrito666: me to :-/ the maas environment i have with real machines seems to work fine, but i can't figure out what's different with this setup
<wwitzel3>  
<perrito666> wwitzel3: how eloquent
<wwitzel3> ignore me!
<hazmat> davecheney, pong
<wwitzel3> ok, there we go, all better :) was having some weird window manager issues
<perrito666> wwitzel3: ah happens
<perrito666> BjornT_: well if it is a whole virtual setup, some weirdness might occur in the network config (I am purely guessing here)
<BjornT_> perrito666: well, i think i've found the culprit. it seems the curtin installer is failing for some reason, so probably not a juju issue
<bits3rpent> Hey, I was just running through the code yesterday, and I didn't understand a part of server.go 100%.
<bits3rpent> I was wondering in the context of say, a client running the set command, how would bindRequest find out which method to run?
<fwereade> bits3rpent, hmm, the MethodCaller stuff rings a bell, but rogpeppe will remember the details better than I will
<fwereade> bits3rpent, I would suggest that digging into the infrastructure is relatively unlikely to directly help you accomplish anything app-level -- what are you working on at the moment?
<natefinch> rogpeppe: have you had a chance to look at that commented out code in Machineagent's APIWorker?  It needs the StateServingInfo, but it has an api.State not a state.State, and thus doesn't have a StateServingInfo() method on it.
<voidspace> rogpeppe: https://code.launchpad.net/~mfoord/juju-core/wrapsingletonworkers/+merge/214208
<rogpeppe> natefinch: will do
<rogpeppe> natefinch: would you be able to have a glance through https://codereview.appspot.com/84470043/ before i approve it, please?
<natefinch> rogpeppe: sure thing
<rogpeppe> natefinch: there's a StateServingInfo method on State.Agent()
<mattyw> fwereade, would you be able to take another look at this: https://codereview.appspot.com/83060049/
<natefinch> rogpeppe: oh yeah, right, MachineAgent has a state in it.  Sorry, got confused by the local variable in that method
<rogpeppe> natefinch: i've made the change in my branch (and a couple more, rationalising the use of configChanged). i will push up shortly, when i've run tests
<rogpeppe> pwd
<rogpeppe> natefinch: we'll want a test that a machine agent started with no state serving info in its config will get it from state, start the api server, and stash the info in its config
<natefinch> rogpeppe: great, thanks.  Yeah, that test sounds like a pain, but definitely needed.
<voidspace> rogpeppe: NewEnvironProvisioner is called twice
<voidspace> rogpeppe: once in cmd/jujud/machine.go
<voidspace> ah no
<voidspace> rogpeppe: the second one is container_initialisation_*test*
<voidspace> my brain parsed out the "_test" bit on first read
<voidspace> never mind
<voidspace> sorry
<rogpeppe> natefinch: tests seem to pass. here's the branch for you to merge: lp:~rogpeppe/juju-core/natefinch-030-MA-HA
<natefinch> rogpeppe: awesome, doing so now
<natefinch> rogpeppe: is st.Agent().StateServingInfo() better than using MachineAgent's st.StateServingInfo?
<rogpeppe> natefinch: i don't understand
<natefinch> a.st.StateServingInfo()  in that place
<rogpeppe> natefinch: oh yeah
<rogpeppe> natefinch: MachineAgent.st is horribly bogus
<natefinch> rofl
<rogpeppe> natefinch: it should not be there
<natefinch> wow ok
<rogpeppe> natefinch: and it's not available at that point anyway
<rogpeppe> natefinch: MachineAgent.st is a really nasty hack to try and get the *state.State from a StateWorker to the APIWorker
<rogpeppe> natefinch: for the upgrade code
<natefinch> that's unfortunate
<rogpeppe> natefinch: it would be considerably better if the upgrade code made its own connection to the state
<voidspace> rogpeppe: https://pastebin.canonical.com/107793/
<voidspace> rogpeppe: now I have to change my monitor orientation!
<rogpeppe> voidspace: sorry 'bout that
<natefinch> lol
<wwitzel3> natefinch: hangout?
<wallyworld> fwereade: sinzui : tested live on ec2 with version 1.18 and bootstrap --upload-tools https://code.launchpad.net/~wallyworld/juju-core/fix-tools-tests-1.18/+merge/214159
<wallyworld> the branch name is now misleading
<natefinch> wwitzel3: sure
<wallyworld> fwereade: sinzui : i gotta get some sleep so if it's +1 could one of you please approve so it can land
<fwereade> wallyworld, many thanks indeed
<sinzui> wallyworld, thank you very much. I will manage its landing when the time comes
<wallyworld> fwereade: i took a while cause i went down so many dead alleys trying to get all the tests to pass, and i had to find exactly the right tweaks
<fwereade> wallyworld, you have gone even further above and beyond than usual
<wallyworld> np. i really hope it works, i'll check email with anticipation later :-)
<rogpeppe> natefinch: did you manage to have a look through https://codereview.appspot.com/84470043/ ?
<rogpeppe> natefinch: don't worry if not. i'll approve it anyway.
<wwitzel3> lol
<natefinch> haha...
<natefinch> rogpeppe: sorry, got halfway through and got distracted.  was hoping we could put the unreliable tests somewhere central so other places can use it
<rogpeppe> natefinch: the flag, you mean?
<natefinch> rogpeppe: yes, sorry
<rogpeppe> natefinch: yes, that's not a bad idea
<natefinch> juju-core/testing maybe
<rogpeppe> natefinch: i'll consider it for the future, but if that's the only issue, i'll go ahead with it anyway.
<rogpeppe> natefinch: when some other test requires it, it can move it into testbase
<natefinch> rogpeppe: fair enough.
<natefinch> rogpeppe: not sure I can review the whole thing right now, there's quite a lot of code.
<rogpeppe> natefinch: np
<voidspace> rogpeppe: added the singularRunner to StateWorker and removed the now extraneous New functions
<voidspace> https://code.launchpad.net/~mfoord/juju-core/wrapsingletonworkers/+merge/214208
<rogpeppe> natefinch: it's mainly there to convince myself that the strategy works
 * rogpeppe finds it difficult to read diffs without full context...
<natefinch> rogpeppe: me too
<voidspace> I have the same problem with reitveld - I consider the rest of the diff to *be* context...
<voidspace> rogpeppe: either your microphone is right by your keyboard - or you're typing with a sledgehammer
<dimitern> fwereade, rogpeppe, mgz, Provisioner API for networks and interfaces https://codereview.appspot.com/84570043 PTAL
<rogpeppe> voidspace: the problem is the i see the changes, and often the start of the function is missing, so i have to try to infer which function the changes are in
<mgz> dimitern: looking
<rogpeppe> voidspace: that all looks great, BTW. i think i'd put the singular conn types at the end of the file though.
<voidspace> yeah, good call
<rogpeppe> voidspace: i'm not sure which extraneous New functions you meant, but i guess it doesn't matter now they're gone :-)
<voidspace> I had New functions to instantiate the singular*Conn structs
<voidspace> but not needed, can just use singularStateCon{state, machine} (etc)
<voidspace> I've muted the hangout by the way
<rogpeppe> voidspace: also, i have a vague convention that if i'm mocking something, i'll make the name the same as the usual name, but without the dot. so i'd use singularNew to mock singular.New, even though the name reads slightly more awkwardly.
<voidspace> tempted to say I have a convention to use the best name for the thing being mocked
<voidspace> but I will resist
<rogpeppe> voidspace: well, i've never actually stated that convention; it's just something that i've been doing and seems to work ok
<voidspace> rogpeppe: that would mean the test would need to be an explicitly whitebox test
<voidspace> rogpeppe: but I guess it avoids making the alias a publicly exported part of the package under test
<rogpeppe> voidspace: it *is* an explicitly whitebox test, if you're mocking out function definitions
<voidspace> right
<rogpeppe> voidspace: FWIW the point is moot in cmd/jujud anyway, because all the tests are in the package itself
<voidspace> ok
<rogpeppe> voidspace: and i feel that avoiding polluting the public docs is an important thing
<voidspace> yep, fair point
<rogpeppe> voidspace: (not that that's an issue in cmd/jujud though)
<fwereade> sinzui, I think I'm happy with wallyworld's patch -- if I mark it approved can I leave it in your hands from then on?
<sinzui> Thank you fwereade
<voidspace> I still think in terms of Python, where NewSingularRunner(thing) looks like a constructor function call and singularRunner(thing) doesn't
<rogpeppe> voidspace: yeah, so singularNew doesn't look like either. but it's sufficiently unusual that hopefully people will either a) understand the convention and know it's intended to be an alias for singular.New or b) go and look at the def'n
<voidspace> coffee
<perrito666> voidspace: marvelous idea, Ill have one too, no sugar please
<perrito666> :p
<wwitzel3> when I set my scrollback buffer to 5000 I didn't know at the time I'd be having to read juju test failures
<wwitzel3> or I would of set it much larger :P
<natefinch> wwitzel3: go get github.com/natefinch/nolog  && nolog ./...
<natefinch> optionally pass it -f to write out the full log to tests.out in the current directory
<dimitern> mgz, does it make sense?
<dimitern> mgz, the CL I mean :)
<mgz> typing m in now
<mgz> dimitern: done
<dimitern> mgz, ta!
<mgz> dimitern: anything unclear? my normal kind of not-super constructive review.
<dimitern> mgz, :) it's fine, I'll split some of the larger tests when possible
<dimitern> fwereade, mgz, next in line - StartInstance() returns network information (but in this CL just the interface is changed, so it's trivial) https://codereview.appspot.com/84470044
<mgz> nil, nil, nil, err
<rogpeppe> nil, nil, nil, nil, nil, err
<arosales> sinzui: fyi dannf submitted https://bugs.launchpad.net/juju-core/+bug/1302205 this is a critical one for arm
<_mup_> Bug #1302205: manual provisioned systems stuck in pending <add-machine> <hs-arm64> <manual-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1302205>
<arosales> sinzui: I see you just traiged it
<sinzui> arosales, making changes now
<hazmat> arosales, that log output is normal
<rogpeppe> wwitzel3: my scroll buffer is infinite...
<wwitzel3> rogpeppe: well that's just not true
<rogpeppe> wwitzel3: well, it might start struggling at >10GB :-)
<wwitzel3> haha
<rogpeppe> wwitzel3: although it's disk-backed, so it won't use more RAM
<wwitzel3> rogpeppe: yeah, I can enable disk based buffer, I've just been lazy
<wwitzel3> rogpeppe: and I bumped mine up to 10k, which is good enough
<rogpeppe> wwitzel3: ha ha! you haven't been running uniter tests recently :)
<wwitzel3> rogpeppe: I'm looking forward to that then
<arosales> hazmat: stuck in pending, could that be firewalls?
<hazmat> arosales, not for manuala
<natefinch> dammit ubuntu, stop losing my damn windows
<hazmat> arosales, its strange the machine logs there say there connecting back to the state server
<wwitzel3> natefinch: I can no longer lose a window, even if I want to ...
<natefinch> somewhere, invisible to the desktop, I have a google hangout window
<arosales> hazmat: ok, re firewall
<hazmat> arosales, it might be an issue on the state server
<hazmat> arosales, there's a couple of panics / process restarts there
<dimitern> mgz, it will eventually get nil, err, but not today :)
<arosales> hazmat: thanks for taking a look.
<hazmat> that's odd too.. 2014-04-03 18:09:57 ERROR juju.worker environ.go:56 loaded invalid environment configuration: storage-port: expected int, got float64(8040)
 * hazmat wonders if this is related to new instance updater code lands
<hazmat> oh this is arm64
<rogpeppe> dimitern, voidspace, fwereade, wwitzel3, natefinch, mgz: here's the code that kills the api server when the mongo connection goes down: https://codereview.appspot.com/84540044
<dimitern> rogpeppe, looking
<rogpeppe> dimitern: thanks
<voidspace> rogpeppe: cool
<dimitern> rogpeppe, reviewed
<rogpeppe> dimitern: ta!
 * dimitern gives up on trying to land all vlan stuff today :/ it's still couple of branches away
<dimitern> mgz, but I can at least land the StartInstance CL ;)
<mgz> dimitern: okay, I'll stamp that one
<dimitern> mgz, tyvm
<mgz> dimitern: lgtm
<dimitern> mgz, ta
<natefinch> rogpeppe: I've forgotten, what did we do to fix "cannot get replset config: not authorized for query on local.system.replset" when we try to initiate?
<natefinch> 'cause it's back
<rogpeppe> natefinch: when are you getting it?
<natefinch> rogpeppe: in bootstrap, just before we initiate state, we're calling ensuremongoserver and then maybeinitiatereplset
<natefinch> er MaybeInitiateMongoServer... it fails in there
<rogpeppe> natefinch: live or in tests?
<natefinch> rogpeppe: live
<rogpeppe> natefinch: local provider?
<natefinch> rogpeppe: nope, amazon
<wwitzel3> rogpeppe: and for me on maas
<rogpeppe> natefinch: are you in a hangout?
<natefinch> https://plus.google.com/hangouts/_/7ecpi12cuupgkah473lbirvs1k
<tvansteenburgh> hey guys, i'm deploying a trusty workload to lxc, and all unit agent-states get stuck in "pending" and never come up. machine-0 log -> http://paste.ubuntu.com/7203724/
<tvansteenburgh> looking for help on how to proceed if anyone has time
<tvansteenburgh> precise workload deploys fine
<tvansteenburgh> $ juju --version
<tvansteenburgh> 1.17.7-trusty-amd64
<tvansteenburgh> the trusty cloud image isn't even being downloaded:
<tvansteenburgh> root@trusty-vm:/home/tvansteenburgh# ll /var/cache/lxc/
<tvansteenburgh> total 12
<tvansteenburgh> drwx------  3 root root 4096 Apr  4 11:08 ./
<tvansteenburgh> drwxr-xr-x 18 root root 4096 Mar 25 12:06 ../
<tvansteenburgh> drwxr-xr-x  2 root root 4096 Mar 26 14:51 cloud-precise/
<tvansteenburgh> root@trusty-vm:/home/tvansteenburgh# lxc-ls --fancy
<tvansteenburgh> NAME                   STATE    IPV4  IPV6  AUTOSTART
<tvansteenburgh> -----------------------------------------------------
<tvansteenburgh> juju-precise-template  STOPPED  -     -     NO
<rogpeppe> wwitzel3: ~rogpeppe/juju-core/natefinch-030-MA-HA/
<wwitzel3> rogpeppe: thanks
<rogpeppe> tvansteenburgh: interesting
<rogpeppe> tvansteenburgh: could you paste all-machines.log?
<tvansteenburgh> rogpeppe: http://paste.ubuntu.com/7204338/
<rogpeppe> voidspace: did you have the code done for your singular worker wrapping changes?
<rogpeppe> voidspace: (i don't care about the tests, but i'd like the try it out to see if i can get HA actually working live)
<rogpeppe> s/the/to/
<voidspace> rogpeppe: incomplete
<voidspace> rogpeppe: and I'm EOW now
<rogpeppe> voidspace: ok
<rogpeppe> voidspace: could you push what you've got so far?
<voidspace> rogpeppe: ok
<rogpeppe> voidspace: thanks
<voidspace> rogpeppe: https://code.launchpad.net/~mfoord/juju-core/wrapsingletonworkers/+merge/214208
<voidspace> rogpeppe: so, I believe this does
<voidspace> EnvironProvisioner, Firewaller, MinUnitsWorker, CharmRevisionUpdater and Cleaner
<voidspace> rogpeppe: assuming they're all done in cmd/jujud/machine.go
<voidspace> rogpeppe: Provider Provisioner still needs to be done
<voidspace> and maybe some other provisioners
<rogpeppe> voidspace: lovely stuff
<rogpeppe> voidspace: i was just about to actually try it for real, then realised that the second instance needs to write its passwords for jujud
<rogpeppe> voidspace: i think we're *that* close
<rogpeppe> voidspace: to having it (theoretically) working
<rogpeppe> voidspace: but eow for me too now
<voidspace> cool!
<voidspace> g'night everyone
<rogpeppe> voidspace, wwitzel3: thanks for all your work
<rogpeppe> happy weekends all
<wwitzel3> rogpeppe: see ya, have a good weekend
<tvansteenburgh> rogpeppe: should i file a bug for my problem you think?
<jcastro> Charm school at the top of the hour, The topic is Juju Plugins:  http://ubuntuonair.com, we'll be taking questions in #juju
<bcsaller> looks like upgrade-charm on current devel release with trusty is spinning on a git failure, looks to be retrying endlessly
#juju-dev 2014-04-06
<hazmat> anyone around?
<tvansteenburgh> anyone at all?
<hazmat> tvansteenburgh, well. on core.. running into some oddities around how addresses are handled..
<tvansteenburgh> yeah, i figured i wasn't the one you were looking for :)
<hazmat> looks like juju does a reverse ip address lookup before recording dns-name on manual provider
<hazmat> hmm.. another bug.. dead machines stuck in status on manual provider..
<lazyPower> hazmat: a community member ran into that week before last
<lazyPower> there's an open bug against it. i can fish up the bug # if you're interested
<hazmat> lazyPower, no worries. already found it.. also the one with curl not being installed for manual provider.
<lazyPower> i'm about to launch a forray into manual provider land after wrestling with maas on 14.04 breaking the pxe enlistment after a reboot
<lazyPower> its the strangest thing, worked all day. Rebooted and *poof*
<thumper> of ffs
 * thumper forgot about his call with fwereade again
<thumper> fwereade: if you are around, I have a physio appt
<thumper> I keep forgetting we have something first thing monday
<fwereade> thumper, not to worry
<thumper> fwereade: I have about 10 minutes now
<thumper> we could catch up quickly if you like
<fwereade> thumper, let's
<thumper> hazmat: hey
<hazmat> thumper, greetings
<thumper> hazmat: I saw someone yesterday with the "hazmat" license plate on the car
<thumper> wanted to take a photo
<thumper> but there was a guy in the passenger seat
<hazmat> thumper, :-)
<thumper> and that would have been weird
<hazmat> thumper, considering the underlying meaning.. perhaps for the best ;-)
<thumper> :)
 * hazmat is having a meta model  headache
<hazmat> wrapping up tosca meta models via python dynamic class gen.. i should know better.. but it feels so right..
<thumper> hah
#juju-dev 2015-03-30
<thumper> davecheney: you around?
<davecheney> thumper: sorry i missed you
<davecheney> i thought the 1:1 was tuesday
<thumper> ah :)
<thumper> just last week
<thumper> I have some time in an hour if that works for you
<davecheney> thumper: i don't have anythig to talk about
<davecheney> tomorrow is my last day
<davecheney> then i'm taking a few personal days
<davecheney> then off to vienna
<davecheney> see you in nuremberg
<thumper> um... ok
<davecheney> or we can 1:1
<davecheney> if you're free
<davecheney> if there is stuff you have to talk about
<anastasiamac> wallyworld_: hi :D
<wallyworld_> hi
<thumper> jam: ping for when you are around
<anastasiamac> wallyworld_: u keep dorpping from canonical ...
<anastasiamac> wallyworld_: 1.23 and master forwards r up for review
<anastasiamac> wallyworld_: also map-ordering milestone is 1.24 which is currnt trunk so no backporting is required :D
<wallyworld_> ok, ta looking
<thumper> jam: reping
<jam> hey thumper
<thumper> jam: just doing expense paperwork
<thumper> jam: hangout in 5 minutes?
<jam> thumper: as you'd like, what about?
<thumper> container stuff
<thumper> jam https://plus.google.com/hangouts/_/canonical.com/containers
<mattyw> morning everyone
<dimitern> mattyw, o/
<jam> hey dimitern, want to meet up a bit early?
<dimitern> jam, hey - yeah, that works for me
<jam> dimitern: k, I'm there
<dimitern> jam, omw
<TheMue> morning o/ â (windy)
<dimitern> TheMue, morning
<voidspace> wallyworld: ping
<dimitern> voidspace, dooferlad, morning
<dooferlad> dimitern o/
<dimitern> dooferlad, I have a PR for you to have a look - https://github.com/juju/juju/pull/1976/
<dooferlad> dimitern: looking
<dimitern> dooferlad, in retrospect, I should've done that a week ago, but there it is
<dooferlad> dimitern: If you had, I would probably have done a lot less digging into the Juju code. It is all an education.
<dimitern> dooferlad, that's my consolation :)
<dooferlad> dimitern: :-)
<voidspace> dimitern: morning
<dimitern> voidspace, nice branch btw
<dimitern> voidspace, i'll approve it shortly I think
<voidspace> dimitern: fixing the provisioner issue? cool.
<voidspace> dimitern: wallyworld reviewed it, but he missed the test I think.
<dimitern> voidspace, the maas thing yeah
<voidspace> dimitern: I have a trunk branch as well, but I haven't submitted it
<dimitern> voidspace, was it a diff mismatch on RB or it shows that test?
<voidspace> dimitern: in case I need to make changes, when the first one lands I'll submit the second
<voidspace> dimitern: it shows the test, but it's in container_test.go and wallyworld was expecting something in provisioner_test.go
<dimitern> voidspace, ah, right
<voidspace> dimitern: I'm pretty sure that's it anyway, he's not around to ask :-)
<wallyworld> voidspace: hi, sorry as having dinner
<voidspace> wallyworld: you're allowed to have dinner... :-)
<wallyworld> voidspace: sorry i missed the test, i'll take another loko
<voidspace> wallyworld: np
<wallyworld> voidspace: actually, i gave you a shipit so go for it, was more of a question seeking clarification
<voidspace> wallyworld: ah
<dimitern> voidspace, reviewed
<voidspace> wallyworld: well, it was a "Fix it, then ship it!"" with an open issue. I wanted to check with you before just dropping the issue.
<wallyworld> voidspace: ah i see what you mean, thanks for asking
<voidspace> dimitern: thanks
<voidspace> wallyworld: I have some minor issues from dimitern to fix anyway...
<voidspace> :-)
<dimitern> TheMue, standup?
<voidspace> dimitern:
<voidspace> ... value *errors.Err = &errors.Err{message:"", cause:(*errors.Err)(0xc2100790f0), previous:(*errors.Err)(0xc2100a50f0), file:"github.com/juju/juju/leadership/leadership.go", line:43} ("leadership claim denied")
<voidspace> dimitern: util_test.go:1406:
<frankban> ocr: is anyone available for reviewing http://reviews.vapour.ws/r/1324/ ? thank you!
<dimitern> dooferlad, my branch landed btw
<dooferlad> dimitern: sweet.
<dimitern> dooferlad, I'm starting on CLI for subnets following the same approach
<mattyw> natefinch, morning
<mattyw> natefinch, judging by twitter I'd say you've been watching the news/ reading a paper this morning ;)
<natefinch> mattyw: been watching the news for a while, just finally figured out how to put my views into 140 characters :)
 * TheMue is out for lunch, bbiab
<TheMue> dimitern: btw, found a nice way to simulate the error, it's pretty simple
<dimitern> TheMue, yeah? let me know when you're back please
<TheMue> dimitern: sure, "select id, hostname from maasserver_node;" resolves the names, then you do a "select id, name from metadataserver_noderesult where node_id = ..." to find the right gathered datas.
<TheMue> dimitern: interesting is the one named 00-maas-01-lshw.out
<dimitern> TheMue, yes, indeed
<dimitern> TheMue, so you managed to reproduce the bug and the error?
<TheMue> dimitern: having its ids allows you to do a "update metadataserver_noderesult set data = '' where id = 43;"
<TheMue> dimitern: in a first round the bootstrap funnily wanted exactly my corrupted node, yes, with a matching error like in lp
<TheMue> dimitern: I then acquired the node to have a working bootstrap and then released it again to simulate the error during deploying
<TheMue> dimitern: this currently hangs, so I now want to take a deeper look into the logs and await to find the same error there
<dimitern> TheMue, btw you can specify which node to pick at bootstrap time with --to node.maas
<TheMue> dimitern: ah, makes the next round a bit more simple
<dimitern> TheMue, yeah :)
<TheMue> dimitern: but so it is fine too, with currently only four nodes here you quickly get the right (corrupted) one
<dimitern> TheMue, so if the error is reproduced, you should see it just before bootstrap outputs Lauching instance XYZ
<dimitern> TheMue, and the bootstrap should fail
<dimitern> TheMue, if it keeps going after the instance is started, then it's not reproduced
<TheMue> dimitern: yeah, I had the same output like in the lp issue
<TheMue> dimitern: same error message and bootstrapping failing
<dimitern> TheMue, nice!
<TheMue> yeah
<voidspace> bug 1437038
<mup> Bug #1437038: 1.23b2 fails to get IP from MAAS for containers, falls back to lxcbr0 <addressability> <maas-provider> <network> <juju-core:Fix Committed by mfoord> <juju-core 1.23:Fix Committed by mfoord> <https://launchpad.net/bugs/1437038>
<mup> Bug #1438168 was opened: juju 1.23 doesn't release IP addresses for containers <juju-core:In Progress by mfoord> <https://launchpad.net/bugs/1438168>
 * dimitern steps out for a while
<natefinch> perrito666: if you can tweet you can get on the hangout ;)
 * dimitern is back
<dimitern> TheMue, thanks for updating bug 1427814, it's really useful to have the info about how to tweak lshw data in the maas db
<mup> Bug #1427814: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged by themue> <https://launchpad.net/bugs/1427814>
<TheMue> dimitern: yw
<ericsnow> cherylj: would you mind updating #1435974 with where things are at with the LICENCE fixes?
<mup> Bug #1435974: Copyright information is not available for some files <juju-core:In Progress by cherylj> <juju-core 1.22:In Progress by cherylj> <juju-core 1.23:In Progress by cherylj> <https://launchpad.net/bugs/1435974>
<cherylj> ericsnow: sure.
<ericsnow> cherylj: thanks :)
<cherylj> ericsnow: I do have questions about a couple repos.
<cherylj> I'm guessing we don't need to modify the gojson* repos.
<cherylj> and the same for syslog
<ericsnow> cherylj: right
<ericsnow> cherylj: (since they are slight adaptations of the Go stdlib code and retain that copyright/license)
<cherylj> k
<cherylj> I just need to do the charm branches, and I think I'll be done.
<cherylj> then on to updating dependencies.tsv
<ericsnow> dimitern, dooferlad: FWIW, "juju space" is pretty ambiguous; any chance we could name it something more clearly related to networking?
<ericsnow> cherylj: awesome!  thanks for slogging through all that :)
<cherylj> ericsnow: np!  Although I did run into that unrelated test failure when trying to merge juju/testing 1.22
<cherylj> thumper just manually merged it last time
<voidspace> dimitern: can we add a new upgrade step in a bugfix release?
<dooferlad> ericsnow: That is a discussion which has started several times and is currently on hold. I expect it will come up at the sprint.
<voidspace> dimitern: as adding the addresser would require upgrading IP addresses to add a Life field
<voidspace> dimitern: that seems unfortunate
<ericsnow> dooferlad: cool, thanks
<voidspace> dimitern: I have a bunch of patches but I'm not sure what to do about the upgrade step
<dimitern> sorry guys - in a call
<voidspace> dimitern: np
<cherylj> ericsnow, natefinch:  since the license is changing for charm, do I need to update all the branches?  Or just 1.22, v4 and v5?
<mup> Bug #1438258 was opened: error while destroying incomplete environment <juju-core:New> <https://launchpad.net/bugs/1438258>
<ericsnow> cherylj: I'd say consider the branches that will be related to current or future juju releases
<natefinch> cherylj: don't update old branches (other than 1.22 & v4)
<cherylj> ericsnow, natefinch:  Thanks!
<voidspace> ericsnow: natefinch: if I want to prepare a binary for someone to try out, know how I should do it?
<voidspace> we have a script to do source releases but not binaries
<voidspace> I just need an amd64 build
<voidspace> can I just tart up juju* from $GOPATH/bin
<natefinch> voidspace: yeah, you just need juju and jujud
<voidspace> natefinch: cool, thanks
<ericsnow> voidspace: just "go install ./juju/..." and send them the file out of $GOPATH/bin, right?
<voidspace> ericsnow: s/file/files/ but yeah - that's what I thought and natefinch seems to be confirming
<ericsnow> voidspace: yep :)
<ericsnow> voidspace: BTW, did you see my first-draft poster yet? :)
<natefinch> yep... nice thing about go.  It's just copy and paste the binaries.  for us, we just need the client and the server
<ericsnow> natefinch, voidspace: don't the tools also need to get copied (so they can be uploaded)
<ericsnow> natefinch, voidspace: jujuc, etc.
<voidspace> ericsnow: natefinch: jujud is "the tools"
<voidspace> ah, maybe
<ericsnow> voidspace: yeah, the hook tools like set-relation
<natefinch> jujud is the tools, the upload just symlinks jujud to jujuc
<natefinch> er vice versa
<ericsnow> natefinch: ah
<natefinch> ericsnow: all that stuff, symlinks
<ericsnow> natefinch: how funny
<cherylj> okay, I need reviews for the charm license changes:  https://github.com/juju/charm/pull/107
<cherylj> https://github.com/juju/charm/pull/108
<cherylj> https://github.com/juju/charm/pull/109
<ericsnow> jam: thanks (for the calender access) :)
<cherylj> ericsnow: Here's the update list of repos:  https://bugs.launchpad.net/juju-core/+bug/1435974/comments/11
<mup> Bug #1435974: Copyright information is not available for some files <juju-core:In Progress by cherylj> <juju-core 1.22:In Progress by cherylj> <juju-core 1.23:In Progress by cherylj> <https://launchpad.net/bugs/1435974>
<cherylj> Are there any I missed?
<dimitern> voidspace, hey
<dimitern> voidspace, so what's the issue with the upgrade step?
<ericsnow> cherylj: LGTM, thanks!
<cherylj> yay!  thanks, ericsnow   :)
<voidspace> dimitern: 1.23 has IP addresses in it
<dimitern> voidspace, yeah?
<voidspace> dimitern: so if we backport "release IP addresses" to 1.23, we'll need an upgrade step from beta2 to beta3
<voidspace> dimitern: adding the Life field to IP addresses
<voidspace> dimitern: is that ok?
<dimitern> voidspace, can we do that?
<dimitern> voidspace, aren't the steps based on major/minor versions?
<voidspace> dimitern: well exactly
<voidspace> dimitern: I don't think we *can* do it
<voidspace> dimitern: that's exactly what I'm asking though :-)
<dimitern> voidspace, well
<voidspace> dimitern: the other way is to backport the *original* approach
<dimitern> voidspace, I think you could still try to run the step - it shouldn't do any harm if Life is already there
<voidspace> dimitern: do upgrade steps run at all? I'd have to look through the code to work it out
<voidspace> dimitern: the original approach was with a Provisioner API instead of a worker
<voidspace> and no Life field
<voidspace> I still have that code
<dimitern> voidspace, hmm
<dimitern> voidspace, ok, let's think for a minute
<dimitern> voidspace, what's the worst that can happen if we omit this from 1.23?
<voidspace> it looks to me like upgrade steps for a version are run / re-run when you upgrade within a version
<dimitern> voidspace, addresses won't be released
<voidspace> i.e. 1.23.1 to 1.23.2 will run 1.23 upgrade steps I believe
<dimitern> voidspace, ah - then it might work?
<voidspace> dimitern: if I'm right
<voidspace> PerformUpgrade and runUpgradeSteps in upgrades/upgrade.go
<mup> Bug #1438274 was opened: unit test failures: storeManagerStateSuite.TestStateWatcher <ci> <juju-core:New> <https://launchpad.net/bugs/1438274>
<dimitern> voidspace, it seems like a quick experiment is needed to verify this
<voidspace> yeah
<voidspace> dimitern: I'll define a new upgrade step that dies horribly and see if it runs :-)
<dimitern> voidspace, e.g. start from the earliest possible version that has IP addresses collection, which is actually used
<dimitern> voidspace, which should be the 1.23-beta1 right?
<voidspace> sounds right
<voidspace> dimitern: but the upgrade step is only on trunk - so I'll either need to do the full port and test that
<voidspace> dimitern: or just take trunk and change the version back to 1.23-beta3 or whatever
<dimitern> voidspace, the latter seems easier
<voidspace> dimitern: that's what I'm doing
<voidspace> dimitern: just bootstrapping 1.23
<dimitern> voidspace, yeah and deploy some lxc-s
<voidspace> yep
<voidspace> dimitern: hmm, there's still an issue. This will become a 1.22 upgrade step instead of 1.23
<voidspace> dimitern: so the upgrade step needs to check if the ipaddress collection exists, and bail without error if it doesn't
<voidspace> and it needs to run if upgrading from 1.22 -> 1.24
<dimitern> voidspace, considering the steps are idempotent, it shouldn't be a problem to have the same step for 1.22 and 1.23 I guess
<voidspace> dimitern: yep, true - that solves the problem of 1.23 beta 1 -> 1.24
<dimitern> voidspace, sweet!
<voidspace> and 1.22 -> 1.24 I think
<voidspace> in fact 1.23 upgrade steps must run then anyway
<voidspace> all intermediate steps must run
<dimitern> exactly
<voidspace> deploying lxc
<cherylj> ericsnow, natefinch:  Can I get a review on the last license changes?    https://github.com/juju/charm/pull/107
<cherylj> https://github.com/juju/charm/pull/108
<cherylj> https://github.com/juju/charm/pull/109
<cherylj> and the utils changes:  http://reviews.vapour.ws/r/1329/        http://reviews.vapour.ws/r/1328/
<voidspace> dimitern: it looks like 1.22 steps don't get run when going from 1.23beta3 to 1.23beta4
<voidspace> which is odd
<voidspace> I'll try again
<voidspace> I'm only seeing steps121 in the logs though
<dimitern> voidspace, I wouldn't expect 1.22 steps to run for 1.23-beta3 -> 1.23-beta4
<dimitern> voidspace, but the 1.23 should
<voidspace> dimitern: well - I'm seeing 1.21 ones run - but neither 1.22 nor 1.23...
<dimitern> voidspace, how did you prepare your scenario?
<voidspace> dimitern: http://pastebin.ubuntu.com/10707700/
<voidspace> dimitern: juju bootstrap --upload-tools  (branch 1.23)
<voidspace> dimitern: then "juju add-machine lxc:0" and wait for instance id
<voidspace> dimitern: then checkout master and do the godeps / go install dance
<voidspace> well, after changing version/version.go to 1.23-beta3 (should have picked beta4 but it shouldn't matter)
<dimitern> voidspace, and before bootstrap you've rebuilt the juju binaries, right?
<voidspace> then "juju upgrade-juju --upload"
<voidspace> dimitern: yep
<voidspace> then "juju upgrade-juju --upload-tools"
<voidspace> I mean
<voidspace> dimitern: http://pastebin.ubuntu.com/10707700/
<voidspace> I will try again, with a better new version number and maybe some extra logging
<voidspace> but first - coffee
<dimitern> ok
<dimitern> time to go
<thumper> mramm: ping
<bogdanteleaga> +
#juju-dev 2015-03-31
<wallyworld_> axw_: question, we volumes are listed, i would expect that we'd want to see the unit and storage name to which the volume may be attached, so that we can see this 100GB volume here serves the data-dir storage for mysql/0, right?
<wallyworld_> at the moment, the PR just shows storage tag
<redelmann> hi, im having some strange problem after " juju upgrade-juju --version 1.23-beta2"
<redelmann> all units are loging "unit-mongodb-production-0[25074]: 2015-03-31 00:22:51 ERROR juju.worker runner.go:219 exited "uniter": failed to initialize uniter for "unit-mongodb-production-0": cannot read "/var/lib/juju/agents/unit-mongodb-production-0/state/uniter": invalid operation state: unexpected hook info with Kind Continue"
<redelmann> ok, now stop working :P
<axw_> wallyworld_: volumes are machine-level, hence we see machine attachment. you could argue that since we know the assigned storage instance, we could also show the unit-storage attachments... but we have "juju storage show" if people really want to see that
<wallyworld_> axw_: i think that distinction will be lost on the user
<wallyworld_> storage will also show fs etc
<wallyworld_> if i list volumes, i'd like to see where they're attached (ie what unit) if i were a user
<wallyworld_> s/attached/in use
<axw_> wallyworld_: I'm not opposed to adding an optional UNIT column
<wallyworld_> ok, let's do it
<wallyworld_> we could if required (which i'm not sure we will be) add a CLI flag to exclude/include volumes attached to units
<wallyworld_> redelmann: i'm not sure what's happened with your upgrade, can you raise a bug and attach as many logs as possible from the affected machine
<redelmann> wallyworld_: ok
<wallyworld_> redelmann: the error is an internal one that indicates that something got out of sync, but we'd need more info
<redelmann> wallyworld_: im collecting log from machine-0
<wallyworld_> even if you zip the /var/log/juju dir
<wallyworld_> but we'd need logs from the machine running the affected unit
<redelmann> wallyworld_, where i can send logs?
<wallyworld_> redelmann: attach them to the bug
<jw4> redelmann: that looks like an upgrade issue where the upgrade steps for 1.23 didn't run.  Let me know when you've created the bug and attached the logs
<jw4> (one of the upgrade steps)
<redelmann> jw4: ok, first im trying to remove "some way" upgrade from mongo in machine0, need this running for today :P
<jw4> thanks redelmann
<redelmann> jw4, i keep a copy of log for bug
<jw4> gracias
<redelmann> jw4: thank to you
<axw_> wallyworld_ thumper: pyfmt - https://plus.google.com/+EliBenderskyGplus/posts/SzKrvzvUuyc
 * thumper looks
<axw_> I can't see it being as effective as gofmt, since whitespace matters in Python
 * thumper guesses yet another python fromatter
<axw_> indeed :)
<thumper> yeah, first paragraph
<wallyworld_> can't have too many
<thumper> axw_: interesting
<thumper> I want a js version too
<thumper> resharper does a good job with visual studio
<thumper> and C#
<redelmann> axw_, wallyworld_ : https://bugs.launchpad.net/juju-core/+bug/1438489
<mup> Bug #1438489: juju stop responding after juju-upgrade <juju-core:New> <https://launchpad.net/bugs/1438489>
<redelmann> sorry axw_: that no was for you
<redelmann> jw4: https://bugs.launchpad.net/juju-core/+bug/1438489
<jw4> thanks redelmann :)
<axw_> np
<redelmann> tellm if you need more details, and how to get it.
<redelmann> now im going to keep trying to remove upgrade from Â¿queue? mongo
<jw4> redelmann: I don't see that error in that log
<jw4> redelmann: do you have other logs?
<redelmann> jw4, that error is in "juju debug-log"
<jw4> redelmann: I see
<redelmann> cant run debug-log again, it stuck
<jw4> seems like that text should be in one of the other log files under ~/.juju/
<redelmann> that's why im looking in machine0 logs
<jw4> that error would have come from one of the units; what other machine logs do you have under ~/.juju ?
<redelmann> jw4, i cant see any log in ~/.juju/
<redelmann> jw4, all unit say the same
<redelmann> jw4, actually im deploying to aws
<jw4> redelmann: ya, I see that environment
<redelmann> jw4, juju keep log in ~/.juju if deploying to aws?
<jw4> redelmann: I think it'd be on the machine that's having trouble upgrading
<jw4> redelmann: how many machines do you have deployed?
<redelmann> jw4, seven
<jw4> redelmann: which machine is unit-pgsql-medium-0 on?
<jw4> redelmann: also, machine-0 should have all-machines.log in the /var/log/juju folder
<redelmann> jw4, you are right
<redelmann> give me a second
<jw4> redelmann: certainly, thanks!
<redelmann> im scping it
<mup> Bug #1438489 was opened: juju stop responding after juju-upgrade <juju-core:New> <https://launchpad.net/bugs/1438489>
<redelmann> jw4, im uploading complete file, this happend today.
<jw4> redelmann: thanks; I'll review that.  I'm going to be out for 30 minutes or so, but I'll brb
<redelmann> jw4, ok, i attached it to https://bugs.launchpad.net/juju-core/+bug/1438489
<mup> Bug #1438489: juju stop responding after juju-upgrade <juju-core:New> <https://launchpad.net/bugs/1438489>
<jw4> thanks
<davecheney> cherylj: do you need some reviews done ?
<davecheney> OH MY GOD
<davecheney> why does juju depend on ajstarks/svgo !?!?
<davecheney> how is that possibly necessary for the core operation of juju ?
<wallyworld_> axw_: only if you feel like it/have time, there's a juju status review which is the first 3 or so branches which would be good to get looked at http://reviews.vapour.ws/r/1334, otherwise i'll bug william when he's net online
<axw_> wallyworld_: just started looking, it's quite involved. I'd like to get some of my stuff proposed, hope to take a look later on
<wallyworld_> sure np
<wallyworld_> i an talk you through anything if needed
<wallyworld_> i'll have another proposed straight after, and then a 3rd hopefully later today
<redelmann> jw4, ok, i "fix" it
<redelmann> jw4, http://paste.ubuntu.com/10710367/
<redelmann> jw4, after that it upgrade fine
<redelmann> so, it keep saying cannot read "/var/lib/juju/agents/unit-xxx-0/state/uniter": invalid operation state: unexpected hook info with Kind Continue
<jw4> redelmann: yeah
<redelmann> jw4, but now i can juju status ;)
<jw4> the basic issue is that in 1.23 the uniter does not expect there to be hook information in the uniter state except when it's actually running a hook
<redelmann> jw4, any workaround? like deleting /var/lib/juju/agents/unit-xxx-0/state/uniter?
<jw4> redelmann: the upgrade steps were supposed to remove the unnecessary hook info from the uniter state file, but apparently it didn't work
<jw4> redelmann: if you can find the uniter state file (yaml) and just delete the hook and then restart the uniter, it *might* fix it :)
<redelmann> jw4, i will try
<jw4> redelmann: it should just be called uniter I believe
<redelmann> mh...
<redelmann> filter.go:137 cannot retrieve meter status for unit ganglia/0: not found
<redelmann> maybe writing a working uniter
<jw4> redelmann: I'm not sure about that one (possibly upgrade related too, but I'm not familiar with that part)
<redelmann> jw4, thats happend after deleting uniter file
<jw4> redelmann: oh. yeah.  I wouldn't delete the uniter file
<redelmann> jw4, this one: /var/lib/juju/agents/unit-xxx-0/state/uniter
<redelmann> oh
<jw4> redelmann: inside that file there should be a line (in yaml format) signifying the hook
<jw4> if you just update the yaml so there is no hook key/value
<jw4> that *might* work
<jw4> redelmann: unfortunately it's past my bedtime, and my wife has been waiting for me to come to bed for 45 minutes now :(
<jw4> redelmann: :) I'll check in again in the morning
<redelmann> jw4, thank you
<redelmann> jw4, have a good night
<jw4> thanks redelmann you have a great morning/afternoon/night day :)
<mattyw> morning everyone
<tasdomas> dimitern, thanks for going through my reviews, much appreciated
<dimitern> tasdomas, no worries
<dimitern> tasdomas, aren't you ready to graduate btw ? :)
<tasdomas> dimitern, well, that's not really up to me to decide ;-]
<dimitern> tasdomas, I think you are, but I'll have a chat with cmars as well
<tasdomas> dimitern, but what I find really holding me back in some reviews is lack of knowledge of certain parts of juju
<dimitern> tasdomas, that will come in time, but when unsure about some part of the code, you should ask questions :)
<voidspace> morning all
<dimitern> morning voidspace
<voidspace> o/
<TheMue> morning o/
<TheMue> dimitern: the described network problem isn't visible in the clients log. sadly I cannot grab the log of the VM
<TheMue> dimitern: here you can see that downloads from the maas controller fail
<TheMue> dimitern: also connections to 169.254.169.254 timeout
<voidspace> TheMue: o/
<TheMue> dimitern: so that's why I think the network setup on the node fails after the changes
<TheMue> voidspace: o/
<dimitern> TheMue, hmm - can you ssh into the node after it failed and check /var/log/cloud-init-output.log?
<TheMue> dimitern: with the written release we've added the gathering of a primary interface out of the lshw data which is used in newCloudinitConfig()
<TheMue> dimitern: I'll see if I can
<dimitern> TheMue, yes, in order to determine which interface to bind into the juju-br0 bridge at cloud-init initial boot
<TheMue> dimitern: yep, this has been with 1.20.12
<TheMue> dimitern: only checked back where it has been changed
<dimitern> TheMue, yeah, I remember I did this to fix another bug about not using the correct primary interface for the bridge
<TheMue> ok, while client is still waiting the new node at least gave up
<dimitern> TheMue, ok, I think this can be faked - if getting the ifaceInfo and the primary interface fails, try using "eth0" as primary interface for newCloudinitConfig()
<TheMue> now I only have the problem to log in
<dimitern> TheMue, maybe the ssh keys where not set?
<TheMue> dimitern: same setting as yesterday
<TheMue> dimitern: but don't know how far they are distributed to the node
<dimitern> TheMue, no, I mean if cloud-init failed to complete for some reason, the ssh keys might not be set on the node
<dimitern> TheMue, cloud-init sets the keys
<TheMue> dimitern: yep, that could be the reason
<TheMue> dimitern: my node dislikes me because I corrupted its data :,(
<TheMue> dimitern: :)
<TheMue> dimitern: will do the eth0 approach, should be quickly done
<dimitern>  TheMue, it's not the node - that's a case of juju not generating the userdata correctly so the node cannot boot properly :)
<TheMue> dimitern: damn security, thought we're building OPEN source *rofl*
<dimitern> TheMue, try that workaround I suggested - destroy and cleanup to start afresh, then use "eth0" as primaryNIC if lshw cannot be parsed
 * TheMue btw loves his MAAS environment
<axw_> wallyworld_: published some comments on your PR
<TheMue> dimitern: no real change, the missing interface information leads to >> 2015-03-31 08:29:49 DEBUG juju.provider.maas environ.go:807 node "/MAAS/api/1.0/nodes/node-4a6120e6-d6ea-11e4-a9b5-000c2975eaae/" network information: []network.Info(nil)
<TheMue> dimitern: already a bit earlier >> 2015-03-31 08:29:49 DEBUG juju.provider.maas environ.go:760 node "/MAAS/api/1.0/nodes/node-4a6120e6-d6ea-11e4-a9b5-000c2975eaae/" has network interfaces map[]
<dimitern> TheMue, that could be fine, all it matters is the generated userdata for cloud-init and the node booting ok
<dimitern> TheMue, did it finish?
<TheMue> dimitern: looks like before, no action anymore on the node while the client is still "deploying" (repeating this log entry until timeout)
<dimitern> TheMue, did you use --debug with bootstrap?
<dimitern> TheMue, it will help if you can paste the output :)
<TheMue> dimitern: yes, that's where those two lines above are coming from
<TheMue> dimitern: will create a paste when the timeout is done so that the whole debug log is in
<dimitern> TheMue, ok
<TheMue> dimitern: the one I've mailed to you is also debug, see the top line how I'm deploying
<TheMue> dimitern: fresh-ducks.local is my corrupted node ;)
<dimitern> TheMue, hmm.. well it seems to me some more debug logging is needed around newCloudinitUserdata to show what's generated
<TheMue> dimitern: will log it
 * TheMue just receive a warning by the national weather service, winds will get really strong today :/ 
<voidspace> TheMue: we've had strong winds all night, continuing now
<TheMue> voidspace: it will reach its top here between 2 and 6pm, and our neighbor has still two very high trees on her ground which always sway extreme. during the last storm one felt, thankfully not into our direction
<mattyw> dimitern, ping?
<dimitern> mattyw, hey
<dimitern> voidspace, standup?
<voidspace> dimitern: omw
<mup> Bug #1438590 was opened: juju version tries to make directories and files in my home <landscape> <juju-core:New> <https://launchpad.net/bugs/1438590>
<dimitern> dooferlad, so just calling c.SpaceCommandBase.SetFlags(f) in c.SetFlags() works
<TheMue> dimitern: String method sadly had same troubles with references as values in map[string]interface{}, so had to use the renderer way
<TheMue> dimitern: here is the according output http://paste.ubuntu.com/10711305/
<dimitern> TheMue, ok, this looks fine to me
<dimitern> TheMue, does it still fail to boot?
<TheMue> dimitern: yep, still the same failing behavior
<TheMue> dimitern: while when using a not corrupted node it works
<dimitern> TheMue, can you try ssh into it?
<dimitern> TheMue, while the bootstrap goes on? it should be possible after retrying for a while (might not be possible immediately)
<TheMue> dimitern: yes, currently rejected
<TheMue> dimitern: still Permission denied (publickey).
<dimitern> TheMue, try: ssh -i ~/.juju/ssh/id_rsa ubuntu@IP
<TheMue> dimitern: still the same
<TheMue> dimitern: at least it's pingable
<dimitern> TheMue, can you see the console of the VM ?
<TheMue> dimitern: if the ubuntu user would have a standard password I could login directly on the console
<dimitern> TheMue, nope, that won't work unfortunately
<TheMue> dimitern: I know, sadly
<dimitern> TheMue, maybe the VM is still booting - do you see any messages on the console?
<TheMue> dimitern: only the login screen
<dimitern> TheMue, try with your ssh key configured in maas?
<TheMue> dimitern: the last interesting part have been messages that downloads from controller and this 169... failed
<TheMue> dimitern: that's what I'm doing, using that key
<TheMue> dimitern: I'll bootstrap to a valid node and see what the cloudinit looks there
<dimitern> TheMue, did you try both the juju_id_rsa key *any* your key?
<dimitern> s/*any*/*and*/
<TheMue> dimitern: my key
<TheMue> dimitern: http://paste.ubuntu.com/10711389/
<dimitern> TheMue, well, that's why I wrote this earlier: <dimitern> TheMue, try: ssh -i ~/.juju/ssh/id_rsa ubuntu@IP
<dimitern> TheMue, that's the juju ssh key
<TheMue> dimitern: eh, sorry, sure, took it too
<dimitern> TheMue, so both you couldn't ssh with either key
<dimitern> s/both/both/
<dimitern> aargh
<dimitern> s/both//\
<TheMue> dimitern: hehe, yes
<TheMue> dimitern: and you're right, the cloudinit looks similar, only the host names
<TheMue> dimitern: I send you a screenshot of the console. does this help to get in? sadly I cannot cut'n'paste, but enter the key by hand
<TheMue> wife calls for lunch, bbiab
<voidspace> Code comments: https://twitter.com/nzkoz/status/538892801941848064/photo/1
<dimitern> voidspace, dooferlad, please have a look - juju subnet CLI http://reviews.vapour.ws/r/1339/
<dimitern> TheMue, that screenshot is too small to read, unfortunately
 * fwereade swings by quickly to say: sorry sick yesterday, public holiday today, should be around properly later to catch up a bit
<voidspace> dimitern: looking after coffee
<TheMue> dimitern: hmm, it is sent in full size, strange
<dimitern> voidspace, I'm in a call with spakiegeek now investingating an issue with maas and juju
<dimitern> voidspace, it seems we're not out of the rabbit hole yet
<dimitern> voidspace, I'm getting logs to help debugging the issue
<dimitern> voidspace, he'll file a bug with details
<dimitern> voidspace, it's a separate issue than the one you fixed, but also revolves around parsing lshw properly
<dimitern> TheMue, ah, so it's just that thunderbird is dump - I managed to zoom in using a copy of the screenshot in gimp
<dimitern> TheMue, that screen is from too early in the boot process
<dimitern> TheMue, we should do a screensharing session I think to diagnose the issue
<dimitern> TheMue, it won't work by just describing what you see :)
<TheMue> dimitern: just doing some preparations
<TheMue> dimitern: so, sent you an invitation, we'll see how it works
<dimitern> TheMue, brt
<voidspace> dimitern: ah, right :-/
<voidspace> dimitern: so after #1339 there will be a "subnets" super command, but it will do nothing?
<voidspace> dimitern: wouldn't it be better to add the functionality first and do the CLI as the last bit - or have I misunderstood?
<voidspace> "subnet create" anyway
<dooferlad> voidspace: the idea is to do CLI before API, so we know what the API needs to provide. We know what commands we want already (see Juju Network Model document)
<voidspace> dooferlad: right, but then we're adding public facing brokenness
<voidspace> dooferlad: if we know what commands we want, don't we also know what API we need?
<dooferlad> voidspace: only to a feature branch
<voidspace> ah yes, of course
<voidspace> I still prefer to work the other way round
<voidspace> then we don't *need* a long lived feature branch
<dooferlad> voidspace: We have a pretty good idea about what the API needs to provide, but this way we don't end up designing endpoints that are a bad fit for the code that is using them.
<dimitern> voidspace, sorry, in a call again
<voidspace> dooferlad: ok
<voidspace> dimitern: np
<dimitern> voidspace, the CLI returns an error when you try to use it
<voidspace> dimitern: well exactly :-)
<voidspace> dimitern: CLI commands that do nothing but error out shouldn't exist...
<voidspace> dimitern: why do you need the --private option?
<voidspace> dimitern: if it's the default it does nothing
<voidspace> dimitern: flag I mean
<voidspace> specifying it does nothing and it's existence is causing you pain in the code
<voidspace> dimitern: why not just have --public ?
<dimitern> voidspace, we always went with the approach "state / api first, cli last" and that bit us on more than one occasion
<voidspace> dimitern: ok, interesting
<voidspace> I'm definitely in favour of *designing* the CLI, just not necessarily implementing it first
<dimitern> voidspace, so starting from the CLI with stub API is the new way I'd like to try now
<voidspace> but as it's on a feature branch it doesn't matter so much anyway
<voidspace> dimitern: ok
<dimitern> voidspace, so by the time we reach state /api we already know what's needed
<dimitern> voidspace, the --private being the default comes as a requirement from mark
<voidspace> dimitern: fine. In that case the "--private" flag is superfluous, it does nothing.
<dimitern> voidspace, it's part of the spec though
<voidspace> dimitern: just say, "networks are private by default, unless you pass the --public flag"
<voidspace> dimitern: heh
<voidspace> it does *nothing*
<dimitern> voidspace, yeah that's correct
<dooferlad> voidspace: well, it is an exciting way of starting an IRC conversation :-)
<voidspace> heh
<dooferlad> ... just like the name "space"
<voidspace> dimitern: other than that (and feel free to drop my issue - I meant it as a comment) it all looks good to me
<voidspace> dimitern: mostly boilerplate except for the parameter checking, which all looks fine
<dimitern> voidspace, sorry, I'm looking at your review now
<dimitern> voidspace, yes, having --private seems redundant, but it's part of the spec
<dimitern> voidspace, I'll add a comment
<TheMue> A large tree crashed our car, shit. I'm off for some time.
<dimitern> TheMue, oh that's bad :(
<jw4> TheMue: shoot
<jw4> TheMue: after all that felling of trees one still got your car!?
<dimitern> TheMue, I hope the damage is not extensive
<wallyworld> fwereade: andrew has looked at http://reviews.vapour.ws/r/1334/, it you get time would love it if you could look too
<TheMue> the rear is totally crashed
<dimitern> TheMue, oh dear :(
<dimitern> TheMue, well, the only thing I could do is offer you to take a day off if you need to sort things out :/
<dooferlad> TheMue: Yikes! I hope your insurer is efficient :-|
<mup> Bug #1438683 was opened: Containers stuck allocating, interface not up <cloud-installer> <landscape> <juju-core:New> <https://launchpad.net/bugs/1438683>
<dimitern> voidspace, dooferlad, I've replied to your review comments; thanks!
<dooferlad> dimitern: who knew one little flag would cause so much typing :-)
<dimitern> voidspace, I've also triaged that maas bug ^^ and added a comment capturing what me and sparkiegeek discovered so far, which will possibly help finding the issue
<voidspace> dimitern: yeah, I've been reading it
<dimitern> dooferlad, indeed :)
<voidspace> sounds like a mess... :-/
<dimitern> voidspace, yep :( workarounds biting us back, as usual
<dimitern> if only maas had usable api :)
<joec1> Hi folks and esteemed juju devs, apologies for the impertinent question but are there any known issues getting juju to work in Azure (aside from the bug reports)?
<natefinch> alexisb: sorry, I had hoped the baby wasn't audible over the headset mic.... guess it was
<alexisb> yes, and sorry I muted you but the baby cry still triggers the mommy instinct and made it hard to concentrate on what I wanted to say :)
<natefinch> heh I understand
<dimitern> voidspace, you should really do something to start noticing your PMs :)
<anastasiamac> dimitern: tyvm for reviewing my PR
<ericsnow> dimitern: PTAL http://reviews.vapour.ws/r/1234/
<anastasiamac> dimitern: i had to add unit info and change sort order for tabular format
<ericsnow> dimitern: also http://reviews.vapour.ws/r/1332/ and http://reviews.vapour.ws/r/1333/
<dimitern> ericsnow, ok, I have a few already, will add them to my queue
<anastasiamac> dimitern: if u have a chance if u could PTAL it again despite ur prev shipit - would be amazing!
<ericsnow> dimitern: thanks
<anastasiamac> dimitern: http://reviews.vapour.ws/r/1323/
<dimitern> anastasiamac, np - remind me which one?
<dimitern> anastasiamac, ok, cheers
<anastasiamac> dimitern: thnx ;D m EODing now 00:27 on the clock...
<ericsnow> dimitern: http://reviews.vapour.ws/r/1332/ shouild be easy and is a blocker for the 1.23 release, so perhaps you could "nice" it up :)
<dimitern> anastasiamac, oh that's late - have a good evening then :)
<dimitern> ericsnow, ack, will start with it then
<ericsnow> dimitern: thanks!
<anastasiamac> dimitern: or early :D ttyl
<ericsnow> cherylj: it looks like the LICENCE fixes are all done for 1.22 \o/
<ericsnow> cherylj: is that right?
<cherylj> ericsnow: yes, as long as the patch for dependencies.tsv passes CI :)
<ericsnow> cherylj: awesome!  Thanks for tackling all that!
<cherylj> ericsnow: np!
<ericsnow> cherylj: be sure to mark the bug as "fix committed" for 1.22
<cherylj> thanks for the reminder :)
<cherylj> hooray!  it passed CI
<mup> Bug #1438721 was opened: sync-tools does not support patch versions <juju-core:New> <https://launchpad.net/bugs/1438721>
<natefinch> abentley: where can I find the code for the CI tests?
<aznashwan> dimitern, voidspace: ping
<dimitern> aznashwan, pong
<abentley> natefinch: lp:juju-ci-tools
<voidspace> aznashwan: pong
<natefinch> abentley: sigh.. launchpad, huh?
<aznashwan> dimitern: could I bother you guys with what looks like a horrendously huge review but there's actually little to it: http://reviews.vapour.ws/r/1330/ :D
<dimitern> aznashwan, I'm about 33% done with that monster branch of yours about cloudinit
<dimitern> :)
<abentley> natefinch: of course!
<aznashwan> dimitern: great
<aznashwan> dimitern: as said there, most of it's relocated code
<dimitern> aznashwan, why did you decide to rename MachineConfig to InstanceConfig?
<dimitern> aznashwan, that definitely blew up the diff considerably
<aznashwan> dimitern: that was bogdanteleaga's doing at the suggestion of one of you guys
<dimitern> aznashwan, I see
<dimitern> ok then
<aznashwan> dimitern: he'd be the better half to ask about this
<dimitern> aznashwan, ok, thanks
<bogdanteleaga> dimitern, it was done after some consulting with william; in hindsight it might not have been the best idea exactly because it ended up making the diff humongous, but there's not much to see outside of /cloudconfig
<dimitern> bogdanteleaga, right, I agree it could've waited, but well .. :)
<TheMue> dimitern: dooferlad: voidspace: wow, what an organizational stuff with insurance, fire department, neighbor. will post pics later, car seems to be totally crashed
<dooferlad> TheMue: time for another whisky tasting?
<TheMue> dooferlad: will these eve definitely need one
<dimitern> TheMue, :( too bad - hopefully the insurance will cover all
<TheMue> dimitern: currently all signs are positive, looks like a 100% coverage
<TheMue> better than many of our unit tests *lol*
<dimitern> TheMue, good!
<jw4> TheMue: I saw that about your car - You've already had one tree fall this year, and your neighbor was felling more trees a couple weeks ago... what gives?
 * natefinch tries to remember how to use bzr
<voidspace> TheMue: ouch :-/
<natefinch> abentley: do we have tests trying out HA?
<natefinch> (in CI)
<abentley> natefinch: Yes.  See http://juju-ci.vapour.ws/job/functional-ha-backup-restore/ and http://juju-ci.vapour.ws/job/functional-ha-recovery/
<voidspace> dimitern: port is done, but not run manual tests yet
<voidspace> dimitern: doing a full normal test run first
<voidspace> dimitern: then can switch to the other bug
<dimitern> voidspace, ok, sounds good
<cherylj> natefinch, ericsnow:  I'm updating the dependencies for 1.23, and I see that updating juju/names pulls in this change:  https://github.com/juju/names/pull/43
<cherylj> natefinch, ericsnow:   It brings in a new tag, but doesn't change any functionality.
<natefinch> space tag sounds so much better than freeze tag
<cherylj> natefinch, ericsnow:  Will that be okay?  or do we need a new branch?
<cherylj> haha
<natefinch> cherylj: that's expanding the API in a backwards compatible way, so I think it's fine to leave it in the same branch
<natefinch> cherylj: wait sorry
<natefinch> cherylj: misunderstood... yes, I think making a new branch there is the right thing to do
<natefinch> cherylj: it's simple, but doesn't really belong in 1.23, and none of the rest of the code will know what to do with it
<cherylj> natefinch: okay, glad I asked :)  Can you create the branch?
<natefinch> cherylj: do you have the right commit hash handy?
<natefinch> (and yes)
<natefinch> is it just the one before that space tag change?
<cherylj> natefinch: ce4ecb2967822062fc606e733919c677c584ab7e
<natefinch> cherylj: thanks
<cherylj> np!
<natefinch> cherylj: there you go
<voidspace> dimitern: hah, a few calls to network.NewAddress to fix first...
<cherylj> natefinch: thanks!
<dimitern> voidspace, :) I dread the moment when I have to merge master into net-cli already
<voidspace> dimitern: heh
<voidspace> dimitern: it wasn't so many I had to do
<mup> Bug #1438748 was opened: Use of /tmp/discover_init_system.sh is a security vulnerability. <juju-core:In Progress by ericsnowcurrently> <juju-core 1.23:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1438748>
<voidspace> dimitern: so, for the "multiple networks with no index" - manually increment the index?
<voidspace> dimitern: we still risk duplicating an index if there are some with suffix and some without
<voidspace> dimitern:  no idea if that's possible though
<dimitern> voidspace, I guess that's the only thing to do
<voidspace> ok
<dimitern> voidspace, we should add more logging at debug level
<voidspace> dimitern: ok
<dimitern> voidspace, cheers
<voidspace> dimitern: and I'll look through the code seeing if I can work out why we pick the disabled nic
<voidspace> dimitern: it's almost certainly due to them having the same subnet (network) *or* due to the index issue
<voidspace> dimitern: but it would be good to know
<voidspace> dimitern: running a manual test of my 1.23 branch in parallel to doing this
<natefinch> abentley: I'm trying to write a new CI test to test using ensure availability to turn existing machines in the environment into state servers.  Is there documentation on how to write CI tests?  It looks fairly straight forward, but docs are always helpful :)
<dimitern> voidspace, yeah - it was hard to tell what's going on, but the logs should tell
<abentley> natefinch: Sorry, was on a call.
<natefinch> abentley: np
<abentley> natefinch: There isn't documentation.  Basically you need to return 0 on success and 1 on failure, and you should allow the runtime environment name to be customized, and jujupy may be helpful.
<natefinch> abentley: ok, cool.  It looks pretty easy, except perhaps how to add the extra jenkins job
 * natefinch knows jack all about jenkins
<abentley> natefinch: when you've got a script that works locally, I can help you with getting it onto Jenkins.
<abentley> natefinch: When you say "existing machines", do you mean machines that aren't provisioned by juju?
<alexisb> natefinch, can we land in the HA stuff at this stage?
<voidspace> dimitern: ok, so manually testing this has revealed a problem with the upgrade step...
<voidspace> dimitern: and I think trunk is screwed too - I just didn't notice before
<voidspace> dimitern: http://pastebin.ubuntu.com/10712911/
<voidspace> dimitern: the best fix is to have ReleaseAddress not require an instance iD
<dimitern> voidspace, oh sh*t
<voidspace> dimitern: I'll repeat the test for trunk, but I bet it has the same issue and I just didn't notice it before :-/
<dimitern> voidspace, this is because we need the instance id?
<voidspace> dimitern: yep
<dimitern> voidspace, yeah
<voidspace> dimitern: but I don't think either MaaS or ec2 actually require it
<dimitern> voidspace, I should've thought of that
<voidspace> dimitern: so we should just drop it from the provider method signature
<voidspace> if it's really not used
<dimitern> voidspace, well, how do you suggest fixing it?
<voidspace> dimitern: yeah, me too :-)
<voidspace> dimitern: stop requiring instance ID
<dimitern> voidspace, don't you need it to get the machine?
<dimitern> voidspace, or we added it only because we needed it for ReleaseAddress?
<voidspace> dimitern: I think we just thought we might need it
<voidspace> dimitern: ah no
<voidspace> dimitern: ec2 does use it
<dimitern> voidspace, *whew* ok, then it's easy :)
<voidspace> nope
<dimitern> voidspace, oh?
<voidspace> dimitern: it actually needs a nic id
<voidspace> dimitern: but we get the nic id from the instance id
<dimitern> voidspace, yeah
<dimitern> voidspace, ok, sorry I'm a bit confused
<cherylj> Can I get a couple license related reviews?  http://reviews.vapour.ws/r/1342/      http://reviews.vapour.ws/r/1343/
<dimitern> voidspace, you need instance id in order to call ReleaseAddress in the worker
<voidspace> dimitern: yes
<voidspace> dimitern: maas doesn't use the instance id
<dimitern> voidspace, you don't need instance id in the provisioner api
<voidspace> dimitern: but ec2 does
<voidspace> dimitern: the issue here is specifically when the upgrade runs and there are dead ip addresses
<voidspace> dimitern: nothing to do with the provisioner api
<voidspace> dimitern: the worker notices the dead addresses when it starts and tries to remove them
<dimitern> voidspace, ok
<dimitern> voidspace, so we do need to pass instance id, even if it's unused
<voidspace> dimitern: the addresses have a MachineId()
<voidspace> dimitern: the worker tries to get the instance id from the machine - but the machine is already gone
<voidspace> dimitern: Environ.ReleaseAddress takes an instance id
<voidspace> dimitern: that is not used by maas, but unfortunately *is* used by ec2
<natefinch> alexisb, abentley: sorry, left for a minute to make lunch....
<dimitern> voidspace, but fortunately, in ec2 it doesn't matter
<dimitern> voidspace, because if the instance is gone, all its nics and ips are gone with it
<natefinch> alexisb: I can land it by EOD.  I have to do a few trivial code review cleanup things and write a couple trivial unit tests, and then I can start working on the CI tests
<voidspace> dimitern: ok, so we need a way to release the address for maas
<dimitern> voidspace, so I guess it only matters for maas - we need to release the addresses, but instance id can be empty
<dimitern> voidspace, it can be a special value like instance.UnknownId ?
<voidspace> dimitern: ok, fine
<voidspace> dimitern: and ec2 will make that a no-op
<natefinch> abentley: I mean machines that have been added to the juju environment, either through deploy or add-machine.  So, like, you could do juju ensure-availability --to 1,2 and convert machines 1 and 2 into state machines
<voidspace> dimitern: whereas maas will release the address
<voidspace> dimitern: fine - thanks
<dimitern> voidspace, exactly - the upgrade step should try a best effort, but not fail if instance id cannot be found
<abentley> natefinch: Cool.  I was thinking this might be something like the manual provider.  We have a solution for testing the manual provider, but it's not the cleanest.
<natefinch> abentley: nope, pretty easy, really... just like the other HA tests./.. just bootstrap, juju add-machine -n 2, wait for them to come up, then juju ensure-availability --to 1,2 and then wait for HA.
<dimitern> ericsnow, re http://reviews.vapour.ws/r/1332/ - it seems it just drops upstart-specific confs
<abentley> natefinch: great.
<ericsnow> dimitern: that is correct
<dimitern> ericsnow, shouldn't it only drop them when systemd is used?
<ericsnow> dimitern: we don't need them for upstart either
<dimitern> ericsnow, i.e. isn't that strictly worse than before?
<dimitern> ericsnow, ok, if they're not used for upstart fair enough
<ericsnow> dimitern: they are just clutter since we generate a new upstart conf when we bootstrap
<dimitern> ericsnow, I'll take your word for it though :)
<dimitern> ericsnow, ok, that makes sense
<dimitern> ericsnow, thanks!
<ericsnow> dimitern: if restore were more than replace-the-old-state server then we would have a different story :)
<dimitern> ericsnow, LGTM then
<ericsnow> dimitern: thanks
<natefinch> I love it when writing documentation for code reveals a bug.
<dimitern> natefinch, it's worse when it reveals a bug in the spec :)
<natefinch> dimitern: heh
<natefinch> dimitern: I actually wasn't being sarcastic.  I actually do like it when that happens.  Better than not finding the bug until later :)
<natefinch> dimitern: btw, are watchers fired off serially, or do I need a lock in my Handle() method in case two get fired off in quick succession?
<dimitern> natefinch, you're using the same handler for 2 watchers? brave! :)
<natefinch> dimitern: no no... but if there's two changes back to back
<dimitern> natefinch, the watcher should coalesce events properly
<natefinch> dimitern: not exactly filling me with confidence ;)
<dimitern> natefinch, well, it depends if the watcher is working properly :)
<natefinch> lol
<natefinch> ok
<cherylj> natefinch: we also need to branch juju/utils for 1.23  at commit 3efdaa3f15cc47ee83f6c03f640dc14f5915e289
<natefinch> cherylj: done
 * natefinch is getting the hang of this git thing. ;)
<cherylj> natefinch: thanks!  I'm not sure if we need to branch testing too...  It pulls in https://github.com/juju/testing/pull/55  and https://github.com/juju/testing/pull/56
<alexisb> natefinch, awesome thank you
<natefinch> cherylj: to be on the safe side, I think I would
<cherylj> natefinch: okay, the commit to branch from there is: c07aef9cb4f2ff1db7ddc9d43a0ea88eca39c9ea
<natefinch> cherylj: done
<cherylj> natefinch: thanks!
<natefinch> cherylj:  welcome :)
<mup> Bug #1438798 was opened: juju sync-tools requires default environment <juju-core:New> <https://launchpad.net/bugs/1438798>
<alexisb> voidspace, you still around?
<cherylj> natefinch-afk: I think we can get away with not branching juju/charm for 1.23.  It just pulls in this:  https://github.com/juju/charm/pull/82
<cherylj> natefinch-afk: what do you think?
<natefinch> cherylj: lgtm
<cherylj> natefinch: thanks1
<voidspace> alexisb: yep
<voidspace> alexisb: just, about to go
<wwitzel3> is there an example of putting a provider behind a feature flag? not exactly sure how to approach this
<cherylj> natefinch: could you review a few more of the license changes?  http://reviews.vapour.ws/r/1342/      http://reviews.vapour.ws/r/1343/        http://reviews.vapour.ws/r/1345/            http://reviews.vapour.ws/r/1346/
<alexisb> voidspace, looks like you picked up a new bug today for 1.23
<voidspace> alexisb: yep
<alexisb> I was just curious the scope of work
<voidspace> alexisb: two I think :-/
<alexisb> yay!
<voidspace> alexisb: should be able to land both in the next two days - one per day, maybe quicker
<voidspace> alexisb: I need to file the second one
<alexisb> great thank you that is what I needed
<voidspace> alexisb: the one that is filed is a *little bit* unknown
<voidspace> alexisb: so it *could* explode :-)
<voidspace> alexisb: but we don't think so
<alexisb> voidspace, ok, keep me posted
<voidspace> alexisb: will do
<natefinch> cherylj: I'm kinda slammed getting some critical code into 1.23, maybe someone else could do the review, like voidspace or ericsnow or cmars or wwitzel3
<cherylj> ah, okay, thanks
<cmars> cherylj, about to head out for lunch, can take a look in a little bit
<cherylj> thanks, cmars
<voidspace> alexisb: actually 3 bugs
<voidspace> alexisb: for 1.23
<cherylj> ah, ericsnow got 'em.  Thanks, ericsnow!
<ericsnow> cherylj: they all LGTM
<cherylj> thanks!!
<voidspace> alexisb: bug 1438820
<mup> Bug #1438820: IP address life field upgrade step and addresser worker don't play well together <juju-core:In Progress by mfoord> <https://launchpad.net/bugs/1438820>
<ericsnow> cherylj: good catch on the blobstore dep :)
<voidspace> bug 1438683
<mup> Bug #1438683: Containers stuck allocating, interface not up <add-machine> <cloud-installer> <landscape> <maas-provider> <network> <juju-core:Triaged by mfoord> <https://launchpad.net/bugs/1438683>
<voidspace> bug 1438168
<mup> Bug #1438168: juju 1.23 doesn't release IP addresses for containers <juju-core:In Progress by mfoord> <https://launchpad.net/bugs/1438168>
<alexisb> voidspace, are you thinking a day for each?
<alexisb> any you think could be deferred to a point release?
<voidspace> alexisb: one of them is done but blocked on the other two
<voidspace> alexisb: so still two days for all of them is my thinking
<voidspace> alexisb: bug 1438168 is complete but in testing it I discovered bug 1438820 that also affects trunk
<mup> Bug #1438168: juju 1.23 doesn't release IP addresses for containers <juju-core:In Progress by mfoord> <https://launchpad.net/bugs/1438168>
<mup> Bug #1438820: IP address life field upgrade step and addresser worker don't play well together <juju-core:In Progress by mfoord> <https://launchpad.net/bugs/1438820>
<voidspace> alexisb: but it is 3 bugs / 3 branches
<alexisb> voidspace, ok, now go enjoy your evening
<alexisb> thanks for the info
<cherylj> ericsnow: I'm glad you commented that you couldn't see the review on RB.  I saw that I created that pull request against the wrong branch!
<cherylj> ericsnow: here's the correct branch:  http://reviews.vapour.ws/r/1347/
<ericsnow> cherylj: LGTM
<cherylj> ericsnow: thanks again!
<ericsnow> cherylj: np
<mup> Bug #1438820 was opened: IP address life field upgrade step and addresser worker don't play well together <juju-core:In Progress by mfoord> <https://launchpad.net/bugs/1438820>
<natefinch> thumper: are you actually on?
<natefinch> so, you're supposed to use UnitsWatcher to watch Machines... makes total sense
<alexisb> natefinch, fwereade would have lots to say about that (this is one of the areas he wants to clean up really badly)
<natefinch> alexisb: heh... yeah, this is the first time I've delved into watchers and stuff, and there's some interesting choices being made in there... I'm sure they each made sense at the time
<thumper> natefinch: no, I wasn't
<thumper> obviously forgot to close IRC last night
<natefinch> thumper: heh, figured
<natefinch> thumper: 7am isn't your usual start time :)
<thumper> nope, it isn't
<natefinch> thumper: I had some questions about watchers and the API, but I think I figured it out from reading other API facades
<thumper> awesome
<ericsnow> davecheney: in case you missed it (re: gccgo in vivid): https://lists.ubuntu.com/archives/ubuntu-devel/2015-March/038740.html
<natefinch> ericsnow: yeah, I saw that, but uh, joining ubuntu-devel to respond is kinda a high barrier of entry.  I think putting gccgo and go as different effective versions is a really bad idea.
<ericsnow> natefinch: yeah, I was thinking that too :)
<thumper> ericsnow: dave is off now for a while
<ericsnow> thumper: k
<thumper> off until he flies to eurpoe, next week sprinting on arm64 go stuff, then meeting us in Nuremberg
<ericsnow> thumper: ah
<natefinch> oh amazon, you're so slow...
<natefinch> bbl
<mup> Bug #1436655 was opened: gce provider should stop using deprecated zone europe-west1-a <gce-provider> <juju-core:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1436655>
<ericsnow> wwitzel3: would you mind assigning the GCE issues you are working on to yourself
<ericsnow> wwitzel3: there are 2 right?
 * thumper moves to the coffee shop to see if a change of scenery will help with focus
<ericsnow> cherylj: so all 1.23 changes are wrapped up now, right? :)
<cherylj> ericsnow: yes :)
<ericsnow> cherylj: lol, too many channels
<cherylj> hehe :)
<cherylj> natefinch-dinner: In updating the dependencies for juju master, I see a new repo, juju/jujusvg which is using the LGPL, but doesn't mention the exception found in other repos.  Should I add it in?
<ericsnow> could anyone spare me a review on http://reviews.vapour.ws/r/1349/ and http://reviews.vapour.ws/r/1350/?
<redelmann_> Hello, is safe to have two enviroments in same AWS account?
<redelmann_> juju destroy-enviroment --force will kill everithing in aws? or just instances of enviroment?
<thumper> redelmann_: interesting question...
<thumper> redelmann_: in theory, it should be fine
<thumper> redelmann_: in practice, I'd test it first
<thumper> redelmann_: it should be fine, so if it isn't, please make sure you file a bug
<thumper> could just be my paranoia
<redelmann_> thumper, I tried it a while ago and juju terminate all my instances (juju 1.20 i think)
<redelmann_> thumper, thats why i asking about this
<thumper> redelmann_: can you file a bug please?
<thumper> also though...
<thumper> you shouldn't need to use --force
<thumper> that is a very "last resort" mechanism for cleaning up an environment
<wallyworld_> axw: after school drop off did we need to catch up about storage since we missed the standup?
<axw> wallyworld_: I don't have much to talk about. I'm going to propose storageprovisioner changes today, assuming I get enough test coverage done
<axw> can do if you like tho
<wallyworld_> all good, maybe we can touch base this arvo if needed
<axw> wallyworld_: ok. gotta go help get the kids ready, bbl
<wallyworld_> ttyl
<ericsnow> wallyworld_: if you have a few minutes, could you take a look at http://reviews.vapour.ws/r/1349/ and http://reviews.vapour.ws/r/1350/?
<ericsnow> wallyworld_: they are both for 1.23
<wallyworld_> ok
<ericsnow> wallyworld_: thanks
<redelmann_> thumper, ok
#juju-dev 2015-04-01
<redelmann_> thumper, https://bugs.launchpad.net/juju-core/+bug/1438951
<mup> Bug #1438951: destroy-enviroment --force destroy all aws instances <juju-core:New> <https://launchpad.net/bugs/1438951>
<redelmann_> thumper, y cant give more info about this, and i cant test it again in current aws
<thumper> redelmann_: thanks
<ericsnow> wallyworld_: regarding IsLocal, the key thing is that we are checking if the init system corresponding to the package is the one running on the *local* host
<wallyworld_> IsLocal() doesn't imply that
<ericsnow> wallyworld_: in code it won't be "IsLocal()", it will be "systemd.IsLocal()", etc.
<ericsnow> wallyworld_: k
<wallyworld_> hmmm
<wallyworld_> IsUsed() perhaps
<wallyworld_> systemd.IsUsed()
<wallyworld_> wadda ya reckon?
<ericsnow> wallyworld_: IsCurrentlyTheOneRunningOnTheLocalHost? :)
<wallyworld_> always one smarty pants
<wallyworld_> systemd.IsRunning()
<wallyworld_> what happens if both files are there though?
<ericsnow> wallyworld_: IsRunning is good
<wallyworld_> can a host have both binaries installed?
<ericsnow> wallyworld_: the Ubuntu guys promised me that that will *never* be a problem
<ericsnow> :)
<wallyworld_> promises, yeah right
<ericsnow> wallyworld_: how about IsRunningLocally?  too long?  I was hoping that it would be super clear that we're only checking the local host
<ericsnow> wallyworld_: BTW, thanks for the review :)
<wallyworld_> how is IsRunning() not implying that?
<wallyworld_> sure :-)
<wallyworld_> wouldn't it be assumed that it pertains to the host on which it is run?
<ericsnow> wallyworld_: yeah, you're right; the lack of args limits the possible interpretations :)
<wallyworld_> ericsnow: i started reviewing the other one. i don't understand why ioutil.TempFIle is not used
<wallyworld_> wasn't the issue that we were using /tmp/somestaticfilename
<wallyworld_> so /tmp/somerandomfilename would be fine
<ericsnow> wallyworld_: right
<ericsnow> wallyworld_: but I want to be consistent between the shell script and the Go code
<wallyworld_> what do you mean?
<ericsnow> wallyworld_: the patch fixes both the discovery script (written in bash for remote use) and the Go code that does the same thing
<wallyworld_> both can still use a random tmp dir
<ericsnow> wallyworld_: I looked at using mktemp on the shell side to do that, but doing it made the code (not insignificantly) more complicated
<wallyworld_> hmmm
<ericsnow> wallyworld_: using a subdirectory of the juju data dir helped it stay simple (er)
<wallyworld_> i'm not across the implementation, why is using mktemp in the shell script hard?
<ericsnow> wallyworld_: because subsequent commands must be written in relation to where that script gets written
<wallyworld_> what generates the shell script? juju? why can't the dir be a script arg?
<ericsnow> wallyworld_: juju does (it's all in service/discover.go + service.go)
<mup> Bug #1438951 was opened: destroy-enviroment --force destroy all aws instances <juju-core:New> <https://launchpad.net/bugs/1438951>
<ericsnow> yikes, mup!
<wallyworld_> ericsnow: so, i'm missing something maybe. in ListServicesScript(), we have const filename = "/tmp/discover_init_system.sh, and that is passed to the script generation commands. why not just generate a random file and pass that
<ericsnow> wallyworld_: so just generate a random filename under /tmp and use that on the remote host?
<wallyworld_> oh you are generating the scripts locally and then running remotely
<ericsnow> wallyworld_: correct
<ericsnow> wallyworld_: currently all for the sake of manual provider :)  though I have considered using some of this for the cloudinit script
<wallyworld_> can init_system=$(blah) run the script inline then?
<wallyworld_> rather than from a filename
<wallyworld_> then the problem goes away
<ericsnow> wallyworld_: perhaps
<wallyworld_> this is a one off bit of bash I think?, so no need to write it out i don't think
<ericsnow> wallyworld_: originally that is effectively what I was doing, but I had to add more complicated logic to the script, I switched to writing the script out to a separate file
<wallyworld_> bash doesn't care about how complicated it is when it runs it
<ericsnow> wallyworld_: having a separate script certainly requires much less knowledge of bash :)
<ericsnow> wallyworld_: it's more for my and our sakes than for bash's :)
<ericsnow> wallyworld_: biab
<wallyworld_> ok
<ericsnow> wallyworld_: back
<ericsnow> wallyworld_: did I mention that bash is the devil?
<wallyworld_> yeah
<wallyworld_> i like tcsh
<ericsnow> wallyworld_: hey, isn't Python system-installed everywhere nowadays...
<wallyworld_> so ioutil.TempFile is nice and portable, and simple to use, none of this data dr and series stuff andeep juju's dir clean
<wallyworld_> can't count on it maybe? not sure?
<wallyworld_> the script is only 20 lines or so, so surely it can be run inlien and all this just goes away
<ericsnow> wallyworld_: I'll work up a different approach in that patch
<wallyworld_> ok, sorry to be a party pooper, it's just my opinion, maybe a different reviewer would feel differently
<ericsnow> wallyworld_: after that other patch you reviewed the script gets a lot shorter and simpler
<wallyworld_> yeah
<ericsnow> wallyworld_: I'll get that landed and see where things are at
<wallyworld_> i was having a big problem with the various g=hacks also
<ericsnow> wallyworld_: and hey, I appreciate you taking a stand :)
<wallyworld_> and this will remove those
<axw> wallyworld_: just gave you a shipit
<wallyworld_> axw: awesome, ty
<ericsnow> wallyworld_: I think you'll like this better: http://reviews.vapour.ws/r/1351/
<wallyworld_> ok
<wallyworld_> ericsnow: yay, looks much better
<wallyworld_> it works?
<ericsnow> wallyworld_: thanks for sticking to your guns :) I like it better too
<ericsnow> wallyworld_: yep
<wallyworld_> \o/
<ericsnow> wallyworld_: there's a unit test that checks
<wallyworld_> yeah, much cleaner
<ericsnow> wallyworld_: thanks for those reviews
<wallyworld_> np :-)
<ericsnow> wallyworld_: I'll land those for 1.23 now-ish and then vanish into the night
<wallyworld_> sure
<wallyworld_> i'll re-merge if there's a spurious failure
<wallyworld_> ty
<thumper> wallyworld_: got a few minutes?
<thumper> wallyworld_: I need an insanity check
<wallyworld_> ok, give me 2 mins
<thumper> kk
<wallyworld_> axw: would be awesome if you got to look at this sometime if you are free http://reviews.vapour.ws/r/1354/
<axw> wallyworld_: sure, will look in a little while
<wallyworld_> np ty, i have to duck out for an hour or so anyway
<wallyworld_> soon
<jog> wallyworld_, still around?
<jam> wallyworld_: ping
<axw> wallyworld_: I'll have to read the spec before I can review, so probably won't get to it until I'm OCR tomorrow sorry
 * dimitern steps out - back in a few hours
<wallyworld_> jam: hi, i was out, about to have dinner, can i ping you soon?
<jam> wallyworld_: np
<jam> I was just checking if there was anything you want me to bring up to Mark.
<jam> I know you had the Storage "hints" vs "properties"
<jam> wallyworld_: but any other information about things you want clarity on for Storage or Health, I'm on the call with him now
<TheMue> morning o/
<TheMue> dimitern: I'll be working in an interrupted way today. coordinating cleaning of the ground, expecting the reviewer, calling the garage to pick the car etc
<voidspace> TheMue: sorry about your car!
<voidspace> dimitern: I've made those tweaks
<voidspace> dimitern: I'll land the branch so I can fix the issue with upgrading and then forward port the fix to trunk
<TheMue> dimitern: regarding the fix imho our tests showed that it isn't the primary interface. so now I'll focus on the empty interfaces, because they are the only difference returned from the lshw parsing function
<TheMue> dimitern: so I'll compare the values and follow their usage bottom-up to see, how they influence the further process
<TheMue> voidspace: thanks, yes. thankfully first feedback is, that it likely is full covered
<voidspace> TheMue: *phew*, what a hassle :-/
<wallyworld_> jam: with "juju status-history <unit>", I was going to default to say 10 recent status changes with an option -n arg. Also you would see agent and workload status interleaved
<TheMue> voidspace: now it's "only" all that organizational stuff as well as looking/waiting for a new one
<jam> wallyworld_: mark likes "hints"
<wallyworld_> ok
<wallyworld_> jam: with the legacy agent state, I added Stopped (so now we have Pending, Error, Started and Stopped
<wallyworld_> jam: the status interleaving is so you could see that an agent ran X hook, which caused the unit to report Y status
<wallyworld_> jam: we also firmly believe that when a hook fails, it should be the agent that is in error, not the workload (as the workload is most very likely still fine). Nonetheless, I followed the spec and we can discuss again if users complain
 * dimitern is back
<dimitern> TheMue, voidspace, thanks guys, sounds good - keep me posted :)
<voidspace> dimitern: fix for upgrade on 1.23 nearly ready for review - just pushing it now
<dimitern> voidspace, awesome!
<jam> wallyworld_: "juju status-history" sounds good to me, can you put it into the doc as you've developed it?
<wallyworld_> jam: haven't put fingers to keyboard yet; that's how i propose to do it, will update doc
<jam> wallyworld_: for the workload, we're certainly in a situation where "we have no idea what is going on" once we're in an error state. So there are at least questions about what is the smallest lie
<wallyworld_> jam: agreed to an extent. we can see how it unfolds once in the hands of users. william has very strong views
<dimitern> voidspace, I assume your latest PR includes both the worker and the fix?
<voidspace> dimitern: ah yes
<voidspace> dimitern: yeah, to fix on 1.23 I needed to base it off the release-address branch which has the worker
<voidspace> dimitern: once that branch lands the diff will be smaller...
<dimitern> voidspace, right, got it
<dimitern> voidspace, reviewed
<voidspace> dimitern: thanks
<voidspace> dimitern: they're good comments - except for the very last one
<dimitern> voidspace, oh yeah? :)
<voidspace> dimitern: what do you mean by an extra test for a removed machine?
<voidspace> dimitern: we have a test for a machine that doesn't exist
<voidspace> dimitern: what's the difference between that and a removed machine?
<dimitern> voidspace, no, that's fine then
<dimitern> voidspace, I must've missed it
<voidspace> dimitern: the SetUp code that creates dead addresses allocates them to a non-existent machine
<dimitern> voidspace, right, all good then :)
<voidspace> which simulates the situation we're guarding against
<voidspace> I'll fix the other issues you pointed out, thanks
<dimitern> voidspace, cheers
<dimitern> dooferlad, hey
<dooferlad> dimitern: hi
<dimitern> dooferlad, I've realized while reviewing your update command that some bits of the spec are contradictory
<dooferlad> dimitern: ah
<dimitern> dooferlad, we shouldn't allow a space with no subnets
<dimitern> dooferlad, and create has to be changed slightly to accept at least one subnet
<dooferlad> dimitern: I was pondering this yesterday, but after reading the spaces and subnets sections of the spec several times it seemed that just implementing what it said was the way to go for now.
<dimitern> dooferlad, that's due to the way I plan to implement spaces on AWS at least - using tags on subnets
<dooferlad> dimitern: I agree that a space without subnets doesn't make any sense
<voidspace> dimitern:  logger.Debugf("requested ReleaseAddress of address %q for unknown instance, ignoring", addr.Value)
<dimitern> dooferlad, I agree - with nothing better to go with :) sure
<voidspace> dimitern: will change to (ignoring) - I think that's your preferred style
<dimitern> voidspace, I'd go with "release address for an unknown instance ID is a no-op, ignoring" ?
<dimitern> voidspace, or (ignoring) at the end - both are fine
<voidspace> dimitern: and not log the actual address?
<dimitern> voidspace, ah, good point - please do :)
<dimitern> release address %q ...
<voidspace> done
<dimitern> TheMue, voidspace, standup?
<voidspace> dimitern: oops, omw
<voidspace> dimitern: the forward port to trunk: http://reviews.vapour.ws/r/1358/diff/#
<dimitern> voidspace, LGTM
<natefinch> dimitern: saw your review on my WIP branch for ensure-availability converting machines... after looking at the code, I think I understand the problems with the API stuff, but want to make sure I'm going down the right path.
<dimitern> natefinch, great, do you think we need to have a chat or?
<dimitern> natefinch, I'm glad to help if you have things to ask as well
<natefinch> dimitern: yeah, but I have a lightly sleeping baby next to me, so it'll need to be text. :)
<dimitern> natefinch, sure :)
<natefinch> dimitern: So, I presume I should be using UnitsWatcher to watch a machine, instead of rolling my own, correct?
<natefinch> dimitern: wayne wrote the watcher code for this, and I think didn't realize UnitsWatcher was also for watching machines (it took me a while to figure that out too... actually just got lucky seeing a comment about how it also worked for machines)
<dimitern> natefinch, hmm UnitsWatcher IIRC reports changes to a service's units
<dimitern> natefinch, i might be missing some context
<natefinch> dimitern: it seems to work on machines and services in practice, plus the code just takes a tag
 * dimitern revisits the PR
<natefinch> dimitern: you were pretty vague about what was wron with the code, so maybe you should start by explaining what you meant: http://reviews.vapour.ws/r/1299/
<natefinch> :)
<dimitern> natefinch, right, sorry - I tried to explain 3 times, but each time my connection dropped or something else was wrong, so I lost 3 separate summaries (growing shorter with frustration)
<natefinch> ha, I know how it is.
<dimitern> natefinch, yeah, so let me have another look now and will explain
<natefinch> dimitern: thanks
<natefinch> dimitern: I think I have an idea, after looking at the other API endpoints, but want to make sure I'm on the right track.
<dimitern> natefinch, ok, so one thing is definitely about using the error result for "fatal" errors, while using the Error field of the result structs for per-tag issues (e.g. failed to start watching machine X's units)
<dimitern> natefinch, that's in the client-side api methods
<dimitern> natefinch, and checking that if you asked for 1 tag you got 1 result and there wasn't an error in the result's Error field
<dimitern> natefinch, this applies to both client methods
<natefinch> dimitern: ok, yeah, trhat's what I was thinking
<dimitern> natefinch, on the server-side, it seems you are taking a bunch of args (tags), but in some cases returning on error with one of them (e.g. ParseMachineTag failed), rather than continuing
<mattyw> dimitern, ping when you have a moment
<dimitern> mattyw, sure, in a little bit
<mattyw> dimitern, sure, I'll ping you some stuff for you to take a look at at your convenience if that's ok?
<dimitern> mattyw, no worries
<dimitern> natefinch, also server-side - it's more common to have a getAuthFunc which returns an AuthFunc(tag) and checks permissions, rather than using the authorizer directly
<dimitern> natefinch, the JobsResult struct should have a Error field like other result structs
<natefinch> dimitern: yep, ok.  This is all exactly what I just fixed up yesterday afternoon... I had hoped that's what you meant.  Of course now that I've fixed it all, it doesn't work anymore, but I'm sure there's just a dumb bug somewhere :)
<dimitern> natefinch, finally, please use names.MachineTag rather than string client-side; the rest are trivial formatting things
<natefinch> dimitern: yep, cool.
<dimitern> natefinch, oh, too bad - have you found out why it doesn't work?
<natefinch> dimitern: not yet, need to put in some logging to see... the handler fires, so that much is working, maybe I mucked up the code that returns the jobs
<dimitern> natefinch, I see, well ping me if I can help with something else
<natefinch> dimitern: thanks
<TheMue> dimitern: you yesterday wanted to take a look into the cloud-init.log. I still cannot reach it on a failing node, but I'm now on a working one and try to find aspects that are matching to the information generated based on the lshw results
<TheMue> dimitern: do you had something special in mind to look at or only wanted to find some kind of errors or strange looking messages?
<dimitern> TheMue, well, it's hard to understand what's going on without being familiar with cloud-init source - there's a lot of stuff in that log
 * TheMue btw should create another vmaas environment for overlapping tests :/
<TheMue> dimitern: it is, indeed
<dimitern> TheMue, more useful usually is cloud-init-output.log
<TheMue> dimitern: ah, thx for that hint, will switch
<dimitern> TheMue, there could be some errors or warnings in cloud-init.log, but most of them are ok - unless it says something serious (e.g. "cannot start" or "failed ..")
<TheMue> dimitern: ok
<TheMue> dimitern: I'm currently adding debugs all the call stack upwards to see how the data influences the processing
<dimitern> TheMue, +1
<TheMue> dimitern: sometimes I wish my old smalltalk back, breaking the execution with live editing of the code and manipulation of the data
<dimitern> TheMue, or even a proper debugger with breakpoints and patching the code on the fly? :)
<TheMue> dimitern: so far no debugger for static languages I've seen during my travel through programming languages had the same simplicity and power of a Smalltalk environment
<dimitern> TheMue, I haven't used it, but I believe you :)
<TheMue> dimitern: it's a wonderful language as well as environment (everything is in one so called image). but sadly it doesn't scale on multicore, everything is single-process :(
<dimitern> TheMue, I see - well, multicore CPUs where not that common at the time I guess
<TheMue> dimitern: exactly, but multicore isn't so young anymore too, so one could at least have added this as a feature to the VM and then the according code. maybe I should port it to the Erlang VM, like LFE is doing it for LISP :D
<dimitern> :)
<TheMue> but then I would need a time compressor before, putting 48h into a day
<tasdomas> I'm seeing test failures like this when I run tests in juju master:
<tasdomas> http://paste.ubuntu.com/10717600/
<tasdomas> the weird part is that I'm getting these with go1.4, go1.3 and go1.2.2
<tasdomas> they seem to be an ordering issue
<tasdomas> but as far as I can tell, nobody can reproduce them
<tasdomas> could I have messed something up in my environment?
<natefinch> first off, only use 1.2.2 .. we don't officially support newer versions (and I know there's a problem at least with 1.4)
<mup> Bug #1439112 was opened: cmd/juju DeploySuite.TestUpgradeCharmDir fails on windows <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1439112>
<dimitern> tasdomas, is than on master?
<tasdomas> dimitern, yes
<tasdomas> dimitern, I've been able to reproduce that with a clean checkout of juju (go get github.com/juju/juju) in an empty GOPATH
<dimitern> tasdomas, and is it random or you can repro it reliably?
<tasdomas> dimitern, can reproduce it every single time
<dimitern> tasdomas, ok, that's good - we had reports about those tests but they were unreliably reproducible
<dimitern> tasdomas, it's not an ordering issue as there are not maps involved there at all, something else is wrong
<natefinch> dimitern: it could still be an ordering issue :)
<tasdomas> dimitern, well, if I can help with solving this let me know
<natefinch> dimitern: it's a slice :)
<dimitern> natefinch, with slices?
<dimitern> natefinch, :) ah, right
<dimitern> tasdomas, can you replace that gc.DeepEquals with jc.DeepEquals, run the tests a few times and paste the result please?
<tasdomas> dimitern, sure
<tasdomas> dimitern, still a failure
<tasdomas> http://paste.ubuntu.com/10717644/
<dimitern> tasdomas, ok, thanks - just to scratch off the easy solution - try one more time with jc.SameContents instead of jc.DeepEquals?
<tasdomas> dimitern, sure
<natefinch> I think the lists are just different
<dimitern> natefinch, they are the same length, so ISTM the order is the only issue
<dimitern> tasdomas, could it be you're using a more recent mongodb?
<tasdomas> dimitern, 2.6.3
<tasdomas> dimitern, SameContents panics
<dimitern> tasdomas, hmm I thought it could be mongo related; oh - is the panic about the map field ExtraConfig?
<tasdomas> dimitern, not as far as I can tell: â  juju  (git)-[master]-% go test github.com/juju/juju/api/networker
<tasdomas> ----------------------------------------------------------------------
<tasdomas> PANIC: networker_test.go:204: networkerSuite.TestMachineNetworkConfig
<tasdomas> [LOG] 0:00.011 DEBUG juju.environs.configstore Made dir /tmp/check-8674665223082153551/2/home/ubuntu/.juju/environments
<tasdomas> [LOG] 0:00.099 DEBUG juju.environs.configstore writing jenv file
<tasdomas> [LOG] 0:00.099 DEBUG juju.environs.configstore writing jenv file to /tmp/check-8674665223082153551/2/home/ubuntu/.juju/environments/dummyenv.jenv
<tasdomas> [LOG] 0:00.099 DEBUG juju.environs.tools reading v1.* tools
<tasdomas> [LOG] 0:00.099 INFO juju.environs.testing uploading FAKE tools 1.24-alpha1-trusty-amd64
<tasdomas> [LOG] 0:00.101 INFO juju.environs.testing uploading FAKE tools 1.24-alpha1-precise-amd64
<tasdomas> [LOG] 0:00.101 INFO juju.environs.testing uploading FAKE tools 1.24-alpha1-utopic-amd64
<tasdomas> [LOG] 0:00.102 DEBUG juju.environs.tools no architecture specified when finding tools, looking for any
<tasdomas> [LOG] 0:00.102 DEBUG juju.environs.tools no series specified when finding tools, looking for any
<tasdomas> [LOG] 0:00.103 DEBUG juju.environs.simplestreams searching for metadata in datasource "existing metadata"
<tasdomas> [LOG] 0:00.103 DEBUG juju.environs.simplestreams fetchData failed for "file:///tmp/check-8674665223082153551/5/tools/streams/v1/index2.sjson": stat /tmp/check-8674665223082153551/5/tools/streams/v1/index2.sjson: no such file or directory
<tasdomas> [LOG] 0:00.103 DEBUG juju.environs.simplestreams streams/v1/index2.sjson not found, trying legacy index file
<tasdomas> [LOG] 0:00.103 DEBUG juju.environs.simplestreams fetchData failed for "file:///tmp/check-8674665223082153551/5/tools/streams/v1/index.sjson": stat /tmp/check-8674665223082153551/5/tools/streams/v1/index.sjson: no such file or directory
<tasdomas> [LOG] 0:00.103 DEBUG juju.environs.simplestreams cannot load index "file:///tmp/check-8674665223082153551/5/tools/streams/v1/index.sjson": invalid URL "file:///tmp/check-8674665223082153551/5/tools/streams/v1/index.sjson" not found
<tasdomas> [LOG] 0:00.103 DEBUG ju
<tasdomas> dimitern, sorry - wrong buffer
<tasdomas> http://paste.ubuntu.com/10717662/
<dimitern> tasdomas, right - yeah it's not obvious, but it is because the map field makes the struct unhashable
<dimitern> tasdomas, ok, so I think we should definitely file a bug about this and tackle it at some point, but because it only happens with a more recent mongod, it's not a serious issue (I mean of the "fix asap" kind)
<tasdomas> dimitern, understood
<tasdomas> dimitern, I'll file the bug
<tasdomas> dimitern, what version of mongo is preferrable ?
<dimitern> tasdomas, great, thanks for your help
<dimitern> tasdomas, the one we're using is 2.4.9 from trusty
<dimitern> tasdomas, there are a few known issues with 2.6
<dimitern> (more juju incompatibilities than mongo issues)
<dimitern> dooferlad, I've updated the network spec to clarify a few bits around managing spaces, including the changes we discussed around update (added rename as a separate command)
<jam> wallyworld: are you still around?
<wallyworld> yeah
<jam> wallyworld: well, I'm half tempted to just say "go to bed" :)
<jam> wallyworld: but the other half of me has a question about the simplestreams tuff
<jam> stuff
<jam> wallyworld: specifically, in environs/simplestreams/simplestreams.go GetProductsPath
<jam> we filter by datatype
<jam> and then we return "errors.NotFoundF" if there are no entries that have the same DataType
<jam> we alsor return NotFoundf if the cloud spec doesn't match
<jam> but we return NoMatchingProductsError
<jam> for the other circumstances
<jam> (if the only thing that doesn't match is ProductId)
<wallyworld> jam: ?
<jam> wallyworld: so I'm curious why finding an index file but not finding cloudspec or datatype is considered NotFound
<jam> but finding one that just doesn't have the product is considered NoMatchingProducts
<jam> *specifically* because we special case NotFound in how we log errors
<wallyworld> no particular reason, except maybe bad implementation. maybe we should have used NoMatchingClouds and NoMatchingDataTypes errors
<wallyworld> we could or should fix it i guess
<jam> wallyworld: well if we get noMatchingProductsError, then we do something weird and log it, but then fall through
<jam> so you still get an items list instead of nil
<wallyworld> from memory, that could be because the products might still be found in a different products file
<wallyworld> but i'd have to look at the code, it's been a while
<jam> wallyworld: sure, I have the feeling things have evolved, because the next higher loop keeps searching on any error
<wallyworld> the implementation has grown organically to match what's served by cloudimages
<wallyworld> it needs to be looked at fresh and a proper V2 refactoring done
<wallyworld> mirrors were also add after V
<wallyworld> 1
<wallyworld> so it got very messy
<jam> sure
<wallyworld> i do wish it were rewritten
<jam> wallyworld: http://reviews.vapour.ws/r/1362/
<wallyworld> looking
<wallyworld> jam: \o/
<tasdomas> dimitern, ping?
<dimitern> tasdomas, pong
<tasdomas> dimitern, a uniter API question, if I may
<dimitern> tasdomas, sure
<tasdomas> dimitern, so the uniter uses only the uniter API client, I need to modify the way metrics are added to state (from the unit)
<tasdomas> should I override the existing method in the uniter API (and APIserver) or should I introduce a different facade?
<tasdomas> s/different/new
<dimitern> tasdomas, it depends on how compatible the api changes is - if it's adding a new method or adding args to an existing one, it's fine to do it directly in the current uniter api facade
<tasdomas> dimitern, what if it's changing the params of an existing one?
<dimitern> tasdomas, if it changes behavior or removes args/methods in a backward-incompatible way - a new facade version of the uniter api is needed
<tasdomas> dimitern, got it - thank you
<dimitern> tasdomas, np - it will help to have a look at the change, when ready
<tasdomas> dimitern, it's related to api/metricstorage (and apiserver/metricstorage) - I introduced this as a new facade, but now see the error of my ways and will move the functionality to the uniter api client
<dimitern> tasdomas, ok, ISTM it will be fine to add the new methods to the existing uniter api facade (v1 IIRC)
<dimitern> tasdomas, however, keep in mind when implementing the client-side methods that the apiserver might be older and can return CodeNotImplemented error for the new methods
<tasdomas> dimitern, thanks
<tasdomas> dimitern, now I remember why I added this as a new facade - fwereade suggested I do this to avoid incrementing the version of the uniter facade (which is largish) due to this small change
<dimitern> tasdomas, I see, there's no need to increment the version if only new (and not critical) methods are added (i.e. if the client code is prepared to handle gracefully the case when the new methods are missing)
 * dimitern steps out for a bit
<mup> Bug #1439204 was opened: environs/tools does not cleanup in the right order <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1439204>
 * dimitern is back
<rogpeppe> dimitern: what's the current standard way of creating a juju review request?
<jam> katco: fairly trivial review: http://reviews.vapour.ws/r/1363/diff/#
<katco> jam: k i'll take a look
<dimitern> rogpeppe, just propose a branch against one of the branches in juju/juju - a RB diff should be created automatically
<jam> rogpeppe: generally propose a github merge
<rogpeppe> dimitern: ah, i'll just make a PR then, thanks
<jam> rogpeppe: rb notices and then updates reviews.vapour.ws and updates github with a link to it.
<katco> jam: wow you weren't kidding :)
<rogpeppe> jam: it would be nice if the README had contribution guidelines, i guess
<katco> jam: +1
<jam> rogpeppe: probably needs to be updated, I agree.
<jam> I thought we had CONTRIBUTING
<natefinch> we do... the code review section is kind of a wall of text, though
<natefinch> and links to https://github.com/juju/juju/blob/master/doc/contributions/reviewboard.md
<natefinch> which has more specifics
<rogpeppe> jam: thanks - i hadn't seen that
<rogpeppe> jam: the README should probably link to it
<rogpeppe> jam: this particular PR is interesting from the p.o.v. of the recent discussion on juju-dev
<rogpeppe> jam: as it uses an external type in the API serialisation
<rogpeppe> jam: i'm not convinced that it's wrong here though
<rogpeppe> jam: i'd be interested in your thoughts
 * katco does happy dance
<katco> i'm feeling good today :)
 * rogpeppe is pleased for katco
<jam> rogpeppe: I'd say I generally prefer being more explicit on API stuff because it is far too easy to stay compatible with yourself and break everyone else in the world
<katco> rogpeppe: i've had a sinus infection for the past few weeks. haven't been able to do much of anything =/
<rogpeppe> katco: ew
<rogpeppe> katco: i also had a horrible flu thing last week, still feeling pretty knacked
<katco> rogpeppe: seems everyone's been sick
<rogpeppe> katco: yeah
<katco> rogpeppe: and we'll bring it all to nuremberg! :)
<rogpeppe> katco: i hadn't had something like this in decades
<rogpeppe> katco: joy!
<rogpeppe> katco: sinus thing sounds 'orrible
<katco> rogpeppe: yeah it's been a few years since i've been knocked on my butt like this
<katco> rogpeppe: i suppose it's a good reminder to appreciate the good times :)
<rogpeppe> katco: well, continue to take it easy! yeah.
<katco> rogpeppe: you too sir! see you in nuremberg i hope
<rogpeppe> katco: deffo
<rogpeppe> jam: the issue in this particular case is that we want to transfer a macaroon over the wire, and the macaroon wire format is well defined, and implemented inside the macaroon package
<rogpeppe> jam: there's actually no easy way to use a different format except by dependending on precisely the format we're trying to avoid depending on
<jam> rogpeppe: isn't a serialized macaroon just a series of lines with a final hash?
<rogpeppe> jam: no
<rogpeppe> jam: and even if it was, i wouldn't want to duplicate all the (very well tested) serialisation code that's in the macaroon package
<jam> rogpeppe: so I'm saying that the API can be "you get a string" which you then parse as a macaroon. not "you get a Macaroon object"
<rogpeppe> jam: how is that any better?
<jam> rogpeppe: fwiw I was confusing M.serialize() with M.inspect(). The latter being the line-by-line with a final sig
<rogpeppe> jam: there's a JSON serialisation format too
<rogpeppe> jam: (which is what we use in all the other APIs where we're using macaroons)
<jam> rogpeppe: interestingly JSON serialization isn't supported by the android lib
<rogpeppe> jam: which android lib?
<jam> rogpeppe: https://android-arsenal.com/details/1/914
<jam> rogpeppe: I was searching for "macaroon JSON serialization" and one of the first hits was "JSON not supported" :)
<rogpeppe> jam: i'm not that surprised. the libmacaroons guy doesn't like the JSON serialisation much, although i took the format from his code.
<jam> rogpeppe: so for something like this where there is an official format, it does feel like you should use it. It is different when it is one of *our* formats
<jam> rogpeppe: the short text from google references you
<jam> Merge branch '002-fix-json-serialization' of https://github.com/rogpe
<rogpeppe> jam: yeah, i fixed libmacaroons so it actually worked
<jam> rogpeppe: so is http://godoc.org/gopkg.in/macaroon.v1 just a wrapper around lib or you were just looking at interop ?
<rogpeppe> jam: i was just looking at interop
<rogpeppe> jam: (i wrote it independently to start with, but then converged the serialisation formats)
<rogpeppe> jam, dimitern, katco, anyone else: anyway, a review would be appreciated if you have a few moments to look at it: http://reviews.vapour.ws/r/1364/diff/#
<natefinch> the macaroon stuff is versioned with gopkg.in, right?  So in theory, it should never break compatibility unless juju updates to including a new version
<ericsnow> fwereade: ping
<jam> natefinch: there is code compat, and there is wire-protocol compat
<jam> technically gopkg.in is only code compat I thought
<katco> rogpeppe: i'll get to it in a few, working down the queue (but i'll skip to yours next)
<natefinch> jam: I would hope that would be part of the contract
<rogpeppe> katco: ta!
<jam> certainly that was the discussion from something else, though the thought was that code compat would iterate faster than wire compat
<natefinch> jam: I could see how v1 and v2 could share wire compatibility... but I can't see how v1 and v1.1 could not... at least, I think most people would assume they'd have compatible wire formats
<jam> rogpeppe: so one problem with your proposal is that you are changing what is supported by the API without changing the version numbers. So new juju clients can't tell that the server doesn't support it, right?
<jam> rogpeppe: you really do need a version bump
<dimitern> rogpeppe, why macaroon-bakery.v0 and not v1? I thought v0 was only used as a fallback when no versions exist
<jam> so that juju 1.25 can say "oh,I'm talking to Client v0, which doesn't support macaroon based conversations"
<rogpeppe> jam: that seems right
<rogpeppe> jam: where do i bump the version?
<katco> rogpeppe: jam: natefinch: http://semver.org/
<rogpeppe> dimitern: because we haven't decided that the bakery API is stable yet
<rogpeppe> dimitern: i think it's getting close though
<dimitern> rogpeppe, so imports will use v1 for the release of 1.23 then?
<rogpeppe> dimitern: there is no v1 yet
<rogpeppe> dimitern: i have one moderately big change in the pipeline and then we might consider bumping to v1
<dimitern> rogpeppe, please do, as releasing juju depending on unstable imports is a no-no
<dimitern> rogpeppe, apart from that LGTM I think
<rogpeppe> dimitern: most of juju's imports are unstable...
<dimitern> rogpeppe, none of the versioned ones are, except charm.v5-unstable, but we agreed to bump that to v5 before the release
<rogpeppe> dimitern: most of juju's imports aren't versioned
<dimitern> rogpeppe, I believe you got my point, come on :)
<rogpeppe> dimitern: not really
<rogpeppe> dimitern: i don't see there's a difference between an unversioned import and an import with a v0 version
<rogpeppe> dimitern: and i don't think you'd be complaining if the import path was github.com/juju/bakery
<dimitern> rogpeppe, the difference is simple: the unversioned import is not yet versioned, the unstable but versioned one is imported as unstable as a conscious choice
<rogpeppe> dimitern: they're exactly the same. neither is stable.
<rogpeppe> dimitern: i used .v0 just so it would be trivial to update with govers when the time comes to bump the version
<dimitern> rogpeppe, ok, that's fine, I'm just saying we'll need to bump it before releasing a stable 1.23
<rogpeppe> dimitern: i don't think that should be a necessary prereq
<rogpeppe> dimitern: although i'd like to do it anyway
<dimitern> rogpeppe, cool
<natefinch> technically, with godeps, we don't really need versioning.  The version is just a nice human-readably suggestion.  For example... 1.23 says it's importing charm.v5-unstable, but it's really importing a commit from the 1.23 branch
<natefinch> note that I do still think versioning is good and that we should continue to use it.
<natefinch> we need juju status -f
<natefinch> so it'll update the status whenever there's a change, and I don't have to spam juju status constantly
<benji> "watch juju status" can be a reasonable substitute
<natefinch> benji: yeah that works :)
<voidspace> dimitern: so, there's a comment in extractInterfaces about skipping disabled network interfaces
<voidspace> dimitern: but it doesn't skip them
<voidspace> dimitern: if it did, life might be simpler...
<dimitern> voidspace, oh, yeah - I noticed that one as well and glared at it :)
<voidspace> dimitern: do we *need* to know the disabled interfaces?
<dimitern> voidspace, we need to not try to use them as primary interfaces at least
<dimitern> voidspace, that's coming from another bug around that code
<voidspace> dimitern: well, if extract interfaces didn't return them there's a lot less chance we'd try and use them
<voidspace> dimitern: although finding the actual bug would be good - maybe *as well*?
<dimitern> voidspace, no, I mean we need to know whether they are disabled or not
<dimitern> if possible
<voidspace> dimitern: digging in still
<dimitern> dooferlad, voidspace, PTAL http://reviews.vapour.ws/r/1365/ when you have a moment - juju subnet add cmd
<dooferlad> dimitern: *click*
<voidspace> also looking
<dimitern> thanks guys
<dooferlad> dimitern: I like CheckNumArgs - nice!
<dimitern> dooferlad, it came along nicely yeah :)
<dimitern> dooferlad, that helper is a candidate for factoring out in a common place later
<dimitern> dooferlad, if you like, use it for spaces as well (just copying it for now I guess - for simplicity, then we'll move it somewhere)
<dooferlad> dimitern: Yea, I was thinking of making use of it, though I was thinking of something like ParseArg(arg string, *parseFunction, *targetVariable) err {}
<dooferlad> dimitern: Not sure if combining the two ideas just gets messy!
<dooferlad> dimitern: also, it gets to a point where you are just writing code because it is a cool idea, rather than making progress. I think I am approaching that point :-)
<dimitern> dooferlad, hah I know the feeling
<dimitern> dooferlad, voidspace, and a final PR for today - juju subnet remove - https://github.com/juju/juju/pull/2014/ (the diff includes the previous PR - please ignore that)
<TheMue> dimitern: what does " install -D -m 644 /dev/null '/var/lib/juju/nonce.txt'" of the userdata in cloudinit do?
<dooferlad> TheMue: I believe that file is required for the machine to boot, but it doesn't need to contain anything. I ran into it a while ago.
<dimitern> TheMue, it installs the nonce file for the machine agent
<dimitern> dooferlad, TheMue, the nonce is used to verify the machine agent trying to login as "machine-X" is indeed allowed to do so (the provisioner generates the nonce when it starts an instance for machine-X)
<dimitern> ok folks - time for me to go
<TheMue> dimitern: I looked the whole bootstap up and down
<TheMue> dimitern: and everything really looks similar, so I'll now check the content of the nonce
<dooferlad> TheMue: There are plenty of people having problems because that file is missing (https://www.google.co.uk/search?q=var%2Flib%2Fjuju%2Fnonce.txt%2520missing&gws_rd=ssl#q=var%2Flib%2Fjuju%2Fnonce.txt+missing)
<dimitern> TheMue, I'd appreciate if you summarize your findings in a mail please, and let's discuss it tomorrow?
<TheMue> dimitern: yep, will do
<dimitern> TheMue, thanks!
<alexisb> katco, you around?
<katco> alexisb: i am!
<alexisb> dooferlad, voidspace if you all have updates on the 1.23 networking bugs please provide them to me before you eod
<alexisb> we need to make a call on releasing 1.23 by end of my day
<jw4> alexisb: there is a high priority bug in upgrades that I may have a fix for today
<jw4> (1.23)
<jw4> 1438489
<jw4> bug 1438489 (sorry for the stutter)
<mup> Bug #1438489: juju stop responding after juju-upgrade <upgrade-juju> <juju-core:Triaged by johnweldon4> <https://launchpad.net/bugs/1438489>
<alexisb> jw4, nice
<alexisb> if we want to included it for beta3 it needs to land today
<alexisb> otherwise it will go in a point release
<jw4> alexisb: hopefully yep, although there seems to be another bug right behind it if this one clears
<jw4> alexisb: in a different part of code but also to do with upgrades
<mup> Bug #1439204 changed: environs/tools does not cleanup in the right order <test-failure> <windows> <juju-core:Fix Released by jameinel> <https://launchpad.net/bugs/1439204>
<voidspace> alexisb: two bugs of the three I was working on done and fix committed
<voidspace> alexisb: third in progress, partial fix but not the main issue, done - still hopeful to land tomorrow
<voidspace> alexisb: can go into the next release though - or I can try and land the simple (partial) fix we have immediately
<alexisb> voidspace, ack, thank you!
<natefinch> ericsnow, wwitzel3: either of you still working on 1.23 bugs?
<mup> Bug #1435413 changed: rename "juju backups restore" to "juju backups recover" <backup-restore> <juju-core:Won't Fix by ericsnowcurrently> <juju-core 1.23:Won't Fix by ericsnowcurrently> <https://launchpad.net/bugs/1435413>
<ericsnow> natefinch: wrapping up some vmware stuff and there's still the 1 GCE bug that needs attention
<natefinch> ericsnow: sounds like they're trying to get 1.23 cut tonight.   vmware is still a ways off, right?  Seems like GCE should be the priority
<ericsnow> natefinch: yep
<voidspace> g'night all
<natefinch> ...and now that my HA stuff is ready, there's no graduated reviewers around
<natefinch> le sigh
<katco> natefinch: o/
<katco> natefinch: finishing up a review and i'll TAL
<natefinch> oh, shit,  I forgot some of the "newbies" are graduated :)
<katco> natefinch: haha yeah :)
<natefinch> katco: much appreciated - http://reviews.vapour.ws/r/1299/
<katco> boy reviews are like laundry.... just when you think you might be done and you can work on something else :p
<natefinch> katco: haha, yep
<natefinch> katco: ahh crud, I have to fix some of the comments... I went from one type to another and back to the first, but I forgot to put the comments back to the first type
<katco> natefinch: if you want to return the favor, fairly small: http://reviews.vapour.ws/r/1367/
<katco> natefinch: ok np, lmk when it's ready
<natefinch> katco: ok, fixed
<katco> k looking
<natefinch> katco: looking at your review
<katco> natefinch: ty
<natefinch> katco: The file 'featuretests/package_gccgo_test.go' (r3b6a6c8) could not be found in the repository
<katco> natefinch: right i deleted it :)
<katco> natefinch: i don't know why RB has problems with that
<natefinch> katco: heh ok
<katco> natefinch: https://github.com/juju/juju/pull/2015/files#diff-765f9c55678c118cef1ce099ec147738L1
<katco> natefinch: that's what it was
<ericsnow> any networking folks around?
<ericsnow> I'm seeing the addressworker in a restart loop around this log entry:  2015-04-01 19:47:52 ERROR juju.worker runner.go:219 exited "addresserworker": environment does not support networking
<natefinch> katco: ship it
<katco> natefinch: woot! ty!
<natefinch> katco: welcome :)
<natefinch> I swear HA used to work on local, but it totally doesn't now.
<mup> Bug #1439364 was opened: error in logs: environment does not support networking <juju-core:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1439364>
<mup> Bug #1439364 changed: error in logs: environment does not support networking <juju-core:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1439364>
<mup> Bug #1439364 was opened: error in logs: environment does not support networking <juju-core:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1439364>
<natefinch> katco: how's the review coming?
<katco> natefinch: good. my wife came home so i got interrupted for a few
<natefinch> katco: no problem. Sorry to pester you, just need to get it checked in today (if possible), and I'm running out of day.
<katco> natefinch: np, reviewing as fast as i can :)
<natefinch> katco: thank you, I appreciate it.
<mup> Bug #1439375 was opened: logger in worker/instancepoller is named "juju.worker.instanceupdater" <juju-core:New> <https://launchpad.net/bugs/1439375>
<katco> natefinch: i forget, do mgo update operations need an exists assert?
<natefinch> katco: shouldn't... mongo is update == upsert  but I don't know if mgo somehow separates the two
<katco> k
<katco> natefinch: i have an initial review posted
<katco> natefinch: i need to look at the api stuff again... that stuff is so tedious
<natefinch> katco: yeah, the API stuff is super annoying.  totally needs to be either generated or somehow refactored to take out all the boilerplate
<katco> natefinch: definitely
<katco> natefinch: i see dimiter already commented on the api stuff, do you feel like he gave that a good once-over?
<katco> natefinch: b/c the logic looks fine to me, it's the nuances of our RPC implementation that i'd really have to go over
<natefinch> katco: yes, but I had to make changes to it in response to what he asked for, so really, he sort of needs to approve my changes. But of course, they weren't done until he went offline. le sigh.  Maybe I can get some of the NZ/AUS guys to review the API stuff and get it merged in later tonight.
<katco> natefinch: that might be best... i don't want to just rubber stamp it.
<katco> natefinch: the logic looks fine though
<katco> natefinch: axw is the next OCR
<natefinch> katco: no problem.  I appreciate the time you put into it.
<katco> natefinch: today, it's my job ;)
<natefinch> axw: when you get on, if you could review http://reviews.vapour.ws/r/1299/ I would really appreciate it, especially the API stuff.
<katco> natefinch-dinner: i will ask him in our standup as well
<natefinch-dinner> katco: thanbks
<ericsnow> wwitzel3: I think you may be right
<katco> natefinch-dinner: enjoy dinner
<cherylj> ericsnow, thumper:  Could I get a quick license review?  https://github.com/juju/jujusvg/pull/24
<cherylj> cmars ^^
<mup> Bug #1439398 was opened: GCE low-level RemoveInstances fails if firewalls are not found <juju-core:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1439398>
<ericsnow> cherylj: that license exception is the same one we have everywhere else, right?
<cherylj> ericsnow: yes, I copied it from another repo
<ericsnow> cherylj: cool, LGTM
<cherylj> thanks!
<jw4> I'm pulling my hair out with this local upgrade test... it seems to not be picking up my updated code on my 1.23 branch... any tips for iterating on upgrade testing?
<jw4> ah, strike that, my code is getting pulled in... there was a problem in my assumptions about upgrades
<jw4> it looks like my upgrade steps have to manually iterate units on the machine, they don't get passed in as part of the upgrade operation
<ericsnow> just got bit by the fact that the pointer to a loop var does not change across iterations (which makes sense *now*)
<ericsnow> could I get a review on http://reviews.vapour.ws/r/1370/?
<ericsnow> katco: ^^^
<ericsnow> axw: ping
<ericsnow> axw: I guess you won't be one quite yet :)
<ericsnow> s/one/on/
<ericsnow> wallyworld: perhaps you could takea quick look at http://reviews.vapour.ws/r/1370/
<wallyworld> ericsnow: in a meeting, will look soon
<ericsnow> wallyworld: thanks!
<axw> ericsnow: LGTM
<ericsnow> axw: thanks
<axw> natefinch-dinner: will take a look a bit later on
<axw> np
<ericsnow> axw: it was such a dumb bug :(
<axw> ericsnow: yeah, that's an easy one to fall for
<mup> Bug #1439447 was opened: tools download in cloud-init should not go through http[s]_proxy <cloud-installer> <landscape> <juju-core:New> <https://launchpad.net/bugs/1439447>
#juju-dev 2015-04-02
<ericsnow> axw: PTAL http://reviews.vapour.ws/r/1373/ (should be quick)
<jw4> anyone familiar with upgrades, willing to answer a couple questions?
<axw> ericsnow: done
 * axw goes for breakfast
<ericsnow> axw: thanks!
<axw> wallyworld: can you please link me the status spec?
<wallyworld> axw: https://docs.google.com/a/canonical.com/document/d/1SsHDxi58xgrim6VTKorqMn4GlzxPV9EFvu1ueBgnMlc
<axw> ta
<axw> wallyworld: so, a charm can never status-set error. what if the software is irreparably broken?
<axw> i.e. the charmed service, not the charm itself
<wallyworld> axw: it then sets blocked
<wallyworld> blocked means it can't run and a user has to intervene
<wallyworld> for whatever reason
<wallyworld> error is reserved to report hook errors only
<axw> wallyworld: mk. that implies to me that it can be repaired, which may be optimistic
 * axw continues
<wallyworld> axw: wrt storage add, did we want the additional storage (eg a new volme) to be able to get different sizing, tags etc, or did we want to enforce storage add must create the new volume exactly the same as the first one
<axw> wallyworld: I think it should take the same args as "--storage" in "juju deploy"
<axw> wallyworld: i.e. pool,size,count
<wallyworld> axw: awesome, that was my tpught also
<wallyworld> just wanted to confirm
<wallyworld> ty
<axw> np
<wwitzel3> can I get one more set of eyes on http://reviews.vapour.ws/r/1371/
<axw> wallyworld: reviewed
<wallyworld> axw: ty, will look
<axw> wwitzel3: will take a look soon
<wwitzel3> axw: thanks, appreciate it
<natefinch> axw: my stuff needs to be in for 1.23 that is getting cut basically ASAP... so if you could prioritize it, I could get it merged (barring major problems, of course) - http://reviews.vapour.ws/r/1299/
<axw> natefinch: ok
<natefinch> axw: thanks, I appreciate the help.
<wallyworld> axw: i've updated the pr for that health branch, after you finished your current review
<axw> wallyworld: ok
<wallyworld> axw: i have to go out for lunch, if when you look at the pr you are happy with it, could you $$merge$$ for me and i'll propose the next one when i get back
<axw> wallyworld: np
<wallyworld> ty
<axw> wwitzel3: reviewed, sorry for the delay
<wwitzel3> axw: np, thank you
<wwitzel3> axw: it requires work, so I won't get to it until tomorrow anyway ;)
<axw> wwitzel3: sorry :~(
 * axw is creating work for lots of people today
<wwitzel3> haha
<wwitzel3> that's probably a good thing
<marcoceppi_> okay, 1.23-beta2 has been really flaky with local provider
<marcoceppi_> seems about every third machine doesnt' get the agent running on it
<marcoceppi_> I realize that's not helpful, I'm gathering log files
<marcoceppi_> re-ran cloud-init, I think this is a problem with the seed data, ssh keys aren't getting installed
<marcoceppi_> I also can't seem to connect to the API with python-jujuclient anymore. I noticed that the api server is only listening on ipv6
<marcoceppi_> is this a new configuration?
<marcoceppi_> prefer-ipv6: false is in my jenv, not sure why the api-server is only binding to the ipv6 address locally, this may be a redherring
<marcoceppi_> also noticed that the user changed to admin where it was user-admin previously
<axw> wallyworld: if you can take a look at http://reviews.vapour.ws/r/1360/ and http://reviews.vapour.ws/r/1361/ some time today, I'd be most grateful
<wallyworld> sure, np. thanks for landing my stuff
<wallyworld> i'm just doing a pr for the next bit
<axw> wallyworld: nps
<axw> cool, ping me and I'll review
<wallyworld> axw: http://reviews.vapour.ws/r/1376/
<axw> looking
<wallyworld> ah i half looked at the managed filesystem source one last night, looked good
<jog> wallyworld, Would you have time to read over bug 1435644, or suggest someone? It's a private cloud streams question and I know you've been able to give guidance on similar bugs.
<mup> Bug #1435644: private cloud:( environment is openstack )index file has no data for cloud <juju-core:New> <https://launchpad.net/bugs/1435644>
<wallyworld> jog: ok, sre
<jog> wallyworld, thank you, it needs another set of eyes, as I'm not sure what to suggest.
<wallyworld> jog: i just need to finish a few things, will comment on the bug when i can
<jog> wallyworld, np I'm EOD
<wallyworld> ok
<jam> axw: http://reviews.vapour.ws/r/1377/ can you give it a quick look? It is the same patch as katco but it just fixes a test that was also using the leader-election feature flag (which is now removed)
<axw> jam: okey dokey
<jam> thx
<jam> hmmm... I think it is supposed to be targetting 1.23 I'll have to check on that
<axw> jam: shipit
<axw> ah yeah, probably
<jam> axw: I have to rebase it, but I'll propose another one for 1.23
<axw> jam: nps, I expect it'll be exactly the same given the size :) just merge if so
<jam> axw: sgtm
<marcoceppi_> where does juju cache it's api endpoints?
<jam> axw: so it looks to be an entirely bigger patch. I have the feeling master is not up-to-date with the leader-election code that is in 1.23
<marcoceppi_> I changed values in the api endpoints in .jenv but it says loading from cache
<jam> tbh I was surprised the patch was so small
<jam> the flag in master only changes the client side (essentially), but all of the internal workers were running behind that flag in the 1.23 branch.
<axw> jam: as was I. I'll take a look
<jam> katco: ping
<axw> jam: LGTM
<marcoceppi_> what is the api user in juju? user-admin or admin?
<jam> axw: http://reviews.vapour.ws/r/1378/ is the newer proposal, but I'm running through tests, etc since it kept growing.
<axw> sure
<jam> marcoceppi_: the name of the user is "admin" the *tag* is "user-admin" (vs machine-0 etc)
<marcoceppi_> jam: so what should I use in the websocket? user-admin?
<jam> marcoceppi_: so in most of the API we talk in terms of tags. so Login probably wants 'user-admin', but know that in the future we're looking to be able to name those users and they will then be "user-joe" etc.
<jam> I believe the agents login as "machine-0" etc.
<marcoceppi_> sure, thanks
<marcoceppi_> I'm having a hell of a time getting python-jujuclient to connect to 1.23-beta2 bootstrapped environment
<axw> wallyworld: reviewed
<wallyworld> ty
<jam> marcoceppi_: I believe thumper has been making changes to Login which is supposed to be compatible, but I thought he had to submit some patches recently.
<marcoceppi_> let me try rolling back to 1.22
<jam> marcoceppi_: if something is broken wrt compatibility, we really appreciate that feedback
<jam> well, *I* appreciate it, hopefully the people who have to fix it do too :)
<marcoceppi_> jam: I need to do more testing, I'm having a hard time locking this down
<marcoceppi_> other than "it's not working"
<jam> marcoceppi_: sure. if it doesn't "just work" and it used to, then we certainly have a  bug
<marcoceppi_> too many moving pieces
<axw> wallyworld: BTW, I saw later that the time is set by the state server. you can probably safely ignore my comment, I was just thinking it would be nice to show relative times in the UI
<axw> wallyworld: but that involves quite a bit of complexity, in order to ensure timestamps are synchronised between state servers and clients
<wallyworld> axw: Agreed, this is one area where I'm hoping for feedback from users. The spec says timestamp but I suspect we'll be asked for relative times instead/as well as.
<wallyworld> i just want to get *something* reasonable out there so we can then see what real users ask for and complain about
 * axw nods
<jam> wallyworld: axw: you probably need to use the universal "time since epoch GMT" timestamp, and then on the client turn that into localtimes. It seems the most portable way
<jam> relative times (as in 1hr ago) seem like a fair amount more work.
<wallyworld> jam: it does store epoch
<wallyworld> on client it formats as RFC822
<axw> jam: that still assumes the clocks are all correct. I suppose it's fair to say that if they're not, you're on your own
<wallyworld> i can't recall if that includes tz conversion
<jam> axw: if you're clocks aren't reasonably close to reality there isn't really much we can do is there?
<axw> wallyworld: it just displays the timezone it's in. you could concert to local TZ
<wallyworld> ah, i did mean to do that, but it got late
<axw> jam: well, you can implement poor-man's NTP, but it's probably not worthwhile :)
<marcoceppi_> jam: okay, there's an issue in 1.23-beta2
<wallyworld> axw: i am counting on our deployents using NTP OOTB
<jam> marcoceppi_: a bug is appreciated, targetting the 1.23 series, as this seems pretty critical. It *might* already be fixed but I wouldn't hold my breath on it.
<marcoceppi_> jam: just writing repro steps
<marcoceppi_> jam: would it be worth compiling the 1.23 branch of the repo to verify as well?
<axw> jam: in my former life, I worked on a distributed system where the servers (owned by customers) were *constantly* skewed and they would never run NTP. I think it's okay to rely on NTP, I just had flashback nightmares
<axw> wallyworld: SGTM
<jam> axw: :)
<jam> marcoceppi_: if you want to take the time, its nice to have the info, but its mostly a "do what you can" sort of thing.
<jam> it's not your responsibility to fix all our bugs, but we're happy to have your support
<marcoceppi_> it's 3am and this has blocked me, I don't have much else to do
<jam> I'm sorry to hear that, and sorry that we broke stuff, but certainly appreciate you discovering it.
<jam> much better to find out in a beta release.
<marcoceppi_> jam: http://pad.lv/1439535
<marcoceppi_> I'll try compiling 1.23 from github then try trunk as well
<voidspace> morning all
<jam> marcoceppi_: thanks for investigating, that looks much weirder than I expected
<marcoceppi_> jam: fwiw, this works with 1.23 branch (juju version shows 1.23-beta3)
<mup> Bug #1439535 was opened: 1.23-beta2 websocket incompatibility <juju-core:New> <python-jujuclient:New> <https://launchpad.net/bugs/1439535>
<dimitern> voidspace, morning
<dimitern> voidspace, there's a new bug about the addresser I've assigned to you
<dimitern> voidspace, trivial to fix - just don't start the worker if environs.SupportsNetworking() returns false
<voidspace> dimitern: ah, ok
<voidspace> dimitern: easy enough :-)
<voidspace> dimitern: is it a problem to have an addresser around otherwise?
<dimitern> voidspace, well, I don't think so - but it should not spam the logs and restart every 3 seconds :)
<voidspace> dimitern: ah, yes it is a problem
<voidspace> dimitern: just reading the bug :-)
<dimitern> voidspace, I'd prefer to have it running in all environments TBH
<dimitern> voidspace, but without a netEnviron interface it can't do its job anyway
<jam> marcoceppi_: I don't see anything specifically in "git log --first-parent juju-1.23-beta2..1.23" that makes it clear why your API issues would have been fixed
<jam> marcoceppi_: is this local provider?
<jam> yeah "switch local"
<marcoceppi_> jam: aye, it is
<wallyworld> axw: i'm going blind, i can't see what calls func processPending(...)
<axw> wallyworld: the main loop in storageprovisioner.go
<axw> at the top
<jam> marcoceppi_: which makes me worry that it is more of a packaging issue.
<jam> dimitern: voidspace: do you know if the backport of "addressable containers" into 1.23 would have affected local provider?
<marcoceppi_> jam: really? seems odd it would be in packaging
<jam> marcoceppi_: to quote sherlock holmes, "when you have eliminated the impossible, whatever remains, however improbable, must be the truth?"
<jam> marcoceppi_: I certainly wouldn't expect it there either.
<dimitern> jam, it's not a backport - it was first implemented in 1.23, but it shouldn't affect the local provider
<jam> dimitern: I just see addressing changes in 1.23 beta 3
<jam> which *could* be something that would allow local provider to work/not work.
<jam> marcoceppi_: I don't see anything about login, etc changing
<axw> wallyworld: found it?
<wallyworld> axw: ffs, looked straight past it. the process functions aren't thread safe, is it worth a comment that they're being called from a single threaded loop, or is that asking for an unnecessary comment
<jam> marcoceppi_: just to eliminate variables, can you "git co juju-1.23-beta2" and see if it is broken for you ?
<dimitern> jam, it's possible, however the local provider does not use the same brokers as other providers, where most of the changes are
<axw> wallyworld: like the uniter, the whole thing is not goroutine-safe
<marcoceppi_> jam: sure
<axw> wallyworld: I can put a comment, but I'm not sure where it'd go ...
<wallyworld> fair enough
<jam> I see changes to GCE, but those should also not effect local
<wallyworld> don't wory
<jam> marcoceppi_: I do see a change to how local provider was getting its IP address. I wonder if it was suffering from the "claim I'm on the LXC bri
<jam> bridge bug in 1.23-beta2"
<marcoceppi_> jam: possibly? about to compile
<wallyworld> axw: reviewed, just a few small comments/suggestions
<axw> wallyworld: cheers
<jam> anyone have thoughts on expired cert issues?
<jam> 1.23 points to go.googlesource.com
<jam> which has a bad cert
<marcoceppi_> yup, I give up jam, 1.23-beta2 from source works
<jam> nm. I was testing in a VM that had been suspended for 2 weeks, and the time hadn't updated yet.
<jam> so their cert was renewed 2 weeks ago
<jam> marcoceppi_: le sigh....
<jam> marcoceppi_: but you can reliably reproduce when running /usr/bin/juju, right?
<anastasiamac> jam: another fix that went in into 1.23 related to http- and apt- addresses that may affect marcoceppi_ is the check for loopback address
<marcoceppi_> jam: everytime, going to spin up another vm to verify
<jam> anastasiamac: yeah, but in theory he just tested rolling back his local build to 1.23-beta2 and it still passed
<anastasiamac> jam: however m not sure why there would b a diff btw 1.23-beta2 and 1.23-beta3 with respect to this fix..
<anastasiamac> jam: yep..
<jam> marcoceppi_: the other thing is to make sure you do "godeps" and all that, just in case there is some depedency we were using in 1.23-beta2 that had something wrong.
<marcoceppi_> jam: I run godeps everytime I build
<marcoceppi_> following this workflow: http://marcoceppi.com/2014/11/compiling-juju-core-from-source/
<jam> marcoceppi_: that looks decent to me
<jam> having various versions of juju in $PATH could confuse things in the past, did you check if there were build errors?
<jam> (as that would leave the other 1.23 around in $GOPATH/bin)
<jam> axw: can you try a quick test for me? "cd worker/uniter; go test -check.v -check.f Leader"
<jam> I'm still sorting out things in this VM, but on other machines it was failing for me. I'm wondering if the tests are just poorly isolated (they use some other test's setup to be able to work properly)
<jam> or maybe I'm just insane :)
<marcoceppi_> jam: juju version reported 1.23-beta2 and `which juju` was the one in $GOPATH/bin
<jam> marcoceppi_: were you running "juju foo" or $GOPATH/bin/juju foo ?
<jam> IIRC, there was a really old bug at one point where because juju was running sudo
<marcoceppi_> just `juju foo`
<jam> it would find the wrong juju because root's PATH was not user's PATH
<marcoceppi_> I can try again with full path
<jam> marcoceppi_: I don't expect that's the problem, but just trying to eliminate possibilities
<marcoceppi_> sure
<axw> jam: will do, with your 1.23 branch you mean?
<jam> axw: i'm having it fail on master as well as stock 1.23
<jam> there it passed
<jam> at least that gives me a baseline
<jam> the VM is happy
<marcoceppi_> jam: yeah, I'm unable to reproduce on a clean vm now
<axw> jam: works on master for me
<marcoceppi_> there's something buggered with my setup, this was just a big 'ol snipe hunt
<jam> axw: thanks for confirming. I'll just move forward :)
<voidspace> dimitern: for bug 1438683
<mup> Bug #1438683: Containers stuck allocating, interface not up <add-machine> <cloud-installer> <landscape> <maas-provider> <network> <juju-core:Triaged by mfoord> <https://launchpad.net/bugs/1438683>
<dimitern> voidspace, yeah?
<voidspace> dimitern: can you point me to where in the logs or config that indicates eth1 is being used
<voidspace> dimitern: I can't find eth1 mentioned by name or MAC address like this
<voidspace> dimitern: and the reference to primary network in the logs is for eth0
<dimitern> voidspace, in machine-0.log around returning the result from PrepareContainerInterfaceInfo
<voidspace> dimitern: ok, thanks
<voidspace> dimitern: and there it is...
<dimitern> voidspace, as for eth0 being primary - there are 2 places (also in that log) - before starting but after acquiring the instance, and before starting the container
<voidspace> dimitern: I grepped for "eth1", not sure how I missed that :-/
<dimitern> voidspace, :)
<voidspace> dimitern: ok, so easy
<voidspace> dimitern: we iterate over all subnets and map subnets to interfaces
<voidspace> dimitern: we don't check if the interface is disabled - and where the same subnet appears more than once we'll overwrite
<dimitern> voidspace, yeah - both of these are problems
<voidspace> dimitern: so we *do* need to skip disabled interfaces there
<voidspace> dimitern: that will be the problem
<dimitern> voidspace, where?
<voidspace> dimitern: prepareAllocationNetwork
<voidspace> dimitern: lines 1021 and 1051
<voidspace> coffee
<dimitern> voidspace, so the result of NetworkInterfaces should include all NICs we can find, but with correct device index and disabled flag
<voidspace> dimitern: yep, I already have a fix for that - although "correct device index" is a bit arbitrary if lshw doesn't give it to us
<voidspace> dimitern: and when we iterate over interfaces to pick we should be skipping disabled ones
<dimitern> voidspace, hmm I'm not quite sure
<voidspace> dimitern: this is in prepareAllocationNetwork I'm talking bout
<voidspace> *about
<dimitern> voidspace, even if we skip them, we still shouldn't overwrite the subnet info in case more than one nic is on the same subnet
<voidspace> dimitern: do we ever want to return interface info for a dsiabled nic?
<voidspace> dimitern: agreed, but that's a different issue
<voidspace> although
<voidspace> we need to pick *an* interface, so if we have picked a subnet and allocated an address on it - we only need one non-disabled nic
<voidspace> so overwriting isn't really an issue (so long as we skip disabled ones)
<dimitern> voidspace, if by "return" you mean from NetworkInterfaces() - yes, we want that; in prepareAllocationNetwork though - that's different
<voidspace> it's prepareAllocationNetwork I'm talking about
<dimitern> voidspace, ok
<voidspace> that's where the specific problem is
<voidspace> dimitern: in prepareAllocationNetwork do we want to always prefer the primary network, unless it's disabled?
<voidspace> and always try that first (try to allocate an IP on the subnet associated with the primary interface)
<dimitern> voidspace, just keep in mind that we'll most likely start allocating  addresses (and creating NICs) for containers such that we have a 1:1 correspondence with the host enabled nics
<voidspace> ok
<dimitern> voidspace, so in the long term it doesn't matter which NIC is primary
<voidspace> so I don't think overwriting actually matters, as we only want to pick one nic anyway
<voidspace> but we *do* need to skip disabled networks in prepareAllocationNetwork
<dimitern> voidspace, but for now we only want 1 address/nic per container - connected to the host's primary nic
<voidspace> which is a 3 line fix plus test... (along with the device index fix I already have for NetworkInterfaces)
<dimitern> voidspace, yes, but we shouldn't pass [id1, id1] to Subnets when we have 2 nics on the same subnet id1
<dimitern> voidspace, (or if we do, we should only fetch the info once per unique id)
<voidspace> dimitern: ok, that's also true
<voidspace> :-)
<dimitern> :)
<voidspace> dimitern: so the singular runner doesn't have an obvious way to not start a worker
<dimitern> voidspace, it won't start it if you don't add it to the list of workers to run :)
<voidspace> dimitern: right - so in which case the agent needs to construct an environ
<voidspace> dimitern: *or* we can start the runner and Handle can be a no-op if networking isn't supported
<voidspace> dimitern: either is fine, I'd just like to know which is preffered
<voidspace> dimitern: startEnvWorkers (cmd/jujud/agent/machine.go) doesn't currently have an env
<dimitern> voidspace, I think we should start it
<dimitern> voidspace, but then internally it should handle "networking not supported" properly, i.e. logging that it won't do anything, but not returning an error
<voidspace> dimitern: that's fine - and easier :-)
<dimitern> voidspace, exactly :)
<TheMue> dimitern: shit, exactly this moment the garage comes to fetch my car. will report afterwards, got an idea after your hint
<dimitern> TheMue, ok, no worries
<axw> wallyworld: in your email you wrote "juju-get" and "juju-set". I think s/juju/status/ ?
<TheMue> dimitern: thinking about I would say your theory is correct, I'll talk to rvba. when watching the node during boot and it's wanting to fetch metadata from the controller the return code is 404.
<TheMue> dimitern: this sounds like "yes, I can connect the server, but it doesn't has the info (here the lshw) that I want."
<dimitern> TheMue, yeah, something like this - perhaps it's not because lshw is missing, but something else
<TheMue> dimitern: maybe, I'll discuss on #maas. but it seem to be able to at least reach the maas controller. and that's why pings also work.
<dimitern> TheMue, yeah, ok
<TheMue> btw, my car is now gone *sniff* less than a year old
<axw> dimitern: not sure if it's due to networking stuff going on, but I cannot "juju ssh" to ec2 machines on master. works fine if I disable proxying through machine-0
<axw> dimitern: I get "nc: getaddrinfo: Name or service not known"
<dimitern> axw, hmm odd I'll try here with a fresh tip of master
<dimitern> axw, but it will be in about half an hour
<axw> dimitern: no rush, just thought I'd let you know in case you knew of somethign related
<dimitern> axw, do you have containers deployed on machine 0 ?
<axw> dimitern: could be unrelated, I see a bunch of network failures due to network resolution failing
<axw> dimitern: nope
<dimitern> axw, if you paste me some logs I'll investigate
<axw> I just destroyed, I'll recreate
<axw> dimitern: never mind, must've been an intermittent DNS error.
<dimitern> axw, *whew* good! :)
 * dimitern goes to get his car back
<rogpeppe> axw: i was just looking at NewClient in apiserver/client
<rogpeppe> axw: ISTM that you could save a mongo round trip in every single API call by using common.NewToolsURLGetter(st.EnvironTag().Id(), st)
<rogpeppe> axw: instead of fetching the env from mongo every time
<rogpeppe> axw: (unless there's some reason that the env uuid might change, i guess)
<axw> rogpeppe: yeah, agreed. that possibly predates EnvironTag caching... pretty sure that value is fixed
<rogpeppe> axw: cool. might be worth bearing in mind.
<jam> axw: *if* you're still around I have a new update for the branch. Unfortunately, we still have 1 test that fails because it is nondeterministic. I haven't figured out how to fix that yet.
<jam> katco: are you around?
<jam> katco: if/when you are, I've been looking at enabling leader-election always in http://reviews.vapour.ws/r/1378/
<jam> it is almost complete except for one big TODO. If you have time, I'd appreciate a look at it.
<jam> I think we could enable this in production, because the test is failing because we're triggering a hook that should be triggered, but at a random time so I can't just add it to a fixed spot in the test expectation.
<dimitern> back
<abentley> alexisb: I don't have a blessed revision, and there's at least one GCE bug unfixed.  Do you want to meet anyway?
<abentley> alexisb: Correction, I see a bless for 16bed49 in build 2508
<abentley> alexisb: Correction 9710c29 / 2509
<mgz> yeah, the ppc tests managed to get through on that one
<abentley> mgz: local-deploy-vivid-amd64 was stuck for most of yesterday, and is stuck in the same way today.  I am disabling it.
<mgz> abentley: fair enough
<dimitern> dooferlad, voidspace, ping
<dimitern> I feel like I'm talking to myself >_<
<voidspace> dimitern: heh
<mgz> katco: are you around? I'm trying to test cn and the v4 signing code on 1.23-beta2 is not playing ball with me it seems
<dooferlad> dimitern: howmy I be o service?
<TheMue> dimiter: btw, I'll file a bug against maas, it seems to fail during cloudinit
<dimitern> TheMue, ok, that's what it looked like to me
<TheMue> yeah, to rvba also
<dimitern> TheMue, but we should still find a way to reproduce and fix that bug
<TheMue> to repoduce it is no problem, but we cannot fix the booting bug
<TheMue> we can fix our bug to stop processing, that's what I've done
<TheMue> now need tests for it
<hazmat> marcoceppi_: ping
<alexisb> ericsnow, wwitzel3, what is the latest on the GCE bugs?
<ericsnow> alexisb: wrapping up (all but 1 merged)
<marcoceppi_> hazmat: otp
<hazmat> marcoceppi_: just curious about that issue w/ py juju client and 1.23.. just looked up the bug report and it looks like its already resolved though.
<aznashwan> ericsnow, axw: could I bother you guys with a closer lookthrough of http://reviews.vapour.ws/r/1218/ and, if you're feeling really adventurous, http://reviews.vapour.ws/r/1330/? :D
<ericsnow> aznashwan: sure thing
<dimitern> I'm is off for now - might be back later
<katco> jam: mgz: BoD
<katco> jam: one of the tests is failing then?
<wwitzel3> alexisb: I should have the last patch up in 20 minutes or so
<mgz> katco: bod? beginning of day?
<katco> mgz: yep!
<mgz> katco: >_<
<katco> mgz: ?
<mgz> katco: so, we expect 1.23-beta2 to work in china right? it has all your code in it.
<mgz> katco: I get enough silly acronyms from xwwt
<katco> mgz: as much as we can expect untested fixes to work =/
<wwitzel3> lol
<xwwt> mgz: Keeps you on your toes.  ;)
<katco> mgz: we never had a cn north instance to test against for legal reasons
<mgz> katco: how should I go about debugging it? I have flipped the debug flag in goamz, and it basically confirms we are using the v4 path (doesn't print the headers, I could also enable that extra dumping in the signing file), but aws complains at me that the access key query param (I presume) is not supplied
<mgz> which is non-sensical as that's not how v4 signing works
<mgz> I will paste you my junk for your curiousity
<katco> mgz: hmmm... yes ty
<mgz> katco: https://pastebin.canonical.com/128882/
 * katco looking
<mgz> I can try flipping the juju code to always using v4 and running it against us-east-1?
<katco> mgz: that might be informative
<mgz> will do that, and turn on the signing debug output
<katco> i'm doing some research on that param
<mgz> so, the v2 version does all the query params as normal, plus the access key, plus a hashed-with-private-key param
<katco> mgz: right, v4 uses headers primarily
<mgz> yup
<katco> mgz: do you know what request was being made? e.g. what api is failing?
<katco> looks like https://github.com/go-amz/amz/blob/v1/ec2/ec2.go#L1080 ?
<mgz> katco: DescribeAccountAttributes
<cherylj> ericsnow:  when you get a minute, could you review this:  https://github.com/juju/replicaset/pull/1
<mgz> katco: hm, I didn't get more printed from the signing flipping to os.Stdout at the top
<cherylj> ericsnow: I found another repo that needed updating
<ericsnow> cherylj: yeah
<mgz> katco: same issue with us-east-1
<ericsnow> cherylj: thanks for being so thorough
<katco> mgz: i think that debugging is only for v4
<ericsnow> cherylj: I need to add a GH webhook for that repo too
<mgz> it's using v4 now
<mgz> I flipped it in juju
<cherylj> ericsnow: thanks!  I think that will be the last one
<ericsnow> cherylj: did you mean to remove the summary comment that was on line 1
<ericsnow> ?
<cherylj> ericsnow: yes, I did for consistency with the other repos.
<cherylj> ericsnow: I debated it, but figured I should err on the side of consistency.  That, and the doc that was put together didn't mention the summary line
<ericsnow> cherylj: k
<mgz> katco: I'm rebuilding from the beta2 tag in git, for line number references
<ericsnow> cherylj: if I recall correctly, that summary line was a suggestion from the license text but is much less relevant for our use :)
<cherylj> ericsnow: yeah, I think you're right.
<ericsnow> cherylj: LGTM
<cherylj> ericsnow: thanks!
<katco> mgz: so you're passing in SignV4Factory(...)?
<katco> mgz: because if you've switched the debug logger to stdout, and it's using v4, i have no explanation for why you're not getting output.
<mgz> katco: https://pastebin.canonical.com/128887/
<mgz> katco: I am also mystified
<katco> mgz: i can never remember... does --debug collect the logs from the disparate machines?
<katco> mgz: bc i think this would be in a jujud instance?
<jam> katco: so the patch you proposed to remove leader-election feature flag was strictly against master, which doesn't actually have all the code that is in 1.23
<jam> katco: so I picked it up and started fixing it for 1.23, which involved a fair bit more work
<katco> jam: ahhh i see. not a straightforward backport
<jam> but now there is 1 more test to fix
<katco> jam: doh :(
<mgz> katco: https://pastebin.canonical.com/128889/
<jam> which has a race condition I don't have an immediate answer for
<mgz> katco: this is all just from the client
<jam> katco: http://reviews.vapour.ws/r/1378/ should be my work so far, proposed against 1.23, and I should have a big TODO in there. I'd appreciate it if you could look at it, since I'm way past EOD here
<katco> jam: sure thing
<katco> jam: fyi juggling a few things here. i've been out for a week, and am behind on some storage work for tanzanite
<katco> mgz: i see your v4 signing is definitely running... and you're sure godeps or gopkg.in isn't fooling you on which version you're compiling against?
<mgz> katco: it may be, I will double check
<mgz> only thing I get is:
<mgz> godeps: "/home/ubuntu/go/src/gopkg.in/amz.v3" is not clean; will not update
<mgz> which implies I changed the right junk
<katco> mgz: that's... good i think
<katco> yeah
<katco> maybe try a go clean github.com/juju/...?
<katco> "go clean github.com/juju/..."
<katco> if that wasn't clear
<mgz> will `rm -rf ~/go/pkg/linux_amd64/*` to be sure
<katco> k
<katco> mgz: out of curiosity -- and i don't know much about this -- are these "temporary credentials" by any chance?
<katco> mgz: this came up in my research indicating there may be some inconsistency: https://github.com/mitchellh/goamz/pull/154
<wwitzel3> can I get a review for http://reviews.vapour.ws/r/1371/, thanks :)
<mgz> katco: the cn ones may be, but the us-east-1 is just our normal account
<mgz> katco: DEBUG: 2015/04/02 15:12:04 GZ: requestTime err Could not retrieve a request date. Please provide one in either "x-amz-date", or "date".
<mgz> that error happens, but gets swallowed
<katco> mgz: o.0 swallowed?
<katco> mgz: i see... in ec2.go
<mgz> katco: yeah, Signer returns error, but query in ec2.go doesn't check for it
<katco> mgz: well that's the smoking gun, it's not actually signing the request
<katco> mgz: it looks like ec2.go's query(...) is providing a timestamp. i wonder if that's a valid attribute to look at
<wwitzel3> ericsnow: that gce review is up when you get a chance
<ericsnow> wwitzel3: looking now
<mgz> katco: I don't understand the requestTime code really
<mgz> how does it think it's getting a header set if we're *sending* our first request?
<katco> mgz: the headers are set by the code
<katco> mgz: when building the http.Request
<katco> mgz: the signing documentation (i believe) states that the user can either specify x-amz-date or date. i'm not sure if Timestamp is something to look for
<mgz> well, we can make the ec2 code do that
<mgz> but currently it can just never work?
<katco> mgz: it looks that way... v4 needs a timestamp
<mgz> I will bug a file
<katco> mgz: http://pastebin.ubuntu.com/10724611/
<katco> mgz: try that rq, just to spike and see if we can get cn working
<mgz> katco: doing
<marcoceppi_> hazmat: yeah, I'm not sure what happened
<katco> (and handle the error if you hadn't already)
<marcoceppi_> but for a good several hours I couldn't get juju-local to repsond on the websocket
<marcoceppi_> just getting "websocket closed"
<katco> marcoceppi_: no websocket for you!
<marcoceppi_> Ukraine is not game
<mgz> katco: auth failure, but I have output
<katco> mgz: auth failure as in the signing failed?
<mgz> katco: https://pastebin.canonical.com/128890/
<katco> mgz: ah... so that indicates that signing is fine, b/c it usually complains loudly about signing
<katco> mgz: is that the us-east-1? or cn?
<mgz> katco: us-east-1
<katco> stupid me just looked at log lol
<mgz> I can switch back as needed
<katco> mgz: well, i think at least that gets you past the signing issue
<katco> mgz: in terms of credentials... not too sure what causes that. http://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html
<katco> mgz: just indicates to check your creds
<natefinch> man I wish our code had more comments about why the code is doing what it's doing
<wwitzel3> natefinch: but it is self documenting (said every person writing code ever) ;)
<mgz> katco: yeah, signing errors are deliberately obscure
<katco> mgz: well i don't think it's a signing error... usually it will say something like "the hash you sent does not match the hash we calculated" with some debugging info
<katco> mgz: i think it's something genuinely amiss with the creds
<natefinch> wwitzel3: yeah, that's my main problem with the "no comments" people... sure, I can tell *what* the code is doing, but I can't tell *why* they're doing it.
<katco> natefinch: but thank god all those New(...) methods have comments!
<katco> // NewFoo returns a new Foo.
<natefinch> I'd give my external keyboard for a  // hide the not found error with ErrPerm so we don't expose when the machine is not allowed to be accessed vs. doesn't exist
<mgz> katco: I suspect you could repo this locally with any aws account
<mgz> katco: anyway, will file bug and we'll work out what's up
<katco> mgz: k, ty for troubleshooting with me.
<ericsnow> wwitzel3: review done (with a couple minor comments)
<wwitzel3> ericsnow: I think we can just toss out the replacement based on what I am seeing
<ericsnow> wwitzel3: yeah, I think so too
<ericsnow> wwitzel3: but it's worth a comment because if our assumptions are wrong it would effectively be a silenced error
<wwitzel3> ericsnow: well, looking at this again, I think we should just check for deprecated, and log a warning about it being skipped (and any replacement)
<ericsnow> wwitzel3: perfect!
<wwitzel3> as for NewZone, I didn't see it used outside of the tests at all
<ericsnow> wwitzel3: so it's even less of an issue :)
<mgz> katco: filed bug, also seems I reviewed your original branch so we've no one to blame but ourselves for missing that err return :)
<katco> mgz: lol
<natefinch> mgz: why is the Machine api called Machiner?  It's not a Go interface :/
<katco> mgz: is that a 1.23 blocker?
<rogpeppe> dimitern: ping
<rogpeppe> anyone out there have some decent knowledge of the ins and outs of the juju deploy command implementation?
<mgz> katco: I believe so
<katco> mgz: ok
<mgz> natefinch: it's one of the ancient ones
<katco> mgz: have a link to the bug handy?
<mgz> ah, we haven't got the little bot in here, I thought it'd pop up in a minute
<mgz> bug 1439761
<mup> Bug #1439761: AWS V4 signing does not work <ec2-provider> <juju-core:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1439761>
<mgz> doesn't add anything to what we've been over in here currently
<katco> mgz: so, us-east bootstrapping with v4 isn't working, right?
<katco> mgz: b/c i will have no way of closing this bug for china without someone's help
<katco> mgz: (no test instance)
<mgz> katco: indeed, I believe v4 signing should work on us-east-1 - and doesn't, even with the date fix atm
<mgz> katco: I can give you ec2 creds if you need them as well
<katco> mgz: well, again, i think signing is working fine :)
<katco> mgz: it will complain if not
<katco> mgz: it's something regarding the request
<katco> mgz: ty, i will let you know. i have some i can try
<mgz> katco: my assuming, given the same creds work when v2 is used, is that the v4 code must be at fault
<mgz> is there anything else I need to be supplying that I'm not, past the access and secret key (and region/endpoint)
<katco> mgz: possibly the ec2 code is at fault for not providing some requisite in the request
<mgz> katco: sure, that also sounds possible
<mgz> I tried removing the Timestamp query param as well as an experiment
<katco> mgz: um, i don't think so. let me have a go and i'll let you know
<mgz> katco: hm, I have another idea
<alexisb> voidspace, hehe, I will have to make sure we have Fritos and tab at the sprint ;)
<katco> mgz: i was using s3cmd when i was working on s3, is there a way to control ec2 instances in a similar way since i don't have access to a web console for this account?
<wwitzel3> lol Fritos and Tab
<voidspace> alexisb: good call :-)
<wwitzel3> I'd like to opt-out
<voidspace> hah
<voidspace> wwitzel3: not allowed :-)
<mgz> katco: yeah, `apt-get install euca2ools`
<katco> mgz: ty
<katco> mgz: what's your other idea?
<mgz> then `euca-describe-instances` etc
<voidspace> wwitzel3: I just linked alexisb to Code Monkey by Jonathan Coulton...
<wwitzel3> ahhh, haha
<katco> mgz: ty works
<mgz> katco: using x-amz-date only, as date is a standard http field and may get overwritten later
<mgz> no joy yet
<katco> mgz: good point
<mgz> format is probably wrong
<voidspace> and interestingly, Jonathan Coulton is how dooferlad and I met a few years before working together...
<voidspace> in a cafe in London before a Jonathan Coulton concert
<mup> Bug #1439761 was opened: AWS V4 signing does not work <ec2-provider> <juju-core:In Progress by cox-katherine-e> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1439761>
<katco> mgz: i have a reproducible live test in amz
<katco> mgz: same error
<mgz> katco: ace, I'm just having another go at date formats
<katco> http://docs.aws.amazon.com/AmazonRDS/latest/APIReference/CommonParametersV4.html
<katco> mgz: it request ISO 8601
<katco> mgz: but i believe the signing takes care of that conversion
<mgz> katco: it does, but I'm trying to understand the docs over what the headers are expected to me
<mgz> *be
<mgz> implies only ISO8601, but switching to that didn't help
<mgz> messing with the date header at all seems suspect
<katco> mgz: well, the signing will convert whatever you feed it to ISO 8601 Basic Format
<mgz> katco: for comparison, https://pastebin.canonical.com/128903/
<katco> mgz: huh... we do ec2.us-east-1, and they do us-east-1.ec2.
 * natefinch opens a window because even though there's still 8"(20cm) of snow on most of the ground... it's 75Â°f (24Â°C) inside
 * natefinch needs an imperial->metric units bot
<natefinch> ericsnow: core team meeting
<wwitzel3> ericsnow: PTAL http://reviews.vapour.ws/r/1371/
<mup> Bug #1439813 was opened: Destroying lxc environment sometimes throws Go error <juju-core:New> <https://launchpad.net/bugs/1439813>
<ericsnow> wwitzel3: LGTM
<natefinch> hazmat: you had some magic with btrfs to make the local provider lightning fast.... do you have that documented somewhere?
<natefinch> anyone on happen to know how why I might be getting "connection is shut down" when trying to use the machiner API in a watcher's Handle method?
<rick_h_> natefinch: https://pastebin.canonical.com/128921/ is a copy of an email on this a while back
<rick_h_> heh, april 2014 to be exact so a year ago
<natefinch> rick_h_: awesome thanks!
<rick_h_> natefinch: np, fulltext search ftw
<natefinch> rick_h_: heh, I hadn't thought to just do a mail search, couldn't remember if he's actually emailed it out or not
<ericsnow> could I get a review on http://reviews.vapour.ws/r/1380/?
<ericsnow> it adds a --file option to relation-set
<hazmat> natefinch: documented?.. just the code itself.. nutshell is if /var/lib/lxc is a btrfs mount, lxc can use btrfs cow snapshots for lxc-clone'd containers ( -s -B btrfs), so that and a template container per series.
<hazmat> the rest was just manual registration / with user data gathered from machinescripts api, so its async init
<ericsnow> voidspace: I thought you were long gone :)
<mup> Bug #1439880 was opened: Container's interfaces are all on private networks instead of host's eth0 network <oil> <juju-core:New> <https://launchpad.net/bugs/1439880>
<katco> mgz: you still around by any chance?
<katco> axw: did i misunderstand? are you all off today in AUS?
<anastasiamac> katco: it's good friday today - public holiday... so yes :D
<anastasiamac> katco: Monday is easter monday - another public holiday :D
<anastasiamac> katco:
#juju-dev 2015-04-03
<voidspace> dimitern, ping
<voidspace> dimitern, did you see my two branches? ericsnow reviewed them, so I'll try and land them later.
<voidspace> dimitern, they're only short, so you may, or may not, want to look at them
<voidspace> dimitern: thanks!
<aznashwan> hey, could a couple of follow-ups on http://reviews.vapour.ws/r/1218, and, if you guys are really in the review spirit: http://reviews.vapour.ws/r/1330/
<frankban> ocr, could you please take a look at http://reviews.vapour.ws/r/1383/ ? thanks!
<cherylj> ericsnow: Can you ping me when you get a minute so we can talk about bug 1439447?
<mup> Bug #1439447: tools download in cloud-init should not go through http[s]_proxy <cloud-installer> <landscape> <juju-core:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1439447>
<ericsnow> cherylj: OTP
<ericsnow> cherylj: hangout?
<cherylj> ericsnow: sure, let me get my headset on
<alexisb> aznashwan, are those the centos support patches?
<mup> Bug #1440097 was opened: unittest failure: apiserver/root_test.go:rootSuite.TestPingTimeout <ci> <juju-core:New> <juju-core 1.23:New> <https://launchpad.net/bugs/1440097>
<alexisb> just so that folks know all of our scheduled all call reviewers are suppose to be on vacation today
<jw4> woot - free for all
<natefinch> or free for none ;)
<mup> Bug #1440097 changed: unittest failure: apiserver/root_test.go:rootSuite.TestPingTimeout <ci> <juju-core:New> <juju-core 1.23:New> <https://launchpad.net/bugs/1440097>
<mup> Bug #1440097 was opened: unittest failure: apiserver/root_test.go:rootSuite.TestPingTimeout <ci> <juju-core:New> <juju-core 1.23:New> <https://launchpad.net/bugs/1440097>
<jw4> natefinch: such a downer ;)
<natefinch> jw4: I try :)
<katco> jw4: hey, wanna rewrite the project in python?
<katco> jw4: i bet we can do it before anyone gets back
<mgz> katco: you tested the original v4 code against s3 right?
<mgz> I think the rest of aws just does it differently
<katco> mgz: yes, live tests and all
<katco> mgz: except it's passing the amazon test suite just fine
<mgz> the region name is different as you pointed out yesterday, and some other stuff
<mgz> their test suite is apparently just not as tight as their real auth
<katco> hehe possibly
<mgz> I'm looking at boto/auth.py HmacAuthV4Handler vs S3HmacAuthV4Handler
<katco> mgz: wwitzel3 said he had worked on boto quite a bit, he's peeking at the issue as well. what are the main diffs you're seeing?
<mgz> it's slightly annoying as the classes are written differently,
<mgz> but the headers that get signed is different, the region format, and some of the sequencing
<mgz> S3 signs all headers, general only signs Host and X-Amz-*
<jw4> katco: lol
<katco> if the headers are present, you must sign them
<jw4> katco: we might even get hazmat back if we do
<katco> jw4: hehe
<mgz> katco: for s3, everything but the Auth itself, yeah, but not in general
<aznashwan> alexisb: sorry, got a little distracted with work
<aznashwan> alexisb: yes, those are both the CentOS patches
<hazmat> katco: i'm listening ;-)
<katco> mgz: no, i mean the algorithm requires that. you can't optionally sign headers; i don't think that's a mutable property of the algorithm based on which service
<katco> hazmat: haha o/ :)
<alexisb> aznashwan, ok, I have had a few folks comment re those patches, I am thinking we may need to do some pair reviewing when we are all in germany
<mgz> S3 also doesn't do url path normalisation, whereas the other does
<katco> mgz: i don't think we're doing that at all
<mgz> which can me something as dumb as trailing slash would break it maybe
<aznashwan> alexisb: we have slowly come to terms with the fact that those PR's won't get in until the sprint; but I still like to hope beyond hope :D
<katco> mgz: yeah
<mgz> like, our failed one was going a GET with a path
<mgz> the one that worked was post to root and form-encode body
<mgz> so it could be something as dumb as bad path
<alexisb> aznashwan, the alternative is to have you break everything down as requested
<mgz> katco: but you probably are going to need two versions to keep s3 working at the same time as fixing this
<aznashwan> alexisb: as mentioned, the refactor, added CentOS userdata and package management changes are so inter-dependent that breaking them up would take a tone of re-work, writing temporary code which only gets overwritten in the following PR, and triple/quadruple the pain of maintaining the PR's rebased unto master
<katco> awesome, my robot vacuum cleaner just unplugged my computer
<katco> IoT ftw
<mgz> ehehe
<mgz> rise of the downtrodden robots!
<katco> i definitely kicked it
<aznashwan> alexisb: that would add an overall delay of at least a month whilst the PR as is now is merge-able with the exception of a handful of tests which are still not CentOS-ready
<katco> this is when you discover the temporary work you were doing in /tmp is less temporary than you would have liked.
<aznashwan> (...which we are working on as we speak)
<natefinch> gah, stupid f'ing machiner... I don't know how the hell you're supposed to use this thing.  It hides everything under too many layers of abstraction.
<alexisb> aznashwan, then I suggest we plan to have a dynamic review session in person
<aznashwan> alexisb: would not be too bad if it comes to that. I would insist to still get a review here-and-there in the mean time so we get the small stuff ironed out before the sprint so we focus on the bigger picture there.
<katco> mgz: i think i found the problem
<katco> mgz: i vaguely recall removing default paths "/" from the canonical request string for S3 b/c that was causing an issue
<katco> mgz: it looks like adding that in gets me a result
<mgz> katco: ha, was paths :)
<katco> mgz: i tip my hat to you, sir
<mgz> :D
<katco> mgz: and i then slap aws's collective faces with it.
<katco> mgz: what an undocumented mess
<katco> mgz: https://github.com/go-amz/amz/commit/3431a6c7dea296878e5efa2681e85e0b1a2f5a27#diff-5f72c79adc6ba80e9d4d6cf78433008eL151
<katco> mgz: feel like a review? https://github.com/go-amz/amz/pull/47
<mgz> katco: surething
<katco> ah foo i broke a signing test. those things are so fragile
<mgz> yeah, was wondering if more tests would need changing
<katco> nah it's just a space
<mgz> so if it works with s3 and ec2, I think this is basically good to go
<mgz> this isn't super-robust, callers can still pass in stuff that will mess this up I'm pretty sure
<katco> mgz: i think we're still broke on relative paths "/../.." or something
<mgz> and I don't like the date-magic
<katco> date magic?
<mgz> katco: yeah, and probably double slashes as well
<katco> yeah those tests fail
<mgz> the pass in a x-amz-timestamp in nay random format and get it back out the right way code
<mgz> I'd prefer we just demanded a sensible time object in the interface or something
<katco> well, smallest change possible.
<mgz> but that's not something that really needs changing right now
<katco> right
<mgz> right, I agree
<katco> repushed with test fix
<katco> just added some spaces
<mgz> katco: lgtm
<katco> mgz: do we have this behind a bot yet?
<mgz> katco: it's got a funny pre-merge check thing instead, which passed
<katco> mgz: ok, so merge manually?
<mgz> yeah, oh, travis runs against both go 1.2 and go 1.4, interesting
<mgz> only the unit tests obviously but fine
<cherylj> natefinch: I heard you had some thoughts about bug 1439447.  Don't know if you wanted to weigh in before I make any code changes...
<mup> Bug #1439447: tools download in cloud-init should not go through http[s]_proxy <cloud-installer> <landscape> <juju-core:In Progress by cherylj> <juju-core 1.23:In Progress by cherylj> <https://launchpad.net/bugs/1439447>
<katco> mgz: so i'm trying to test this in 1.23
<katco> mgz: and when i bootstrap i get a bootstrap failure
<natefinch> cherylj: my thought was basically that we should have a configuration that lets the user decide whether juju uses the proxy to connect to other machines in the environment or not.
<mgz> katco: as in, the machine doesn't come up?
<katco> mgz: "ERROR failed to bootstrap environment: Juju cannot bootstrap because no tools are available for your environment."
<mgz> katco: with --upload-tools?
<natefinch> cherylj: since it seems to me that it's likely that no matter which way we decide to do it, someone's going to want it to work the other way
<cherylj> natefinch: ha, too true
<katco> mgz: i knew it was something dumb
<katco> cherylj: looking forward to charming at the sprint. it would be nice if i actually got to work WITH juju more, and not just ON it :)
<cherylj> katco: me too!  It should be fun and I think alexisb is working on some actual prizes for the teams :D
<mgz> katco: ...that's just begging for a cheesy joke
<mgz> why do all the things we work with have silly names
<katco> mgz: please proceed :)
<mgz> well, you're clearly charming already?
<katco> LOLOLOLOL
<katco> 10 points england.
<katco> mgz: (et. al.) http://reviews.vapour.ws/r/1386/
<katco> mgz: and it would be super awesome if you could try china again
<katco> 1 line change btw
<redelmann> hi, is safe to deploy block-storage-broker to machine0??
<mgz> katco: lgtm, how to the multiple branches with go-amz work? change also needs to land on v4-unstable, or does v3 get merged up periodically?
<redelmann> create one instance just to manage credential is overkilling
<katco> mgz: i think dimiter merges changes to v3 up to v4 occasionally
<mgz> katco: I'll merge that locally and see
<katco> mgz: i don't know why we branch an unstable before we have unstable changes actually
<katco> mgz: seems like it creates a lot of work
<mgz> discourage people from landing features on an active verion I'm guessing
<mgz> er... s/active/stable/
<mgz> redelmann: that may be a better question for #juju - but gernally feel free to smoosh till something actually breaks
<redelmann> mgz, thank!!
<katco> mgz: and trunk: http://reviews.vapour.ws/r/1388/
<mgz> whoops, used wrong key
<mgz> well, it bootstrapped till the ssh step
<katco> :)
<katco> mgz: can i get a rq lgtm on http://reviews.vapour.ws/r/1388/?
<mgz> I was trying to make sure it works first, but this ssh step hates me ;_;
<katco> oh, no worries then
<katco> take your time
<mgz> I can ssh into the address fine, but juju refuses to for some reason
<katco> weird...
<mgz> but prints stuff out the first time I do on another console? bootstrap is too darn complicated these days
<natefinch> these days? :)
<mgz> get off my lawn!
<natefinch> haha
<mgz> okay, now it's running
<katco> haha
<mgz> I have no idea what was happening there
<mgz> katco: so, basically, api queries do now work
<mgz> and my china bootstrap is happily installing packages currently
<katco> o/ <--- tiny lighter you can't see
<natefinch> haha... I spent all day trying to debug an api connection problem and somehow forgot to look at the log for machine 0..... where it was evidently filling up with panics :/
<mgz> stamped the trunk dep update too
<mgz> joy
<katco> mgz: so to sum things up
<katco> mgz: i finally accomplished the first task i was given when i started canonical.
<katco> mgz: and it only took me about a year. :)
<mgz> https://pastebin.canonical.com/128953
<katco> woohoo!
<katco> that is great to see! :D
<mgz> hey, getting it done is getting it done :)
<mgz> katco: when the 1.23 branch goes through, I'll take the deb and set up a cloud-health job for the china region, hopefully later tonight
<katco> mgz: :D
<mgz> natefinch: juju running on az-cn is something we can talk about publically right (slightly late, wtv)
<natefinch> dhah
<natefinch> Â¯\_(ã)_/Â¯
<natefinch> honestly no clue
<alexisb> all, I have to go pick up kiddo realy from grandma's today, so I am will be out until james gets back from work
<alexisb> so everyone have a very happy holiday weekend!
<katco> alexisb: tc!
<katco> alexisb: habe a great weekend
<mup> Bug #1440199 was opened: api/uniter: Panic: stateSuite.TearDownTest <ci> <test-failure> <unit-tests> <juju-core:New> <https://launchpad.net/bugs/1440199>
<mup> Bug #1440205 was opened: cmd/juju: PANIC: addrelation_test.go:11: SetUpTest.pN39_github_com_juju_juju_cmd_juju.UserSuite <ci> <test-failure> <unit-tests> <juju-core:New> <https://launchpad.net/bugs/1440205>
<mup> Bug #1440209 was opened: juju action do doesn't accept non-string params on command line <juju-core:New> <https://launchpad.net/bugs/1440209>
<mup> Bug #1440213 was opened: worker/uniter: TestLeadership.pN51_github_com_juju_juju_worker_uniter_test.UniterSuite <juju-core:New> <https://launchpad.net/bugs/1440213>
<ericsnow> cmars: you have a minute to look over http://reviews.vapour.ws/r/1380/?
<ericsnow> cmars: I've switched it over to YAML and am using the new cmd.FileVar.Open method
<mup> Bug #1440213 changed: worker/uniter: TestLeadership.pN51_github_com_juju_juju_worker_uniter_test.UniterSuite <juju-core:New> <https://launchpad.net/bugs/1440213>
<mup> Bug #1440213 was opened: worker/uniter: TestLeadership.pN51_github_com_juju_juju_worker_uniter_test.UniterSuite <juju-core:New> <https://launchpad.net/bugs/1440213>
<mup> Bug #1440219 was opened: worker/uniter:TestLeadership.pN51_github_com_juju_juju_worker_uniter_test.UniterSuite <juju-core:New> <https://launchpad.net/bugs/1440219>
#juju-dev 2015-04-04
<natefinch> wonder if anyone's going to complain about my package named conv2state
<mup> Bug #1403151 changed: local provider stops bootstrapping: "Job is already running" <bootstrap> <local-provider> <juju-core:Expired> <https://launchpad.net/bugs/1403151>
 * marcoceppi_ isn't happy with juju
<marcoceppi_> http://paste.ubuntu.com/10737540/
<mup> Bug #1403151 was opened: local provider stops bootstrapping: "Job is already running" <bootstrap> <local-provider> <juju-core:Confirmed> <https://launchpad.net/bugs/1403151>
#juju-dev 2015-04-05
<mup> Bug #1440445 was opened: juju-run can not be invoked from within an action <juju-core:New> <https://launchpad.net/bugs/1440445>
<natefinch> exit
#juju-dev 2016-04-04
<davecheney> grrr, something is leaking /tmp/gui* turds
<axw> thumper: "Generally LGTM" = shipit? I've answered your question about newline
<axw> thanks for reviewing btw
<thumper> axw: yes
<axw> thumper: ta
<davecheney>         // If any post-MVP command suite enabled the flag, keep it.
<davecheney>         hasFeatureFlag := featureflag.Enabled(feature.PostNetCLIMVP)
<davecheney>         s.BaseSuite.SetUpTest(c)
<davecheney>         s.FakeJujuHomeSuite.SetUpTest(c)
<davecheney>         if hasFeatureFlag {
<davecheney>                 s.BaseSuite.SetFeatureFlags(feature.PostNetCLIMVP)
<davecheney>         }
<davecheney> wut
<davecheney> if the feature flag is enabled, then enable the feature flag
<davecheney> taht feel when you find the same bug copy pasted into several test suites
<natefinch> heh
<thumper> heh
<thumper> golint needs more smarts
<thumper> don't use underscores in Go names; type interface_ should be interface (golint)at line 13 col 6
<thumper> also complains about type_
<menn0> thumper: here's an important one: http://reviews.vapour.ws/r/4414/
 * thumper looks
<menn0> that was fun
 * menn0 hasn't been in the zone like that for a long time
<thumper> I'm sure will will like that one
<menn0> thumper: yes, he doesn't like these custom watchers
<menn0> thumper: and I now pretty much agree with him
<thumper> shipit
<menn0> thumper: cheers
<thumper-afk> bbl to catch europeans
<davecheney> fixing cleanup suite failures in the ec2 tests are making me sad
<davecheney> all day
<davecheney> no fucking idea what is broken
<davecheney> touch one thing, and magic values in other parts of the program dont' get overwritten
<davecheney> i hate patch value
<davecheney> it's tumor
<rogpeppe> davecheney: sorry about that
<rogpeppe> davecheney: it seemed like a good idea at the time
<davecheney> FFFFFFFFFFFFFFFFUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
<davecheney> Cleanup suite uses a package singleton
<davecheney> so you can have multiple CleanupSuites
<davecheney> pooped all the way through your suite construction
<davecheney> and they all COMPETE FOR THE SAME FUCKING SingleTON!
<davecheney> oh
<davecheney> no
<davecheney> i was wrong
<davecheney> i take that rant back
<davecheney> https://github.com/juju/testing/pull/94
<dooferlad> frobware, voidspace: hangout time
<voidspace> dooferlad: frobware: be there in 2 minutes!
<voidspace> dooferlad: omw
<voidspace> babbageclunk: I'll ping you shortly, just fending off some emails
<babbageclunk> ok cool
<voidspace> babbageclunk: I've pulled in the changes from use-boot-resources onto our maas2instance branch
<voidspace> babbageclunk: and am doing the rename
<babbageclunk> voidspace: the one Tim suggested? ok
<voidspace> babbageclunk: yeah, I think it's clearer
 * babbageclunk nods
<voidspace> babbageclunk: so the old maasInstance becomes maas1Instance and the interface becomes maasInstance
<voidspace> babbageclunk: we need to update to the latest version of gomaasapi and fix verifyCredentials to not hit Machines endpoint plus use the new gomaasapi error instead of the net/http one
<voidspace> babbageclunk: we can do that in a new branch though
<babbageclunk> voidspace: shall I make a start on the verifyCredentials change?
<voidspace> babbageclunk: sorry, missed your message
<voidspace> babbageclunk: sure you can look at errors too
<voidspace> babbageclunk: just grabbing coffee then I'm ready
<voidspace> babbageclunk: use-boot-resources landed
<voidspace> frobware: dooferlad: gah, updating to use the latest version of gomaasapi from thumper causes 23 test failures :-/
<voidspace> just venting
<voidspace> now bisecting to find what caused it
<frobware> voidspace: 23 test failures in juju or gomaasapi?
<perrito666> marcoceppi: hello, you had mentioned the name of a charm that implements update-status what was it?
<perrito666> also mgz ping
<babbageclunk> frobware: juju - it turned out to be an errors.Trace that was added in gomaasapi.
<babbageclunk> frobware: it meant adding errors.Cause in a few places.
<perrito666> anyone knows the exact version of lxd that works with master?
<voidspace> frobware: that was in juju
<voidspace> frobware: we found the cause, and fixed it
<voidspace> ah yes
<voidspace> babbageclunk: grabbing coffee
<voidspace> frobware: dooferlad: http://reviews.vapour.ws/r/4422/
<marcoceppi> perrito666: any of the bigdata charms
<perrito666> yup, already found tx a lot marcoceppi
<mup> Bug # changed: 1229903, 1292157, 1323446, 1365542, 1531954
<mup> Bug #972515 changed: Charm store needs search functionality <store> <juju-core:Invalid by niemeyer> <https://launchpad.net/bugs/972515>
<mup> Bug #972515 opened: Charm store needs search functionality <store> <juju-core:Invalid by niemeyer> <https://launchpad.net/bugs/972515>
<frobware> voidspace, sorry, sidetracked by a customer issue.
<frobware> dooferlad: would you mind obliging with voidspace's review ^^
<dooferlad> frobware: sure
<mup> Bug #972515 changed: Charm store needs search functionality <store> <juju-core:Invalid by niemeyer> <https://launchpad.net/bugs/972515>
<mup> Bug #1565826 opened: Unable to build juju2 from master <juju-core:New> <https://launchpad.net/bugs/1565826>
<mup> Bug #1565827 opened: TestTimeoutRun fails <ci> <test-failure> <juju-core:Incomplete> <juju-core feature-juju-run-action:Triaged> <https://launchpad.net/bugs/1565827>
<dooferlad> voidspace: got a +1
<voidspace> dooferlad: thanks!
<katco> natefinch: ericsnow: standup time
<alexisb> morning all
<alexisb> if anything needs attention from me today please ping me directly
<alexisb> crawling through email atm
<katco> alexisb: wb
<alexisb> thanks katco !
<mup> Bug #1565831 opened: unable to create authenticated client with maas 1.9 <bootstrap> <ci> <maas-provider> <juju-core:New> <juju-core maas2:Triaged> <https://launchpad.net/bugs/1565831>
<perrito666> returning from holidays my brain is all :"oh that english thing again, sure, lemme switch everything, in the meanwhile, talk like scooby doo"
<katco> perrito666: you did fine ;)
<perrito666> katco: when I just connected my brain was in "what are these people talking?" mode
<natefinch> perrito666: lol
<ericsnow> fwereade: thanks for the review; processing now
<voidspace> rick_h_: is the meeting on today?
<voidspace> frobware: dooferlad: is the meeting with rick_h_ on today?
<voidspace> I added babbageclunk as a guest
<natefinch> ericsnow: charmstore meeting
<mup> Bug #1565826 changed: Unable to build juju2 from master <juju-core:Invalid> <https://launchpad.net/bugs/1565826>
<rick_h_> voidspace: frobware babbageclunk sorry!
<voidspace> dooferlad: frobware: rick_h_ is here!
<katco> ericsnow: natefinch: so when we all have a moment, we should point new work, and i can give you update on projected completion of project to see if we're in trouble
<frobware> voidspace, rick_h_: omw
<ericsnow> katco: k
<frobware> rick_h_: sorry was clicking as you were speaking...
<rick_h_> frobware: all good
<mup> Bug #1565872 opened: As a juju user I would like to use docker on the local provider <adoption> <juju-core:New> <https://launchpad.net/bugs/1565872>
<alexisb> katco, ping
<katco> alexisb: pong
<mup> Bug #1565872 changed: Juju needs to support LXD profiles as a constraint <adoption> <juju-core:New> <https://launchpad.net/bugs/1565872>
<mup> Bug #1565872 opened: As a juju user I would like to use docker on the local provider <adoption> <juju-core:New> <https://launchpad.net/bugs/1565872>
<mup> Bug #1565880 opened: juju list-credentials --show-secrets does not do anything <docteam> <juju-core:New> <https://launchpad.net/bugs/1565880>
<natefinch> katco: done meeting with the charmstore guys, would like to get lunch if that's ok?
<katco> natefinch: that's fine
<katco> ericsnow: natefinch: we'll meet after
<ericsnow> katco: k
<perrito666> natefinch: just as a reference, re lxd, the version required for juju to work is the one in the ppa no the one in wily
<natefinch> perrito666: wait, I thought they reversed that
<perrito666> natefinch: so did I but juju says otherwise
<natefinch> perrito666: whatever, my lxd works, that's all I care about for now
<perrito666> natefinch: heh, mine too
<natefinch> perrito666: you're right, mines from the PPA
 * natefinch lunches
<voidspace> frobware: dooferlad: review if you get a chance http://reviews.vapour.ws/r/4425/
<natefinch> katco, ericsnow: ready when you guys are
<ericsnow> natefinch: k
<katco> natefinch: ericsnow: let's do it!
<marcoceppi> can I remove storage from a service?
<marcoceppi> why do we have a detaching hook, but no way to detach storage?
<marcoceppi> rick_h_: ^
<katco> urulama: rick_h_: hey, can you be authorized to a specific channel?
<urulama> yes
<urulama> acls are different for each channel
<natefinch> urulama: so a macaroon is channel-specific?
<mup> Bug #1503029 changed: juju plugins which exit > 0 report a subprocess ERROR <charmers> <juju-core:Fix Released by cmars> <https://launchpad.net/bugs/1503029>
<rick_h_> katco: yes, the idea being you give your tester folks access to dev channel
<katco> rick_h_: makes sense... suspicion confirmed ty :)
<urulama> natefinch: macaroon is not, but ACL is
<mup> Bug #1565943 opened: Can't bootstrap on VSphere <vsphere> <juju-core:Triaged> <https://launchpad.net/bugs/1565943>
<natefinch> urulama: so that's kinda weird... there's no channel parameter sent up when you get a charm archive.. I guess if that charm is in a public channel it'll just work? and if it's not it'll return an access denied error of some sort?
<urulama> natefinch: sure it does. check out https://api.jujucharms.com/charmstore/v5/~jorge/bundle/wiki-simple/archive?channel=unpublished vs https://api.jujucharms.com/charmstore/v5/~jorge/bundle/wiki-simple/archive
<natefinch> urulama: ahh, ok, I was looking at the docs, where it doesn't seem to indicate channels get passed to get the archives
<natefinch> urulama: https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md#get-idarchive
<urulama> natefinch: ha, ok, that needs some updating then
<natefinch> urulama: oh, I guess the blurb about channels at the top covers that, for any endpoint that takes an id can take a channel
<urulama> natefinch: works also on /meta endpoint
<natefinch> urulama: cool, thanks for clarifying
<urulama> np
<mbruzek> cherylj: Have you seen issues with deploying LXD issues with deploying xenial with the juju agent not finishing installation?
<katco> can anyone tell me why we aren't using logging here? https://github.com/juju/juju/blob/master/provider/common/bootstrap.go#L133
<mbruzek> ping anyone else working with LXD and xenial
<natefinch> katco: weird
<cherylj> mbruzek: I haven't tried it in a couple days
<cherylj> mbruzek: are you using lxd provider on a daily xenial image?
<mbruzek> cherylj: yes.
<mbruzek> Marco and I looked at the logs, we saw a modprobe fail.
<cherylj> mbruzek: k, let me provision a new xenial instance
<natefinch> katco: that's the output for the bootstrap command, to the CLI
<katco> natefinch: was just typing that
<katco> natefinch: got lost in a lot of --debug output so incorrectly seemed odd looking at backtraces
<natefinch> katco: it would still make sense to wrap it in a logger so you don't risk interleaved writes, but it's less likely on the client, I guess
<mbruzek> cherylj: I assert the agent will be stuck "Waiting for agent initialization to finish"
<mbruzek> after deploying a charm in xenial series
<mbruzek> Or at least that is what I am seeing
 * thumper dives into email
<cherylj> mbruzek: so it's also a xenial container you're deploying too?
<cherylj> mbruzek: is it a trusty controller?
<mbruzek> I was following this page: https://jujucharms.com/docs/devel/config-LXD
<mbruzek> That bootstrap command looks like I am requesting a xenial controller.
<mbruzek> cherylj: Once you get bootstrapped, deploy a xenial charm.
<mbruzek> juju deploy ubuntu --series xenial --force
<mbruzek> cherylj: ^
<cherylj> mbruzek: are you using beta3, or tip of master?
<mbruzek> beta3
<cherylj> omg, I'm deploying an openstack bundle on my vmaas and my laptop is screaming!
<cherylj> much lag, such slow
<mbruzek> cherylj: Oh
<mbruzek> cherylj: Yikes!
<mbruzek> cherylj: I just deployed the ubuntu charm on both trusty and xenial
<cherylj> k, my instance in aws is coming up :)
<mbruzek> LXD inside aws?
<cherylj> mbruzek: yeah, I like to spin up a clean xenial install when testing the lxd provider
<mbruzek> cherylj: so I got both of the charms to deploy completely but I see the error in the machine log that will never work on lxd
<mbruzek> The juju agent checks for kvm:  WARNING juju.cmd.jujud machine.go:760 determining kvm support: INFO: /dev/kvm does not exist
<mbruzek> Not there in the base cloud image
<mbruzek> HINT:   sudo modprobe kvm_intel
<mbruzek> cherylj: Then I see an error when the juju agent tries to do modprobe.
<mbruzek> modprobe: ERROR: ../libkmod/libkmod.c:556 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.0-15-generic/modules.dep.bin'
<mbruzek> : exit status 1
<mbruzek> no kvm containers possible
<cherylj> mbruzek: and that's causing the machine agent to barf?
<cherylj> mbruzek: that should be fine
<cherylj> bootstrapping now...
<mbruzek> cherylj: This time it does not appear that they barfed, both trusty and xenial seem OK now.
<cherylj> mbruzek: did you do anything differently?  or did just doing it a second time work?
<mbruzek> cherylj: why do you think that is OK? doing a modprobe within a LXD container is never going to work.
<cherylj> mbruzek: it's just a check to see if we have the capability of hosting KVMs
<cherylj> happens on all providers
<mbruzek> cherylj: but since LXD is sharing the kernel, a modprobe will not work in KVM. So the error is handled approprately?
<mbruzek> cherylj: s/KVM/LXD
<mbruzek> Because they share the kernel
<mbruzek> you can not insert any more mods
<mbruzek> cherylj: OK I was able to bootstrap, deploy and clean up correctly this time.
<cherylj> mbruzek: is there a better way to detect whether or not we can host KVMs?  (I'm not familiar with how we would do that)
<cherylj> mbruzek: and on this lxd instance issue - when the unit was waiting for agent initialization, did it have an instance ID yet?
<mbruzek> cherylj: Not that I am aware of, but perhaps we should check for LXD / containers first and if not in a container then check for kvm.
<mbruzek> cherylj: let me check my status
<mbruzek> cherylj: yes, I was even able to ssh to it, but the juju agent was dead
<cherylj> ah, I'm running into a different issue then
<cherylj> mbruzek: were both unit and machine agents dead?
<mbruzek> cherylj: I think it was the machine unit, and I was not able to destroy the controller
<cherylj> mbruzek: when you did destroy-controller, what was the error?  or did it just hang?
<mbruzek> cherylj: it went into an infinite loop
<cherylj> mbruzek: ah, in the "waiting for x service" blurb?
<mbruzek> I hit control-c and re ran it with --debug on
<mbruzek> Waiting on 2 models, 1 machine, 2 services
<mbruzek> cherylj: with debug:
<mbruzek> 2016-04-04 19:32:20 INFO cmd cmd.go:129 Waiting on 2 models, 1 machine, 2 services
<mbruzek> 2016-04-04 19:32:20 INFO cmd cmd.go:141 admin@local/default (alive), 1 service
<mbruzek> for ever, I could not --force it
<cherylj> mbruzek: this sounds familiar.  I think I've run into this before, but couldn't recreate
<mbruzek> cherylj: well kill the machine agent, and try to destroy the controller
<cherylj> mbruzek: you can manually terminate the controller machine, then run kill-controller
<mbruzek> But this time everything came down OK
<cherylj> ok
<cherylj> let me poke more, see if I can recreate
<mbruzek> cherylj: Yes I figured out the lxc commands to stop and delete the images
<mbruzek> But all the Juju stuff was left in the .local/share/juju
<cherylj> mbruzek: yeah, if you just kill the controller machine and run kill-controller, it will give up talking to the controller and then go to the provider to clean up
<cherylj> and then it will clean up your local cache information
<mbruzek> cherylj: OK I was not able to reproduce that, but I didn't know that worked
<cherylj> mbruzek: I wrote a lot of the destroy / kill controller code so I know ALL ITS SECRETS
<mbruzek> cherylj: OK well thank you for the information
<cherylj> mbruzek: there's also a bug open to provide a way to clean up stale controller information
<cherylj> It'd be super awesome if we could get that done for 2.0
<mbruzek> cherylj: OK so you were able to get a xenial ubuntu and everything looks good?
<cherylj> mbruzek: no, I'm running into a different bug
<cherylj> mbruzek: what I see is that on a new xenial install, deploying in lxd doesn't even get an instance associated with the service
<mbruzek> cherylj: so let me understand, you are using amazon to run a local LXD provider?
<cherylj> mbruzek: yes, I manually deploy a xenial machine, install juju2 on it, and bootstrap lxd
<mbruzek> cherylj: OK, I just wanted to understand the workflow
<cherylj> mbruzek: :)  I do it to make sure it's clean and I haven't messed things up some how
<mbruzek> that is a good idea!
<cherylj> mbruzek: if you haven't seen it before, I use the cloud image finder to quickly launch a particular instance in a particular region:  https://cloud-images.ubuntu.com/locator/daily/
<mup> Bug #1564622 changed: Suggest juju1 upon first use of juju2 if there is an existing JUJU_HOME dir <juju-release-support> <juju-core:Triaged> <https://launchpad.net/bugs/1564622>
<mup> Bug #1565991 opened: juju commands don't detect a fresh juju 1.X user and helpfully tell them where to find juju 1.X <juju-core:Triaged> <https://launchpad.net/bugs/1565991>
<mbruzek> cherylj: Thanks for the link
<mbruzek> cherylj: which type do you pick, I imagine the ssd ones are more expensive
<cherylj> mbruzek: I just go with the ssd ones
<voidspace> thumper: ping
<thumper> voidspace: hey
<voidspace> thumper: morning
<voidspace> thumper: I just wanted to say thanks
<thumper> for?
<voidspace> thumper: your changes to gomaasapi broke 24 tests and it took us nearly two hours to work out why
<voidspace> ;-)
<voidspace> thumper: we fixed it, but I do wonder if we ought to change it (which is why I'm really pinging)
<thumper> wont make that mistake again then will you?
<voidspace> hehe
<voidspace> thumper: you added an errors.Trace to the error the client returns
<thumper> gomaasapi.GetServerError(err error) (ServerError, bool)
<voidspace> thumper: which means that anything that attempts to cast to a ServerError fails
<voidspace> sure
<thumper> I added that for that exact reason
<voidspace> but it's backwards incompatible
<thumper> eh...
<thumper> yeah
<thumper> ish
<thumper> a bit
<thumper> not heaps
<voidspace> well, it broke 23 tests on master...
<voidspace> so yeah - ish
<thumper> you're welcome
<voidspace> :-D
<voidspace> it's *better*
<voidspace> maybe we just see if anyone else complains
<voidspace> gomaasapi does have users
<voidspace> not many probably but some :-)
<voidspace> (I mean the change is better)
<voidspace> anyway, I'm off to bed
<voidspace> well - watch TV anyway
<voidspace> thumper: just thought as you were around I'd hassle you :-)
<voidspace> thumper: have a good day
<thumper> :)
<mup> Bug # opened: 1564157, 1564163, 1564165, 1566011, 1566014
<mup> Bug # changed: 1564157, 1564163, 1564165, 1566011, 1566014
<mup> Bug #1565880 changed: juju list-credentials --show-secrets does not do anything <docteam> <juju-release-support> <juju-core:Triaged> <https://launchpad.net/bugs/1565880>
<mup> Bug # opened: 1564157, 1564163, 1564165, 1564168, 1564670, 1566011, 1566014, 1566023, 1566024
<menn0-afk> thumper: PR #20 LGTM. It's a bit hard to read the #21 b/c it builds on it so let me know when you've merged #20.
<thumper> menn0: ack, will land, and update pr
<mup> Bug #1566044 opened: list-models and show-model should represent similar keys for controller model <juju-core:New> <https://launchpad.net/bugs/1566044>
<mup> Bug #1566044 changed: list-models and show-model should represent similar keys for controller model <juju-core:New> <https://launchpad.net/bugs/1566044>
<mup> Bug #1566044 opened: list-models and show-model should represent similar keys for controller model <juju-core:New> <https://launchpad.net/bugs/1566044>
<perrito666> axw: anastasiamac is standup still happening?
<axw> perrito666: yes, omw
<anastasiamac> m here
<davecheney> # github.com/juju/juju/provider/ec2_test
<davecheney> local_test.go:93: ambiguous selector t.AddCleanup
<davecheney> FATAL: command "test" failed: exit status 2
<davecheney> pungent smell that CleanupSuite is present more than once in this suite
<perrito666> davecheney: odd, although I found someone had refactored something upstream last time I was nearby
#juju-dev 2016-04-05
<davecheney> does anyone know where the code that fakes out the simple streams is ?
<davecheney> [LOG] 0:00.023 DEBUG juju.environs.simplestreams read metadata index at "file:///tmp/check-6283502795135149108/15/tools/streams/v1/index2.sjson"
<davecheney> ^ the one that generates this local file
<davecheney> for some reason the ec2 tests are different to all the other providers
<thumper> nope
<thumper> not me
<anastasiamac> davecheney: ToolsFixture?..
<davecheney> anastasiamac: thanks
<davecheney> i'll try to figure out where that is hooked up
<davecheney> and why it is special in the ec2 provider tests
<anastasiamac> davecheney: i think test roundtripper is what delivers this stuff in tests :D
<anastasiamac> davecheney: have fun
<davecheney> oh boy, i think i've crackd it
<davecheney> fixed the ec2 test
<davecheney> imagetesting "github.com/juju/juju/environs/imagemetadata/testing" is the magic import
<davecheney> menn0: anastasiamac thumper https://github.com/juju/juju/pull/4957
<davecheney> could I get a second look
<davecheney> this change is bigger than it started because upgrading the testing dependency hit a lot of places
<davecheney> i'm 90% confident that I've backported all the AddCleanup fixes from master
<davecheney> i'd be more confident, but the local tests haven't finished running for me
<natefinch> man that embedded test suite stuff is wicked error prone
<thumper> davecheney: hmm... what changed with the AddSuiteCleanup code?
<thumper> I have vague recollections...
<natefinch> thumper: I believe it's just that there's no more separation between test cleanup and suite cleanup. AddCleanup does the right thing depending on when it's called
<natefinch> thumper: since we found there were placing we were calling the wrong one, and it was causing problems.
 * thumper nods
<natefinch> thumper: https://github.com/juju/testing/blob/master/cleanup.go#L59
<davecheney> thumper: there are a few changes here
<davecheney> 1. updaed the testing dependency to spot suite mistakes
<davecheney> 2. updated testing itself to remove the deprecated AddSuiteCleanup method
<davecheney> this is already comitted to master
<davecheney> I backported this fix to 1.25
<davecheney> then adjusted the code to avoid calling AddSuiteCleanup
<davecheney> and backported all of jam's fixes for various suite failures to 1.25
<thumper> davecheney: lgtm
<mup> Bug #1566024 changed: The juju GCE error message references the wrong key name <juju-core:New> <https://launchpad.net/bugs/1566024>
 * thumper grumbles
<mup> Bug #1564163 changed: environment name in credentials file is not a tag <juju-core:Invalid> <juju-core (Ubuntu):Invalid> <https://launchpad.net/bugs/1564163>
<mup> Bug #1564165 changed: Credentials file displays unhelpful message for syntax errors <juju-core:New> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1564165>
<mup> Bug #1566130 opened: awaiting error resolution for "install" hook <juju-core:Triaged> <https://launchpad.net/bugs/1566130>
<davecheney> func (s *UpgradeSuite) getAptCmds() []*exec.Cmd { s.aptMutex.Lock() defer s.aptMutex.Unlock() return s.aptCmds
<davecheney> }
<davecheney> ^ note, doesn't actaully prevent a race
<davecheney> unless you're only appending to that slice
<davecheney> , maybe
<menn0> anastasiamac: review please http://reviews.vapour.ws/r/4431/
<anastasiamac> menn0: looking \o/
<davecheney> dummy needs some love http://reviews.vapour.ws/r/4433/
<rogpeppe> davecheney: FWIW I think the "p := &providerInstance" thing was just to make it more convenient to use. There's nothing wrong about it per se.
<rogpeppe> anyone know if dimitern is gonna be around today?
<frobware> rogpeppe: tomorrow
<rogpeppe> frobware: i'm interested to inquire about an apparent networking bug with multiple models in a controller. do you know who else might know about the networking stuff?
<frobware> rogpeppe: try us "me, dooferlad, voidspace"
<rogpeppe> frobware, dooferlad, voidspace: ok, so we got a controller to start an instance in another model (with different provider creds) yesterday, and the machine was network-isolated from the controller
<rogpeppe> frobware, dooferlad, voidspace: i.e. it couldn't connect to the API server or ping the controller machine
<rogpeppe> frobware, dooferlad, voidspace: this was in juju 1.25.4
<rogpeppe> frobware, dooferlad, voidspace: i was hoping this might be a known issue that's been fixed in 2.0
<frobware> rogpeppe: when you network-isolated, by how much? at the risk of stating the obvious, no network connectivity ...
<rogpeppe> frobware: we could ssh to it
<rogpeppe> frobware: (only directly, but that's another bug :-\)
<rogpeppe> frobware: i didn't test whether it could dial out to the outside world
<frobware> rogpeppe: still a bit confused. is one instance running 1.25?
<rogpeppe> frobware: everything was running 1.25
<frobware> rogpeppe: otp, back in a bit...
<dooferlad> voidspace, fwereade, jam: hangout?
<voidspace> dooferlad: omw
<voidspace> dooferlad: frobware: review please http://reviews.vapour.ws/r/4425/
<fwereade> http://reviews.vapour.ws/r/4403/diff/1/?file=324207#file324207line52
<fwereade> http://reviews.vapour.ws/r/4342/
<voidspace> babbageclunk: hey, hi
<babbageclunk> voidspace: hi!
<frobware> babbageclunk: should be in the office around 10am tomorrow... trains permitting.
<babbageclunk> voidspace: hmm, my irc connection died because I've dropped off ethernet, and the wifi is a bit spotty in the office.
<voidspace> babbageclunk: ok
<babbageclunk> frobware: great! I'll be in well before then.
<voidspace> frobware: so, will you and babbageclunk be pairing tomorrow? (and the rest of the week?)
<voidspace> frobware: sounds like a good plan
<babbageclunk> voidspace: oh nice, restarting network-manager doesn't actually drop the connection.
<frobware> babbageclunk, voidspace: I guess... I think there's some general stuff to go over. There's also the bug I'm looking at. And there's a couple of bugs to shift to dimiter. But, yes, in principle...
<voidspace> ah yes, dimiter returns tomorrow - yay
<babbageclunk> voidspace, frobware: we should try to get to a point where there are parallelisable bits of work to do on the maas provider.
<frobware> babbageclunk: yep. and I'm going to need an intro to what's been done too. :)
<voidspace> babbageclunk: frobware: it's easily parallelisable now
<voidspace> babbageclunk: frobware: we need Instances, AvailabilityZones and acquireNode implementing for MAAS 2
<voidspace> those are the next steps, all can be tackled separately and all already have support in gomaasapi
<voidspace> we have the basics of test infrastructure in place too
<voidspace> frobware: babbageclunk *should* be able to show you what we've done
<babbageclunk> voidspace, frobware: I can have a go
<voidspace> frobware: it's pretty straightforward - the diff of maas2 against master isn't too huge and shows it
<voidspace> babbageclunk: frobware: we could topic it in standup
<voidspace> or just a hangout
<voidspace> it's actually it took us a week to get here, but the code isn't hard to understand I don't think
<voidspace> nor is the path ahead
 * frobware needs to sort his craptop out...
<voidspace> :-)
<voidspace> oh, we'll need Spaces too
<voidspace> we also have the endpoint for that already written
<frobware> dooferlad: can I steal some of your time? h/w too. :)
<dooferlad> frobware: sure. 2 mins.
<frobware> dooferlad: 5. coffee.
 * fwereade amusing typo: synchorinses for synchronises
<frobware> dooferlad: ready whenever works for you. In standup HO.
<mup> Bug #1566237 opened: juju ssh doesn't work with multiple models <juju-core:New> <https://launchpad.net/bugs/1566237>
<jam> frobware: were you investigating bug #1565461
<mup> Bug #1565461: deploy Ubuntu into an LXD container failed on Xenial <lxd> <juju-core:Triaged> <juju-core maas-spaces-multi-nic-containers:New> <juju-core maas-spaces-multi-nic-containers-with-master:New> <https://launchpad.net/bugs/1565461>
<jam> ?
<frobware> jam: not actively. sidetracked by bug #1565644
<frobware> jam: but I added a comment to bug #1565461 just in case it was significant.
<mup> Bug #1565461: deploy Ubuntu into an LXD container failed on Xenial <lxd> <juju-core:Triaged> <juju-core maas-spaces-multi-nic-containers:New> <juju-core maas-spaces-multi-nic-containers-with-master:New> <https://launchpad.net/bugs/1565461>
<jam> k
<frobware> jam: I haven't looked to see if the failure on xenial is related to juju not creating any network devices for the container
<jam> frobware: fwiw I saw it on Trusty as long as you --upload-tools from Master.
<jam> frobware: it might be the same bug, I didn't get a ip addr show from inside the container when I tested last.
<frobware> jam: and there did you take a look at the LXD network profile that gets created?
<jam> frobware: I'll go bootstrap now and do some debugging. I'll let you know when it is up and running.
<frobware> jam: first pass validation since we did the multi nic support would be to check the LXD profile
<jam> frobware: well I would be testing but it seems jujucharms.com is broken right now.
<frobware> jam: do you need a charm? can you just add-machine lxd:0 in this case?
<jam> frobware: fair point
<voidspace> fwereade: ping
<voidspace> fwereade: we're fixing a theoretical panic case in maasEnviron.Instances (that we hit in testing our new implementation for MAAS 2)
<voidspace> fwereade: in the case that MAAS returns instances with different ids to the ones you requested you can get a slice of nil instances back
<voidspace> fwereade: because the code that builds the map of id -> instance doesn't check the id is actually in the map when fetching them back
<voidspace> fwereade: fixing that to return ErrPartialInstances when an id you requested isn't returned causes an existing test to fail
<voidspace> fwereade: because it assumes that even in the case of an error return that the returned partial results will be present
<voidspace> hmm... we've found a better way that makes this a non issue I think
<mup> Bug #1566268 opened: poor error when "jujucharms.com" is down <error-reporting> <observability> <juju-core:Triaged> <https://launchpad.net/bugs/1566268>
<mup> Bug #1566271 opened: It is hard to open juju API if you're not implementing a ModelCommand <juju-core:New> <https://launchpad.net/bugs/1566271>
<jam> frobware: so I see a "juju-machine-0-lxd-0-network' profile that contains nothing
<jam> the machine itself seems to only have a "lo"
<jam> but somehow it came up correctly...
<jam> frobware: ok, no it did not come up correctly
<jam> machine-status is "running" but juju-status is "pending"
<frobware> jam: can you try bouncing the node and adding a new container
<jam> frobware: so it does seem to be bug #1564395
<mup> Bug #1564395: newly created LXD container has zero network devices <bootstrap> <network> <juju-core:Triaged by frobware> <https://launchpad.net/bugs/1564395>
<jam> frobware: restarting the host or just the container?
<frobware> jam: yep, was suspicious (to me at least).
<frobware> jam: just the node hosting the container
<frobware> jam: the first container will still fail but I'm expecting subsequent containers to work correctly
<jam> frobware: are we not detecting networking correctly without a reboot?
<frobware> jam: bug introduced post March 21st... is as far as I got.
<frobware> jam: sometimes... (rarely) we get eth0 added to the container. so, a timing issue IMO
<jam> frobware: juju-machine-0-lxd-1-network is *also* empty
<frobware> jam: sigh
<frobware> jam: let me try again
<jam> frobware: this is with a Trusty controller, but we'll want it to work there ,too.
<frobware> jam: my tip commit is probably behind master (a084e423e0586d2348963e6ba91aa3d2454997dd)
<frobware> jam: any chance you could validate against xenial?
<jam> 23 commits
<jam> frobware: sure
<jam> frobware: any reason to keep trusty around?
<frobware> jam: not for me. :)
<frobware> jam: just bootstrapping, back in 10
<voidspace> jam: who does babbageclunk ping to get added to the juju team calendar?
<jam> frobware: bootstrap is the new complie step?
<jam> voidspace: I believe all team leads should be admin, but I can go do i
<jam> it
<voidspace> jam: thanks!
<jam> voidspace: he should be able to add items now
<jam> have babbageclunk check to make sure I did it right
<frobware> jam: heh, I bootstrapped to a node which ... will fail ... because that's configured to try and fix another issue ...
<jam> apt-get is a bit slow today
<frobware> jam: swings. roundabouts. repeat.
<frobware> jam: and then I run into: ERROR some agents have not upgraded to the current model version 2.0-beta4.1: machine-0-lxd-0
<frobware> jam: wow, today. ffs.
<jam> not everything got to the broken version so you can't upgrade to the fixed one...
<jam> frobware: maybe you can 'juju destroy-machine --force'
<jam> ?
<frobware> jam: I upgraded to MAAS 1.9.1 and no DNS running there anymore...
<jam> frobware: no DNS at all? or they just moved where DNS is running?
<frobware> jam: not sure if my 1.9.0 > .1 borked maas-dns. Either way named is not running anymore.
<frobware> jam: could be because I futzed with my MTU setting to try and fix bug #1565644
<jam> frobware: xenial is up and running
<jam> trying now
<frobware> jam: lxd-images is no longer a thing... ?
<jam> frobware: no, "lxc image ubuntu:"
<jam> frobware: but juju should handle those for you
<jam> but you can do"
<jam> "lxc launch ubuntu:trusty"
<jam> it reads simplestreams directly
<jam> frobware: on xenial juju-machine-0-lxd-0-network is empty
<jam> trying reboot and 0/lxd/1
<frobware> fingers crossed for at least one thing to kind-of work today.
<frobware> I have too many things which are broken.
<fwereade> voidspace, sorry!
<fwereade> voidspace, I think ErrPartialInstances is a bit different
<frobware> jam: whee... error: Get https://cloud-images.ubuntu.com ....... i/o timeout.
<fwereade> voidspace, if maas tells us extra instances, that is annoying, but I think the reactions there are either to ignore or to go nuclear -- maas is making no sense, give back no instances and ErrMaasInsane
<jam> frobware: juju-machine-0-lxd-0 is shown as being on the lxdbr0 bridge
<jam> with an address
<fwereade> voidspace, if we ignore that, which is reasonable, we return the instances we got (so long as we got at least one we asked for) and ErrPartialInstances if any are missing
<frobware> jam: is it possible my current tip is no longer compatible with lxd as installed on xenial?
<jam> frobware: well, the agent still didn't come up for 0-lxd-0
<jam> and cloud-init-output.log looks very truncated
<jam> checking if 0-lxd-1 comes up
<frobware> jam: I cannot import any images
<jam> frobware: 0-lxd-1 comes up with the *same* IPV4 address as 0-lxd-0 not a great sign
<jam> 10.0.3.1 for both
<frobware> jam: well, I knew it was a bug... just not working on it atm... :(
<jam> frobware: juju-machine-0-lxd-1-network is also empty
<frobware> jam: trying with tip of master now
<frobware> jam: my maas named conf had duplicate entries
<frobware> jam: (not sure how!)
<voidspace> fwereade: I think we've fixed it in a sane way
<fwereade> voidspace, cool
<voidspace> fwereade: I like the idea of ErrMaasInsane
<voidspace> fwereade: although the tempation would be just to return that for everything
<fwereade> haha
<voidspace> fwereade: on the maas2 work bootstrap now gets into StartInstance, which is nice tangible progress
<voidspace> frobware: dooferlad: if you get a chance we now have two PR ready: http://reviews.vapour.ws/r/4425/
<voidspace> frobware: dooferlad: plus one that didn't make it onto reviewboard (yet?) https://github.com/juju/juju/pull/4995
<voidspace> ericsnow: this PR hasn't appeared on reviewboard: https://github.com/juju/juju/pull/4995
<frobware> jam: so I'm not going entirely bonkers: http://pastebin.ubuntu.com/15629100/
<frobware> jam: but there's a new issue now. /e/n/i in the container is not what it used to be.
<voidspace> frobware: you coming to the maas meeting?
<frobware> jam: http://pastebin.ubuntu.com/15629133/
<frobware> voidspace: nope. too much entropy.
<voidspace> frobware: sure
<frobware> voidspace: I can if needed, but I guess you'll have more to discuss anyway
<voidspace> frobware: we're fine
<voidspace> frobware: and we're done
<voidspace> babbageclunk: so, lunch
<frobware> jam: https://bugs.launchpad.net/juju-core/+bug/1564395/comments/3
<mup> Bug #1564395: newly created LXD container has zero network devices <bootstrap> <network> <juju-core:Triaged by frobware> <https://launchpad.net/bugs/1564395>
<mup> Bug #1566303 opened: uniterV0Suite.TearDownTest: The handle is invalid <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1566303>
<fwereade> voidspace, oops, missed that too: awesome!
<perrito666> aghh this kill controller thing is ridiculous
<rick_h_> perrito666: what now?
<perrito666> I bootstraped an lxd controller yesterday and now I cannot destroy it, and I am pretty sure nothing changed betweenyesterday and today
<rick_h_> perrito666: :/
 * perrito666 takes the killbyhand hammer
<perrito666> its a good thing I actually love lxd so I dont mind playing with it
<jcastro_> I had to kill the containers from underneath it
<perrito666> apparently the lxc container is not there
<jcastro_> and then blow away most of ~.local/config/juju
<perrito666> but juju thinks otherwise
<jcastro_> yeah, look in ~/.local/config/juju
<jcastro_> I removed everything but my creds from there and that got juju to stop lying to itself
<perrito666> jcastro_: that IS a bug though
<jcastro_> oh I agree 100%
<perrito666> that is exactly what kill controller should do
<perrito666> I am worried this goes beyond the current ongoing discussion about what is not working in kill controller
<mbruzek> lxc list | grep -E 'juju-(.*)-machine(.*)' | awk '{print $2}' | xargs lxc stop
<perrito666> I am extra worried that this did not blow in someone' s face in CI
<perrito666> mbruzek: lxc says no running container
<mbruzek> lxc list | grep -E 'juju-(.*)-machine(.*)' | awk '{print $2}' | xargs lxc delete
<perrito666> its clearly juju
<mbruzek> perrito666: Then juju needs to be more forceful when I tell it to KILL
<mbruzek> perrito666: This happened to me yesterday which is why I had those commands in my history.
<mbruzek> perrito666: I could not kill-controller it just sat there in a loop
<perrito666> mbruzek: tx anyway, I suspect this are going to be useful to me soon
<mbruzek> perrito666: I also helped out one of our partners (IBM) who was having problems with the local lxd provider
<mbruzek> yesterday
<katco> perrito666: mbruzek: if it's not listed here, please file a bug: https://blueprints.launchpad.net/juju-core/+spec/charmer-experience-lxd-provider
<jcastro_> oooh, can we add a bug to this?
<mbruzek> katco: https://bugs.launchpad.net/juju-core/+bug/1565872
<mup> Bug #1565872: Juju needs to support LXD profiles as a constraint <adoption> <juju-release-support> <lxd> <juju-core:Triaged> <https://launchpad.net/bugs/1565872>
<katco> jcastro: sure... do you have a "link a bug report" button or is that just the owner?
<jcastro_> I appear to not have a link button
<jcastro_> but it's the bug mbruzek just linked
<katco> jcastro_: k np just toss me the #
<katco> mbruzek: linked your bug
<mbruzek> Thanks katco
<cherylj> heh, it feels like we need a --force flag for kill-controller :)
<cherylj> I've also hit the "kill spins in a loop" error.
<natefinch> heh
<cherylj> maybe if it doesn't complete in a certain amount of time, it falls back to just destroying through the provider
<cherylj> ?
<perrito666> well that is actually what it should be doing
<cherylj> perrito666: yeah, I'm going to open a bug
<lazyPower> not to dogpile on, it appears kill-controller is also not removing storage, nor is it removing units which had storage volumes attached at the time of issuing kill-controller. Working on getting a bug for you about this now
<perrito666> bbl
<mup> Bug #1565991 changed: juju commands don't detect a fresh juju 1.X user and helpfully tell them where to find juju 1.X <juju-core:Triaged> <https://launchpad.net/bugs/1565991>
<mup> Bug #1564622 opened: Suggest juju1 upon first use of juju2 if there is an existing JUJU_HOME dir <juju-release-support> <juju-core:Triaged> <https://launchpad.net/bugs/1564622>
<mup> Bug #1566332 opened: help text for juju remove-credential needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1566332>
<mup> Bug #1566339 opened: `juju run` needs a --all-machine, --all-service, --all-unit <juju> <machine> <run> <juju-core:New> <https://launchpad.net/bugs/1566339>
<cherylj> hey jam, I see you made this statement in a PR:  "We're currently broken on AWS which makes it hard for me to evaluate this" - what's going on with AWS?
<frobware> cherylj: at a guess, related to https://launchpad.net/bugs/1564395
<mup> Bug #1564395: newly created LXD container has zero network devices <bootstrap> <network> <juju-core:Triaged by frobware> <https://launchpad.net/bugs/1564395>
<cherylj> hmm, fun
<frobware> cherylj: the trouble is nobody working on it. :(
<frobware> cherylj: although I was but now preempted
<katco> frobware: alas, we are interrupt driven :|
<natefinch> katco: crap, gotta help my wife with our accountant.... she's there now and needs my help.  I'll almost certainly miss the standup.  Sorry
<natefinch> katco: I should be back by 15-30 minutes after standup is scheduled to start, though.
<katco> natefinch: let's talk when you get back
<natefinch> katco: yep
<mup> Bug #1566345 opened: kill-controller leaves instances with storage behind <juju-core:New> <https://launchpad.net/bugs/1566345>
<mup> Bug #1566345 changed: kill-controller leaves instances with storage behind <juju-core:New> <https://launchpad.net/bugs/1566345>
<frobware> dooferlad: ping - any chance of using one of your NUCs? If not I'll look elsewhere
<rick_h_> frobware: you need a nuc? what else do you need around it?
<rick_h_> frobware: there's two free in http://maas.jujugui.org/MAAS/#/nodes
<frobware> rick_h_: ability to change the MTU for jumbo frames
<frobware> rick_h_: might affect the rest of your network :-D
<frobware> rick_h_: needs two physical NICs
<babbageclunk> jam: yup, adding me on the calendar worked - thanks!
<frobware> rick_h_: can I grab an account on there anyway?
<mup> Bug #1566345 opened: kill-controller leaves instances with storage behind <juju-core:New> <https://launchpad.net/bugs/1566345>
<rick_h_> frobware: sure thing, what's your LP username
<frobware> rick_h_: frobware
<frobware> rick_h_: if it has two NICs I'll try anyway
<rick_h_> frobware: yes
<rick_h_> frobware: sec
<cherylj> hey lazyPower, regarding bug #1566345 - are you getting errors that your rate limit has been exceeded?
<mup> Bug #1566345: kill-controller leaves instances with storage behind <juju-core:New> <https://launchpad.net/bugs/1566345>
<lazyPower> cherylj - negative, i think what happened is the volumes weren't unmounted during the storage-detaching hook (we haven't implemented this) and everything was left behind
<cherylj> lazyPower: I'm wondering if your bug is another side effect of bug 1537620
<lazyPower> but no log errata regarding rate limits
<mup> Bug #1537620: ec2: destroy-controller blows the rate limit trying to delete security group - can leave instances around <2.0-count> <ci> <jujuqa> <juju-core:Triaged> <https://launchpad.net/bugs/1537620>
<cherylj> lazyPower: ah, ok
<katco> ericsnow: standup time
<voidspace> natefinch-taxes: are you here today, or are you too heavily taxed?
<voidspace> natefinch-taxes: you're OCR :-)
<katco> voidspace: he's here
<katco> voidspace: will be back momentarily
<voidspace> katco: cool, thanks
<voidspace> ericsnow: ping
<ericsnow> voidspace: hey
<ericsnow> voidspace: thanks for getting that poster stuff sorted out
<voidspace> ericsnow: no problem
<voidspace> ericsnow: we have a PR that didn't make it's way onto reviewboard
<voidspace> ericsnow: https://github.com/juju/juju/pull/4995
<ericsnow> voidspace: k
<voidspace> ericsnow: looks like you're lumbered with reviewboard issues for life... :-)
<ericsnow> voidspace: mwahaha
<mup> Bug #1566362 opened: help text for juju add-credential needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1566362>
<mup> Bug #1566367 opened: help text for juju upgrade-juju needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1566367>
<mup> Bug #1566369 opened: help text for juju ssh needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1566369>
<cherylj> frankban: you still around?
<mgz> voidspace: that one is almost certainly just that the guy isn't in the right github group
<voidspace> mgz: I don't think so
<voidspace> mgz: his other PR worked fine
<frankban> cherylj: I am, on call
<mgz> hm, I take it back, is in hackers and did set public
<mgz> eric's up then :P
<cherylj> frankban: np, ping me when you get a minute, please :)
<frankban> cherylj: sure
<cherylj> thanks!
<cherylj> ericsnow: thanks for fixing bug 1560201!
<mup> Bug #1560201: The Client.WatchAll API command never responds when the model has no machines <2.0-count> <juju-release-support> <kanban-cross-team> <landscape> <juju-core:Fix Committed by ericsnowcurrently> <https://launchpad.net/bugs/1560201>
<ericsnow> cherylj: glad to do it
<natefinch> katco: back
<katco> natefinch: moonstone
<natefinch> katco: going
<frankban> cherylj: I am available now
<cherylj> hey frankban, I saw that the embedded-gui branch had a blessed CI run.  Are there things in there you want to get merged into master?
<cherylj> is it ready?
<frankban> cherylj: we already merged what's ready there, and we'll need to merge more form there before eow
<fwereade> hmm, it seems the cat has learned to unlock the front door from inside on her own
<fwereade> this may be an actual problem
<cherylj> frankban: sorry, I'm in a stand up, so my responses are slow.   Are you done with what you need to put into embedded-gui?
<ericsnow> voidspace: is https://github.com/juju/juju/pull/4995 based correctly? (will merge correctly)
<frankban> cherylj: no, we are working this week on remaining stuff (basically retrieving the GUI from simplestreams)
<ericsnow> voidspace: sometimes an out-of-sync base can cause RB trouble
<cherylj> frankban: ok, thanks.
<cherylj> frankban: I have a bundle bug question too
<cherylj> frankban: can you take a quick look at bug 1564057?
<mup> Bug #1564057: juju2: Charms fail with series mismatch when deployed to containers in bundle <juju-core:Triaged> <https://launchpad.net/bugs/1564057>
<cherylj> frankban: I took an initial stab at fixing, but not sure if that's the right fix
<cherylj> frankban: it seems weird to require "series" in the charm stanza when it could be implied from the charm store url?
<frankban> cherylj: looking
<rogpeppe> dooferlad, frobware: i've managed to reproduce the bug i talked about this morning
<voidspace> rogpeppe: our team hasn't touched the code around multiple models
<rogpeppe> voidspace: ok, but this is really a networking issue
<voidspace> rogpeppe: everything juju does involves networking :-)
<rogpeppe> voidspace: on at least one ec2 region, if you create a model with different aws creds, the instances are network-isolated from the controller
<frobware> rogpeppe: otp (sorry!)
<voidspace> rogpeppe: ah right - so the controller needs to use the public ips to talk to the controller then
<voidspace> rogpeppe: because the model *is* network isolated from the controller
<rogpeppe> voidspace: no, it doesn't seem to be able to use public ips either
<voidspace> rogpeppe: doesn't seem to be *able* to use them (it tries and they don't work)? weird
<rogpeppe> voidspace: how are the units meant to talk to the API server then?
<voidspace> rogpeppe: two different aws accounts *are* network isolated
<voidspace> rogpeppe: if you're using the same meta account you might be able to setup routing between them
<rogpeppe> voidspace: so why does it work in us-east?
<voidspace> but the public ips should still work
<rogpeppe> voidspace: we're relying on model units being able to talk to the controller API server
<rogpeppe> voidspace: i'll just check
<frankban> cherylj: I agree we should infer the series from the charm stanza, from the URL, fallback to series, fallback to global bundle one I guess
<frankban> cherylj: that's a good bug
<cherylj> frankban: okay, so passing it into the addMachineParams part looked ok?
<rogpeppe> voidspace: the env got torn down, just trying again
<ericsnow> natefinch: which are the patches you need reviewed still?
<frankban> cherylj: let me check the diff
<voidspace> rogpeppe: did this used to work? If it never worked I still say it's a bug in the multiple model implementation. :-)
<rogpeppe> voidspace: i'm not gonna argue who's responsible
<voidspace> rogpeppe: if we've broken it then fair enough. (Like everyone else we have a lot on our plate)
<voidspace> rogpeppe: I just don't think we have capacity to take this on.
<rogpeppe> voidspace: neither you nor anyone else
<voidspace> rogpeppe: I'll help in any way I can with diagnosis
<voidspace> rogpeppe: sure
<rogpeppe> voidspace: but it's a critical bug AFAICS
<voidspace> rogpeppe: in which case we have to look at who *is* responsible.
<voidspace> rogpeppe: you may well be right :-(
<rogpeppe> voidspace: i'm not pointing the finger at you - i just know that your team's been doing some of the network stuff
<natefinch> ericsnow: anything on reviewboard withouit reviews.... hold off on the long lived macaroon one, though, since that's still WIP
<voidspace> rogpeppe: fair enough
<natefinch> ericsnow: (just marked it as such)
<voidspace> rogpeppe: just a bit touchy about workload right now!
<rogpeppe> voidspace: so thought i might get a useful answer (which I have, thanks!)
<rogpeppe> voidspace: aren't we all?
<ericsnow> natefinch: what about "WIP: sprinkle..."
<voidspace> rogpeppe: :-)
<voidspace> natefinch: we have a few branches up for review old boy
<voidspace> natefinch: this is the oldest http://reviews.vapour.ws/r/4425/
<natefinch> ericsnow: lemme check on that one.. might be ready to remove the WIP
<voidspace> natefinch: and this one didn't make it onto reviewboard https://github.com/juju/juju/pull/4995
<natefinch> voidspace: ok, I'll try to take a look.  I'm slammed with work due Friday, but I know I'm on call today, so will do my best.
<rogpeppe> voidspace: we've got an instance that is currently exhibiting the issue if you've got a moment to spare
<frankban> cherylj: your changes look good, except for the fallback that needs to be implemented, and if I am  not missing something, perhaps we should pass the series also in the case a new machine is created to place a unit?
<voidspace> rogpeppe: I'm pairing with babbageclunk but I can multitask on IRC
<voidspace> rogpeppe: he knows what he's doing right now anyway
<cherylj> frankban: that's probably true.  The bundle I was looking at specified the series for the machines when declaring them in the 'machines' section
<ericsnow> natefinch: is http://reviews.vapour.ws/r/4269/ ("backing support...") still active?
<natefinch> ericsnow: yes
<ericsnow> natefinch: k
<cherylj> frankban: I can test what happens with out that
<natefinch> ericsnow: all my branches are active... just removed the WIP from the sprinkle one
<ericsnow> natefinch: reviewing now
<frankban> cherylj: a placement can just specify "new", without referring to a declared machine
<frankban> cherylj: I thinkin that case we should infer the series
<cherylj> frankban: ah, ok, I can try that too
<cherylj> frankban: is this bug something you could take?  I can try to get to it later this week if not
<cherylj> katco: interesting lxd issue I consistently hit:  bug 1566420.  Not that it's urgent, just very weird.  Thought your team might find it interesting
<mup> Bug #1566420: lxd doesn't provision instances on first bootstrap in new xenial image <juju-core:Triaged> <https://launchpad.net/bugs/1566420>
<katco> cherylj: eh? that does seem weird
<cherylj> katco: very.
<frankban> cherylj: that would be awesome, we could sync up later this week and try to find a slot?
<cherylj> katco: I usually provision a new xenial machine in aws and install juju2 on it to test lxd in a clean environment, and I hit this every time
<cherylj> frankban: sure, sounds good
<katco> cherylj: i can't immediately think of any theories as to why that would happen...
<frankban> cherylj: thanks
<cherylj> katco: I guess I should upload the machine-0.log while I still have this up.  Not that it's hard to reproduce
<cherylj> katco: yeah, it's a weird, wtf kinda bug
<cherylj> so I had to share :)
<katco> hehe
<rogpeppe> voidspace: ok, i'm now on the instance
<rogpeppe> voidspace: i can't ping the controller on its public ip address
<rogpeppe> voidspace: or its private one
<rogpeppe> voidspace: can you think of another address to try?
<voidspace> rogpeppe: wow
<voidspace> rogpeppe: is this from another aws account or from *anywhere*?
<rogpeppe> voidspace: ah!
<rogpeppe> voidspace: i can't ping but i can connect to 17070
<rogpeppe> voidspace: phew
<voidspace> :-)
<rogpeppe> voidspace: so it's a simple(ish) fix - the cloudinit script can't always use the private ip address
<rogpeppe> voidspace: (but it can't always use the public one either, marvellous :))
<voidspace> rogpeppe: if it's different credentials it has to use the public, for same credentials it has to use the private?
<rogpeppe> voidspace: i wonder how this manages to work ok on us-east
<rogpeppe> voidspace: something like that... but the rules might be different for different providers
<voidspace> yep
<voidspace> and it depends on the controller provider and the model provider combo
<rogpeppe> voidspace: really it should probably do what the Go logic does and try all addresses
<natefinch> voidspace: I take we only support maas 1.9+ now?
<voidspace> natefinch: yes, we've already dropped 1.8 support on master
<voidspace> rogpeppe: yes - trying all of them seems like the only sane option
<rogpeppe> voidspace: difficult to do in a shell script
<natefinch> voidspace:  cool, I love dropping legacy support
<voidspace> rogpeppe: right
<voidspace> natefinch: yeah, we cut out about 1300 lines of code from the maas provider (and tests)
<mgz> do we actually aim to support cross-region controllers?
<mup> Bug #1566414 opened: juju block storage on ec2 does not default to ebs-volumes <juju-core:New> <https://launchpad.net/bugs/1566414>
<mup> Bug #1566420 opened: lxd doesn't provision instances on first bootstrap in new xenial image <juju-core:Triaged> <https://launchpad.net/bugs/1566420>
<cherylj> For anyone else hitting issues where kill-controller hangs in a loop trying to destroy resources - I've opened up bug #1566426
<mup> Bug #1566426: kill-controller should always work to bring down a controller <juju-release-support> <kill-controller> <juju-core:Triaged> <https://launchpad.net/bugs/1566426>
<natefinch> babbageclunk: for http://reviews.vapour.ws/r/4425/ you have a shipit
<voidspace> natefinch: yay, thanks
<voidspace> natefinch: subsequent PRs include earlier ones I'm afraid as we're building incrementally.
<rogpeppe> voidspace: https://bugs.launchpad.net/juju-core/+bug/1566431
<mup> Bug #1566431: cloud-init cannot always use private ip address to fetch tools (ec2 provider) <juju-core:New> <https://launchpad.net/bugs/1566431>
<voidspace> rogpeppe: thanks
<natefinch> voidspace: I started to notice.  understandable
<natefinch> babbageclunk: lgtm on https://github.com/juju/juju/pull/4995
<mup> Bug #1566426 opened: kill-controller should always work to bring down a controller <juju-release-support> <kill-controller> <juju-core:Triaged> <https://launchpad.net/bugs/1566426>
<mup> Bug #1566431 opened: cloud-init cannot always use private ip address to fetch tools (ec2 provider) <juju-core:New> <https://launchpad.net/bugs/1566431>
<voidspace> natefinch: thanks nate
<mgz> katco: yeah, the keystone 3 changes are more likely
<mgz> katco: sorry I didn't have more time for narrowing down the specifics last week, was stuck in packaging head space
<katco> mgz: no worries at all
<mgz> katco: I'd suggest turning on goose debugging and looking at the output you get when requesting a token from the lcy02 v2 versus v3 endpoints
<mgz> it's likely a configuration issue with canonistack that change is exposing
<mgz> maybe we should not default to v3, or have some fallback logic, or...
<mgz> right, cafe time is up, later all
<katco> mgz: that's where i was headed: probably improperly configured canonistack. want to pin it down though
<mgz> katco: the keystone v2 output for getting a token looked fine to me, had all the bits
<katco> mgz: i verified it is attempting to use the v3 endpoint
<katco> mgz: check out the links section: https://keystone.canonistack.canonical.com/v3/
<mgz> katco: can probably dump serviceURLs at the juju level as well
<katco> mgz: looks suspect
 * mgz really quits
<katco> :)
<mup> Bug #1566450 opened: Juju claims not authorized for LXD <bootstrap> <ci> <lxd> <juju-core:Incomplete> <juju-core maas2:Triaged> <https://launchpad.net/bugs/1566450>
<mup> Bug #1566452 opened: Win client cannot talk to Ubuntu controller <api> <ci> <windows> <juju-core:Incomplete> <https://launchpad.net/bugs/1566452>
<perrito666> anyone gets lxd failing to bootstrap waiting for address?
<cmars> perrito666, if you lxc exec into the container, is it stuck at mountall?
<cmars> basically, this: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1555760
<mup> Bug #1555760:  Too many levels of symbolic links /proc/sys/fs/binfmt_misc  <binfmt-support (Ubuntu):Confirmed> <systemd (Ubuntu):Incomplete> <https://launchpad.net/bugs/1555760>
<cmars> that'll hang a bootstrap
<perrito666> cmars: lxc  list marks it as running
<cmars> perrito666, yeah, it'd be running, but if you exec bash in it, if there's no sshd running, check /var/log/upstart/mountall.log
<cmars> if there's that binfmt_misc error at the tail end of the log, its the systemd bug
<perrito666> aghh juju killed it, let me try again
<perrito666> cmars: tx
<perrito666> mm, not that
<perrito666> something might be dirty in my system
<tvansteenburgh> hey guys, at what point does a newly created controller/model get written to ~/.local/share/juju/models/cache.yaml
<mup> Bug #1559277 changed: cannot set initial hosted model constraints: i/o timeout <bootstrap> <ci> <juju-core:Invalid> <juju-core admin-controller-model:Fix Released> <https://launchpad.net/bugs/1559277>
<tvansteenburgh> asking b/c i just upgraded to beta3, i've bootstrapped a controller, created a model, and deployed a charm, and yet this controller/model don't exist in my cache.yaml
<voidspace> tvansteenburgh: it's probably now in models.yaml
<voidspace> tvansteenburgh: I'm not even sure cache.yaml exists now
 * tvansteenburgh looks
 * voidspace is not really here
<voidspace> gotta go o/
<tvansteenburgh> hrm, well it is in models.yaml, but the parts i need aren't, specifically api-endpoints and admin-secret
<tvansteenburgh> thanks anyway voidspace
<voidspace> tvansteenburgh: there's also controllers.yaml
<voidspace>  /me is still not really here
<tvansteenburgh> aha, between that and accounts.yaml, i can get what i need, thanks voidspace, you were not here when i needed you
<natefinch> lol
<cherylj> tych0: just fyi - your "better lxd configuration" PR merged.  (In case you didn't see it yet)
<tych0> cool
<tych0> thanks, should have another one coming shortly
<natefinch> huzzah for unit tests finding bugs
<natefinch> oh ho... all tests pass.  Finally.
<marcoceppi> natefinch: is there anyway to get the name of a controller from the API?
<natefinch> marcoceppi: buh
<natefinch> thumper: ^ ?
<thumper> um...
<thumper> no
<thumper> marcoceppi: there are two names :)
 * thumper thinks
<thumper> no, just one
<thumper> what the user called it
<thumper> the controller model is always called "admin" I believe
<thumper> or something like that
<marcoceppi> thumper: sure, so we can get model names and UUIDs, we can get controller uuid, can I get controller name from api?
<thumper> if you have access to the controller model, it will show up in your list
<thumper> however the "name" of the controller is what you called it
<thumper> the controller name is "admin"
<thumper> that is the name of the controller model
<thumper> the name you gave it is what you use in switch
<thumper> or the command line
<thumper> AFAICT
<natefinch> thumper: so do we store the name you gave it in mongo, or is that purely a locally stored value that maps to a UUID that is stored in mongo?
<marcoceppi> thumper: `juju bootstrap fart lxd` gives me admin and default, if I go to another machine and use the controller API url and password
<marcoceppi> thumper: how would I get "fart" ?
<thumper> marcoceppi: I'm not sure you could
<thumper> natefinch: correct, the name in mongo is "admin"
<marcoceppi> thumper: is name only stored locally?
<thumper> the name on marcoceppi's machine is "fart"
<thumper> marcoceppi: I think so, yes
<marcoceppi> thumper: so, how will jaas do this?
<natefinch> marcoceppi: the name you gave it is just an alias for the UUID, effectively, an alias stored locally on the machine from which you bootstrapped it
<thumper> marcoceppi: when you use a controler, or login in, you give it a name
<marcoceppi> thumper natefinch can we like, put the controller name in the controller?
<thumper> no
<marcoceppi> please?
<thumper> no
<thumper> there was explicit direction given to call it "admin"
<natefinch> marcoceppi: It's definitely very much not up to me :)
<thumper> the model name that is
<marcoceppi> thumper: but I don't want the model name
<marcoceppi> I want the name, to the controller, running all the models
<thumper> there is no controller name
<thumper> just what you call it
<marcoceppi> but, fart, is a name
<thumper> no
<thumper> it is what you called it
<thumper> it is your alias
<marcoceppi> I brought it into this world
<marcoceppi> and I want it to produly know it's name
<natefinch> it could be a name.. we choose not to store that value in the controller
<thumper> ok... well, right now, there is no way to do this
<marcoceppi> right
<marcoceppi> I want that name in there
<thumper> and it won't be in 2.0
<thumper> not enough time
<marcoceppi> this really fucks up a bunch of stuff we're trying to do
<marcoceppi> because no one cares about a stupid uuid
<thumper> :)
<marcoceppi> and I can't distinguish two controllers from each other
<thumper> how about you email the dev list with what you are really trying to do
<natefinch> marcoceppi: how do you pass around credentials?
<thumper> and we'll see what solution we can come up with
<natefinch> marcoceppi: just pass around the name with the credentials
<thumper> we'd get more eyes on it then
<marcoceppi> so if I have two controllers, and each controller has a "benchmark" model, and I have data from all of those in a central repo. I either show duplicate models names or disambiguate with <controller_name>:model
<marcoceppi> but now controller_name is UUID
<marcoceppi> and I have to punch my user in the face with that
<marcoceppi> natefinch: the credentials are being set on login, like iwth juju-gui
 * marcoceppi emails the list
<thumper> marcoceppi: yes
<thumper> marcoceppi: we currently don't model a controller name
<natefinch> marcoceppi: but wherever you're storing the credentials and IP address of the controller, you could store the name of the controller that goes with the IP address, couldn't you?  I know it's not ideal.
<marcoceppi> thumper: it seems like we could, since we havea controller_uuid, just add controller_name since  - you know - mongodb doens't have strong data structs
<thumper> marcoceppi: but we do
<marcoceppi> natefinch: we get the controller ip the same way the gui does - it's deploye din the controller
<marcoceppi> natefinch: all we need is username and password, like the gui
<marcoceppi> if I ask you to name the controller each time it seems sily - they already did that when they created the controller
<thumper> marcoceppi: but the controller name is entirely at the discression of the creator
<thumper> marcoceppi: I have a controller called "stuff" and so does natefinch
<thumper> now what?
<thumper> both have models called "benchmarks"
<thumper> you need to disambiguate through user not just name
<marcoceppi> thumper: we will
<marcoceppi> thumper: in the saas endpoint we're building
<marcoceppi> it's user - controller - model
<thumper> ok
<marcoceppi> where use can only see the controllers they've submitted benchmark data for
<thumper> but I also think that the user should be able to give their controller a name you show
<thumper> not necessarily the name that they called it when they created it
<thumper> I don't personally see any problem of asking them for a name to show it as when they register their controller
<marcoceppi> thumper: I see it as a UX flub, because we may never ask them if this is done automated
 * thumper shrugs
<marcoceppi> thumper: also, models have names, and they're stored in the environment, and they're descritionary and created by the user
<marcoceppi> thumper: we store them, and have them, I'd just like the same for a controller
<thumper> they are also non-writable
<marcoceppi> non-writable?
<thumper> can't change
<thumper> histerical raisins
<thumper> no real reason for it
<marcoceppi> can't change the controller name either?
<thumper> but the name used to be used for cloud resouces
<thumper> what controller name?
 * thumper chuckles
<marcoceppi> I will fly to austraila
<marcoceppi> so I can laugh at you from across the water
<thumper> ha
<natefinch> lol
<marcoceppi> then curl up and cry as all the animals eat me
<natefinch> marcoceppi: FWIW, I agree with you.
<thumper> marcoceppi: there is no reason we couldn't except time and effort
<thumper> but we currently don't
<marcoceppi> this whole conversation made me regret asking
<thumper> sorry
<marcoceppi> how do I get information about the cloud of a model/controller?
<marcoceppi> like name, region, etc
<mup> Bug #1566531 opened: Instances are left behind testing Juju 2 <ci> <destroy-environment> <ec2-provider> <jujuqa> <juju-ci-tools:Triaged> <juju-core:Triaged> <https://launchpad.net/bugs/1566531>
<perrito666> ok something new is broken :p juju is looking for lxcbr0 and I have lxdbr0
<marcoceppi> thumper: how about getting the cloud name from the api?
<marcoceppi> I've got provider-type, but that's ec2, etc, I want aws or in the case of openstack, the name of the openstack cloud the user created
<cherylj> marcoceppi: juju list-clouds
<marcoceppi> cherylj: from the api
<cherylj> well so sorry if I didn't like read your whole question and stuff
<cherylj> heh
<cherylj> let me look
<cherylj> marcoceppi: wait
<cherylj> that wouldn't be an api call
<marcoceppi> cherylj: so we don't store it.
<cherylj> that's strictly from a local system
<marcoceppi> grrrrrrrrrrrrrrrr
<cherylj> no, it's all local in your clouds.yaml
<marcoceppi> no single source of truths for things is really grinding me today.
<cherylj> marcoceppi: except the public clouds
<cherylj> that's stored in streams?  I think?
<cherylj> so it can be updated
<marcoceppi> cherylj: but how do i tell the name of the cloud for a deployed controller/model/environment
<cherylj> marcoceppi: let me see if I can figure that out for you
<mup> Bug #1533431 changed: Bootstrap fails inexplicably with LXD local provider  <2.0-count> <docteam> <juju-release-support> <juju-core:Invalid> <https://launchpad.net/bugs/1533431>
<davecheney> mwhudson: http://seclists.org/oss-sec/2016/q2/11
<mwhudson> davecheney: oh good!
<anastasiamac> marcoceppi: at cli, running `juju show-controller` will show you bootstrp config including cloud name like 'aws'
<anastasiamac> marcoceppi: at least master tip will
<mwhudson> davecheney: any idea on timelines?
<marcoceppi> anastasiamac: cool, but I really need to get this from the API
<davecheney> mwhudson: do you know jason ?
<davecheney> i could ask him
<davecheney> but i could just introduce you and you could ask him yourself
<davecheney> I'd expect before the end of this US week
<mwhudson> we've emailed a little i guess, you're right i should just ask
<anastasiamac> marcoceppi: afaik, there is no api... it's all client-side in a file... cli effectively just parses local file(s)
<thumper> ugh...
<thumper> in trying to use my new API I've realised more changes I need to make...
<thumper> fooey
<mup> Bug #1566545 opened: max log age should be exposed as a configuration option <sts> <juju-core:New> <https://launchpad.net/bugs/1566545>
<thumper> ugh...
 * thumper needs to write tests... many tests
<menn0> thumper: can I have a quick hangout with you?
<thumper> yep
<menn0> thumper: 1:1
<axw> redir: standup?
<redir> woop
<redir> s
<redir> still there axw?
<axw> redir: yup
<redir> perrito666: the rename workaround works perfect thanks
<perrito666> redir: glad to help
<perrito666> see you all, good night
#juju-dev 2016-04-06
<mup> Bug #1566583 opened: set-default-region/set-default-credential can't clear the defaults <juju-core:Triaged> <https://launchpad.net/bugs/1566583>
<mup> Bug #1566589 opened: ERROR cannot find network interface "lxcbr0": route ip+net: no such network interface <juju-core:New> <https://launchpad.net/bugs/1566589>
<mup> Bug #1566589 changed: ERROR cannot find network interface "lxcbr0": route ip+net: no such network interface <juju-core:New> <https://launchpad.net/bugs/1566589>
<mup> Bug #1566589 opened: ERROR cannot find network interface "lxcbr0": route ip+net: no such network interface <juju-core:New> <https://launchpad.net/bugs/1566589>
<mwhudson> hm
<mwhudson> will juju in xenial need to use the mmapv1 mongo storage except for upgrades?
<menn0> mwhudson: not sure about that one. wallyworld or perrito666 might know.
<mwhudson> because it is disabled by mongo tip on big endian...
<davecheney> mongo on s390x
<davecheney> what could possibly go wrong
<mwhudson> what could possibly go right!
<mwhudson> or thgir
<davecheney> well said
<mwhudson> menn0: i presume we don't use any of the geospatial nonsense
<menn0> mwhudson: no we don't
<menn0> mwhudson: looking at the code, there's a new "upgrade-mongo" juju command. It allows you to specify whether you want wired tiger or not
<menn0> mwhudson: so it looks like we expect to be able to use mmapv1 with mongo3
<mwhudson> menn0: better hope noone wants to use that on s390x
<menn0> mwhudson: it looks like mmapv1 is assumed by default
<mwhudson> :(
<mwhudson> menn0: i guess we can have a different default on s390x...
<menn0> mwhudson: that might have to be what we do
<natefinch> you know, I used to love macaroons, but now, I'll be happy if I never see that word again
<cherylj> lol
<menn0> axw: is it a known issue that you can't upgrade a hosted model using --upload-tools?
<cherylj> menn0: bug 1564026
<mup> Bug #1564026: Unable to upgrade hosted model with --upload-tools after upgrading controller with --upload-tools <juju-release-support> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1564026>
<cherylj> :)
<menn0> cherylj: yay
<menn0> cherylj: at least there's a ticket
 * cherylj sighs....
<cherylj> the fallback in mongo isn't working
<cherylj> E: Unable to locate package juju-mongodb3.2
<cherylj> and it fails to bootstrap
<redir> hasta manana juju-dev
<cherylj> perrito666: are you still around?
<anastasiamac> cherylj: it's nearly midnight where perrito666 is...
<cherylj> axw, anastasiamac, do either of you know if wallyworld's mongo3.2 PR was supposed to fall back to 2.4 on xenial if 3.2 was not available?
<cherylj> https://github.com/juju/juju/pull/4715
<anastasiamac> cherylj: i don't
<cherylj> because right now you can't bootstrap on xenial (with his PR)
<cherylj> which, admittedly, I guess I should've tested before merging it
<anastasiamac> cherylj: can we revert it?
<cherylj> Think I'm going to have to
<anastasiamac> cherylj: looking at the code comments, there was an intent to fall back...
<anastasiamac> / We'll try for mongo 3.2 first and fallback to
<anastasiamac> +		// mongo 2.4 if the newer binaries are not available
<cherylj> yep, I saw that
<cherylj> it just keeps retrying mongo 3.2
<anastasiamac> :/
<axw> menn0: not a known issue to me. wouldn't you need to upgrade the controller with --upload-tools before you can upgrade the hosted model?
<axw> (sorry for delay, was out)
<menn0> axw: cherylj pointed out it's a known issue
<axw> ah
<axw> so I see
<menn0> axw: if you update the controller with --upload-tools
<menn0> axw:  then you can't upgrade the hosted model
<menn0> because that always bumps the build one version past the controller's version :)
<axw> menn0: ah, because of the magic +.1 I guess
<axw> yep
<menn0> there's a ticket anyway
<menn0> my favourite oneliner at the moment: lxc list -cn | perl -ne '/(juju-[^ ]+)/ && print "$1\n"' | xargs lxc delete --force
<axw> menn0: kill-controller is broken for you too?
<menn0> axw: only post migration... the old controller still thinks it has control of the migrated agents
<menn0> axw: that part isn't done yet
<menn0> axw: it seems to break kill-controller
<axw> menn0: ah, ok. some people are having problems with kill-controller & lxd generally
<menn0> yeah I saw that
<menn0> it's been mostly ok for me
<davecheney> https://github.com/juju/juju/pull/5005
<cherylj> hey axw, did you see ian's email about bug 1566414?
<mup> Bug #1566414: juju block storage on ec2 does not default to ebs-volumes <juju-core:New> <https://launchpad.net/bugs/1566414>
<axw> cherylj: yes, just responding. I've replied to the juju@ list already with the answer tho
<cherylj> ah, cool, thanks!
<cherylj> ah, I see the problem with mongo
<cherylj> the version is passed in, but not used when deciding which version to install
<cherylj> fabulous
<anastasiamac> \o/
<davecheney> menn0: thumper  https://github.com/juju/juju/pull/5005
<cherylj> anastasiamac: did you want to pick up the mongo work?  or should I revert and fix tomorrow?
<anastasiamac> cherylj: m happy to pick up \o/
<anastasiamac> just proposed a streams fix anyway.. :D
<cherylj> ah, so looking for something to do, eh?  ;)
 * anastasiamac ducks
<anastasiamac> aha
<mup> Bug #1566628 opened: Juju cannot bootstrap on xenial without juju-mongodb3.2 package <blocker> <bootstrap> <mongodb> <juju-core:Triaged> <https://launchpad.net/bugs/1566628>
<cherylj> hmm
<cherylj> I wonder if this bug requires discussion with sinzui and team
<cherylj> about which packages will be supported on which series
<cherylj> maybe reverting for tonight is the way to go
<cherylj> anastasiamac: yeah, just revert for tonight.  Could you do that?
<cherylj> or I guess I could do it real quick like
<anastasiamac> cherylj: if u get a chance, sure..
<cherylj> review request for the revert:  http://reviews.vapour.ws/r/4450/
<anastasiamac> cherylj: looking
<natefinch> cherylj: if it's just a github-initiated revert of the PR, seems like it doesn't really need a review
 * cherylj is paranoid
<natefinch> cherylj: ship it so I can land stuff :D
<cherylj> hehe
<davecheney> menn0: thumper  https://github.com/juju/juju/pull/5005
<menn0> davecheney: sorry, I'm swamped. i'll look.
<davecheney> ta
 * natefinch sleeps for a bit
<menn0> davecheney: done
<davecheney> menn0: thanks
<mup> Bug #1536445 changed: juju rackspace provider requires auth-url <2.0-count> <juju-release-support> <juju-core:Fix Released> <https://launchpad.net/bugs/1536445>
<mup> Bug #1566639 opened: Rackspace provider - "cannot determine available auth versions auth options fetching failed" <rackspace> <juju-core:Triaged> <https://launchpad.net/bugs/1566639>
<menn0> davecheney: http://reviews.vapour.ws/r/4451/diff/ pls
<davecheney> menn0: https://github.com/juju/juju/pull/5010
<davecheney> fixes 1.25 blocker
<davecheney> menn0: LGTM
<menn0> davecheney: looking
<menn0> davecheney: and thanks
<menn0> davecheney: ship it
<davecheney> thanks, I'm hoping the other failure in that bug is just a flake
<davecheney> this CL should make it clearer anyhoo
<mup> Bug #1566684 opened: Charm hooks to be called "upgrade" and "config" <juju-core:New> <https://launchpad.net/bugs/1566684>
<dimitern> morning o/
<anastasiamac> dimitern: o/ how was ur break? :P
<dimitern> anastasiamac, much needed :) the weather is getting better as well, as a bonus
<anastasiamac> \o/ welcome back
<dimitern> anastasiamac, cheers ;)
<thumper> o/ babbageclunk
<babbageclunk> thumper: hi!
<dimitern> hey thumper, babbageclunk :) how's maas 2 going?
<thumper> dimitern: good, was going to come to the standup to chat about it
<thumper> dimitern: how was your break?
<dimitern> thumper, ah very good, just long enough hehe
<thumper> dimitern: and come back to a mountain of emails
<thumper> dimitern: select all, delete?
<dimitern> thumper, "Mark all as read" :)
<thumper> :)
<mup> Bug #1566707 opened: Unable to bootstrap lxd with beta3 <juju-core:New> <https://launchpad.net/bugs/1566707>
<babbageclunk> hey dimitern, welcome back!
<dimitern> babbageclunk, thanks!
<TheMue> morning
<voidspace> dimitern: frobware: dooferlad: needs review please http://reviews.vapour.ws/r/4435/
<dimitern> voidspace, looking
<voidspace> dimitern: thanks
<voidspace> babbageclunk: did you complete the maas-spaces test?
<voidspace> maas2-spaces even
<voidspace> babbageclunk: looks to me like that branch is ready for PR
<dooferlad> voidspace: hangout time
<voidspace> dooferlad: omw
<mup> Bug #1566751 opened: lxd provider relies on deprecated lxc bridge <juju-core:New> <https://launchpad.net/bugs/1566751>
<frobware> jam, ping
<babbageclunk> voidspace: I'm just waiting for the availability zones branch to be merged before creating the PR on maas2-spaces, should only be 10misn
<babbageclunk> mins
<voidspace> babbageclunk: no need to wait
<voidspace> babbageclunk: the PR will update automatically when az lands
<babbageclunk> ah, ok
<babbageclunk> voidspace: https://github.com/juju/juju/pull/5012
<voidspace> babbageclunk: cool, thanks
<babbageclunk> voidspace: so, you're going to do the feature flag - should I start looking at acquire node, or the storage stuff Tim was suggesting?
<voidspace> babbageclunk: I was going to do acquireNode and you and Andy pick up storage
<voidspace> babbageclunk: as it's nice and isolated so we won't conflict
<voidspace> and apparently we'll need it for bootstrap anyway
<babbageclunk> voidspace: ok cool - is there a motivating command like bootstrap for that?
<voidspace> babbageclunk: not directly - Tim reckoned we'll need it for bootstrap though
<babbageclunk> voidspace: ok - so just start hacking in storage.go then, I guess
<babbageclunk> voidspace: I mean "hacking"
<babbageclunk> voidspace: looks fairly understandable, I'll try starting now and picking your and frobware's brains if I get stuck
<voidspace> babbageclunk: cool
<voidspace> babbageclunk: availability zones has merged
<voidspace> babbageclunk: it says that your spaces branch has conflicts
<voidspace> babbageclunk: I think it's just got confused - merge maas2 into it and push
<voidspace> frobware: dimitern: dooferlad: review please http://reviews.vapour.ws/r/4454/
<dimitern> voidspace, *click*
<dimitern> voidspace, babbageclunk, reviewed ^
<voidspace> dimitern: cool, thanks
<frankban> dooferlad: ping
<voidspace> dimitern: why do you think var result []network.SpaceInfo  is better than result := []network.SpaceInfo{}
<dimitern> voidspace, marginally better, yes
<voidspace> dimitern: I mean why?
<dimitern> voidspace, as it saves an unnecessary allocation of an empty slice
<voidspace> dimitern: what's the difference (other than nil initialisation)
<dimitern> voidspace, which append does anyway
<voidspace> dimitern: but if it's already allocated append won't do an extra one - that just moves the initial allocation
<voidspace> dimitern: doesn't it?
<voidspace> dimitern: you might be right, in which case the compiler is a bit dumb
<dimitern> voidspace, append always allocates and returns a new slice
<voidspace> dimitern: no it only does that if you reach capacity
<voidspace> dimitern: in terms of allocation
<voidspace> surely!?
<dimitern> voidspace, capacity and length are zero for an empty slice
<voidspace> dimitern: ah, ok - so that is a bit dumb
<voidspace> dimitern: fair enough, thanks
<dimitern> voidspace, :)
<dimitern> voidspace, http://play.golang.org/p/sQwf6fSCJw - just to illustrate << babbageclunk
<voidspace> dimitern: it only grows the capacity one at a time - no overallocation to prevent unnecessary reallocation
<voidspace> babbageclunk: that answers our question from yesterday
<voidspace> dimitern: I assumed go would be smarter than that
<dimitern> voidspace, yep
<voidspace> dimitern: it reallocates on every append - so adding items to a slice in a loop with append is O(n^2)
<babbageclunk> voidspace: Oh no!
<dimitern> voidspace, you can use make + copy to make it a O(1)
<voidspace> dimitern: right
<dimitern> just won't work if your source data is in a map
<voidspace> dimitern: still O(n) if you do a copy, right
<babbageclunk> So you have to do the exponential growth yourself to get O(1)? That's rubbish.
<dimitern> voidspace, oh, right - in general it is, but compiler might be optimizing it to a bulk instruction
<voidspace> dimitern: ah, maybe
<dimitern> voidspace, have you seen this? http://underlap.blogspot.bg/2015/04/go2.html
<frobware> dimitern, hoping you've checked the date...
<dimitern> yeah :D
<dimitern> but it took me some time after the initial shock
<babbageclunk> voidspace, dimitern - no, it does the exponential growth.
<babbageclunk> http://play.golang.org/p/sQwf6fSCJw
<dimitern> babbageclunk, it's doesn't allocate more than it needs - it's expected for you to either pre-make a slice of a given len and/or cap and the use indexing or append on it
<dimitern> babbageclunk, https://github.com/golang/go/wiki/SliceTricks - very useful if you haven't looked at it
<dimitern> http://stackoverflow.com/questions/20251900/efficient-appending-to-a-variable-length-container-of-strings-golang also sheds some light
<dimitern> frobware, I'm getting lxd test failures on master: http://paste.ubuntu.com/15644992/
<dimitern> are those known?
<babbageclunk> dimitern: I might be misunderstanding. I thought you were saying that it resizes and copies on every append, but if it does that the behaviour would be O(n^2).
<frobware> dimitern, entirely possible now
<frobware> dimitern, well, since the remove of lxc1 and the lxd bridge
<dimitern> babbageclunk, apparently it does that for slices with less than 1024 elements, for longer ones it does cap()x1.25 on realloc
<frobware> dimitern, would you mind running a NUC experiment for me?
<dimitern> babbageclunk, but the idea is to preallocate the slice and use indexing (or copy(), if no special filtering / transformation is needed)
<babbageclunk> dimitern: So do you mean the growth factor is 2x for < 1024 elements and then switches to 1.25x after that? I think that's fine.
<dimitern> frobware, it needs to be on a nuc, right?
<babbageclunk> dimitern: yes, that's always going to be the best if possible.
<frobware> dimitern, I want to isolate my vMAAS KVM nodes
<dimitern> babbageclunk, here's the answer: https://golang.org/src/runtime/slice.go#L59
<babbageclunk> dimitern: Aha, thanks!
<frobware> dimitern, oh, and to mix things up it needs to be with MAAS 1.9.1 and Juju 1.25.4
<dimitern> frobware, ok, let me fire up my nucs here to make sure they still can be deployed
<frobware> dimitern, appreciated. I have bought two - they arrive tomorrow but I'm not at home...
<voidspace> dimitern: it looks to me like feature flags can be set by the user to arbitrary values and they're runtime checked
<voidspace> dimitern: so there's no point/need to create one on master - it's just dead code until something in juju actually uses the feature flag
<voidspace> dimitern: so we can *document* a feature flag for master, but no code changes until maas2 lands
<dimitern> voidspace, I'm not quite sure why the ff was suggested, but otherwise that makes sense
<dimitern> frobware, bad news :/ my hw maas's power adapter died
<dimitern> frobware, I'll try to find a replacement around here, but chances are slim
<perrito666> cherylj: can you give me more detail when you arrive I might be able to help you with the mongo issue
<voidspace> dimitern: rick_h_ wanted a feature flag in 2.0 even if the actual support wasn't there yet
<voidspace> dimitern: but because of the way feature flags are implemented I don't think that actually makes sense
<dimitern> voidspace, how so?
<voidspace> dimitern: I guess it's so we can say that experimental MAAS 2 support added in 2.0.1 is a bugfix rather than a new feature
<dimitern> voidspace, they're intended to be immutable once bootstrapped
<voidspace> dimitern: it doesn't make sense to add a feature flag before any code using it - because a feature flag added to juju does nothing
<dimitern> voidspace, ah, in that sense - sure :) I agree
<voidspace> I mean, literally nothing
<voidspace> we don't check them for validity
<voidspace> so you can use arbitrary feature flags that don't exist and merely adding the definition into juju still does absolutely nothing
<voidspace> unless it's used by code
<voidspace> so we can just *tell* people there's a new feature flag and that has the same effect
<babbageclunk> voidspace: ok, merging maas2-spaces. Sorry, got myself a bit confused with merging back from upstream.
<voidspace> babbageclunk: :-)
<babbageclunk> voidspace: and magit newbieness
<voidspace> babbageclunk: so I'm doing acquireNode (which is actually selectNode because of the way the code is written)
<voidspace> babbageclunk: so first I need to add hostname and hardwareCharacteristics to maasInstance / maas2Instance
<voidspace> babbageclunk: and next we'll need environ.startNode
<voidspace> babbageclunk: so there would be more bang-for-buck if you worked on startNode instead
<voidspace> then we need StopInstances and the interface stuff used by maasObjectNetworkInterfaces
<voidspace> we'll need all that before storage
<mup> Bug #1566791 opened: VLANs on an unconfigured parent device error with "cannot set link-layer device addresses of machine "0": invalid address <network> <juju-core:New> <https://launchpad.net/bugs/1566791>
<babbageclunk> voidspace: ok - starting on startNode now
<voidspace> babbageclunk: the current implementation returns a gomaasapi.MAASObject
<babbageclunk> voidspace: well, we can't have that.
<voidspace> babbageclunk: this is passed to maasObjectNetworkInterfaces
<voidspace> babbageclunk: so let's have a startNode2 that returns a maas2Instance for now
<babbageclunk> ok
<voidspace> babbageclunk: the important bit is getting the api call right
<voidspace> babbageclunk: then maybe you can look at maasObjectNetworkInterfaces
<voidspace> babbageclunk: but I've got a feeling that's a bit horrible
<voidspace> babbageclunk: hopefully the MAAS2 version will be substantially less horrible
<voidspace> babbageclunk: but you (we) will need to understand the existing one to be able to port it!
<babbageclunk> voidspace: you mean startNode should take a maas2Instance, right? Or a gomaasapi.Machine?
<voidspace> babbageclunk: take *and* return I guess
<voidspace> babbageclunk: and maas2Instance rather than Machine
<voidspace> babbageclunk: so long as that makes sense
<voidspace> babbageclunk: otherwise just do what we need to do...
<babbageclunk> voidspace: but return a newly created one? It looks like gomaasapi updates the machine in place with the response based on the interface - just looking in the code.
<voidspace> babbageclunk: well, the status at least should have changed
<voidspace> babbageclunk: so for MAAS 2 we'll probably want a new maas2Instance
<babbageclunk> voidspace: yeah, it updates it - so I'll create a new maas2Instance with the same underlying machine.
<babbageclunk> Cool
<voidspace> our code has ad-hoc api retries everywhere (well - except not everywhere)
<voidspace> maybe we should ask thumper to put a generic retry in place
<frobware> dimitern, sync?
<dimitern> frobware, omw
<voidspace> babbageclunk: can you write up what you do in the status doc please
<babbageclunk> voidspace: ok
<babbageclunk> voidspace: Dropped out pretty simple - want me to try wiring it into StartInstance, or are you going to do that?
<babbageclunk> voidspace: https://github.com/babbageclunk/juju/commit/a697d8a78b33f2f5c05125e985083bec45d61603
<babbageclunk> voidspace: should I test that individually, or should that be done via StartInstances.
<voidspace> babbageclunk: I've nearly finished extending maasInstance interface (and maas2Instance implementation) with the new methods needed for StartInstance
<voidspace> then I need to do new implementation of startNode
<babbageclunk> ?
<voidspace> babbageclunk: this is *in* StartInstance
<voidspace> babbageclunk: so I think if you work there too it will clash
<babbageclunk> Didn't I just do that?
<voidspace> sorry, I meant selectNode
<voidspace> not startNode
<babbageclunk> Ok -I'll start on maasObjectNetworkInterfaces stuff
<voidspace> babbageclunk: cool
<voidspace> babbageclunk: we also need StopInstances
<voidspace> babbageclunk: I guess we'll have to test this through StartInstance
<voidspace> babbageclunk: doesn't look easy to test in isolation
 * voidspace lunches
<mup> Bug #1566801 opened: LXD containers /etc/network/interfaces currently gets overwritten <network> <juju-core:New for frobware> <https://launchpad.net/bugs/1566801>
<alexisb> jam, fwereade ping
<jam> alexisb: omw, timezone shift confused me
<mup> Bug #1566751 changed: lxd provider relies on deprecated lxc bridge <juju-core:New> <https://launchpad.net/bugs/1566751>
<frankban> dooferlad: ping
<dooferlad> frankban: hi, I was going to have lunch ~now, can it wait 30 minutes?
<frankban> dooferlad: sure
<dooferlad> frankban: great, see you soon.
<jcastro_> axw, +50 to your common-sense approach to killing controllers
<mup> Bug #1566843 opened: juju add-credential should set default when there is only one credential  <docteam> <juju-core:New> <https://launchpad.net/bugs/1566843>
<dooferlad> frankban: back
<frankban> dooferlad: I was just pinging to check the progress of https://bugs.launchpad.net/juju-core/+bug/1555083
<mup> Bug #1555083: Certificate error when visiting the embedded Juju GUI <2.0-count> <juju-gui> <lxd> <juju-core:In Progress by dooferlad> <https://launchpad.net/bugs/1555083>
<dooferlad> frankban: a fix has been checked in.
<frankban> dooferlad: merged to master?
<dooferlad> frankban: yes
<dooferlad> frankban: I think
 * dooferlad checks
<frankban> dooferlad: ty
<mup> Bug #1566843 changed: juju add-credential should set default when there is only one credential  <docteam> <juju-core:New> <https://launchpad.net/bugs/1566843>
<dooferlad> frankban: apologies, it hasn't landed. Not sure how I missed that.
<frankban> dooferlad: cool it's fixed, could you please go ahead and merge it asap?
<dooferlad> frankban: sure, I was targetting the embedded GUI branch. Is that OK?
<frankban> dooferlad: it;s ok
<mup> Bug #1566843 opened: juju add-credential should set default when there is only one credential (when using interactive mode) <docteam> <juju-core:New> <https://launchpad.net/bugs/1566843>
<anastasiamac> perrito666: i agree about kill vs destroy (for me, destroy sounds more final than kill) :D
<perrito666> good I am not crazy... oh well I might be, but I am not alone
<voidspace> anastasiamac: death is not final?
<voidspace> that's good news...
<natefinch> there's death, and then there's death and dismemberment
<anastasiamac> voidspace: both are fatal but one is more drastic... otherwise why have 2 words to mean the same thing... right?
<voidspace> natefinch: so long as they're in that order I don't think it makes a great deal of difference
<perrito666> yeah, destroy sounds like medieval death, which usually included some form of parts of you on the castle doors
<voidspace> anastasiamac: well, you can destroy things that aren't alive but not kill them...
<voidspace> maybe we should add a dismember-controllers argument
<anastasiamac> voidspace: isn't destroying someone worse than killing them?.. in a way?..
<voidspace> anastasiamac: I guess so, I think I just felt like arguing
<anastasiamac> voidspace: 3mins to midnight here, so u win \o/
<voidspace> yay!
<voidspace> at least I get to win at something
<perrito666> voidspace: juju kill-controller --level=vlad_the_impaler
<voidspace> perrito666: :-)
<frankban> dooferlad: could you please ping me when the fix is merged to embedded-gui?
<dooferlad> frankban: sure
<katco> perrito666: could i get a +1 on some code-cleanup first? http://reviews.vapour.ws/r/4457/
<perrito666> katco: looking
<mup> Bug #1556293 changed: gce Invalid volume ID destroying environment <ci> <destroy-controller> <destroy-environment> <gce-provider> <juju-core:Invalid> <juju-core 1.25:Fix Committed by anastasia-macmood> <https://launchpad.net/bugs/1556293>
<mup> Bug #1564700 changed: juju 1.25 -- go 1.6 -- provider/joyent tests explode due to incorrect use of AddCleanup <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1564700>
<mup> Bug #1566893 opened: juju.NewAPIConnection doesn't fall back to using UnresolvedAPIEndpoints when connecting <juju-core:New> <https://launchpad.net/bugs/1566893>
<voidspace> dooferlad: frobware: babbageclunk: simple one up for review http://reviews.vapour.ws/r/4458/
<perrito666> katco: shipit, thanks for that great job
<katco> perrito666: tyvm... #codescout ;)
<frobware> voidspace, +1
<perrito666> did you just use a hashtag in irc?
 * perrito666 -1 nerdpoints katco 
<katco> lol
<katco> i have nerdpoints to spare...
<perrito666> we all do :p
<perrito666> we refill every game night on sprints :p
<katco> haha
<voidspace> frobware: thanks
<frobware> voidspace, the smaller reviews I can look at between re-deploys... :)
<voidspace> :-)
<mup> Bug #1566707 changed: Unable to bootstrap lxd with beta3 <juju-core:Invalid> <https://launchpad.net/bugs/1566707>
<katco> ericsnow: standup time
<rogpeppe> fwereade: ping
<fwereade> rogpeppe, pong
<rogpeppe> fwereade: hiya :)
<fwereade> rogpeppe, heyhey, been a while -- how's it going?
<rogpeppe> fwereade: good thanks, if a little frantic around here...
<fwereade> rogpeppe, I bet :)
<fwereade> rogpeppe, what can I do for you?
<rogpeppe> fwereade: just a brief question about some logic i don't understand that has your name on it
<rogpeppe> fwereade: in dummy.environProvider.PrepareForCreateEnvironment
<rogpeppe> fwereade: it sets "controller" to false if it's true
<fwereade> but leaves it if it's anything else?
<rogpeppe> fwereade: i'm wondering why
<rogpeppe> fwereade: yeah
<fwereade> rogpeppe, there's a tale :)
<rogpeppe> fwereade: i thought there might be :)
<rogpeppe> fwereade: i had a test that was creating a model with controller=true, and it failed 'cos it ended up false
<rogpeppe> fwereade: so it *did* work at one point.
<fwereade> rogpeppe, basically the problem is that we use the controller environment as a template for creating hosted environments (which is fine) but the dummy provider does not play well with multiple environments that think they're the controller
<rogpeppe> fwereade: ah, ok
<fwereade> rogpeppe, going so far as to nuke the global testing mongo from underneath the rest of the test infrastructure
<fwereade> rogpeppe, which leads to surprising errors ;)
<rogpeppe> fwereade: i'm surprised it's a value that's allowed to change
<fwereade> rogpeppe, I don't think it is changing, is it? PFCE is about tweaking a config for a fresh env
<rogpeppe> fwereade: i.e. why not just return "controller" in RestrictedConfigAttributes ?
<rogpeppe> fwereade: ah, but it *must* be different...
<rogpeppe> fwereade: interesting
<fwereade> rogpeppe, it probably should be restricted if it's not, though
<rogpeppe> fwereade: it can't be restricted really
<rogpeppe> fwereade: as restricted implies the value can't change from the controller, but in this case it must be different AFAICS
<fwereade> rogpeppe, ah right I see
<rogpeppe> fwereade: maybe there's no other alternative
<rogpeppe> fwereade: i guess it could return an error
<rogpeppe> fwereade: if controller==true
<mup> Bug #1540061 changed: juju 2.0 alpha + local LXD provider: dns hostname inconsistency <2.0-count> <juju-release-support> <lxd> <s390x> <juju-core:Triaged> <https://launchpad.net/bugs/1540061>
<fwereade> rogpeppe, I see what you mean -- but not that comfortable with either tbh, so slightly inclined towards not touching it ;)
<rogpeppe> fwereade: fair enough. now that i know what's going on i can fix my test.
<fwereade> rogpeppe, oh, and, the sting in the tail
<rogpeppe> fwereade: i might add a comment if i have the energy
<rogpeppe> fwereade: oh yes?
<fwereade> rogpeppe, is that I check for true specifically, because something *else* has a convoluted test that wants to check validation happens at a certain point, and I couldn't see how to do that without allowing nonsense values to pass through untouched
<fwereade> rogpeppe, I'm sure I commented somewhere, evidently not
<rogpeppe> fwereade: ah! rather than just setting it to false
<fwereade> rogpeppe, yeah
<fwereade> rogpeppe, was a pretty shameful day, but it was a terrible merge
<rogpeppe> fwereade: well, the comment says "this looks redundant" but doesn't actually say why it's doing what it's doing
<fwereade> rogpeppe, well that was stupid of me
<fwereade> rogpeppe, sorry :)
<rogpeppe> fwereade: np
<rogpeppe> fwereade: BTW (off topic) have you read the Water Knife yet? if not, get it!
<tych0> frobware: hi, i just noticed that the lxd container type creates no eth0 by default
<tych0> frobware: i guess i have to do something to tell juju to add a network to it, but i'm not sure what
<frobware> tych0, work in progress bug
<frobware> tych0, if you bounc eth agent the profile should be created second time around (on a new add-machine lxd:0)
<frobware> tych0, however, /e/n/i will still be wrong.
<tych0> frobware: i sort of remember some discussion about this. something is overwriting it?
<tych0> frobware: but from my look, the container has no eth0 device in lxd's config, so nothing will add to it
<frobware> tych0, https://bugs.launchpad.net/juju-core/+bug/1564395
<mup> Bug #1564395: newly created LXD container has zero network devices <bootstrap> <network> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1564395>
<frobware> tych0, the current workaround is to reboot the node hosting the container
<frobware> tych0, and add a new container, old one will still be bust
<frobware> tych0, and new container will be bust because of https://bugs.launchpad.net/juju-core/+bug/1566801
<mup> Bug #1566801: LXD containers /etc/network/interfaces as generated by Juju  gets overwritten by LXD container start <network> <juju-core:Triaged by frobware> <https://launchpad.net/bugs/1566801>
<tych0> frobware: ok, thanks
<tych0> frobware: where in the code is that config actually written?
<tych0> frobware: i can probably add the PutFile call we need if that's all the change that's required
<frobware> tych0, I have a solution I'm currently testing based on a conversation with stgraber
<tych0> frobware: ok, thanks
<frobware> tych0, this http://pastebin.ubuntu.com/15653945/ is the essence of it
<tych0> frobware: let me know when you get the PR up and i can test. i want to test some other stuff on top of this :)
<frobware> tych0, use my hack above ^^
<tych0> frobware: ok, thanks
<tych0> frobware: do you want to do PutFile too at some point? or just leave it writing directly?
<frobware> tych0, that's not direct to the filesystem, that gets put there by cloud-init
<tych0> frobware: i think there are some optimizations coming down the path where with zfs the container's fs won't be mounted by default any more
<tych0> ok, ok
<tych0> don't mind me then :)
<tych0> frobware: thanks
<frobware> yw
<frobware> tych0, the implications of "won't be mounted by default" was reference to us writing directly the fs?
<frobware> (which we don't)
<fwereade> rogpeppe, ooh, thank you, will do
<tych0> frobware: yeah, exactly
<tych0> frobware: so you should be fine
<frobware> tych0, I haven't verified but presumably this "solution" will be good for 14.04 too
<tych0> frobware: yeah, hopefully so :)
<rogpeppe> fwereade: the shipbreaker books, though YA, are also well worth reading if you haven't
<frobware> tych0, the view of the world with bounced machine and patched juju should look like http://pastebin.ubuntu.com/15654417/ and http://pastebin.ubuntu.com/15654447/
<tych0> frobware: ok
<tych0> frobware: so the container type juju isn't using lxdbr0 at all then?
<frobware> tych0, not for containers instantiated from the MAAS provider. That provider has `spaces' support, so we know the exact network configuration.
<tych0> ah, i see
<tych0> but for stuff like gce it still will?
<frobware> tych0, yep (and local)
<tych0> frobware: ok, cool, thanks
<frobware> tych0, so I need to consider those cases for my patch.
<tych0> frobware: well, i'm testing your patch on gce now
<tych0> frobware: so i'll complain if it doesn'tw ork :)
<frobware> tych0, outsourced!
<tych0> frobware: :D
<frobware> tych0, oh
<frobware> tych0, in which case I'll hang around a bit if you think you'll know the answer RSN...
<tych0> yeah, just waiting on some i/o
<frobware> tych0, perennially ...
<tych0> :)
<tych0> frobware: no dice, http://paste.ubuntu.com/15654773/
<tych0> frobware: i still have no network device, even in the profile
<tych0> (presumably because there was no network config populated because gce doesn't know about spaces?)
<tych0> frobware: i can send a patch for that if you ahve any pointers
<frobware> tych0, did you bounce the machine after it had bootstrapped?
<tych0> frobware: another thought i had was that it seems like juju is creating 1:1 profiles for containers, we could just use the container's config there (the intent of profiles is really to apply to more than one container at a time)
<tych0> oh, no
<tych0> let me restart it
<tych0> and i'll try again
<frobware> tych0, I'm being lazy. bounce the juju agent.
<tych0> too late :)
<frobware> tych0, I had thought about creating one profile and sharing it.
<tych0> frobware: oh, so the config isn't unique to a particular container?
<frobware> tych0, which is fine until we launch a container which has a different subset
<tych0> frobware: i see
<fwereade> dooferlad, reviewed, not quite there yet but the args/results correspondence is the only thing that's blocking a ship-it
<tych0> so they might be shared, and might not be
<tych0> frobware: are you ever going to re-use profiles? if not, maybe it makes sense to just put it on the container itself
<dooferlad> fwereade: thanks!
<tych0> and cut profiles out of the loop entirely
<frobware> tych0, yes. given the current timescales, I went with the simplest approach. but it is something to reconsider.
<tych0> frobware: ok
<frobware> tych0, what's the difference between 'create profile' and 'just put it on the container itself'?
<tych0> frobware: so profiles are basically just collections of container configuration
<frobware> tych0, when we create the container we create and associate that profile with that container
<tych0> frobware: but you can configure the container itself directly (e.g. `lxc profile device set myprofile` vs. `lxc config device set mycontainer`)
<frobware> tych0, where "that" is the -network profile.
<tych0> frobware: right, that's an extra step you don't really need
<tych0> you can just configure the container directly
<frobware> tych0, through the API?
<tych0> the profiles are mostly inteded to be shared across multiple containers
<tych0> frobware: yes, sec
<tych0> frobware: client.SetContainerConfig()
<tych0> is very similar to SetProfileConfig()
<frobware> tych0, and if you do that, does it still show from: $ lxc profile list
<tych0> frobware: i'm not sure what you mean
<dooferlad> frankban: that GUI fix just landed in the embedded-gui branch.
<tych0> frobware: if you only configure it on the container and don't reate a profile, no profile will show up in lxc profile list
<frobware> tych0, right now if I run (from the CLI): lxc profile list, I see the juju-machine-0-lxd-network profile listed (which is only pertinent to that instance)
<tych0> frobware: right, what i'm saying is don't create or use that profile at all
<tych0> frobware: just configure the instance directly
<frobware> tych0, ok, I see. and does the detail show up in $(lxc info <container>)?
<tych0> frobware: yes
<frobware> tych0, just curious how to verify and/or debug
<tych0> well
<tych0> you might need to lxc config show <container>
<frankban> dooferlad: \o/ thanks, trying it
<tych0> i don't remember if info dumps the config or not
<tych0> arg
<tych0> and my host seems to not have come back up after a reboot :(
 * tych0 makes another
<tych0> yay cloud
<frobware> tych0, sounds like my day with 1 particular maas node...
<tych0> weird
<tych0> it's trying to ssh to the wrong ip
<frobware> MITM :)
<frobware> tych0, http://pastebin.ubuntu.com/15655169/ -- lxc config show
<frobware> tych0, perhaps the network profile would show up in there if it wasn't discrete
<tych0> frobware: sorry, i don't understand
<tych0> what do you mean by perhaps the network profile would show up?
<tych0> - juju-machine-0-lxd-0-network
<tych0> isn't it there/
<tych0> frobware: how do i bounce the juju service?
<frobware> tych0, so if I didn't create a discrete profile (juju-machine-0-lxd-0-network) as you suggest and just client.SetContainerConfig() would the config show it differently?
<tych0> service jujud restart didn't work
<tych0> frobware: no, it should be the same
<tych0> well, other than not having the profile there
<frobware> tych0, so no content that represents what's in that profile at all?
<tych0> frobware: well if you do it directly, there's no profile, right?
<tych0> so there's nothign to represent?
<tych0> perhaps i'm confused.
<frobware> tych0, which for me comes back to how do I debug/verify the network devices
<tych0> frobware: why not with lxc config show?
<frobware> tych0, that's my question, really. would it show up in there?
<tych0> yes
<frobware> tych0, ok, so good. :)
<tych0> frobware: so how do i bounce the juju service?
<frobware> tych0, looking (because of systemd, or its name, or because I reboot)...
<natefinch> ericsnow: does the channels patch have a shipit if I've addressed all the comments?
<ericsnow> natefinch: I'll look
<frobware> tych0, service  jujud-machine-0 stop; service  jujud-machine-0 start
<frobware> tych0, any joy with restarting?
<tych0> not found :(
<tych0> oh
<tych0> because it's machine-1
<frobware> hehee
<tych0> ok, trying a deploy --to lxd:1 now
<mup> Bug #1566978 opened: GCE provider output oddities <juju-core:New> <https://launchpad.net/bugs/1566978>
<frobware> tych0, just $(juju add-machine lxd:1)
<ericsnow> natefinch: ship-it
<frobware> tych0, in your bug, it's not even just .178, the rest is diffeent too.
<natefinch> ericsnow: cool, thanks
<ericsnow> natefinch: (with some extra tiny comments)
<tych0> frobware: http://paste.ubuntu.com/15655607/
<tych0> no luck :(
<tych0> frobware: right, it's the wrong ip
<frobware> tych0, and it machine 1 was bounced?
<tych0> frobware: yeah
<frobware> :(
<tych0> frobware: that's on GCE though
<frobware> tych0, I don't have GCE creds to try...
<tych0> so i guess it doesn't know about spaces or anything?
<frobware> tych0, true. I need to verify what AWS does with master/tip, plus my patch.
<tych0> frobware: yeah, i assume AWS has the same issue
<tych0> jam might know, he's been fiddling with this on aws
<frobware> tych0, I'm just wary of saying that's to be expected because this "bounce the machine" to make it work is just crap
<tych0> frobware: well it seems to me like there's just no network config emitted by juju at all in the non-spaces case
<frobware> tych0, the bounce the agent "appears" to fix the racyness
<tych0> frobware: is that what the "bounce the agent" thing is supposed to fix?
<frobware> tych0, supposed to. bug fix in progress.
<tych0> ah, ok
<frobware> tych0, sometimes you get a case where at least one interface was discovered, but more often that not it's either all or none. Yuck
<frobware> tych0, I will try with aws (probably tomorrow now)
<tych0> ok, np
<frobware> tych0, it's difficult to separate the "no network config" with "no network config (because it's buggy)"
<frobware> tych0, but for the MAAS case it looks like writing a 00-juju.cfg file is going to be the immediate solution.
<tych0> :)
<tych0> right, these are all with the 00-juju.cfg file
<tych0> patch
<tych0> (all my runs, that is)
<tych0> but i still think that's not even it, because shouldn't the profile at least have an interface in it?
<alexisb> cherylj, mattyw, redir can I get one of you guys to review the latest updates from tych0 : http://reviews.vapour.ws/r/4446/ ??
<tych0> even if it does ultimately get blasted away by cloud-init on instance boot, the profile is still wrong
<mattyw> alexisb, will do
<alexisb> thanks mattyw !
<frobware> tych0, yes, it should IMO
<frobware> tych0, fyi - http://pastebin.ubuntu.com/15634033/
<mattyw> tych0, LGTM, might want to add a card to your board to the issue raised by jam
<mattyw> tych0, but otherwise fine
<tych0> mattyw: i don't know what that means :(
<mattyw> tych0, you can land it
<tych0> frobware: right, that is unrelated though isn't it?
<tych0> frobware: all that happens after the instance boots, and lxd won't template eth0.cfg if you don't have an eth0 configured ina  profile somewhere
<tych0> profile or container config
<tych0> mattyw: oh, so i can do the $$merge$$ thing myself?
<frobware> tych0, the FYI bit was where write "00-juju.cfg" came from
<mattyw> tych0, you can indeed
<tych0> frobware: right, that seems reasonable
<tych0> frobware: i'm just wondering if there's an issue even before that in the non-spaces case
<tych0> mattyw: ok, thanks!
<frobware> alexisb, is is possible to get GCE creds to validate/verify LXD/Juju network profile changes that I'm making?
<frobware> tych0, I'm erring on the side of we should (and do) have network info in the non-spaces capable provider. the question is, when it gets to the LXD bits why do we appear to have none.
<tych0> frobware: ah, ok :)
<tych0> frobware: if you have any suspcicions i can poke around a bit
<frobware> tych0, could you please send me the machine-0 (or 1).log with TRACE logging set.
<tych0> frobware: where do i set trace logging?
<frobware> tych0, juju set-model-config 'logging-config=<root>=TRACE'
<frobware> tych0, and deploy another LXD instance
<frobware> tych0, If you could drop that in the mail I'll take a look...
<tych0> frobware: sure, will do
<frobware> tych0, I need to drop. Will sync tomorrow. Thanks for beta-ing my patch. :)
<tych0> frobware: sure, np. i'll send you this log
<tych0> frobware: thanks for the discussion :)
<frobware> tych0, I think we should definitely apply the network profile to the container. It'll mean that we don't litter $(lxc profile list)
<tych0> frobware: cool. hopefully with the api it is easy enough to make the switch
 * frobware heads out to sample ... jellied eels
<tych0> better you than me :)
<sinzui> katco: natefinch: do either of you have a minute to review http://reviews.vapour.ws/r/4459/
<natefinch> sinzui: ship it
<sinzui> thank you natefinch
<natefinch> katco beat me on RB
<katco> #sorrynotsorry
<natefinch> lol
<natefinch> I forgot you had to confirm the shipit button
<bogdanteleaga> is there some docs on working with 2.0?
<bogdanteleaga> especially the new bootstrapping
<mup> Bug #1563607 changed: Handle multi-series charms in 1.25 <charms> <juju-core:Fix Released by gz> <https://launchpad.net/bugs/1563607>
<redir> natefinch: looking at http://reviews.vapour.ws/r/4381 now
<perrito666> bogdanteleaga: dunno, but I can help you
<mup> Bug #1566978 changed: GCE provider output oddities <gce-provider> <ssh> <status> <juju-core:Invalid> <https://launchpad.net/bugs/1566978>
<mup> Bug #1567017 opened: TestDetectSubnetLocal "ip" not in path <centos> <ci> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1567017>
<mup> Bug #1567020 opened: TestLTSSeriesPackages lxd-bridge: permission denied  <ci> <regression> <test-failure> <unit-tests> <wily> <xenial> <juju-core:Triaged> <https://launchpad.net/bugs/1567020>
<cherylj> perrito666: if you're interested in looking into the mongo issues from yesterday, the bug is bug #1566628
<mup> Bug #1566628: Juju cannot bootstrap on xenial without juju-mongodb3.2 package <bootstrap> <mongodb> <juju-core:Fix Committed> <https://launchpad.net/bugs/1566628>
<cherylj> perrito666: my fix was reverting Ian's patch.
<mup> Bug #1546662 changed: juju does not respect --agent-version <2.0-count> <bootstrap> <ci> <juju-core:Fix Released> <https://launchpad.net/bugs/1546662>
 * redir just noticed the "create an issue" tick box when adding a comment in reviewboard....
<perrito666> cherylj: looking
<perrito666> uff, now that I see the error I know what ian did wrong
<perrito666> changing this line https://github.com/juju/juju/pull/5008/files#diff-19525321094e90f6f9962bb888ca0b17L629 to not return when it errs is enough
<perrito666> why on earth would the package not be available for xenial?
<cherylj> perrito666: because the package doesn't exist yet
<perrito666> oh, I assumed they would be building it for various versions
<cherylj> perrito666: it will be available soon
<cherylj> but the package isn't available yet.  at all for any series
<perrito666> oh, that should have broken a lot more than xenial then
<cherylj> and that line you referenced was for upgrade-mongo?   Is that what tries to do the inital install?
<cherylj> perrito666: wily and xenial
<cherylj> perrito666: I think the problem I was running into was that the function that selects the package to try to install does it based on the series of the host, not on the selected version of mongo
<cherylj> specifically, a mongo version is passed to EnsureServer
<perrito666> it is
<cherylj> but isn't used when choosing the package name
<perrito666> that is a bug
<cherylj> ok
<alexisb> perrito666, can you address the bug please so we can get the PR landed?
<perrito666> alexisb: I am confused, you mean re-landed?
<alexisb> perrito666, yes
<alexisb> it was reverted
<alexisb> and we need to land before friday
<thumper> morning folks
<TheMue> thumper: morning (or better evening, at least here *g*)
<thumper> :)
<alexisb> morning thumper
<Makyo_> cherylj: I believe you had the problem with containers being the wrong series for charms deployed to them?
 * TheMue uses the time in a hotel to finish his work on a kind of hierarchical tomb with restarting for his loop package
<cherylj> Makyo: yeah, bug 1564057?
<mup> Bug #1564057: juju2: Charms fail with series mismatch when deployed to containers in bundle <juju-core:Triaged> <https://launchpad.net/bugs/1564057>
<Makyo> cherylj: I've taken over for frankban, and have a PR up at https://github.com/juju/bundlechanges/pull/20 if you're interested.
<cherylj> Makyo: oh sweet, let me take a look
<alexisb> thumper, redir, cherylj starting to look through the helpdocs bugs
<alexisb> for lp 1555248
<alexisb> can we just make the format changes in a comment in the bug and then "+1" so it can be merged?
<cherylj> Makyo: the changes look good, I'm going to build and test
<Makyo> cherylj: awesome, ty
<mbruzek> axw: ping
<alexisb> mbruzek, a little early for him still
<mbruzek> alexisb: What timezone is Andrew in?
<alexisb> he is the wrong side of AUS
<alexisb> I would have to look up the timezone
<mbruzek> OK. thanks for the information.
<rick_h_> lol, who knew there was a right and wrong side of AU
<alexisb> mbruzek, UTC+8 so around 4:30am atm
<cherylj> has anyone been able to bootstrap lxd with tych0's PR (#5004)?
<alexisb> cherylj, I can try really fast
<cherylj> alexisb: could you?  I'm seeing an error "2016-04-06 20:14:50 ERROR cmd supercommand.go:448 invalid config: no addresses match"
<cherylj> but I don't know if that's user error
<alexisb> lovely
<alexisb> yep one sec
<alexisb> I have to kill my current deploy and rebuild master
<redir> cherylj: It worked for me yesterday evening.
<cherylj> redir: had you updated lxd to 2.0.0~rc8-0ubuntu2?
<alexisb>  ./juju bootstrap local lxd --upload-tools
<alexisb> ERROR invalid config: no addresses match
<alexisb> cherylj, ^^
 * cherylj sadface
<cherylj> tych0: is there someone we have to do to get lxd to work with your latest PR (#5004) and lxd 2.0.0-rc8?
<redir> cherylj: I was on lxd 2...rc8-ubuntu3 yesterday
<alexisb> cherylj, it was working for me yesterday
<alexisb> so its something added sense then
<cherylj> I can try the commit before 5004
<redir_> when I tried yesterday it was on tych0's branch
<redir> brb lunch
<cherylj> Makyo: the patch works perfectly!  It fixes the problem from bug 1564057.  But, I didn't test other cases (using a "new"directive for a service, etc)
<mup> Bug #1564057: juju2: Charms fail with series mismatch when deployed to containers in bundle <juju-core:Triaged> <https://launchpad.net/bugs/1564057>
<cherylj> so maybe perfectly wasn't the best description
<cherylj> perfectly for my test case ;)
<cherylj> there
<Makyo> cherylj: awesome, thanks.  Getting other reviews and such from folks, too, but I appreciate it!
<cherylj> Makyo: thank you very very much for taking that bug.  It was on my "must fix" list for 2.0.
<cherylj> Makyo: May I assign the bug to you?
<Makyo> cherylj: yep, that'd be great
<cherylj> kk, thanks again!
<alexisb> Makyo, you can come and fix bugs for us anytime ;)
<Makyo> alexisb: Gladly; Go is so much more fun than JS :)
<redir> Makyo!
<Makyo> redir!
<Makyo> _o/
<redir> :)
<alexisb> cherylj, I am about to disappear into calls again but let me know how the pre-commit master does (if it bootstraps)
<cherylj> alexisb: will do
<redir> fwiw cherylj , alexisb I just bootstrapped lxd with lxd==2.0.0~rc8-0ubuntu5 and juju master @ 97d41bb which includes #5004
<cherylj> alexisb: it's already gotten further :)
<cherylj> so maybe I need to update lxd?  I'm on 2.0.0~rc8-0ubuntu2
<cherylj> if there's a minimum version, we need to make sure we reference it in the release notes
<redir> I had ..ubuntu3 yesterday and it worked.
<redir> deploying hello world, I mean wordpress... and really going for lunch.
<marcoceppi> axw: is type: filesystem valid for storage?
<marcoceppi> mbruzek: ^
<alexisb> people, he is asleep
<mbruzek> marcoceppi:  I already asked here
<alexisb> cherylj, I am running the lastest lxd and it fails
<alexisb> I think it is something that we committed in the last 24 hours
<redir_lunch> alexisb: worked here with latest master and latest lxd
<alexisb> redir_lunch, interesting
<natefinch-afk> redir_lunch, ericsnow: there's a new review from the same macaroon code that has now been rebased and is a real PR here:  http://reviews.vapour.ws/r/4381/   should be mostly the same code with a few very minor differences.  Sorry for the duplicate review
<ericsnow> natefinch-afk: reviewing now
<babbageclunk> thumper: Just added another small note in the maas2 doc - an extra expected error type from ReleaseMachines.
<thumper> awesome, ta
<babbageclunk> thumper: Also, thanks for the chat this morning, really good to get some wider context.
<thumper> all good
<cory_fu> My unit seems to have gone into a weird state where the log is spamming with the same two messages over and over: http://pastebin.ubuntu.com/15660941/
<cory_fu> (This is with juju from charmbox:devel, which I believe is a daily build)
<cory_fu> Or at least beta3
<perrito666> alexisb: ok, right after I finish this Ill fix the bug, it is trivial-ish
<anastasiamac> a review plz :D http://reviews.vapour.ws/r/4456/
<redir> anastasiamac: looking
<anastasiamac> redir: tyvm, but u have already looked at this :D i need a second reviewer as per ur suggestion :D
<redir> anastasiamac: yup nvm
 * redir is too eager
<alexisb> perrito666, thank you!  cherylj is going to open a bug and assign it to you, you lucky dog!
<perrito666> yay, fun day tomorrow :p
<tych0> cherylj: not that i know of
<tych0> cherylj: but i can update to a stock lxd on xenial and see
<axw> marcoceppi: yes, it can be "block" or "filesystem"
<axw> mbruzek: ^^ assuming you were going to ask the same
<alexisb> redir, thumper https://bugs.launchpad.net/juju-core/+bug/1555248
<mup> Bug #1555248: help text for juju destroy-controller needs improving <helpdocs> <juju-core:In Progress by reedobrien> <https://launchpad.net/bugs/1555248>
<tych0> cherylj: so i can bootstrap with current packaged lxd and current juju master
<tych0> oh, but i still have lxcbr0
<tych0> let me get rid of that and try
<tych0> cherylj: i'm also doing --bootstrap-series=xenial
<tych0> cherylj: should i not do that?
<cherylj> tych0: in my case I didn't need to specify bootstrap series
<cherylj> I immediately get this error:  2016-04-06 22:26:55 ERROR cmd supercommand.go:448 invalid config: no addresses match
<tych0> hmm
<tych0> interesting that it was immediate then
<tych0> looks like my bootstrap with no lxcbr0 present also succeeded
<tych0> cherylj: you're doing --upload-tools though i guess?
<cherylj> yeah
<tych0> hmm
<tych0> without --bootstrap-series it works for me too
<tych0> cherylj: what hash are you using?
<tych0> and which lxd package? (dpkg -l | grep lxd
<tych0> )
<cherylj> 2.0.0~rc8-0ubuntu5
<cherylj> and tip of master.
<cherylj> 97d41bb51fbe94f69fd7442e0fb972b58a81f272
<cherylj> is the master commit
<tych0> :(
<tych0> looks like i am using one commit newer than that, but it shouldn't matter
<tych0> just some extra \ns in an unrelated area
<tych0> cherylj: just out of curiosity, what's ifconfig -a on the host?
<cherylj> tych0: http://paste.ubuntu.com/15661846/
<tych0> poop
<tych0> that looks reasonable
<tych0> oh, heh
<tych0> no it doesn't either
<tych0> i bet i know what's going on
<tych0> cherylj: what if you try with,
<tych0> https://github.com/juju/juju/pull/4984
<tych0> cherylj: do you get a better error message?
<cherylj> tych0: give me a few
<tych0> sure, np
<tych0> cherylj: if you just want to get past it,
<tych0> http://tycho.ws/blog/2016/04/lxdbr0.html
<tych0> you need to configure lxdbr0
<tych0> but the branch above should give you a better error message in this case
<mup> Bug #1567104 opened: Unable to connect to API <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1567104>
<alexisb> tych0, I am trying your blog instructions I get this:
<alexisb> ~/gowork/bin$ sudo lxd init
<alexisb> error: You have existing containers or images. lxd init requires an empty LXD.
<alexisb> alexisb@alexisb-ThinkPad-X1-Carbon-2nd:~/gowork/bin$ lxc list
<alexisb> +------+-------+------+------+------+-----------+
<alexisb> | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
<alexisb> +------+-------+------+------+------+-----------+
<alexisb> alexisb@alexisb-ThinkPad-X1-Carbon-2nd:~/gowork/bin$
<tych0> alexisb: try lxc image list
<tych0> you probably have an image cached
<tych0> if you delete that it should let you do it
<thumper> cherylj: just looking at the bug squad cards
<thumper> cherylj: would you like all the headings turned into hyperlinks?
<thumper> I'm ready to click save
 * thumper thigns
<thumper> thinks
<thumper> well, we can disable if you lick
 * thumper sighs
<thumper> like
<cmars> cherylj, alexisb i'm able to bootstrap latest lxd (2.0.0~rc8) with latest juju master
<cmars> just had to name the bridge "lxcbr0"
<tych0> cmars: you shouldn't need to do that at all
<tych0> with current master
<tych0> you /do/ need to have an lxcbr0 with ipv4 subnets configured, though
<cmars> tych0, oh cool, even better :)
<tych0> actually i think the logic in my branch is slightly wrong, it allows ipv4 || ipv6 subnets
<tych0> but juju requires ipv4
<tych0> i don't have time to fix it right now, but i can tomorrow AM
<alexisb> ok tych0 so when I configured the lxdbr0 it worked
<alexisb> that was the issue
<tych0> cool
<tych0> the PR i linked above should give you a better error message
<alexisb> tych0, ok
<alexisb> we should also chat with jam about have juju do the lxd setup
<alexisb> not an urgent thing but something for usability
<alexisb> thanks tych0
<tych0> alexisb: i already got yelled at by mark, hence that PR :)
<alexisb> :)
<tych0> there may be some other things, though
<menn0> cherylj: do you know if this failure is unique to the model-migration feature branch? http://reports.vapour.ws/releases/3861/job/lxd-deploy-xenial-amd64/attempt/475
<menn0> cherylj: my gut says it's not
<tych0> but basically, the docs should all now say `do lxd init before juju bootstrap foo lxd`
<tych0> anyway, gotta run. call time for a show
<redir> is there an option to ignore whitespace in reviewboard?
<alexisb> axw, when you have a moment I want to chat kill-controller stuff
<alexisb> redir, if you are still around could you do a second review of this guy: https://github.com/juju/juju/pull/4984
<alexisb> that way we can get that change merged
<alexisb> redir, scratch that sorry
<axw> alexisb: sorry had to do kid things, back
<alexisb> axw, no worries
<alexisb> I can just jump on your guys standup if you dont mind
<alexisb> we can talk there
<axw> alexisb: sounds good
<anastasiamac> axw: standup?
<axw> alexisb: coming now? or will you be later?
<davecheney>         var err error
<davecheney>         s.client = s.APIState.Client()
<davecheney>         c.Assert(err, jc.ErrorIsNil)
<davecheney> golf clap
<thumper> hahaha
#juju-dev 2016-04-07
<cherylj> menn0: I can take a look later (after I put the kid to bed)
<cherylj> tych0 - running lxd init; systemctl restart lxd.service worked to get the lxd provider to bootstrap
<menn0> cherylj: thank you (no rush)
<cherylj> tych0: will juju need to do that when provisioning lxd containers (using deploy --to lxd)?
<redir> cherylj: is there a kanban board with the helpdocs updates on it?
<anastasiamac> redir: i think bug squad is still it..
<anastasiamac> redir: i'll pm u :D
<cherylj> redir: I haven't been keeping up to date on all the helpdocs bugs and their comments
<cherylj> redir: might be a good idea to change the titles of them once they've been acked and are ready to merge....  makes it easy to quickly search for them in lp
<redir> cherylj: anastasiamac got me to the board. So I can move cards appropriately.
<cherylj> redir: they're not all there, btw
<cherylj> feel free to add if you'd like
<redir> cherylj: will do when I get to one in lp that isn't on the board.
<cherylj> redir: if you're interested, bug 1566237 is an easy non-help docs bug
<mup> Bug #1566237: juju ssh doesn't work with multiple models <juju-core:Triaged> <https://launchpad.net/bugs/1566237>
<redir> cherylj: k
<mup> Bug #1567161 opened: juju2 beta3, cannot download charm, failed to download, 400 <landscape> <juju-core:New> <https://launchpad.net/bugs/1567161>
<mup> Bug #1566843 changed: juju add-credential should set default when there is only one credential (when using interactive mode) <docteam> <juju-release-support> <usability> <juju-core:Invalid by axwalk> <https://launchpad.net/bugs/1566843>
<mup> Bug #1567169 opened: juju deploy bundle does not honor existing machine definitions <conjure> <juju-core:New> <https://launchpad.net/bugs/1567169>
<redir> so if I want to run one test a la `go test . -name TestThatIWantToRun` do I need to do something special for gocheck to honor that?
<anastasiamac> axw: I wonder if TerminateInstances call should be re-written to use retry too instead of shortAttempt...
<axw> anastasiamac: probably
<anastasiamac> redir: go test -gocheck.v -gocheck.f TestYouWant
<anastasiamac> redir: which I think is a regular expression, so u can have both 'myTestSuite' or 'individualTestName' or whatever matching...
<redir> thank you
<redir> if it is a pass through then it should be a regexp
<redir> and thank you
<anastasiamac> u r welcome \o/
<mup> Bug #1567170 opened: Disallow upgrading with --upload-tools for hosted models <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1567170>
<mup> Bug #1567175 opened: Service start is not reliable with any network initialization issues <juju-core:New> <https://launchpad.net/bugs/1567175>
<redir_eod> see you all tomorrow sometime
<thumper> o/ redir_eod
<mup> Bug #1567179 opened: ec2 terminate instances should retry with exponential delay on err <juju-core:New> <https://launchpad.net/bugs/1567179>
<mup> Bug #1567182 opened: Fallback to installing mongo 2.4 if no 3.2 doesn't work <mongodb> <juju-core:Triaged by hduran-8> <https://launchpad.net/bugs/1567182>
<davecheney> menn0: while i'm waiting for other thigns
<davecheney> i started a set of PR's about testing that we talked about
<davecheney> https://github.com/juju/juju/pull/5023
<menn0> davecheney: taking a look
<menn0> davecheney: very nice. land it!
<cherylj> menn0: that lxd failure has been hit on other branches, so it's not unique to model migrations
<menn0> cherylj: ok good
<davecheney> menn0: thanks
<davecheney> lots more where that came from
<cherylj> oh god
<cherylj> I hacked distro-info to return xenial as the lts
<cherylj> to see what fails in unit tests
<cherylj> so many failures
<natefinch> was gonna say, maybe you should catalog what passes.  Might be faster.
<cherylj> lol
<mup> Bug #1567169 changed: juju deploy bundle does not honor existing machine definitions <conjure> <juju-core:Invalid> <https://launchpad.net/bugs/1567169>
 * cherylj cries
<cherylj> we're going to be screwed in 2 weeks
<cherylj> better to know now?
<rick_h_> cherylj: more time for wine between now and then?
<cherylj> rick_h_: I wish.  We gotta fix these or else we will not be able to release anything once xenial is our official lts
<rick_h_> cherylj: understand, it's 11pm have to go light hearted
<natefinch> cherylj: really really smart to check that.... sorry the results weren't more in our favor.
<mup> Bug #1567169 opened: juju deploy bundle does not honor existing machine definitions <conjure> <juju-core:Invalid> <https://launchpad.net/bugs/1567169>
<cherylj> 92 test failures so far
<cherylj> well, to be fair, there are some lxd failures because I don't have lxd on my laptop
<cherylj> so maybe 80
<natefinch> man, I really hate that our code cares what series exist and relies on that data never to change and never to be out of date.
<cherylj> 2 years is forever, man
<cherylj> trusty 4 lyfe
<natefinch> cherylj: 2 years my butt. This happens every 6 months when a new series comes out and also as a bonus, whenever we get a new windows or OSX release... I suppose probably centos as well.
<mup> Bug #1567169 changed: juju deploy bundle does not honor existing machine definitions <conjure> <juju-core:Invalid> <https://launchpad.net/bugs/1567169>
<cherylj> haha
<cherylj> and what unit test run would be complete without a test timeout!!
<cherylj> I wonder how many would pass if we set testing.FakeDefaultSeries = xenial
<cherylj> or, what we should do is testing.FakeDefaultSeries = actualDefaultSeries
<cherylj> and people can patch
<cherylj> if they need to
<cherylj> anyway that's a problem for tomorrow Cheryl
<rick_h_> night cherylj
<natefinch> poor tomorrow Cheryl
<cherylj> yeah, yesterday Cheryl is terrible
<cherylj> :)
<natefinch> lol... yeah, I hate yesterday Nate. That guy's an idiot.
<davecheney> func (s *BaseRepoSuite) SetUpSuite(c *gc.C)    {}
<davecheney> func (s *BaseRepoSuite) TearDownSuite(c *gc.C) {}
<davecheney> great
<davecheney> that's just great
<anastasiamac> davecheney: we should have this on the t-shirt "juju, just great"
<menn0> thumper: easy review pls http://reviews.vapour.ws/r/4466/
<menn0> davecheney: http://reviews.vapour.ws/r/4466/ pls
<davecheney> lookin'
<davecheney> LGTM, mostly harmless
<menn0> davecheney: ta
<davecheney> menn0: https://github.com/juju/juju/pull/5025
<davecheney> more of the same
<natefinch> ahhh... damn macaroons
<mup> Bug #1567228 opened: "juju destroy-controller" can leak hosted models <juju-core:Triaged> <https://launchpad.net/bugs/1567228>
<frobware> dimitern, if you need an immediate fix for the broken /e/n/i try this http://pastebin.ubuntu.com/15653945/
<dimitern> frobware, cheers, I'll try this on the next test I'm doing shortly
<frobware> dimitern, it's obviously not the complete story... but is in essence the fix
<frobware> dimitern, any joy with the case where the first add-machine lxd:0 fails?
<dimitern> frobware, sorry, I had to step afk
<dimitern> frobware, well, add-machine lxd:0 only works (post-bootstrap), if you first juju switch admin, is that what you mean?
<dimitern> frobware, otherwise it says no such machine 0
<dimitern> but apart from that, yes - it still fails, still digging..
<frobware> dimitern, nope. if you switch to :admin and add-machine lxd:0 the first one fails to work until the agent is restarted on the node hosting the container.
<frobware> dimitern, I think we're saying the same things (give or take the model switch)
<dimitern> frobware, yeah
<dimitern> frobware, :) I was about to write the same thing
<thumper> frobware, dimitern: why is there no standup listed for today?
<thumper> voidspace, babbageclunk: care to hangout to discuss maas2?
<thumper> I was awaiting a standup that doesn't appear to be scheduled
<voidspace> thumper: team meeting today at 11am instead
<voidspace> thumper: but sure
<thumper> I'm not going to hang around for that
<voidspace> thumper: that's our loss
<thumper> ow, ow, ow.... cramp
 * thumper stretches
<voidspace> dimitern: we could use you to talk to babbageclunk and thumper about the link layer model and what information we need from maas
 * thumper is in the sapphire normal standup hangout
<voidspace> dimitern: currently the maas 1 code uses stuff like link.Parent() and IPAddresses that don't seem to exist in MAAS 2
<thumper> well it does
<voidspace> thumper: omw
<thumper> ..
<thumper> hmm
<dimitern> oops sorry guys, omw
<dimitern> voidspace, babbageclunk, thumper, standup HO?
<voidspace> dimitern: we're there
<voidspace> dimitern: hello
<dimitern> babbageclunk, dooferlad, frobware, join us guys for standup?
<dooferlad> dimitern: sure. URL?
<babbageclunk> Coming now
<mup> Bug #1567296 opened: Plugin API fails with multiple juju binaries <juju-core:New> <https://launchpad.net/bugs/1567296>
<rogpeppe> anyone know what the best way to shut down a juju lxd provider controller is when juju won't let me (probably because i started it with an old juju version) ?
<davecheney> whoopse, that was rather aburpt
<davecheney> sorry about that
<mgz> rogpeppe: the best way has been build that old env and kill-controller with that
<rogpeppe> mgz: unfortunately i've no idea what version i used to bootstrap the old env
<rogpeppe> mgz: i think i need to go behind the scenes
<rogpeppe> mgz: but my naive approach ("lxd shutdown") doesn't seem to have got me to a good place
<rogpeppe> mgz: i just removed $HOME/.local/share/juju and now i'm getting "ERROR invalid config: no addresses match"
<rogpeppe> mgz: when i try "juju bootstrap local lxd"
<rogpeppe> mgz: :-(
<rogpeppe> mgz: AFAIK i haven't *got* a config
<mgz> rogpeppe: yeah, it's a joy
<rogpeppe> mgz: i've just proposed https://github.com/juju/cmd/pull/35 to make it easier to debug that kind of error message
<rogpeppe> mgz: that makes the error somewhat more informative... 2016-04-07 10:25:39 DEBUG cmd supercommand.go:449 error details: [{github.com/juju/juju/cmd/juju/commands/bootstrap.go:406: } {github.com/juju/juju/environs/open.go:104: } {github.com/juju/juju/environs/open.go:175: } {github.com/juju/juju/provider/lxd/provider.go:44: } {github.com/juju/juju/provider/lxd/environ.go:43: invalid config} {github.com/juju/juju/provider/lxd/config.go:
<rogpeppe> 182: } {github.com/juju/juju/provider/lxd/config.go:255: } {github.com/juju/juju/tools/lxdclient/config.go:65: } {github.com/juju/juju/tools/lxdclient/remote.go:199: } {no addresses match}]
<mgz> didn't that used to have prettier formatting?
<voidspace> frobware: dimitern: babbageclunk: doing a merge of master onto maas2
<voidspace> frobware: dimitern: babbageclunk: some fixing to do as anastasiamac fixed a maas bug that changes the maasInstance interface
<babbageclunk> voidspace: nothing too nasty I hope?
<rogpeppe> mgz: possible. i don't care much :)
<voidspace> babbageclunk: maasInstance.zone() now returns an error - so the interface definition and our maas2Instance implementation need updating
<rogpeppe> mgz: FWIW the error is because juju's looking for netif lxdbr0 but my machine only has lxcbr0
<voidspace> babbageclunk: plus there are a bunch of new tests that do a type cast to maasInstance that should now be maas1Instance
<voidspace> babbageclunk: plus another bugfix by davecheney in maas storage
<voidspace> babbageclunk: nothing too nasty, no - easy enough
<perrito666> morning
<rogpeppe> mgz: ha, i upgraded lxd and now there *is* an lxdbr0 interface but it doesn't have any ipv4 addresses so i get the same failure
<rogpeppe> anyone used the lxd provider with the latest juju, by any chance?
<TheMue> morning perrito666
<rogpeppe> voidspace: do you know anything about this issue, by any chance?
<rick_h_> rogpeppe: there's an email thread.on the juju list around this i think
<rick_h_> rogpeppe: from yesterday
<rogpeppe> rick_h_: yeah, just looking for it
<rogpeppe> rick_h_: found
<rogpeppe> rick_h_: i don't think it helps me though
<rogpeppe> rick_h_: there's no "lxd-bridge" service on my machine AFAICS.
<voidspace> rogpeppe: no, afraid not
<voidspace> rogpeppe: I just saw an upgrade do the same thing (well - change the bridge name) on my server too though
<voidspace> rogpeppe: jam might know if he's still around
<rogpeppe> voidspace: yeah, it seems to break everything
<voidspace> :-(
<voidspace> or maybe frobware I know he's done a lot of work with lxd
<rogpeppe> voidspace: i guess i need to create an ipv4 address on the bridge somehow
<voidspace> rogpeppe: it should *get* an ipv4 address
<voidspace> so it's odd
<rogpeppe> voidspace: it really seems that it shouldn't *need* an ipv4 address anyway
<rogpeppe> voidspace: aren't we supposed to work with ipv6?
<voidspace> maybe look in /etc/network/interfaces and see how the bridge is defined
<rogpeppe> voidspace: good idea
<voidspace> rogpeppe: I'm not convinced I think we've *tried* to be compatible but not been thorough
<rogpeppe> voidspace: FWIW ifconfig shows this: http://paste.ubuntu.com/15667206/
<voidspace> rogpeppe: and ifdown/ifup iit
<rogpeppe> voidspace: well, utils.GetAddressForInterface discards all ipv6 addresses...
<voidspace> rogpeppe: no packets dropped and some traffic
<voidspace> rogpeppe: we have a preferIPv6 setting somewhere - does that code not honour it
<rogpeppe> voidspace: almost nothing in /etc/network/interfaces
<rogpeppe> voidspace: just two lines:
<rogpeppe> auto lo
<rogpeppe> iface lo inet loopback
<rogpeppe> voidspace: nothing in interfaces.d either
<voidspace> oh, odd
<voidspace> I wonder where it is - this is xenial?
<rogpeppe> voidspace: nope, trusty
<voidspace> ah
<voidspace> I've not worked with trusty networking - I can commission a trusty box though
 * rogpeppe has been meaning to find the time to reinstall from scratch for *ages*
<dimitern> rogpeppe, for trusty you need to add "trusty-backports" to /e/apt/sources.list && sudo apt-get update && sudo apt-get install -t trusty-backports lxd
<rogpeppe> dimitern: like: add-apt-repository trusty-backports ?
<dimitern> rogpeppe, voidspace, prefer-ipv6 is no longer respected (always false), but the setting itself is not gone yet (will be soon though)
<rogpeppe> dimitern: hiya BTW :)
<dimitern> rogpeppe, it's not a repo, it's a cloud pocket or something like that
<dimitern> rogpeppe, ;) hey
<rogpeppe> dimitern: what exact line(s) do i need to add for /etc/apt/sources.list ?
<dimitern> rogpeppe, if you paste yours, I can show you - can remember off-hand
<rogpeppe> dimitern: paste what?
<dimitern> rogpeppe, /etc/apt/sources.list from the trusty machine in question
<rogpeppe> dimitern: the current contents of my sources.list
<rogpeppe> dimitern: https://pastebin.canonical.com/153655/
<dimitern> rogpeppe, actually - here's a wiki page: https://help.ubuntu.com/community/UbuntuBackports
<dimitern> rogpeppe, so you need a line like this somewhere: deb http://archive.ubuntu.com/ubuntu trusty-backports main restricted universe multiverse
<dimitern> rogpeppe, but looking at your paste you seem to have it enabled already
<rogpeppe> dimitern: yeah
<dimitern> rogpeppe, so just apt-get update && apt-get install lxd/trusty-backports should work now
<rogpeppe> dimitern: still same problem after doing that
<dimitern> rogpeppe, the container still did not start?
<rogpeppe> dimitern: juju refuses to do anything because the interface has no ipv4 addresses
<dimitern> rogpeppe, lxdbr0 ?
<rogpeppe> dimitern: yeah
<dimitern> rogpeppe, hmm I'm not that familiar with lxdbr0 specifics, but you should be able to use "lxc-bridge: lxcbr0" in your bootstrap config
<dimitern> rogpeppe, provided lxc1 package is also installed and lxcbr0 exists
<voidspace> dimitern: frobware: babbageclunk: dooferlad: merge master onto maas2 http://reviews.vapour.ws/r/4473/
<rogpeppe> dimitern: i'd prefer to be able to bootstrap without using that tbh
<rogpeppe> dimitern: but i'll try it
<dimitern> rogpeppe, well, on trusty lxd is still kinda flaky; btw you might instead need to change /etc/default/lxd to enable IPv4 addresses
<dimitern> rogpeppe, check this, it might help - https://github.com/lxc/lxd/pull/971/files
<rogpeppe> dimitern: unknown config field "lxc-bridge"
<dimitern> rogpeppe, ah, sorry - that's no longer supported yeah :/ - I guess the second option then - changing /e/d/lxd (or lxd-bridge) there to provide IPv4 addresses
<voidspace> dimitern: frobware: dooferlad: babbageclunk: branch adding a feature flag for the MAAS 2 work http://reviews.vapour.ws/r/4474/
<rogpeppe> dimitern: /etc/default/lxd doesn't exist for me
<rogpeppe> dimitern: ah, but lxd-bridge does
<dimitern> rogpeppe, right - there
<dimitern> voidspace, looking
<rogpeppe> dimitern: hmm, i added a bunch of ipv4 stuff in lxd-bridge, restarted lxd (sudo initctl restart lxd), but no ipv4 addresses seem to be arriving
<rogpeppe> dimitern: FWIW my lxd-bridge file now looks like this: http://paste.ubuntu.com/15667827/
<dimitern> rogpeppe, try adding a new container
<rogpeppe> dimitern: is that easy? i've not used lxd directly before.
<anastasiamac> voidspace: in fact, if possible, it'd be awesome if any property accessors from maas instance also returned errors... it was very sad that we were swallowing that one :/
<rogpeppe> dimitern: is the lxd command the way to do it?
<rogpeppe> dimitern: (i don't see anything that talks about creating a new container in its help)
 * rogpeppe googles
<dimitern> rogpeppe, lxc launch ...
<rogpeppe> dimitern: not lxd?
<dimitern> rogpeppe, lxc is the cli client, lxd is the server daemon
<dimitern> voidspace, LGTM
<rogpeppe> dimitern: ok, now i have to work out how to fetch an image...
<dimitern> https://linuxcontainers.org/lxd/getting-started-cli/ << nice guide
<dimitern> rogpeppe ^^
<rogpeppe> dimitern: ah, launch ubuntu failed but launch ubuntu:14.04 worked
<rogpeppe> dimitern: still no ipv4 address
<dimitern> rogpeppe, I think juju adds an alias "ubuntu" for the current series image
<dimitern> rogpeppe, ah :/ bad luck - folks in #server @c might be able to help
<rogpeppe> dimitern: i'll just give up and use ec2 i think. i've already spent too much time chasing this.
<rogpeppe> dimitern: thanks for your help.
<voidspace> dimitern: thanks
<voidspace> anastasiamac: the way we interact with maas has completely changed
<voidspace> anastasiamac: isn't it horrifically late for you now?
<dimitern> rogpeppe, np
<voidspace> dimitern: shall I just land the master merge?
<voidspace> dimitern: http://reviews.vapour.ws/r/4473/
<anastasiamac> voidspace: i had a preview of new maas abstraction (peeked at thumper's branch)! it's awesome \o/ thank you for doing it!
<voidspace> anastasiamac: yeah, it's very cool - all thumper's work, we're just using
<anastasiamac> voidspace: it's 10pm... for normal ppl probably not a work hour... but who here respects that? :D
<voidspace> anastasiamac: ah, I thought it was later
<voidspace> heh
<anastasiamac> voidspace: r u re-writting maas19 interactions in similar way too?
<anastasiamac> or it stays the same?
<dimitern> voidspace, does it build and pass make check?
<babbageclunk> voidspace: sorry, been talking to frobware, not doing much typing
<mup> Bug #1567396 opened: tools/lxdclient should not be using a global variable for several functions <lxd> <tech-debt> <testing> <juju-core:Triaged> <https://launchpad.net/bugs/1567396>
<frobware> dooferlad, ping
<dooferlad> frobware: pong
<frobware> dooferlad, can we HO about the bond issue - was interested in your repro case
<voidspace> anastasiamac: probably not, too much work :-(
<dooferlad> frobware: sure, but I really need lunch
<voidspace> anastasiamac: MAAS 2 is new code so worth doing right
<dooferlad> frobware: can it wait 30 minutes?
<frobware> dooferlad, whenever works
<dooferlad> frobware: thanks!
<voidspace> dimitern: yep, builds and passes
<voidspace> dimitern: I had some conflict resolution to do - nothing too difficult though
<anastasiamac> voidspace: sounds sensible
<voidspace> babbageclunk: my feature flag change has landed on MAAS2
<babbageclunk> voidspace: Sweet
<voidspace> babbageclunk: so after you update you'll need to set the MAAS2 feature flag to bootstrap against MAAS 2.0
<dimitern> voidspace, lgtm
<voidspace> anastasiamac: it would certainly be possible, and nicer... so if anyone has any spare time :-)
<voidspace> dimitern: ta
<anastasiamac> voidspace: well, i don't think it's worth it... but the decision should b based on maas.19 life expectancy ... if it's to be short-lived, I'd say that what we have now will do...
<voidspace> anastasiamac: yeah
<voidspace> nobody ever has any spare time anyway
<anastasiamac> so true
<rogpeppe> could i have a review on this almost-entirely-trivial one line change, please? it should make some things easier to debug in the future. https://github.com/juju/cmd/pull/35
<dooferlad> frobware: back
<natefinch> rogpeppe: would prefer not to log the error twice
<natefinch> rogpeppe: can you do an if debug enabled...
<frobware> dooferlad, was your repro case with h/w?
<dooferlad> frobware: yes
<frobware> dooferlad, as opposed to KVM
<rogpeppe> natefinch: what would you do by preference? it's *really* useful to be able to see the error details.
<rogpeppe> natefinch: you'd print the error differently if debug enabled?
<rogpeppe> natefinch: i think it's kinda reasonable to have a separate debug line exposing details of the error without changing the usual error printing
<natefinch> rogpeppe: yes... details if debug enabled, otherwise just the string..... otherwise you're printing the error twice, which could be confusing, make it look like we did something twice
<rogpeppe> natefinch: tbh i think we'd want the error details on a separate line for readability anyway
<rogpeppe> natefinch: perhaps a better error message string would felp?
<rogpeppe> help
<natefinch> rogpeppe: I just worry that two log entries would be confusing. Maybe if debug is enabled, append the details to the single errorf log message?
<rogpeppe> natefinch: if you do that, that line becomes very unwieldy
<rogpeppe> natefinch: i think it should be reasonably obvious - one's at debug level and they both contain the same text.
<rogpeppe> natefinch: perhaps surround it all in brackets? "(error details: xxxx)" and print after the main error message?
<natefinch> rogpeppe: then put a comment in the code that states you're doing it on purpose, otherwise someone's going to come along and "clean up" the "duplicate" log output.
<natefinch> rogpeppe: I do think after is better than before
<natefinch> rogpeppe: and brackets will make it more obvious that it's not just another instance of the error.
<natefinch> rogpeppe: and maybe use a sans-serif font, since that'll make it stand out more.
<rogpeppe> natefinch: :)
<mup> Bug #1567458 opened: destroy-controller message and failure is not user friendly <juju-core:New> <https://launchpad.net/bugs/1567458>
<rogpeppe> natefinch: better now? https://github.com/juju/cmd/pull/35/files
<natefinch> rogpeppe: lgtm
<rogpeppe> natefinch: thanks
<alexisb> morning all
<dooferlad> morning alexisb
<perrito666> hi alexisb
<kwmonroe> hey tych0, does your lxdbr0 fix always return 'lxdbr0', or do we check elsewhere for whatever the user configured?  (https://github.com/juju/juju/pull/5004/files#diff-d0829a0ea5ffc060343eba40ecd40aa8R66)
<tych0> kwmonroe: yes, that only gets called when the user hasn't configured anything
<tych0> kwmonroe: expand the last hunk of the diff and you can see
<voidspace> babbageclunk: StartInstance can allocate and start a machine
<voidspace> babbageclunk: and I've done as much of StartInstance as is possible without further work in gomaasapi
<voidspace> babbageclunk: now to test it all...
<voidspace> babbageclunk: don't forget to write up what you've done in the doc
<kwmonroe> cool tych0, thx
<frobware> babbageclunk, http://juju-sapphire.github.io/
<frobware> babbageclunk, https://github.com/dimitern/testcharms
<perrito666> cherylj: ping
<babbageclunk> voidspace: nice! I've got the storage stuff done, although not tested yet. Need to merge your master merge.
<cherylj> hey perrito666, what up
<voidspace> babbageclunk: cool
<babbageclunk> voidspace: will write up now
<voidspace> babbageclunk: I found another undocumented parameter to AllocateMachine
<voidspace> babbageclunk: storage....
<babbageclunk> voidspace: yay
<perrito666> hey, I am trying to test my fix using lxd provider but I get a permission denied on my instances :( when juju tries to ssh, did you enconter this issue testing with xenial?
<voidspace> babbageclunk: so storage and spaces are not yet supported, but trivially easy to add them
<babbageclunk> voidspace: why not spaces?
<voidspace> babbageclunk: because interfaces parameter is missing on AllocateMachineArgs
<voidspace> that's the first undocumented parameter, storage is the second
<perrito666> cherylj: that was for you
<voidspace> they haven't changed since 1.9 - but they weren't documented there either...
<babbageclunk> voidspace: ah, right - thought you meant because storage isn't done yet
<cherylj> perrito666: I'm thinking of what might be causing that....
<voidspace> babbageclunk: no, you specify storage to AllocateMachine (as well as the storage specific code)
<voidspace> babbageclunk: I'm off to do some exercise - bbiab
<cherylj> perrito666: when are you running into this?  during bootstrap?
<cherylj> perrito666: do you have a --debug output you could paste?
<voidspace> babbageclunk: what happened with StopInstances - is it done?
<voidspace> babbageclunk: I need that too really, it's used by StartInstance
<perrito666> cherylj: during bootstrap everything seems fine until the moment where it has to try logging int
<perrito666> which is odd because the ubuntu user has the right credentials in authorized keys
<cherylj> perrito666: what's your host?  xenial?
<perrito666> wily
<babbageclunk> voidspace: It's done but not tested - it needed storage so I parked it while I was doing that.
<babbageclunk> voidspace: Once storage is merged and pushed I'll merge storage into stop instances and push that too.
<babbageclunk> Then you can use both/
<mup> Bug #1567518 opened: Payload commands don't work <juju-core:New> <https://launchpad.net/bugs/1567518>
<cherylj> perrito666: could you humor me and paste the --debug output?
<cherylj> redir_afk: your PR: https://github.com/juju/juju/pull/5022 is going to conflict with one of mine because I also removed that lower case test :)
<cherylj> it's a race to merge!!
<perrito666> cherylj: sure I was waiting for it to finish
<perrito666> cherylj: https://pastebin.canonical.com/153710/
<cherylj> oh oh oh I think I may know
<cherylj> perrito666: are you in the lxd group?
<perrito666> yes
<cherylj> I thought I saw something similar
<cherylj> damn
<cherylj>  not that then
<cherylj> why is it connecting to 10.0.3.1??
<cherylj> perrito666: can you run lxd list and see what the IP is for juju-bf76fca1-e52a-4c5a-877e-650f42945363-machine-0?
<cherylj> sorry lxc list
<perrito666> well it was destroyed by juju now but it was
<perrito666> juju-bf76fca1-e52a-4c5a-877e-650f42945363-machine-0 | RUNNING | 10.0.3.1 (lxcbr0) |      | PERSISTENT | 0
<cherylj> perrito666: did you update lxd and do all that reconfiguring?
<perrito666> cherylj: yup
 * perrito666 tries trusty
<cherylj> and did you configure it to use lxdbr0?
<cherylj> I think this is the same issue that they're running into in CI
<perrito666> I changed my lxd to use lxcbr0
<perrito666> cherylj: I found that issue yesterday and fixed it right away
<cherylj> perrito666: I think this is a lxd or config issue - I don't think any instance should be assigned the bridge IP (10.0.3.1)
<perrito666> the problem happens only when using xenial, odd
<cherylj> perrito666: I'm going to play with the machine in CI that's also running into this and see what I can do
<perrito666> tx
<perrito666> the problem is not present in trusty
<perrito666> its  https://cloud-images.ubuntu.com/releases/ the place where images should be being downloaded from?
<perrito666> cherylj: confirmed, this happens with xenial image
<frankban> cherylj: is http://reports.vapour.ws/releases/3868/job/run-unit-tests-xenial-amd64/attempt/788 really related to embedded-gui? or is it a known problem?
<cherylj> frankban: that looks like a CI issue.
<cherylj> not related to the branch
<frankban> cherylj: sorry. I meant http://reports.vapour.ws/releases/3868/job/lxd-deploy-xenial-amd64/attempt/491
<cherylj> frankban: not an issue with your branch.  I am working to get that fixed atm :)
<frankban> cherylj: ccol, so embedded-gui is clean (at least latest branch), I am merging another one there
<frankban> cherylj: ty
<cherylj> np!
<cherylj> frankban: is the --no-gui bootstrap flag the last piece for that branch?
<frankban> cherylj: yes, if QA goes ok it's the last one
<cherylj> k, thanks!  (and thank you for having makyo pick up that bundle bug!)
<frankban> cherylj: so I am thinking about merging embedded-gui into master tonight or tomorrow morning, after QA
<frankban> cherylj: np
<cherylj> frankban: we will merge it for you once it gets a good CI run
<cherylj> so no need to worry about that
<frankban> cherylj: awesome!
<cherylj> and we'll let you know if there are problems too :)
<frankban> cherylj: cool
<frankban> cherylj: oh, after this one lands I'd have to merge master back into embedded-gui, so that we can start QAing with new lxd stuff etc. is that a problem?
<perrito666> cherylj: is there any other way that I can test my fix? are there xenial images in amazon?
<cherylj> frankban: can you work directly on master once we land embedded-gui?  If your changes aren't radical / pervasive, you should do that
<cherylj> perrito666: yes :)  bootstrap on aws with default-series=xenial works  just fine :)
<perrito666> tx a lot
<frankban> cherylj: when are we landing embedded-gui?
<cherylj> frankban: after it gets a good CI run
<frankban> cherylj: ok, ack
<cherylj> so if everything passes, today or tomorrow
<frankban> cherylj: ok, so I'll not merge master back, so we'll have a single CI run, correct?
<cherylj> frankban: when did you last merge master?
<frankban> cherylj: Apr 4 13:44:16
<cherylj> frankban: yeah, I'd re-merge master before we do another CI run.  There have been fixes to CI failures since then
<frankban> cherylj: ok, I'll do that asap then
<cherylj> thx!
<frankban> cherylj: --no-gui just landed, Il'' merge master
<redir> cherylj: let me know what order you prefer
<frankban> cherylj: ok mrege job is running https://github.com/juju/juju/pull/5036
<perrito666> aghhh xenial really hates me
<perrito666> finally booting, bbl in about one hour, mail me if anybody needs me
<lazyPower> So, i'm not sure what to plug in a bug here if someone has a second to lend a hand so i can file a bug about this properly i'd appreciate the help - https://youtu.be/ApLWbc2qQ30  <-- illustration of the issue
<rick_h_> lazyPower: you killed it!
<rick_h_> lazyPower: so...it sure looks like storage-get somehow took down the stateserver?
<rick_h_> lazyPower: can you juju status outside of the debug-hook?
<cherylj> ....um... I'm pretty sure that we shouldn't be setting the lxc bridge address as an API Host port for the lxd provider
<cherylj> Has anyone deployed a service in lxd recently?
<alexisb> cherylj, I have been trying but failing
<cherylj> I've gotten lxd to bootstrap
<alexisb> though before service deploy
<alexisb> my controller bootstraps
<alexisb> and hosted model fails
<cherylj> but the service deployed just stays in " Waiting for agent initialization to finish "
<cherylj> fudgey mcfudgeington
<alexisb> lovely
<alexisb> heh
<cherylj> I look at the log and it's trying to connect on the WRONG IP to the controller
<alexisb> cherylj, dont you like opening bugs??
<cherylj> well, I don't really need to triage bugs that I open, so that's something, right?
<cherylj> heh
<alexisb> o the bright side
<alexisb> see rick_h_ cherylj knows how to see the bright side ;)
<cherylj> nice
<rick_h_> the bright side is the best side!
<mbruzek> cherylj: I tried to bootstrap lxd today, did not get it to work.  ERROR failed to bootstrap model: waited for 10m0s without getting any addresses
<cherylj> sinzui_: the bright side here is that I got lxd to bootstrap on the xenial slave
<cherylj> sinzui_: the bad part is that agents talk to the wrong IP for the state server
<sinzui_> cherylj: but the test still doesn't pass http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/lxd-deploy-xenial-amd64/492/console
<cherylj> sinzui_:  is the revision stale?  I was getting that until I pulled master again
<sinzui_> cherylj: ^ I can seen this setup container/vm non sense before and I had to update severalt hings
<cherylj> mbruzek: I just worked around that issue in our CI machines.  I had to do the dpkg-reconfigure lxd step mentioned in the thread
<lazyPower> rick_h_ - sorry about missing the messages, not sure what happened... some weirdness with my znc i guess... 1 sec while i get you the status output
<sinzui_> cherylj: master? maybe I should make it the most important thing to test next
<cherylj> sinzui_: yeah, I was pulling from master
<mbruzek> cherylj:  I read that, but if I work around it now, will I not have to undo the workaround when Juju fixes the problem?
<rick_h_> lazyPower: yea, the question is that you seem to lost connectivity to the state server, so is that it went down for everyone? or just something on that unit you were on? or what
<lazyPower> just that unit it appears, and it comes back
<lazyPower> its like storage-get is segfaulting or getting an invalid token?
<lazyPower> https://gist.github.com/f8f928f5927cd08c55200d6d91652754
<lazyPower> there's an error to that effect in one of the debug-hook sessions
<mup> Bug #1567594 opened: upgrade-gui command isn't in the juju tab complete <juju-core:New> <https://launchpad.net/bugs/1567594>
 * lazyPower fishes that up as well
<mbruzek> cherylj: so my question is if I work around it. Wil I have to undo that change when it is fixed
<mbruzek> ?
<cherylj> mbruzek: my understanding is that the dpkg-reconfigure step is going to be a permanent thing on the lxd side as part that update.
<lazyPower> http://paste.ubuntu.com/15676295/ <- that thing is what i was referring to about the session being mismatched
<cherylj> mbruzek: as long as there isn't another lxd update that breaks things
<cherylj> mbruzek: this should be a one time thing
<cherylj> mbruzek: and changes in master (not beta3) will be fixing this "for good"
<mbruzek> cherylj: Wouldn't we want to change Juju to look for the new device?
<lazyPower> aha paydirt, there's a treasure trove of stacks in the log
<cherylj> well
 * lazyPower fires up a bug
<cherylj> mbruzek: those changes are in master
<rick_h_> lazyPower: hmm, yea. I'd go with a bug along the lines of "storage-get causes state server to 'error: bad request'
<cherylj> mbruzek: and will be part of the release next week
<mbruzek> cherylj: So my  understanding is the old lxd named the bridge one way, the  new lxd names it something new, so the fix is to reconfigure lxd to use the old name.
<mbruzek> cherylj: I figured Juju was just going to start looking for the new name.
<mbruzek> cherylj: Or am I misunderstanding the email thread?
<cherylj> mbruzek: yeah, that's how you can get it working with beta3.  The changes in master are to make juju smarter about choosing the name, I believe
<cherylj> not hard coding
<mbruzek> cherylj: perfect
<mbruzek> cherylj: Thank you for explaining it to me.
<cherylj> mbruzek: no worries, it helped me too...  and I see in the code that we look first for lxdbr0, then fall back to lxcbr0 if not present
<lazyPower> https://bugs.launchpad.net/juju-core/+bug/1567598
<mup> Bug #1567598: storage-get causes state server to 'error: bad request' <juju-core:New> <https://launchpad.net/bugs/1567598>
<cherylj> latent bug alert!
<cherylj> heh
<cherylj> these lxd issues have revealed a latent bug in the lxd provider
<mup> Bug #1567598 opened: storage-get causes state server to 'error: bad request' <storage> <juju-core:New> <https://launchpad.net/bugs/1567598>
<redir> can I set an env variable via gocheck to have it pass it/set it up for tests?
<redir> or just run with an env var set?
<mup> Bug #1567607 opened: vsphere bootstrap fails when environments.yaml has a password with the # character <bootstrap> <cdo-qa> <vsphere> <juju-core:New> <https://launchpad.net/bugs/1567607>
<perrito666> cherylj: http://reviews.vapour.ws/r/4481/
<mup> Bug #1567635 opened: FilterLXCAddresses should be updated to also filter out lxd bridge addresses <network> <juju-core:Triaged> <https://launchpad.net/bugs/1567635>
<bogdanteleaga> how can I get logs with debug-log from a controller?
<mwhudson> perrito666: ping
<mwhudson> perrito666: looks like mongo/mongo.go only looks for /usr/lib/juju/mongo3/bin/mongod but iiuc that's never going to be released
<mwhudson> perrito666: and it should look for /usr/lib/juju/mongo32/bin/mongod instead?
<mwhudson> er 3.2
<redir> Anyone around with knowledge of juju/juju/cmd/juju/commands/ssh bits ?
<mwhudson> er er this got fixed and then reverted in master a few days ago
<bogdanteleaga> anybody from networking around?
<rick_h_> bogdanteleaga: sorry, they're UK/EU
<thumper> bogdanteleaga: what do you need?
<bogdanteleaga> thumper, just deployed a windows machine with 2.0 and I'm getting a *lot* of spam in the logs
<bogdanteleaga> http://sprunge.us/LdKN
<bogdanteleaga> not sure what it's even trying to do
<thumper> bogdanteleaga: that isn't just spam, but a bug
<thumper> notice this:
<thumper> machine-3: 2016-04-08 05:35:45 DEBUG juju.worker.dependency engine.go:475 "machiner" manifold worker stopped: cannot update observed network config: cannot set link-layer devices to machine "3": invalid device "Loopback Pseudo-Interface 1": Name "Loopback Pseudo-Interface 1" not valid
<thumper> machine-3: 2016-04-08 05:35:45 ERROR juju.worker.dependency engine.go:522 "machiner" manifold worker returned unexpected error: cannot update observed network config: cannot set link-layer devices to machine "3": invalid device "Loopback Pseudo-Interface 1": Name "Loopback Pseudo-Interface 1" not valid
<thumper> unit-noop-2: 2016-04-08 05:35:47 INFO juju.worker.upgrader upgrader.go:178 desired tool version: 2.0-beta4
<thumper> machine-3: 2016-04-08 05:35:48 DEBUG juju.worker.dependency engine.go:461 "machiner" manifold worker started
<thumper> machine 3 bis anyway
<thumper> trying to set an invaliddevice
<thumper> machiner worker stops
<thumper> and then restarts
<thumper> rince and repeat
<bogdanteleaga> yeah, I notice the lack of a machiner
<bogdanteleaga> at least it gets a few seconds of activity to launch the unit \o/
<thumper> so, obvious bug there
<thumper> bogdanteleaga: btw, bumped into a guy over here who when to uni with a some cloudbase guys
<thumper> adi I think
<thumper> and someone else
<bogdanteleaga> we've got quite a few adi's :p
<bogdanteleaga> any chance you know his name?
<bogdanteleaga> (the guy you met)
<thumper> bogdanteleaga: Elvis Adomnica
<thumper> bogdanteleaga: he now teaches at Otago Polytechnic
<thumper> such a small world
<bogdanteleaga> thumper, yup :)
<bogdanteleaga> for a second I thought you're at some sprint in europe :p
<thumper> he
<thumper> not yet
<thumper> speaking of which
<thumper> alexisb: we haven't talked further about team sprint location
<alexisb> thumper, yea
<alexisb> I suck
<thumper> it is a busy time
<thumper> everyone has other focus
<mup> Bug #1567676 opened: windows: networker tries to update invalid device and blocks machiner from working <juju-core:New> <https://launchpad.net/bugs/1567676>
<thumper> anyone? https://github.com/juju/gomaasapi/pull/27
<mwhudson> um
<mwhudson> do the juju tests pass with mongodb 3.2?
 * thumper shrugs
 * mwhudson bangs head on nearby flat surface
<mwhudson> i'm seeing some failures on s390x but i bet they're not the fault of my patches
<mwhudson> ... error string = "server returned error on SASL authentication step: Authentication failed."
<mwhudson> ... regex string = "auth fail(s|ed)"
<thumper> heh
<alexisb> mwhudson, the only bug we have for s390 is https://bugs.launchpad.net/juju-core/+bug/1565044
<mup> Bug #1565044: s390x unit tests fail because not tools for arch <ci> <jujuqa> <s390x> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1565044>
<mwhudson> ahem ahem ahem http://data.vapour.ws/juju-ci/products/version-3869/run-unit-tests-mongodb3/build-484/consoleText
<mwhudson> + echo 'mongodb3 unittests are not supported by master'
<mwhudson> mongodb3 unittests are not supported by master
<mwhudson> + exit 0
<mwhudson> alexisb: i don't want to load more onto the juju team but is someone working on this?
<mwhudson> if juju in xenial is going to use mongodb3.2 it seems like the tests should work with that combination...
<alexisb> mwhudson, yep
<alexisb> we will get someone on it
<mwhudson> ok cool
<mup> Bug #1567683 opened: lxd provider should filter bridge addresses from instance.Address() <lxd> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1567683>
<alexisb> thumper, is menn0 around today?
<thumper> yep
<thumper> heh, he reboots and forgets to reconnect to IRC
<alexisb> I sent mail thanks
<alexisb> finally!
<thumper> alexisb: finally what?
<alexisb> got the lxdbr0 configured correctly
<alexisb> now juju will work until I try and deploy a service
<alexisb> :)
<alexisb> it is a start
 * mwhudson gives up testing juju on his own machine and just gives money to amazon instead
<alexisb> mwhudson, you can expense a certain amount
<alexisb> and we have shared amazon accounts - though I dont have all the details
<alexisb> as I use my own
<mup> Bug #1567690 opened: Can't push charm to my new LP home <juju-core:New> <https://launchpad.net/bugs/1567690>
<rick_h_> alexisb: mwhudson 200/mo no qiestions as long as it's juju related
<rick_h_> more with reasons/etc
<anastasiamac> a review plz http://reviews.vapour.ws/r/4484/ (it's an easy one-liner)
<mwhudson> rick_h_: i expect i'll be spending about $2 :-)
<anastasiamac> axw: perrito666: standup
<axw> onm
<axw> omw
<redir> axw: http://reviews.vapour.ws/r/4485/ and I'll bbiab.
<axw> redir: cheers, looking
#juju-dev 2016-04-08
<mup> Bug #1567598 changed: storage-get causes state server to 'error: bad request' <storage> <juju-core:Invalid> <https://launchpad.net/bugs/1567598>
<mwhudson> perrito666: ping?
<thumper> damn you schema.ForceInt
<thumper> schema.Int -> int64
<thumper> scheam.ForceInt -> int
<thumper> for no good reason
<thumper> bah
<alexisb> mwhudson, it is very much past his eod, if you can open a bug with the info you have that owuld be most helpful
<mwhudson> alexisb: ok
<mwhudson> alexisb: was actually typing up a bug report now, as it happens :-)
<alexisb> perfect :)
<mwhudson> alexisb: https://bugs.launchpad.net/juju-core/+bug/1567708
<mup> Bug #1567708: unit tests fail with mongodb 3.2 <juju-core:New> <https://launchpad.net/bugs/1567708>
<alexisb> mwhudson, thank you!
<mwhudson> np
<mwhudson> some of the errors are clearly quite silly
<mwhudson> (like the error message mongo gives when reporting an auth failure has changed)
<mwhudson> i don't know if any are deep
<mup> Bug #1567708 opened: unit tests fail with mongodb 3.2 <juju-core:New> <https://launchpad.net/bugs/1567708>
<natefinch> evening all
<mup> Bug #1567708 changed: unit tests fail with mongodb 3.2 <juju-core:New> <https://launchpad.net/bugs/1567708>
<redir> axw: yt?
<mup> Bug #1567708 opened: unit tests fail with mongodb 3.2 <juju-core:New> <https://launchpad.net/bugs/1567708>
<mup> Bug #1567712 opened: [juju create-model] Specifying a cloud when referring to a credential is redundant <docteam> <juju-core:New> <https://launchpad.net/bugs/1567712>
<axw> redir_afk: "yt"?
<davecheney> cherylj: http://pad.lv/1566303
<davecheney> did this pass CI testing ?
<davecheney> i have access to a windows machine now and can investigate if it's still failing
<redir> I am
<redir> axw: yt == you there
<axw> redir: oh, well, you have your answer ;)
<redir> axw: do you have a minute for a hangout?
<axw> redir: sure, see you in the tanzanite hangout
<redir> k
<mup> Bug #1567712 changed: [juju create-model] Specifying a cloud when referring to a credential is redundant <docteam> <juju-core:New> <https://launchpad.net/bugs/1567712>
 * thumper heads out to walk the dog
<mup> Bug #1567712 opened: [juju create-model] Specifying a cloud when referring to a credential is redundant <docteam> <juju-core:New> <https://launchpad.net/bugs/1567712>
<cherylj> davecheney: no, the windows test failed again:  http://reports.vapour.ws/releases/3863
<davecheney> cherylj: thanks, i'll try to get on the windows test machine now
<davecheney> cherylj: i don't understand that page
<davecheney> where is the windows failure ?
<cherylj> run-unit-tests-win2012-amd64
<davecheney> ok i see it
<mup> Bug #1567458 changed: destroy-controller message and failure is not user friendly <juju-core:New> <https://launchpad.net/bugs/1567458>
<mup> Bug #1567458 opened: destroy-controller message and failure is not user friendly <juju-core:New> <https://launchpad.net/bugs/1567458>
<redir> cherylj: so you started landing those updates?
<redir> help text updates.
<cherylj> redir: I made an Executive Decision
<cherylj> and pulled the trigger
<cherylj> :)
<redir> OK
<davecheney> menn0: https://bugs.launchpad.net/juju-core/+bug/1474607
<mup> Bug #1474607: worker/uniter/relation: HookQueueSuite.TestAliveHookQueue failure <go1.5> <go1.6> <i386> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1474607>
<redir> so I should fix up that other one and then resubmit or just merge?
<davecheney> this bug is fixed on master bug fires on 1.25
<redir> cherylj: ^^
<davecheney> from memory it was a _lot_ of work to fix on master
<cherylj> redir: as long as you test that the help text looks right, then i'd say just merge
<redir> cherylj: OK. And have you settled on some formatting? indents all with line breaks etc?
<cherylj> redir: basically, I copied what was in the bug for the most part, taking care to make sure lines were < 80 characters
<menn0> davecheney: that bug doesn't ring any bells for me sorry
<redir> OK. I'll do that, too, for the most part:)
<redir> cherylj: ^
<cherylj> thanks, redir :)
<davecheney> menn0: i think this was fixed by william's manifold thinggy
<menn0> davecheney: it won't be the manifold (dependency engine) stuff directly. that's got nothing to do with the uniter's internals.
<mup> Bug #1567458 changed: destroy-controller message and failure is not user friendly <juju-core:New> <https://launchpad.net/bugs/1567458>
<menn0> davecheney: there have been many other improvements in the uniter recently though
<mup> Bug #1567719 opened: help text for juju list-shares needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1567719>
<mup> Bug #1567721 opened: help text for juju set-default-credential needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1567721>
<davecheney> menn0: that's what i'm worried about
<davecheney> we cannot backport them all
<mup> Bug #1567719 changed: help text for juju list-shares needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1567719>
<mup> Bug #1567721 changed: help text for juju set-default-credential needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1567721>
<mup> Bug #1567719 opened: help text for juju list-shares needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1567719>
<mup> Bug #1567721 opened: help text for juju set-default-credential needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1567721>
<mup> Bug #1567722 opened: help text for juju list-credentials needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1567722>
<mup> Bug #1567724 opened: help text for juju add-cloud needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1567724>
<mup> Bug #1567726 opened: help text for juju disable-user needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1567726>
<mup> Bug #1567722 changed: help text for juju list-credentials needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1567722>
<mup> Bug #1567724 changed: help text for juju add-cloud needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1567724>
<mup> Bug #1567726 changed: help text for juju disable-user needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1567726>
<menn0> cherylj: I think I've figured out that local charm hash mismatch bug and I don't think it'll be hard to fix
<cherylj> menn0: excellent
<cherylj> menn0: there's plenty more for you once you're done with it ;)
<menn0> cherylj: oh I know :)
<cherylj> menn0: I also still have that mgopurge problem from mario that I haven't done and could use help with :)
<menn0> cherylj: ok, I can pick that up next
<mup> Bug # opened: 1567722, 1567724, 1567726, 1567728, 1567730, 1567732, 1567734
<axw> menn0: I'm intending to add the names of top-level machines and services to modelDoc, so we can safely advance from Alive to Dead if a model is empty
<axw> menn0: just FYI, in case that would cause problems for model migration
<axw> menn0: also probably will change the hosted-model refcount to references to UUIDs, to avoid ABA problem at destroy-controller time
<menn0> axw: that might have model migration implications. thumper wrote the import and export code.
<menn0> thumper: thoughts?
 * thumper looks up
<mup> Bug # changed: 1567728, 1567730, 1567732, 1567734
<thumper> axw: what names?
<menn0> thumper, axw: it should be easy enough to account for, and tests should start failing when you add fields (but maybe only in the model-migration branch
<thumper> if you add fields, tests will fail
<axw> menn0 thumper: i.e. when you add-machinem we'll $addToSet a "machines" field on the model doc
<axw> and $pull when we remove the machine
<thumper> why?
<axw> thumper: https://bugs.launchpad.net/juju-core/+bug/1567228
<mup> Bug #1567228: "juju destroy-controller" can leak hosted models <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1567228>
<axw> that's part of it
<axw> thumper: https://bugs.launchpad.net/juju-core/+bug/1563615 that's the other part
<mup> Bug #1563615: destroy-controller blocks when you've not removed an empty default model <juju-release-support> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1563615>
<axw> thumper: basically we should short-circuit if the controller only has empty models, but we can't do that safely at the moment
<axw> because the machines and services don't refcount or anything on the model
<thumper> ok
<thumper> if you do this, you'll need to make sure the value is added when the model description is imported
<thumper> the export code probably won't need to change as the precondition is that the model is alive and all machines are alive
<thumper> and no pending cleanups
<thumper> so populating the field when importing should be "iterate through the machines"
 * axw nods
<axw> thumper: where's the import code?
<thumper> axw: state/migration_import.go
<axw> ta
<menn0> thumper or axw: I need a quick hangout to bounce some ideas for a bug fix off someone. either of you keen?
<thumper> menn0: sure
<axw> menn0 thumper: call me in if it's helpful, otherwise I want to get this sorted
<thumper> kk
<thumper> menn0: 1:1 ?
<menn0> thumper: yep
<mup> Bug # opened: 1567728, 1567730, 1567732, 1567734
<davecheney> base_windows.go makes me sad
<davecheney> 1. because the registiry api is nuts
<davecheney> 2. because the way that code enables the api to continue to be nuts, is weird, codependant and unhealtht
<mup> Bug #1566339 changed: `juju run` needs a --all-machine, --all-service, --all-unit <juju> <machine> <run> <juju-core:Invalid> <https://launchpad.net/bugs/1566339>
<davecheney> menn0: cherylj
<davecheney> http://reviews.vapour.ws/r/4486/
<mwhudson> uh
<mwhudson> oh
<mwhudson> nm
<mwhudson> i should just upgrade to xenial
<natefinch> mwhudson: if you like pain and suffering, that's a great idea.
<mwhudson> heh it shouldn't be so bad at this point
<natefinch> I've just heard of a lot of problems with juju-specific things like lxd and having xenial listed as an LTS (though it may not be yet)
<mwhudson> oh yeah, lxd keeps moving things around
<natefinch> I have OS updates that I'm not installing because there's lxd updates, and currently my LXD actually works.
<mwhudson> huh um juju doesn't build with gccgo on xenial either
<natefinch> and I don't have time to futz with network BS
<mwhudson> oh maybe only with the tip go tool
<mup> Bug #1567747 opened: "juju metadata generate-image" does not validate architectures <juju-core:Triaged> <https://launchpad.net/bugs/1567747>
<menn0> davecheney: looking
<menn0> davecheney: looks good
<natefinch> davecheney: do you happen to know why this function has an error return? https://golang.org/src/net/http/cookiejar/jar.go?s=2387:2421#L67  it's vexing my current code. I'd like to just ignore it to make my code cleaner, but it worries me that it might one day start returning an error.
<mup> Bug #1567747 changed: "juju metadata generate-image" does not validate architectures <juju-core:Triaged> <https://launchpad.net/bugs/1567747>
<mup> Bug #1567747 opened: "juju metadata generate-image" does not validate architectures <juju-core:Triaged> <https://launchpad.net/bugs/1567747>
<redir> night
<mup> Bug #1567763 opened: bootstrapping private openstack, with --metadata-source fails when instance-type constraint is specified <juju-core:Triaged> <https://launchpad.net/bugs/1567763>
<davecheney> natefinch ping ?
<davecheney> hmm, too late
<frobware> dimitern, voidspace, dooferlad: going to skip standup today.
<dooferlad> frobware: ok
<frobware> is there anyway I can force an upgrade-tools? It works for a while, but subsequent upgrades result in "ERROR some agents have not upgraded to the current model version 2.0-beta4.4: machine-0"
<dimitern> frobware, ok
<dimitern> frobware, btw I'm about to finally propose a fix for bug 1564395
<mup> Bug #1564395: newly created LXD container has zero network devices <bootstrap> <conjure> <network> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1564395>
<babbageclunk> voidspace, frobware: I've got HR induction from 10-11 so I won't be in the meeting this morning (at least the first part - I'll jump in if it's still going when I get out).
<frobware> babbageclunk, ack
<babbageclunk> voidspace: what I did is in the document from yesterday, though.
 * thumper is in the hangout
<thumper> babbageclunk: good luck
 * thumper wonders if he will be sitting alone....
<voidspace> babbageclunk: ok
<voidspace> thumper: omw
<frobware> dimitern, happy to be a guinea pig for 1564395
<frobware> dimitern, that's one less reboot, for there are many today. :/
<frobware> dimitern, did your change with my /e/n/i *cough* hack... ?
<frobware> dimitern, did your change work with my ...
<dimitern> frobware, testing always appreciated :) yes - it uses the /e/n/i hack
<frobware> dimitern, not sure my hack is working today; newer lxd since weds...
<dimitern> frobware, I did a dist-upgrade this morning, so I have rc9 I think
<dimitern> yep
<frobware> dimitern, I'm trying to find the right place and time to delete the lxd supplied (and mandatory) eth0.cfg
<frobware> dimitern, and ensure any ifup brings up our definition of eth0
<frobware> dimitern, I was gettting provisioning errors earlier where it failed to write to /var/lib/lxd/container/<container>/rootfs/...
<frobware> dimitern, the other thing is I'm only testing/trying this with trusty and xenial. I guess I should try precise and wily at some point.
<voidspace> dimitern: babbageclunk: PR to merge maas2 onto master http://reviews.vapour.ws/r/4487/
<dimitern> voidspace, I'll swap it for this - http://reviews.vapour.ws/r/4488/ :)
<dimitern> voidspace, LGTM
<voidspace> dimitern: thanks - looking
<dimitern> voidspace, ta!
<dimitern> fwereade, hey, are you about?
<dimitern> frobware, ^^ pushed the fix
<frobware> dimitern, you rebased?
<dimitern> yep
<frobware> dimitern, I was just looking at your changes since I pulled from earlier
<frobware> dimitern, ok
<dimitern> frobware, not removing /e/n/i.d/eth0.cfg doesn't seem to cause any harm - even rebooting the host/container is ok
<frobware> dimitern, I'm trying to determine whether that's just luck based on the 'source .../*.cfg' order
<frobware> dimitern, stgraber advised me to delete it
<dimitern> frobware, well, that's even better - a proper fix, but just saying what i've seen so far
<frobware> dimitern, me too. but have you rebooted a lot?
<dimitern> frobware, i did reboot a few times, nothing fancier though
<frobware> dimitern, I'm stuck with upgrade not working for me at the moment which make for slow progress
<dimitern> frobware, that upgrade-juju issue - that's on trusty or xenial?
<voidspace> dimitern: I don't really like adding unused code
<voidspace> dimitern: why not add the gate in the PR that uses it?
<frobware> dimitern, xenial
<dimitern> voidspace, well, it's used by discoverspaces, but not yet by others
<dimitern> voidspace, actually I did this because I thought I might need it in this PR
<dimitern> voidspace, but fair enough, I'll pull gate out of this PR
<voidspace> dimitern: it's up to you - other than that LGTM
<frobware> dimitern, voidspace: seems like the right thing to do as it make reverting the PR saner - should it ever need to
<dimitern> frobware, it's pretty easy with gh web ui
<frobware> dimitern, what I mean is you would only be reverting stuff pertinent to the original fix
<frobware> dimitern, anyway, back to ENI - the interfaces do not always come up for me. :(
<dimitern> frobware, with my fix ?
<frobware> dimitern, nope, mine
<frobware> dimitern, the times I've bootstrapped and added a new machine without reboot seems to work fine with your fix \o/
<dimitern> frobware, I found out something else (probably related to what jamespage was seeing - if say eth0 is unconfigured, but has children which are not - it breaks
<dimitern> frobware, awesome!
<frobware> dimitern, removal of eth0.cfg in cloud-init and taking down / bringing up the 00-juju.cfg does not work reliably. or so it seems.
<frobware> dimitern, I raised a bug for that
<frobware> dimitern, https://bugs.launchpad.net/juju-core/+bug/1566791
<mup> Bug #1566791: VLANs on an unconfigured parent device error with "cannot set link-layer device addresses of machine "0": invalid address <network> <juju-core:Triaged> <https://launchpad.net/bugs/1566791>
<dimitern> frobware, cheers, I'll be tackling this as well with the changes we discussed with thumper - adding 2 workers to do the NIC provisioning, devices creation, and updating provider network config after provisioning, as well as releasing container addresses as needed
<dimitern> frobware, in fact, I'm already thinking how we can do the job of the bridge script but in a worker instead, properly with a lot more useful context and less workarounds
<frobware> dimitern, but the script runs in cloud-init
<dimitern> frobware, it doesn't have to, does it?
<frobware> dimitern, well, as I'm finding out again, the combo of: ifdown, copy-in-new-file; ifup -a, is not guaranteed.
<dimitern> frobware, we can do it with proper retrying, etc. - bridge by bridge, based on what NICs we observe at run-time
<frobware> dimitern, I'm generally -1 on this atm, particularly if MAAS models bridges.
<frobware> in the near future
<dimitern> frobware, perhaps some if-[pre|post]-down script was lingering?
<frobware> dimitern, bbiab - 20 mins.
<dimitern> frobware, well, they will be at some point, but we need to think about other providers
<voidspace> babbageclunk: dimitern: frobware: well that took a long time! I now have a test that can successfully call StartInstance against MAAS 2 code.
<dimitern> voidspace, \\o// great!
 * dimitern should really install a 2.0 maas locally now :)
 * fwereade cheers at voidspace
<voidspace> fwereade: :-)
<voidspace> testing it all will take a while to construct, it's not exactly a small code path - but I can call it now without it blowing up
<frobware> voidspace, very NICE!
<bogdanteleaga> dimitern, https://bugs.launchpad.net/juju-core/+bug/1567676
<mup> Bug #1567676: windows: networker tries to update invalid device and blocks machiner from working <juju-core:Triaged> <https://launchpad.net/bugs/1567676>
<bogdanteleaga> help? :D
<dimitern> bogdanteleaga, hey - the networker is gone for a while now; which version of juju?
<bogdanteleaga> dimitern, latest, I wasn't sure what terminology to use
<dimitern> bogdanteleaga, I see (might have helped to actually read the bug desc first :)
<dimitern> bogdanteleaga, I know the issue
<dimitern> bogdanteleaga, but that's already fixed in master IIRC - is that on a feature branch?
<bogdanteleaga> dimitern, it's from yesterday's master
<bogdanteleaga> dimitern, https://github.com/juju/juju/commit/b631875ff9ed67ec321f1d6fa90bc65d839b9e93
<dimitern> bogdanteleaga, so the error in comment #1 is no longer happening
<dimitern> bogdanteleaga, but the "<nil>" value of the address is troubling
<bogdanteleaga> dimitern, I'll try the latest master
<dimitern> bogdanteleaga, it might be better to use --config logging_config='<root>=TRACE' to bootstrap to get more context (and paste in the bug please)
 * dimitern steps out for a couple of hours
 * perrito666 steps out for an hour too
<rogpeppe> an update to juju-core to fix the resources API used by charmrepo: http://reviews.vapour.ws/r/4490/
<rogpeppe> should be trivial and I've very much like to get it landed to day if poss...
<rogpeppe> so reviews welcome :)
<axw> fwereade: I'm EODing, but if you have any time up your sleep, this PR has some gnarly state changes that I'd appreciate a review of if you have some time today: http://reviews.vapour.ws/r/4491/
<mup> Bug #1567925 opened: help text for juju add-unit needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1567925>
<voidspace> babbageclunk: frobware: dimitern: maas2 has landed on master - all further maas2 work to be against master
<mup> Bug #1567934 opened: uploadSuite.TestMockBuildTools relies on exact archive/zip output <juju-core:New> <https://launchpad.net/bugs/1567934>
<mup> Bug #1567938 opened: juju bootstrap requires network ID as config option on command line although it's specified in clouds.yaml <juju-core:New> <https://launchpad.net/bugs/1567938>
<alexisb> morning all
<voidspace> alexisb: o/
<babbageclunk> voidspace: nice!
<katco> yaaaay life-giving internet
<alexisb> katco, hey
<voidspace> katco: morning
<katco> alexisb: hey
<alexisb> heh
<katco> voidspace: morning from across the way
<alexisb> is what I mean
<voidspace> katco: o/
<katco> alexisb: my neighborhood is 1 short street and they've been replacing the sidewalks 1 section at a time over the past month or so. we've had 3 outages now... o.0
<alexisb> katco, sounds like it is time to move ;)
 * katco wry smile
<katco> perrito666: i have a patch to propose for the keystone issue... will you have a chance to tal?
<babbageclunk> alexisb, katco: morning!
<katco> babbageclunk: o/
<katco> babbageclunk: good to hear from you again. how are you getting on with things?
<babbageclunk> katco: settling in ok, I think. Heaps and heaps to learn, obviously!
<katco> babbageclunk: that's what makes it fun :D
<babbageclunk> katco: :)
<mup> Bug #1567951 opened: help text for juju login needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1567951>
<mup> Bug #1567952 opened: container/lxd: TestDetectSubnetLocal fails with link/none <juju-core:New> <https://launchpad.net/bugs/1567952>
<perrito666> katco: sure, shoot
<katco> perrito666: http://reviews.vapour.ws/r/4492/
<katco> perrito666: ta
<natefinch> ericsnow: I think you're gonna like how the charmstore client code turned out... especially the amount of code needed to put into the csclientImpl wrapper type
<alexisb> cmars, you around yet?
<natefinch> ericsnow: I still have to update the tests for that code, but shouldn't be too bad.
<perrito666> katco: shit it with a doubt
<natefinch> perrito666: lol
<perrito666> meh
<perrito666> sorry typo
<katco> perrito666: i think we only care about the major to resolve the client
<cherylj> jam: you still around?
<katco> perrito666: i.e. if the major is 2, we'd settle on 2.x whatever that may be
<cherylj> frobware: ping?
<perrito666> katco: I had miss interpreted your code, sorry
<katco> perrito666: ah no worries... so is it still OK?
<perrito666> yes
<katco> perrito666: awesome... thanks for reviewing
<perrito666> tx for that fix
<katco> perrito666: weird situation... i don't really understand why an openstack deployment would report a version that isn't working yet
<perrito666> cherylj: speaking of reviews, could I get a rev on http://reviews.vapour.ws/r/4481/ ?
<cherylj> perrito666: yes, I will take a look this morning  (about to have a call right now :/)
<katco> natefinch: ericsnow: https://plus.google.com/hangouts/_/canonical.com/retrospective?authuser=1
<katco> ericsnow: ping?
<frankban> cherylj: hey morning? any news on merging embedded-gui?
<katco> natefinch: ericsnow: deferred half an hour; sorry, thought ericsnow was already on
<mup> Bug #1567963 opened: help text for juju remove-unit needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1567963>
<cherylj> frankban: let me look at the CI reports, one sec
<frankban> cherylj: sure ty
<perrito666> https://www.mongodb.com/blog/post/mongodb-2-6-end-of-life?utm_content=buffere388e&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer
<perrito666> meh we could use a bot that says the title: "MongoDB 2.6 End of Life"
<natefinch> perrito666: the url was pretty obvious ;)
<perrito666> lol, I did not realize, I could have very well have stripped the get params
 * dimitern whew... almost 1h stuck in traffic :/
<dimitern> voidspace, frobware, babbageclunk, btw the sync call is not happening
<dimitern> perhaps next week
<alexisb> cherylj, fyi, I was able to deploy a few services yesterday off master
<dooferlad> frobware: I have the switch in place and can confirm that 802.3ad works over juju-br0 once we put in pre-up/post-down steps to control the underlying bond.
<alexisb> dooferlad, that is good news
<dooferlad> alexisb: :-)
 * alexisb changes locations
<frankban> cherylj: can we stick a little trivial last change to the embedded-gui branch? is it too late?
<babbageclunk> dimitern: sync call? I don't think I'm on it - can you please add me?
<evilnickveitch> cherylj, we may have a problem with a lot of the updated help text
<frankban> hatch: you dropped
<cherylj> frankban: dont' put anything else into embedded gui
<cherylj> wait for us to merge it and put it directly in master
<hatch> :'(
<hatch> :D
<frankban> cherylj: sounds good
<cherylj> evilnickveitch: what's going on with the help text?
<frankban> cherylj: when is the deadline for putting changes into master?
<evilnickveitch> cherylj, a lot of the user related commands reference 'share-model'
<evilnickveitch> 'sahre-model' seems to have disappeared
<evilnickveitch> i mean, as a command
<cherylj> frankban: needs to be done today
<cherylj> evilnickveitch: yeah, it was a late change to be juju grant
<evilnickveitch> cherylj, :(
<evilnickveitch> cherylj, well, be on the lookout for it in case we miss changing any - it appears in a lot of 'see also' text
<cherylj> evilnickveitch: ok, thanks, I'll keep an eye out
<evilnickveitch> cherylj, I will just go and rewrite all the user docs...
<dimitern> babbageclunk, sure - invite sent
<babbageclunk> dimitern: thanks!
<frankban> cherylj: actually I am lucky enough that the code I need to change is the GUI server already in master, will be just a trivial improvement
<cherylj> frankban: great!
<redir> cherylj: evilnickveitch there appears to be one unshare-model too
<cmars> i can review some things now. what should i look at first?
<cmars> alexisb, cherylj ^^ ?
<alexisb> perrito666, are you still waiting for a review?
<alexisb> cmars, this one is important: http://reviews.vapour.ws/r/4491/
 * cmars is reviewing
<alexisb> cmars next inline would be this one: http://reviews.vapour.ws/r/4481/
<mup> Bug #1568028 opened: Juju fails to deploy with 2.0-beta3-xenial-arm64 <juju-core:New> <https://launchpad.net/bugs/1568028>
<alexisb> frobware, I am back online if you are still looking for me
<alexisb> cmars, if you are done with the two reviews above, the next in priority are any from jam dealing with lxd and containers
<alexisb> like: http://reviews.vapour.ws/r/4478/
<cmars> alexisb, still on the first one
<alexisb> cmars, understood, thanks
<mup> Bug #1568028 changed: Juju fails to deploy with 2.0-beta3-xenial-arm64 <juju-core:New> <https://launchpad.net/bugs/1568028>
<cmars> 4491 is going to take me all afternoon to review, some of it i don't fully understand yet. deals with parts of state i'm unfamiliar with
<alexisb> cmars, what about 4881>
<alexisb> ?
<cmars> alexisb, you mean 4481? that looks more manageable. i'll review over lunch
<alexisb> yes that is what I meant sorry
<alexisb> and cool, thank you
<frobware> alexisb, just to say... great few days with christian, have some sort of fix (need testing) for bug #1566801
<mup> Bug #1566801: LXD containers /etc/network/interfaces as generated by Juju  gets overwritten by LXD container start <network> <juju-core:Triaged by frobware> <https://launchpad.net/bugs/1566801>
 * frobware EOW 
<katco> ericsnow: you have ship its
<ericsnow> katco: thanks
<natefinch> katco, ericsnow: down to 4 comments btw
<ericsnow> natefinch: nice
<katco> natefinch: yeah just looked... that is a ton of code lol
<natefinch> katco: yeah, there's a reason it took a while
<katco> natefinch: ericsnow: thanks for pairing on that
<natefinch> katco: still need some new tests for some of the new code eric and I wrote yesterday
<mup> Bug #1568069 opened: Container networking cannot ssh <ci> <lxc> <network> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1568069>
<mup> Bug #1568069 changed: Container networking cannot ssh <ci> <lxc> <network> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1568069>
<alexisb> katco, I have a few minutes if you would like ot meet
<mup> Bug #1568069 opened: Container networking cannot ssh <ci> <lxc> <network> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1568069>
<mup> Bug #1568079 opened: github.com/juju/juju/apiserver/client unit tests fail if xenial is the LTS <xenial> <juju-core:Triaged> <https://launchpad.net/bugs/1568079>
<katco> alexisb: sure
<alexisb> katco, 1x1 HO
<perrito666> alexisb: sadly I am
<cmars> perrito666, reviewed 4481
<perrito666> cmars: tx
<perrito666> cmars: tx a lot
<mup> Bug #1568090 opened: help text for juju sync-tools needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1568090>
<natefinch> ericsnow, katco: and down to one comment, but it's probably the hardest one... fixing model migrations.  But for now I'm going to rebase, since github tells me I have conflicts. sigh.
<ericsnow> natefinch: k
<ericsnow> natefinch: let me know if I can help; as I mentioned, I did the same thing for channels
<natefinch> definitely
<mup> Bug #1568092 opened: ConnectSuite.TestLocalConnectError: centos  cannot connect to local lxd servier <centos> <ci> <lxd> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1568092>
<katco> natefinch: sorry was otp. whoa, what does "fixing model migrations" mean? that doesn't sound fun =|
<natefinch> katco: adding a few lines to state.migration_import.go / _export.go  basically like what eric did with those files here: http://reviews.vapour.ws/r/4441/diff/#
<katco> natefinch: oh b/c you're storing new info in state you have to support it when migrating models
<natefinch> yep
<katco> natefinch: gotcha... makes sense. sounded scary o/0
<natefinch> still a little scary ;)
<katco> ha
<natefinch> uh hmm
<natefinch> there's nothing in there about charms
<natefinch> ericsnow: ^
<ericsnow> natefinch: if we're not migrating charms then I'm guessing that Tim & co. haven't gotten to it yet
<ericsnow> natefinch: however, I'd be surprised by that
<ericsnow> natefinch: perhaps it's folded into the service representation? (and they will re-download the blobs)
<natefinch> ericsnow: I thought of that, but then they can't do that for local charms
<ericsnow> natefinch: yuck
<ericsnow> natefinch: so blobs have to be migrated too I suppose
<mup> Bug #1568101 opened: help text for juju deploy needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1568101>
<natefinch> ericsnow: I would assume so....
<natefinch> ericsnow: hang on... I see some code related to charms in core/migration/migration.go .... reading
<ericsnow> natefinch: ah, no MigrationSuite.TestCharmDocFields()
<natefinch> ericsnow: can you give the review another pass, and we can maybe try to get in touch with the migration guys?  I assume they're all still in their upside down beds, since it's saturday morning down there
<ericsnow> natefinch: will do
<alexisb> katco, ericsnow: has this documentation made ericsnow's google doc obsolete?: https://github.com/juju/juju/wiki/Implementing-environment-providers
<katco> alexisb: axw mentioned he was going to incorporate ericsnow 's doc because he didn't know about it when he created that wiki page. i don't know that he ever did
<natefinch> alexisb or katco: do you know if anyone familiar with model migrations is awake?  I added a macaroon field to charms stored in mongo, but I don't really see any place in the migration code where we migrate charm metadata...
<katco> natefinch: i don
<katco> 't
<katco> natefinch: menn0 is working on that primarily... thumper should still be able to answer questions as well
<natefinch> ..... do our tests create virtual ethernets on the machine they're running on?
<katco> natefinch: omg... PLEASE tell me they don't
<natefinch> sure looks like it
<natefinch> I have like 4 virtual ethernet devices on my machine right now
<katco> what. the. hell.
<natefinch> I noticed because I saw a popup that say "connected to veth<somguid>
<alexisb> natefinch, fwereade sometimes is around late
<alexisb> otherwise they are all on their weekend
<alexisb> natefinch, the MM work is not complete so it may be that it is not in master yet
<alexisb> though with menno's latest branch I was able to successfully migrate a basic mediawiki deploy successfully
<natefinch> alexisb: ok
<natefinch> katco: http://i.imgur.com/d1ZKuPz.png
<ericsnow> katco: gah, I forgot to mention a patch I have up against charmrepo:  https://github.com/juju/charmrepo/pull/84
<katco> ericsnow: k tal
<ericsnow> katco: ta
<natefinch> that feeling when you're pretty sure you're waiting for the 10 minute testing timeout :/
<cherylj> I know that feeling
<redir> natefinch: everytime I run all the tests.
<natefinch> or not: ok  	github.com/juju/juju/state	414.273s
<natefinch> almost 7 minutes just for state tests.  Huzzah.
<alexisb> o the state tests...
<perrito666> natefinch: the state tests are quite shroedinger cat-ish unthil they finish they have and have not failed in your mind
<katco> ericsnow: lgtm... fairly straightforward changes :)
<ericsnow> katco: yep :)
<ericsnow> katco: thanks
<katco> ericsnow: ty
<mup> Bug #1563364 changed: UniterSuite.TestUniterSteadyStateUpgradeForce fails <ci> <intermittent-failure> <test-failure> <juju-core:Invalid> <juju-core embedded-gui:Fix Released> <https://launchpad.net/bugs/1563364>
<mup> Bug #1568122 opened: help text for juju remove-machine needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1568122>
<cmars> alexisb, should i try to continue reviewing 4491 or look at something else
<alexisb> cmars, if they are easier you can do the lxd reviews
<alexisb> http://reviews.vapour.ws/r/4478/
<cmars> alexisb, looking
 * perrito666 sees his refactoring interrupted by eye drops :p
<ericsnow> natefinch: LGTM with a few small comments
<natefinch> ericsnow: ok
<natefinch> ericsnow: thanks
<ericsnow> natefinch: np
<ericsnow> natefinch: thanks for doing it :)
<ericsnow> natefinch: how close are you to pulling the trigger on that patch?
<katco> ericsnow: you were waiting on him to rebase weren't you?
<ericsnow> katco: was hoping he'd merge his patch before I land my last one
<katco> ericsnow: might have to land yours first... your work needs to be in by EOD
<katco> ericsnow: and then we can pair to help through the difficult merge
<ericsnow> katco: won't be hard, just tedious :)
<ericsnow> katco: we're changing a bunch of the same signatures
<katco> ericsnow: he's probably gone to dinner, i'd say go ahead and begin merging
<perrito666> aghh I broke the reboot test :(
<ericsnow> katco: sounds good
<natefinch> ericsnow: thanks, fotgot you were waiting on me
<ericsnow> natefinch: np
<natefinch> bbl
<mup> Bug #1568150 opened: xenial lxc containers not starting <juju-core:New> <https://launchpad.net/bugs/1568150>
<alexisb> perrito666, I am seeing reboot test failures too
<alexisb> from master
<perrito666> meh, It seems broken
<perrito666> I believe its breaking mongod but it is not related from my changes
<perrito666> this might prevent me from merging :(
<alexisb> alrighty all I am out for a few hours will be back this evening
<alexisb> perrito666, please open a bug with details
<perrito666> ok
<alexisb> thanks
<alexisb> alexisb-afk
<perrito666> alexisb: for when you come back, I cannot reproduce now but I feel we are leaking lxcs and mongos
<mup> Bug #1568160 opened: destroying a unit with an error gives no user feedback <juju-core:New> <https://launchpad.net/bugs/1568160>
<mup> Bug #1568161 opened: Pass whether service is primary or subordinate via relation <juju-core:New> <https://launchpad.net/bugs/1568161>
<mup> Bug #1568175 opened: destroy-controller failed: EOF <ci> <destroy-controller> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1568175>
<mup> Bug #1568176 opened: charm deployment requests invalid revision number <juju-core:New> <https://launchpad.net/bugs/1568176>
<mup> Bug #1568175 changed: destroy-controller failed: EOF <ci> <destroy-controller> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1568175>
<mup> Bug #1568176 changed: charm deployment requests invalid revision number <juju-core:New> <https://launchpad.net/bugs/1568176>
<mup> Bug # opened: 1568175, 1568176, 1568177, 1568179
<mup> Bug #1568181 opened: clientRepoSuite.TestBlockRemoveServiceDeployPrincipal cannot put archive blob <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1568181>
<mup> Bug #1568183 opened: GCE timeout pending new instance operation failed <ci> <gce-provider> <jujuqa> <reliability> <juju-core:Triaged> <https://launchpad.net/bugs/1568183>
<ericsnow> katco: third patch merging now :)
<mup> Bug #1568185 opened: statusHistoryPrunerSuite.TestWorker wrong number of logs <ci> <intermittent-failure> <unit-tests> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1568185>
<katco> ericsnow: woot woot!
<mup> Bug #1568186 opened: TestUniterUpgradeGitConflicts never reached desired status <ci> <i386> <intermittent-failure> <unit-tests> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1568186>
<mup> Bug #1568189 opened: RemoveRelationSuite.SetUpTest failed because of mongo <ci> <intermittent-failure> <mongodb> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1568189>
<mup> Bug #1568190 opened: MachinerSuite.TestMachinerSetStatusStopped cannot set status <ci> <intermittent-failure> <unit-tests> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1568190>
#juju-dev 2016-04-09
<mup> Bug #1568175 changed: destroy-controller failed: EOF <ci> <destroy-controller> <regression> <juju-ci-tools:Fix Released by sinzui> <juju-core:Invalid> <https://launchpad.net/bugs/1568175>
<natefinch> katco, ericsnow: rebasing and fixing conflicts btw
<alexisb> well done this week juju devs!
<natefinch> ericsnow: don't suppose you're around?
<axw> katco: no I never did get around to incorporating ericsnow's doc
<ericsnow> natefinch: need a hand?
<redir> have a great weekend #juju-dev
<mup> Bug #1466570 changed: Juju add-unit stuck on new lxc containers <juju-core:Expired> <juju-core 1.20:Incomplete by cherylj> <https://launchpad.net/bugs/1466570>
<axw> cmars: thanks much for the review
<mup> Bug #1568312 opened: Juju should fallback to juju-mongodb after first failure to find juju-mongodb3.2 <blocker> <ci> <mongodb> <juju-core:Triaged> <https://launchpad.net/bugs/1568312>
<cherylj> If there are people around, I need some review to help get master in a good state:  http://reviews.vapour.ws/r/4502/       https://github.com/juju/juju/pull/5059
<TheMue> cherylj: wonderful tests, and again - as needed - more complex than the change itself
<TheMue> cherylj: does the test, not in this change, also contain a testing of a successful loading of a managed package?
<cherylj> TheMue: yeah, I noticed it didn't have a test for success
<mup> Bug #1568372 opened: Bridge script failed with "UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 18: ordinal not in range(128)" <network> <juju-core:Triaged> <https://launchpad.net/bugs/1568372>
<mup> Bug #1568374 opened: github.com/juju/juju/cmd/juju/service unit tests fail if xenial is the LTS <juju-core:Triaged> <https://launchpad.net/bugs/1568374>
<mup> Bug #1568374 changed: github.com/juju/juju/cmd/juju/service unit tests fail if xenial is the LTS <juju-core:Triaged> <https://launchpad.net/bugs/1568374>
<mup> Bug #1568374 opened: github.com/juju/juju/cmd/juju/service unit tests fail if xenial is the LTS <juju-core:Triaged> <https://launchpad.net/bugs/1568374>
<mup> Bug #1568390 opened: Fallback for mongo packages doesn't include wily <ci> <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1568390>
#juju-dev 2016-04-10
<mup> Bug #1568602 opened: Cannot build OS X client with stock Go 1.6 <ci> <go1.6> <osx> <packaging> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1568602>
<davecheney> thumper: http://reviews.vapour.ws/r/4505/
<davecheney> for review
<davecheney> cherylj: http://reviews.vapour.ws/r/4505/
<thumper> davecheney: shipit
<mup> Bug #1554193 changed: deploying local charm twice only deploys first version <2.0-count> <juju-release-support> <juju-core:Triaged> <https://launchpad.net/bugs/1554193>
<davecheney> thumper: oh, and I got the gomanta fix upstreamed
<thumper> davecheney: yeah, saw that
<davecheney> another bug down
<davecheney> it's good that we can call in a favor at joyent
 * thumper nods
<thumper> wallyworld: welcome back
<wallyworld> thumper: thanks, was looking forward to this day for 2 weeks :-)
<thumper> wallyworld: really?
#juju-dev 2017-04-03
<anastasiamac> axw: PTAL? https://github.com/juju/juju/pull/7193
<axw> anastasiamac: looking
<axw> anastasiamac: looks good apart from the panic inducing change made to defer order
<anastasiamac> axw: oh k -dunno how i kept that one ;) i'll revert that little tidbit ;)
<axw> anastasiamac: LGTM
<anastasiamac> \o/
<blahdeblah> Can anyone advise on what the minimum instance size for 2.1.2 controller in Azure would be?  I'm using a trial account, so I need to use the smallest possible instances.
<menn0> blahdeblah: it depends how many models and units you intend on running with the controller
<blahdeblah> menn0: one A0 VM per region, for as many regions as the trial account will allow me
<blahdeblah> So probably around 10-15 VMs total
<blahdeblah> They'll be cs:ubuntu primaries, with telegraf, ntp, and maybe landscape-client subordinates
<menn0> blahdeblah: I haven't used azure much but looking at their machine types an A-Small or A-Medium should do it
<jam> menn0: a small interesting 'mongo' thing. It seems aggregation pipeline has a $split operator, but it doesn't work everywhere. I don't know if it works in 3.4 (laptop) and not 3.2, or whether it doesn't work when you disable the V8 engine.
<jam> menn0: I *almost* managed a query that would pull out TXN ids into a table, but you have to convert strings to OIDs, and there doesn't seem to be any DB level request you can do for it. it has to be done in Javascript or client-side
<jam> menn0: I also saw that you landed "$gte: 5", in my testing the time for $gte: 5 is the same as $in [5, 6]
<jam> exact match on '6' is slightly faster, but it seems better to use a forward looking [5, 6] just in case?
<menn0> jam: the agg pipeline doesn't seem to be very good at using the index
<menn0> jam: I went with $gte b/c that's at least fast with the index with a normal find(), but $in isn't
<menn0> jam: I figured it's more likely to be fast with the agg pipeline in some future mongodb version
<menn0> jam: i'm not too worried anyway... the way things are now, it's not super fast but it's probably fast enough
<menn0> jam: your $split query sounds interesting... but how much would it actually help?
<menn0> jam: at some point the code is still going to have to iterate the result of the agg pipeline
<menn0> jam: i'm not sure that'll be much faster than iterating the docs directly
<menn0> it might even be slower
<jam> menn0: well $lookup seemed interesting
<jam> as a way to do almost all the work server side
<jam> but the lack-of-object-conversion makes it not possible
<jam> I was looking for a "look for completed so I could remove them from the queues"
<menn0> jam: yeah I saw that too
<menn0> jam: it's also not available in mongodb 2.x so we'd have to be careful with how it was used in mgopurge
<blahdeblah> Hi all, I'm running into https://bugs.launchpad.net/juju/+bug/1656723 at the moment; is there any word on when the fix will be released?  Is there a workaround?
<mup> Bug #1656723: azure: firewall rules are wiped out when a new machine is added <azure-provider> <juju:Fix Committed by axwalk> <https://launchpad.net/bugs/1656723>
<blahdeblah> axw: Your name is on that bug - any suggestions?
<jam> blahdeblah: the fix listed there was merged into 2.2, which is scheduled for stable release at the end of April
<blahdeblah> jam: Thanks - any workaround in the time being?  It has basically cut me off from the instance I had running.
<jam> blahdeblah: that you'd have to talk to axw
<blahdeblah> It might be faster to just redeploy
<axw> blahdeblah: I think if you unexpose and then re-expose, the rules will be  recreated
<blahdeblah> axw: Yes, eventually worked that out.  Thanks. :-)
<blahdeblah> I'll note that on the bug for future travellers
<axw> blahdeblah: cool, thanks
<jam> axw: I updated https://github.com/juju/juju/pull/7180 can you give it another look?
<axw> jam: looking
<axw> jam: I agree with your assessment, that we shouldn't need to check model life because we're not creating a new thing. can you please drop the checkModelActive too then?
<axw> brb
<axw> maybe I misunderstood your reply tho
<SimonKLB> hey guys! im having some trouble using the --switch flag when upgrading an application to a different, locally built, charm
<SimonKLB> ERROR cannot upgrade "X" to "Y"
<SimonKLB> it looks like this is the cause: https://github.com/juju/juju/blob/staging/cmd/juju/application/upgradecharm.go#L508
<SimonKLB> am i not understanding the --switch flag correctly? i thought that was the point of it
<anastasiamac> SimonKLB: u may be running into https://bugs.launchpad.net/bugs/1673122
<mup> Bug #1673122: Incorrect series used during upgrade to a local charm and no way to specify it manually <cdo-qa-blocker> <cpe> <talisman> <upgrade-charm> <juju:In Progress by ecjones> <https://launchpad.net/bugs/1673122>
<SimonKLB> anastasiamac: i dont think so, the error message i get is this one: https://github.com/juju/juju/blob/staging/cmd/juju/application/upgradecharm.go#L509
<SimonKLB> which seem to be spawned when the old and the new charm names differ
<anastasiamac> SimonKLB: feel free to file a bug, with repro scenario and logs :)
<SimonKLB> anastasiamac: found one already :) https://bugs.launchpad.net/juju/+bug/1666904
<mup> Bug #1666904: upgrade-charm --switch doesn't work with local charms <charm> <charmers> <upgrade-charm> <juju:Triaged> <https://launchpad.net/bugs/1666904>
<anastasiamac> SimonKLB: \o/ i thought i saw something recently.. no wonder - it only came in a month ago ;)
<tasdomas> hi, could somebody take a look at this: https://github.com/juju/juju/pull/6843 ?
<thumper> morning
<redir> morning thumper
<babbageclunk> morning redir
<redir> morning babbageclunk :)
<cmars> morning thumper
<cmars> thumper, can we get another look at this old PR: https://github.com/juju/juju/pull/6843
<thumper> approved
<cmars> thumper, thanks!
#juju-dev 2017-04-04
 * babbageclunk runs for a bit
<anastasiamac> axw: menn0: coming?
<menn0> anastasiamac: for what? I have the CAAS call now.
<anastasiamac> menn0: k.. release bug and cycle stuf... but u r free to whatever :D
<axw> anastasiamac: not unless you need me, having lunch
<menn0> anastasiamac: sorry, if you need me, can we think about rescheduling? there aren't many times I can meet the CAAS team
<anastasiamac> menn0: no. breathe easy
<mup> Bug #1679463 opened: Cannot update controller-cloud endpoint <juju-core:New> <https://launchpad.net/bugs/1679463>
<mup> Bug #1679463 changed: Cannot update controller-cloud endpoint <juju-core:New> <https://launchpad.net/bugs/1679463>
<mup> Bug #1679463 opened: Cannot update controller-cloud endpoint <juju-core:New> <https://launchpad.net/bugs/1679463>
<mup> Bug #1679463 changed: Cannot update controller-cloud endpoint <juju:New> <https://launchpad.net/bugs/1679463>
<mup> Bug #1679463 opened: Cannot update controller-cloud endpoint <juju:New> <https://launchpad.net/bugs/1679463>
<mup> Bug #1679463 changed: Cannot update controller-cloud endpoint <juju:New> <https://launchpad.net/bugs/1679463>
<jam> rick_h: I'm currently head deep in algorithm stuff, you can ping me if you have stuff you really want to chat, but I'd like to get through this if possible
<rick_h> Jam on holiday. Have fun.
<jam> rick_h: enjoy your holiday
<Mmike> jam, do you have a 'oneliner' of some sort that would allow me to connect to mongodb on juju state server? (juju2.1)
<Mmike> i'm having ssl issues, and I'm not sure how to properly plant the certificate files
<jam> Mmike: http://pastebin.ubuntu.com/24312635/
<jam> is what I run after "juju ssh -m controller 0"
<Mmike> sslAllowInvalidCertificates !!!
<Mmike> jam++ thnx!
<jam> (that declares a bash function, and then you use "dialmgo" to execute it)
<Mmike> ack, thank you! :)
#juju-dev 2017-04-05
<axw> hml: we can't hear you
<axw> hml: still there?
<thumper> happy birthday axw :)
<axw> thanks thumper :)
<axw> thumper jam menn0: speaking of, I'm going out for lunch, so won't be able to make tech board today
<thumper> ack
<menn0> axw: np
<babbageclunk> axw: Oh yeah, happy birthday! Hope the birthday lunch is super delish.
<axw> babbageclunk: thanks
<thumper> fuck, fuck, fuckity fuck
<thumper> does anyone here understand leadership as it was in 1.25?
<blahdeblah> thumper: You really know how to brighten my day. :-)
<thumper> :)
<thumper> blahdeblah: don't suppose you understand it?
<blahdeblah> I don't, but axino might. :-)
<thumper> looks like there should be an entry in the leases collection for it
<thumper> but I don't see entries there for the services I expect
<thumper> like...
<thumper> there aren't any
<thumper> just one for a clokc
<thumper> clock
<thumper> this is crack
<veebers> Happy Birthday axw :-)
<axw> thanks veebers
<anastasiamac> thumper: dunno about 1.25 but in 2., leases collection has an aaplication-leader "clock" , there is also a "clock" and a "lease" per model in that collection... these r both tagged as "singular-controller"
 * thumper sighs
<thumper> FFS
<thumper> my old DB dump didn't have any leases
<thumper> but now they are there
<thumper> why?...
<thumper> I've got nothing
<jam> menn0: btw, I'm no longer sure that deleting documents as you iterate was the cause of the problem vs the bson.M vs bson.D issue.
<menn0> jam: could it have happened at any time?
<jam> menn0: what I mean is that using the old "Id interface{}" meant that some % of the time documents would fail to be removed
<jam> which might have been the actual cause of them not getting removed
<jam> rather than deletions causing my iteration to be wrong.
<menn0> jam: ok right
<jam> menn0: so I've pushed up the changes from your review. IF you could look at it today so I can land this and then iterate on the next steps?
<menn0> jam: looking now
<menn0> jam: ship it on the first one
<menn0> jam: why does the second one mention ericsnowcurrently? :)
<menn0> jam: done
<jam> menn0: I've seen something like that as well. Things like "this change was updated by ericsnowcurrently"
<jam> thanks for the review
<menn0> jam: could be the reviewboard integration as eric set that up?
<jam> menn0: yeah, probably
<jam> menn0: I wanted to run something by you
<jam> menn0: I did find a few things running on a live controller
<jam> one interesting thing
<jam> is that it is actually reasonably to get down to 0 transactions in txns
<jam> which means "pruneFactor" starts to become meaningless
<jam> and it just causes pruning to run all the time
<jam> menn0: yeah, I bet that's it, because it adds the reviewboard link to the pull request
<jam> menn0: I'm thinking to add something that would make the behavior configurable / default to a minimum of 100/1000 transactions
<jam> and maybe a maximum ignoring pruneFactor
<SimonKLB> will LXC containers always show hardware specs as 0 ?
<hoenir> After writing a provider and a api client from scratch it's amazing how well juju is structured in interfaces.
<hoenir> And how easy is to embed and compose the functionalities. I really didn't need to look up on some docs or anything like that. I just watched and readed the code... on some places it laks comments but overall a good experience.
<hoenir> Good job done guys !
<hoenir> Well done..
<hoenir> *
<hoenir> Did anyone noticed this when writing a provideR?
<Dmitrii-Sh> Hi. Question: https://jujucharms.com/docs/2.1/reference-charm-hooks#leader-elected <- this doc says "If the election process is done internally to the service, other code should be used to signal the leader to Juju.". However, I don't see any hook tools to assert leadership http://paste.ubuntu.com/24319908/ So, as far as I understand, there is no manual way
<Dmitrii-Sh> to designate a leader and the doc is wrong. Does anyone know if it is supposed to be that way and if this has not been implemented for a reason?
<Dmitrii-Sh> "Authors can use this hook to take action if their protocols for leadership, consensus, raft, or quorum require one unit to assert leadership." - this doesn't make much sense as well as if you have a network partition you may actually have multiple leaders in separated clusters. If Juju has access to both clusters, for example, it may get conflicting
<Dmitrii-Sh> requests for leadership from that 'other code that signals internal notion of leadership to juju'
<admcleod> sinzui: fyi, magpie now does MTU
<sinzui> admcleod: interesting. I will look soon
<cmars> morning folks, could i get a review of https://github.com/juju/juju/pull/7195 please?
<sinzui> babbageclunk: did you see bug 1680046
<mup> Bug #1680046: Bootstrap failed on maas 1.9 because invalid character '<' looking for beginning of value <bootstrap> <ci> <maas-provider> <regression> <juju:Triaged by 2-xtian> <https://launchpad.net/bugs/1680046>
<babbageclunk> sinzui: no I hadn't - looking now
<babbageclunk> sinzui: is the test running against maas 1.9.5?
 * sinzui looks
<sinzui> babbageclunk: no, 1.9.4+bzr4592-0ubuntu1~trusty1. It is scheduled to be upgraded to 1.9.5+bzr4599-0ubuntu1~14.04.1 this weekend
<sinzui> babbageclunk: I can make it upgrade right now
<babbageclunk> sinzui: hmm, that might be it then. I ran my smoke test against 1.9.5.
<babbageclunk> sinzui: Is breaking juju for 1.9.4  a problem?
<babbageclunk> sinzui: (I can see that it might be.)
<sinzui> babbageclunk: Awkward answer. the answe no we should not, but we do love the maas team when they say the only fix for a bug is to upgrade to the latest maas
<babbageclunk> sinzui: yeah, sure - it would be pretty annoying for a user who has a working 1.9.4 maas
<babbageclunk> sinzui: I'll roll back to my 1.9.4 snapshot and try to work out why it's broken against it.
<sinzui> babbageclunk: 1.9.5 is only 6 days old. so few will have it. Like us we don't get updated every day. BUT....
<sinzui> if you don't fix the issue soon, my maas will go to 1.9.5 anyway
<babbageclunk> sinzui: yay easy fix!
<babbageclunk> sinzui: j/k
<sinzui> babbageclunk: I am half serious myself. I think the issue will fix itself if I don't interviene with the servers update schedule
<babbageclunk> sinzui: well, I guess we can discuss more in about 5 mins
<anastasiamac> babbageclunk: sinzui: it's on the list \o/
<anastasiamac> (minutes)*
<cmars> morning folks, can i get a review of https://github.com/juju/description/pull/11 please?
<cmars> https://github.com/juju/juju/pull/7202 will soon follow
<babbageclunk> sinzui: weirdly, I can bootstrap on 1.9.4, although it requires a lot of retries for the bootstrap to successfully ssh to the deployed controller machine
<babbageclunk> sinzui: Could I get access to the maas where this test was failing?
<babbageclunk> sinzui: no worries, I worked it out - bootstrapping against it now.
<sinzui> babbageclunk: you may already have,. did I send you the snippetsmfrom cloud-city to get into munna?
<babbageclunk> sinzui: I eventually remembered to look in there.
<sinzui> babbageclunk: are you in?
<babbageclunk> sinzui: yup yup
<babbageclunk> sinzui: ok, I see why my smoke test didn't find this now.
#juju-dev 2017-04-06
<menn0> thumper: just a reminder that this exists: https://github.com/juju/pubsub/issues/3
<menn0> (doing my backstop duties)
<cmars> menn0, is a v3 necessary, for a new feature that's not in a supported release yet? or are we giving betas full migration support now?
<cmars> re: https://github.com/juju/description/pull/11
<thumper> menn0: yeah, saw it, but it makes no sense
<thumper> easy. closed it
<thumper> :)
<menn0> cmars: no need to support migration of everything in betas, but the struct version would need to be bumped once released
<menn0> thumper: also these: https://github.com/juju/loggo/issues
<axw> jam: when you're awake, can you please add hmlanigan@github to github.com/go-goose/goose
<cmars> menn0, roger that
<cmars> menn0, even a beta release?
<cmars> menn0, or does it look good?
<cmars> i'm confused :)
<menn0> cmars: so I don't think you necessarily need to bump the version for a beta release
<cmars> menn0, ok, ok
<menn0> cmars: but I am concerned that we'll forget about it if the change gets merged without the version bump
<cmars> menn0, what's the risk, exactly?
<cmars> existing beta models?
 * menn0 thinks
<cmars> menn0, one thing to consider, is that no one currently can set the sla, because we haven't turned this service on
<menn0> cmars: ok... I guess that's fine then
<menn0> cmars: just approved the pr
<cmars> menn0, tyvm
<menn0> axw: what's up with this? https://github.com/juju/gnuflag/issues/1
<menn0> axw: this even: https://github.com/juju/juju/pull/6326
<axw> looking
<axw> menn0: nothing atm, still needs simplestreams updates
<menn0> axw: ok, added comment about that
<axw> menn0: made some progress in barcelona, but then stalled again afterwards. aaron was on that, but not anymore AFAIK
<axw> menn0: ta
<menn0> jam: see this? https://bugs.launchpad.net/juju/+bug/1679875
<mup> Bug #1679875: inability for juju to figure out container's IP addresses <juju:New> <https://launchpad.net/bugs/1679875>
<blahdeblah> How can I download a charm from something other than the stable channel on juju 1.x?
<babbageclunk> axw: can you take a look at this? https://github.com/juju/juju/pull/7206
<axw> babbageclunk: looking
<babbageclunk> axw: thanks
<axw> babbageclunk: LGTM, thank you. sorry, I think I signed off originally - should have picked that up
<babbageclunk> axw: :) Oh well,  least it's fixed now!
<cmars> can i get a review of https://github.com/juju/juju/pull/7202 please?
<cmars> menn0, ^^
<menn0> cmars: looking
<cmars> menn0, thanks!
<menn0> cmars: done
<cmars> menn0-afk, thanks!
<thumper> axw: quick Q) do you know what 1.25 ipaddresses (from collection of that name) are used for? Also, if we didn't migrate them from 1.25 -> 2.x, there is a worker that discovers all the link layer devices and their ip addresses, right?
<axw> thumper: I don't know, sorry. jam would probably know?
<thumper> axw: no worries
<anastasiamac> wpk: ping :)
<wpk> anastasiamac: pong :)
<oops___> status stuck on: "allocating 0/lxd/0 waiting for machine". Any ideas?
<wpk> is machine '0' ready?
<oops___> wpk: it's in down pending
<oops___> wpk: but the machine looks ok: has processes and an IP
<perrito666> Oops__ the juju agent might have had problems to start, try checking /var/log/juju*.log on the container
<SimonKLB> is it possible to set lxc limits such as limits.cpu using juju atm?
<rogpeppe> a code-movement only PR, reviews appreciated: https://github.com/juju/juju/pull/7208
<rogpeppe> another PR, much smaller, but somewhat more significant: https://github.com/juju/juju/pull/7209/files
<rogpeppe> perrito666: you still around?
<perrito666> I am on holidays, there is 0 chance that is going to be me :p
<rogpeppe> perrito666: ha, i saw you on IRC and thought you might be still around :)
<perrito666> I have irc on the phone and was waiting for a light rain to pass before heading back to the pool
<perrito666> :p
<mup> Bug #1680582 opened: Agents losing connection to leader tracker <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1680582>
<mup> Bug #1680582 changed: Agents losing connection to leader tracker <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1680582>
<mup> Bug #1680582 opened: Agents losing connection to leader tracker <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1680582>
#juju-dev 2017-04-07
<axw> babbageclunk: you said in standup you wanted some advice on something?
<blahdeblah> Anyone started looking at lp:1618212 ?  Just got it after upgrading from 2.0.3 to 2.1.2, which means that I can't upgrade any of the models, because I can't list them.
<anastasiamac> blahdeblah: m looking at a bug that feels related
<blahdeblah> Well, let me know if you need to look at anything in this env.
<anastasiamac> blahdeblah: but this bug is about model destruction not listing...
<anastasiamac> blahdeblah: logs r always helpful, mayb even a db dump (altho with 40+models sounds scary...)
<blahdeblah> anastasiamac: I just took a backup, so you can have that if needed.  (This is the same env which led me to create lp:1680683.)
<blahdeblah> The backup is 6 GB
<anastasiamac> blahdeblah: m saying that the bug u referenced above is about destruction, not listing... altho frankly i am ware and kind of looking at both issues - the destruction of the model as well as lsiting of models...
<anastasiamac> aware even
<blahdeblah> anastasiamac: you must be reading a different bug to me; 1618212 is definitely about listing models
<anastasiamac> blahdeblah: the title says "juju models fails during model destruction"
<blahdeblah> anastasiamac: Every commenter on that bug says they're getting the error from "juju models".
<blahdeblah> It might be related to destruction in some way under the covers, but where it shows up in the user experience is listing models.
<blahdeblah> And I've just encountered it while listing models after an upgrade, no destruction involved.
<anastasiamac> blahdeblah: i think the problems r related - we cannot cleanly destroy models under some circumstance, and list models gets confused
<anastasiamac> blahdeblah: specifically for list models, I have: https://bugs.launchpad.net/juju/+bug/1674805 and https://bugs.launchpad.net/juju/+bug/1676279
<mup> Bug #1674805: list-models fails after model is destroyed after model migration <ci> <intermittent-failure> <list-models> <model-migration> <juju:Triaged by anastasia-macmood> <https://launchpad.net/bugs/1674805>
<mup> Bug #1676279: juju 2.1.1 controller not removing models correctly (list-models showing "info: settings not found") <destroy-model> <list-models> <juju:Triaged> <https://launchpad.net/bugs/1676279>
<blahdeblah> maybe one of those will match my problem better
 * blahdeblah looks
<anastasiamac> blahdeblah: definitely worth a comment on any related bug that matches ur case ;)...
<blahdeblah> 1676279 seems like a dup of 1618212 to me
<blahdeblah> so does 1674805, TBH
<blahdeblah> But neither matches better, so 1618212 will do for now
<blahdeblah> I think, however, that destroy-models might be a distraction, since I got the error message without trying to destroy anything.
<anastasiamac> blahdeblah: yeah... i think the underlying cause is the same but all are coming from slightly different angles.. yes, there is an issue in both destroy and list - slightly different issue...
<anastasiamac> blahdeblah: hence, i said that the bug u referenced was for destroy... ppl just started putting list models comments into it
<anastasiamac> blahdeblah: at the end of the day, both issues needs to b fixed so feel free to update whichever bugs feels closer to u :D
<blahdeblah> Well, you know the code better than I
 * anastasiamac laughs
<anastasiamac> blahdeblah: u made my day, really
<blahdeblah> There was no model destruction involved in my case, yet I ended up with the same error message.  So if you want a new bug that says "juju models fails after juju-upgrade", I'm happy to supply one.
<blahdeblah> Number of anastasiamac PRs on juju > number of blahdeblah PRs on juju; hence, you know the code better than I. ;-)
<blahdeblah> (where number of blahdeblah PRs on juju == 0)
<anastasiamac> blahdeblah: my first, almost knee-jerk reaction is "no! i don't want another bug"
<blahdeblah> I figured ;-)
<anastasiamac> blahdeblah: but i think it'd b better if u did report it separately... besides i do want to see ur logs and db...
<anastasiamac> blahdeblah: coz we have not heard (I *think*) of probelms when upgrading...
<anastasiamac> blahdeblah: *after* upgrading
<blahdeblah> So, is that a "yes, I do want another bug"?
<anastasiamac> blahdeblah: and m pretty sure we test upgrades extensively...
<blahdeblah> anastasiamac: Personally, I don't think it would achieve much
<anastasiamac> blahdeblah: no, let's not for now :)
<blahdeblah> I think what's happening is there were models which were marked as destroying when I started the upgrade.
<anastasiamac> blahdeblah: yeah, that's the symptoms m seeing in all other similar failures
<anastasiamac> lingering/ghosting models
<blahdeblah> yeah - given axino's comments in 1676279, I think once you fix one, you'll fix them all
<anastasiamac> blahdeblah: i wonder if his db surgery on the models marked as 'destroying' will get u unblocked.. at least while we r sorting the issue..
<blahdeblah> I still disagree that this isn't a bug in listing; regardless of whether a previous destroy left some models lingering, "juju models" should keep working.
<anastasiamac> blahdeblah: but since u r dealing with production as well, mayb not the most desirable way forward...
<anastasiamac> blahdeblah: there is nothing to disagree - I agree that listing has a bug
<blahdeblah> No, not the most desirable way forward, but if we can't list models, JAAS will probably be a bit dead in the water, so it may be necessary.
<blahdeblah> urulama: ^ See discussion above; looks like there are at least 3 bugs about destroyed/ing models staying in DB
<urulama> juju bugs for breakfast \o/
<urulama> :)
<blahdeblah> anastasiamac: How likely is it that those model listing/destroying bugs will be fixed in a 2.1.x update?
<anastasiamac> blahdeblah: i thought u said that u r seeing in after the upgrade to 2.1.x already... 2.1.2 specifically?..
<blahdeblah> Yep
<blahdeblah> So how likely is it that we'll see a fix in 2.1.[3-5]?
<anastasiamac> blahdeblah: we have not planning another 2.1.x... most likely in 2.2...? unless the sky falls?...
<blahdeblah> I thought that might be your answer.  :-)
<blahdeblah> thanks
<anastasiamac> blahdeblah: just for reference, m still trying to figure out what goes wrong... i can reproduce destroy failure... i also *know* what's causing issues on list... but until i can nail it down, i don't know if it is easy to backport and release another 2.1.x...
<blahdeblah> No worries - just trying to work out best course of action for this controller on which models can't be listed.
<blahdeblah> urulama: ^ You mind checking whether us-east-1 is still functional from your perspective?
<anastasiamac> blahdeblah: m guessing that u have tried the standard?
<blahdeblah> anastasiamac: "the standard"?
<blahdeblah> not as yet, but I will
<urulama> blahdeblah: that was aws, right?
<blahdeblah> yep
<urulama> ok, looks fine, but i'll check with some big users as well
<wpk> https://drive.google.com/open?id=0BwYF43OiGvHjWkFnLVJCVlFaRFk
<wpk> ^^^ that's a dependency graph for juju/juju/api/
<rogpeppe> anyone around to review this large but mechanical code-move branch: https://github.com/juju/juju/pull/7213
<cmars> anyone available this friday afternoon for a quick review?
<cmars> i've got https://github.com/juju/juju/pull/7214 which fixes critical bug https://bugs.launchpad.net/juju/+bug/1680883
#juju-dev 2017-04-08
<mup> Bug #1672306 opened: unit stuck executing update-status <canonical-is> <juju-core:Confirmed> <https://launchpad.net/bugs/1672306>
#juju-dev 2017-04-09
<mup> Bug #1681278 opened: cmd cmd.go:129 Fetching Juju GUI 2.5.0 hangs up and fails <juju-core:New> <https://launchpad.net/bugs/1681278>
<mup> Bug #1681278 changed: cmd cmd.go:129 Fetching Juju GUI 2.5.0 hangs up and fails <juju:New> <https://launchpad.net/bugs/1681278>
<mup> Bug #1681287 opened: juju should retry failed update-status hooks <juju-core:New> <https://launchpad.net/bugs/1681287>
<axw> babbageclunk: morning. do you have time for a small review? https://github.com/juju/juju/pull/7197
<veebers> axw: the calender has babbageclunk as on leave today, so if he doesn't respond I don't think it's because he's being rude :-)
<axw> veebers: doh, thanks :)
<axw> anastasiamac: seeing as christian is out, can you please review ^^ if you have time
#juju-dev 2018-04-02
<jam> manadart: are you around today?
<jam> externalreality: can you review https://github.com/juju/testing/pull/136 ?
<externalreality> jam, can do
<externalreality> jam, LGTM - why is the description explains everything accept why the admin database is being dropped. Just out of curiosity - why is it being dropped?
<jam> externalreality: I have the feeling it never really was, it was just that mongo wasn't complaining about it until 3.6
<jam> admin is what holds the users, etc. so I don't see how you could really drop it
<externalreality> jam, I see
<jam> externalreality: and the Juju patch to bring in testing: https://github.com/juju/juju/pull/8553 ?
<externalreality> approved
<externalreality> jam ^^^
<balloons> hml, finally finished your review. Sorry it took me so long
<hml> balloons: ty
<hml> writing the ci test, i told it to deploy with trusty, but it deployed with xenial instead?
<balloons> hml, did you pass series to the test?
<hml> i defined one in the client.deploy() call
<balloons> hml, odd. Well, try passing --series trusty and see if that fixes it, at least to unblock you
<hml> balloons: i think i figured it outâ¦ i made an invalid assumption about local_charm_path()
<balloons> hml, deploying like  client.deploy(charm, series=charm_series, repository=charm_dir)
<balloons> ?
#juju-dev 2018-04-03
<manadart> jam: Made changes to https://github.com/juju/juju/pull/8551
<manadart> I need to discuss https://github.com/juju/juju/pull/8550
<jam> manadart: replied to https://github.com/juju/juju/pull/8551
<manadart> jam: Ack.
<jam> manadart: any chance you can meet with gsamfira today for Oracle call?
<jam> (now-ish)
<manadart> jam: Sure. Where?
<jam> manadart: https://hangouts.google.com/hangouts/_/canonical.com/cloudbase-sync
<manadart> omw
<jam> manadart: might need https://hangouts.google.com/hangouts/_/canonical.com/cloudbase-sync?authuser=1 ?
<jam> manadart: I'll be happy to chat with you about 8550 in a bit, trying to get my cleanups code working
<manadart> jam: K. Standup is looming in any case.
<jam> manadart: heading to standup now if you want to chat a bit
<manadart> jam: brt
<jam> balloons: standup?
<thumper> balloons, veebers: why... why is develop failing to build for me?
<thumper> container/lxd/lxd_test.go:18:2: cannot find package "github.com/lxc/lxd/client/mocks" in any of:
<veebers> thumper: I noticed the other day, you'll need to add patches to it
<thumper> why?
<veebers> thumper: there is some mock/patch stuff that was added recently (by wpk I think)
<thumper> ffs
<veebers> thumper: I think GoMock related? I haven't followed up yet
<veebers> thumper: the header of the patch states: Code generated by MockGen. DO NOT EDIT.
<thumper> the fact that I can't grab develop and run "make check" is a big deal
<balloons> thumper, YEP. I ran into the same thing
<balloons> we have new patches.. we're going backwards :-(
<balloons> make add-patches
<wpk> thumper: that's temporary as juju has to use very specific version of lxd (freshest one that still has old API), when provider will be moved completely to new API (and therefore HEAD) that should be gone. Alternatively, this mock could be moved into juju/juju/tools/lxdtools/lxdmock
<thumper> at the very least, we should move it internally then kill it with fire
<wpk> kill what? mock?
<wpk> patch?
<wpk> ah, but it still won't work as lxd has no NewOperation/NewRemoteOperation in the 'magical' version.
<wpk> (in HEAD they changed Operation/RemoteOperation to be interfaces
<thumper> hmm..
<wpk> thumper: a very ugly but very effective solution would be to disable those tests for now
#juju-dev 2018-04-04
<thumper> veebers: got a few minutes?
<veebers> thumper: otp with babbageclunk
<thumper> if it is dependency related, I have information
<thumper> and suggestions
<thumper> veebers, babbageclunk ^^
<veebers> thumper: well, was related to the move to macaroon/bakery v2 (failing test).
<thumper> I'm considering a somewhat more agressive stance on imports
<thumper> which impacts all this work
<veebers> thumper: did you want to chat now, or should I have lunch first? I'm needing to pop out for an errand shortly
<thumper> perhaps quick now?
<thumper> 5 min max
<thumper> https://hangouts.google.com/hangouts/_/canonical.com/dep-hell
<veebers> thumper: ack, 5 min timebox :-)
<anastasiamac> thumper: could u plz come into babbageclunk's office (aka a-team standup)?
<anastasiamac> thumper: https://hangouts.google.com/hangouts/_/canonical.com/a-team-standup?authuser=0
<thumper> ack
<thumper> jam: how goes the removal of api server machines?
<thumper> babbageclunk: got a few minutes?
<babbageclunk> thumper: yup
<babbageclunk> thumper: in 1:1?
<thumper> ack
<babbageclunk> hmm, we don't appear to have a 1:1 anymore? I'm in the hangout called christian-tim
<jam> externalreality: gave some feedback on 8555
<externalreality> jam, Ack on the feedback.
<rogpeppe> babbageclunk, veebers: if you're around, i replied to that mail thread about the macaroon error response
<veebers> rogpeppe: hey o/ I'm a little bit around :-)
<rogpeppe> veebers: hiya
<rogpeppe> veebers: so ISTM that this probably isn't a macaroon size issue at all
<veebers> rogpeppe: what's the best way to get you the comparison data? Print out the headers and body from somewhere?
<veebers> rogpeppe: oh?
<rogpeppe> veebers: did you see the email i just sent?
<veebers> rogpeppe: just reading now, oh are you saying introduced in juju/juju (that rev?)
<rogpeppe> veebers: i don't know exactly when this has been changed, but pretty recently
<veebers> rogpeppe: interesting. There was a large branch landeed by babbageclunk but that might be a red herring
<rogpeppe> veebers: looks like it was done in eab1c2550ffc0695a2dfa1ab9583d62863efc41b
<veebers> ah, that would be the large one I mentioned :-)
<rogpeppe> veebers: BTW isn't that a backwardly incompatible change?
<veebers> rogpeppe: which, eab1c25?
<rogpeppe> veebers: yeah
<veebers> rogpeppe: I'm not familiar with the changes, only aware it went in
<rogpeppe> veebers: ok
<rogpeppe> veebers: well, given that that commit seems to have been working, perhaps it's worth looking at the size issue too
<veebers> rogpeppe: what gives you concern? (I have faith in babbageclunks and wallyworlds reviews)
<veebers> rogpeppe: aye, the test pass on that commit
<rogpeppe> veebers: if an old client connects to the new server, i'd be concerned that it can still see the macaroon error response
<rogpeppe> veebers: maybe it decides what to do based on something in the request though
<veebers> rogpeppe: I can mention that tomorrow if you like, get some closure :-)
<rogpeppe> veebers: i'm just trying to work out what goes on in the code
<rogpeppe> veebers: in the meantime, it would be great to get an example of the old and the new macaroons that are being returned from the api server
<rogpeppe> veebers: to see why the size is changing
<rogpeppe> veebers: because that may be indicative of some other issue
<veebers> rogpeppe: posted you some logs, let me know if that's useful or not, I'll grab from tip of develop now (i.e. v1 macaroons)
<rogpeppe1> veebers: sorry, my network stack just died
<rogpeppe1> veebers: what was the last thing you saw me say?
<rogpeppe1> veebers: last thing i saw from you was "I can mention that tomorrow if you like, get some closure :-)"
<veebers> rogpeppe1: ugh sucks. I saw:veebers: because that may be indicative of some other issue
<veebers> oh
<veebers> rogpeppe1: I chucked you some logs, let me resend, let me know if it's the details you need
#juju-dev 2018-04-05
<babbageclunk> veebers: could you please review this? https://github.com/juju/juju/pull/8558
<veebers> babbageclunk: sure thing
<babbageclunk> Thanks! I backed out the change I was doubtful about.
<veebers> babbageclunk: approved with a small question for my own clarification
<babbageclunk> cool, looking now
<babbageclunk> thanks!
<veebers> babbageclunk: you have a quick sec to check something for me? Need to make sure I'm not doing something dumb (this is the test where if I just explicilty return a bakery.MemStorage it works, but won't with a rootKeys.NewStorage + collection
<babbageclunk> sure
<babbageclunk> veebers: ^
<veebers> babbageclunk: standup HO?
<babbageclunk> omw
<kjackal> Hello Juju people, my aws account seems to be out of security groups. Is there a safe way to delete those that are not used?
<manadart> I just opened a PR mooting the use of GoMock, initially for testing the systemd package.
<manadart> https://github.com/juju/juju/pull/8560
#juju-dev 2018-04-06
<mup> Bug #1761706 opened: agent installation fails <juju-core:New> <https://launchpad.net/bugs/1761706>
<mup> Bug #1761706 changed: agent installation fails <juju:Incomplete> <juju 2.3:Triaged> <https://launchpad.net/bugs/1761706>
<mthaddon> hi folks - I've recently upgraded to bionic and just installed the charm snap. charm build (for grafana) is asking "build: Unable to locate interface:nrpe-external-master. Do you need to set INTERFACE_PATH?" - googling doesn't throw up anything obvious - can anyone point me in the right direction?
<balloons> mthaddon, is the interface connected?
#juju-dev 2018-04-08
<thumper> veebers: is there something wrong with the merge bot?
<veebers> thumper: not that I'm aware of, whats the issue/
<veebers> thumper: (which merge job?)
<thumper> I was just looking at one of jam's branches
<thumper> saw the merge request but no bot response
<thumper> https://github.com/juju/juju/pull/8557
<veebers> thumper: it's possible it's the issue where the hook gets dropped or ignored by jenkins.
<thumper> do the checks on a PR get cleared on new pushes?
<veebers> thumper: checks get re-run on pushes. (you can see ticks/crosses beside the commit sha in the list)
<thumper> I know that the merge jobs just show up as checks now...
<thumper> perhaps it was just that
<thumper> never mind me
<veebers> thumper: If the merge bot had run it would have been merged, unless there was an issue then it would show as a failure
<thumper> but we don't add a comment on failure, do we?
<veebers> thumper: if you click "show all checks" you'll see that only the check-merge job has run
<veebers> thumper: it would show up in the checks list
<thumper> ah, found it
<veebers> thumper: argh, so the merge job did run (before your current one) and went unstable, no idea why it didn't update the PR. :-\ Having a quick look now
<thumper> ok, thanks
<veebers> thumper: I'm a little confused :-\ jams merge command worked, it ran and failed and marked that commit broken (red cross) but it wasn't mentioned in the checks section. Jam then pushed up some  . ..  ah
<veebers> thumper: It seems that pushing up a commit and getting a run on it clears any previous runs (incl. failures) so the updated push removed the check comment for the failed merge (it was still marked as error by the red cross though)
 * veebers is no longer confused
 * thumper nods
<thumper> morning wallyworld
<wallyworld> hey
<thumper> veebers: do you use spacemacs with vim editing or emacs?
<veebers> thumper: emacs
<veebers> wallyworld: hey o/
<wallyworld> hiya
<anastasiamac> o/
