[00:27] <thumper> wallyworld: I'm in our hangout if you are ready early
[00:27] <wallyworld> ok
[00:32] <ericsnow> davecheney: I have a question about a review comment you left on our GCE patch
[00:33] <ericsnow> davecheney: do we have a uniform mechanism for getting a string representation of a machine ID (and not by using a machine tag)?
[00:34] <ericsnow> davecheney: given the strong correllation between instances and juju machines, using the machine ID in the instance name is valuable
[00:35] <davecheney> ericsnow: a name for a machine id that isn't a tag ('cos this isn't the api) ?
[00:35] <davecheney> honestly, not sure
[00:35] <davecheney> state.Machine.String() ?
[00:35] <davecheney> ^ total guess
[00:36] <ericsnow> davecheney: k
[00:36] <davecheney> menn0: waigani any ideas ?
[00:37] <menn0> hmm
[00:39] <ericsnow> davecheney: the alternative is to pick a suitable format to use in the one bit of code (losing any benefits of code reuse)
[00:39] <menn0> davecheney, ericsnow: don't you just want Machine.Id()?
[00:39] <menn0> i'm probably not understanding what you're after
[00:39] <ericsnow> menn0: all I have is the ID as a string (e.g. "0")
[00:40] <menn0> ericsnow: right
[00:40] <menn0> ericsnow: and what would you like?
[00:41] <ericsnow> menn0: currently I'm using names.NewMachineTag and then String() on the result, all to get a standardized representation to use in an instance name
[00:42] <ericsnow> menn0: I was trying to keep naming consistent with the rest of juju, but it sounds like we don't have another way to get that uniform repr from a machine ID
[00:45] <menn0> ericsnow: why I don't think there's anything else. A shorter route to the same thing would be someMachine.Tag().String().
[00:45] <menn0> s/why//
[00:45] <menn0> if you have a machine instance
[00:47] <ericsnow> menn0: this code is provider-related, so pretty much it's unrelated (directly) to state
[00:48] <menn0> ericsnow: ok then, I've got nothing :)
[00:48] <ericsnow> menn0: no worries :)
[01:10] <cherylj> ericsnow: I added the function names.ReadableString a while back to do what I think you're looking for
[01:10] <cherylj> oh wait, that takes a tag too
[01:11] <cherylj> but I added that in to not print machine tags out on the CLI
[02:49] <axw> wallyworld: forgot to talk about storage info in 1:1. did you understand what I was getting at in the standup about translating volume/filesystem info to storage info on-the-fly?
[02:50] <hazmat> ahasenack, dpb1, rick_h_ pushed new py j client w/ iterator fix .. version incr math fixed as well (0.50.1)
[02:50] <wallyworld> axw: yeah, sounded "ok" at a high level, could you shoot through a tl;dr; email with a quick summary of the implementation?
[02:50] <axw> wallyworld: sure
[02:50] <wallyworld> ty
[02:51] <rick_h_> hazmat: <3 ty kindly. jcsackett should have finished QA and we'll get it into the juju stable ppa tomorrow.
[02:56] <axw> wallyworld: sent
[02:56] <wallyworld> ty
[03:09] <axw> wallyworld: once again without gpg please
[03:18] <wallyworld> oh ffs
[03:19] <wallyworld> i gotta find out why thunderbird does that
[03:44] <dpb1> hazmat: https://bugs.launchpad.net/python-jujuclient/+bug/1426020 need that one too, I'll be landing it soon, but could use your eyes on that patch if it was something you intended another way
[03:44] <mup> Bug #1426020: TypeError: super object is not an iterator <python-jujuclient:New> <https://launchpad.net/bugs/1426020>
[03:47] <rick_h_> dpb1: got that in http://bazaar.launchpad.net/~juju-deployers/python-jujuclient/trunk/revision/54
[03:48] <rick_h_> dpb1: so think the release done should be good to QA and move forward.
[03:48] <axw> wallyworld: I just thought of a probably better alternative. instead of watching individual storage attachments, the apiserver can return watchers for filesystem or volume attachments depending on the kind
[03:49] <axw> then there's no need to bump the other doc at all
[03:50] <wallyworld> axw: i do prefer to have fewer/no individual watchers - that's sort of what I was questioning (poorly) in that other review
[03:51] <axw> wallyworld: can't really get away without individual watchers. the other one only responds to lifecycle state. also, with only a single watcher, we'd be forced into having everything in the one collection
[03:51] <wallyworld> yeah, given the current implementation, that is true. i wish for a proper pubsub implementation
[03:51] <axw> so I'm thinking a watcher that watches all of a unit's storage attachments' lifecycle states, and then the uniter will watch volumes/filesystems individually
[03:52] <wallyworld> sounds good
[03:52]  * dpb1 checks
[03:52] <dpb1> rick_h_: thx -- closing out the bug
[03:52] <rick_h_> dpb1: ty
[03:53] <axw> wallyworld: I might move this normalisation code out of state too, into apiserver/common. client and uniter can use that, makes state a bit leaner.
[03:53] <wallyworld> yep
[03:53] <wallyworld> i thinkit belongs in a service layer
[03:54] <wallyworld> i sorta think we need it elsewhere, not apiserver
[03:54] <wallyworld> another new storage service layer
[03:54] <wallyworld> apiserver is for network marshalling etc
[03:54] <wallyworld> state is for persistence
[03:55] <wallyworld> a (new) storage service layer is for service business logic
[03:55] <wallyworld> i would love to move methods off the domain objects into that layer
[03:55] <wallyworld> move towards a proper SOA
[05:04] <ericsnow> davecheney: if you have any time to spare, I'd love it if you could follow up on your reviews for the 3 patches I have up. thanks
[05:09] <davecheney> ericsnow: sure
[05:09] <davecheney> will do
[05:09] <ericsnow> davecheney: much appreciated
[05:09] <ericsnow> davecheney: on that note, I'm going to bed :)
[06:10] <axw> wallyworld: argh :(  can't make that change, at least not the way things currently are. for a filesystem-kind storage backed by a volume, it wouldn't be enough to watch a volume attachment
[06:10] <axw> since it is affected by block devices also
[06:10] <axw> (that's where filesystem information comes from)
[06:10] <wallyworld> ah yeah, doh
[06:12] <wallyworld> axw: i've proposed the default block provider stuff http://reviews.vapour.ws/r/1024/, gotta go do pickup so no hurry
[06:12] <axw> wallyworld: ok, thanks
[07:32] <axw> wallyworld: I'm investigating a small-ish model change which I think will simplify things; being adding an optional VolumeTag to Filesystem, identifying the volume that backs the filesystem
[07:32] <dimitern> hmm cursed but not blocked?
[07:33] <dimitern> morning
[07:33] <axw> morning dimitern
[07:34] <axw> wallyworld: so IOW, there will be a Filesystem for filesystem-kind storage, regardless of whether it's first-class
[07:34] <axw> if it's not, that storage will have both a Volume and a Filesystem
[08:06] <TheMue> morning
[08:09] <TheMue> dimitern: did a test from 1.22 fail on your system? I took 1.21.3.
[08:09] <dimitern> TheMue, I should've said 1.21.3, not 1.22
[08:09] <dimitern> TheMue, morning :)
[08:10] <TheMue> dimitern: o/
[08:10] <dimitern> TheMue, so the upgrade did work?
[08:10] <TheMue> dimitern: yep. only message in log has been by the metering
[08:11] <dimitern> TheMue, great! I just wanted to double check
[08:11] <TheMue> dimitern: and I've just seen that the CI is unblocked now, fine
[08:11] <TheMue> dimitern: did you know http://juju.fail?
[08:12] <dimitern> TheMue, yes :) I've heard about it, but have forgotten - will bookmark it now :)
[08:13] <TheMue> dimitern: yes, I've bookmarked it too. better than all those $$please-let-me-in-now$$
[08:14] <dimitern> TheMue, for sure :)
[08:16] <TheMue> dimitern: the bug I'm on now need a bit more for understanding. missing knowledge about juju-deployer
[08:17] <dimitern> TheMue, juju-deployer is irrelevant for the fix itself
[08:17] <bodie_> coreycb, Actions are now out from behind the feature flag in trunk
[08:18] <dimitern> TheMue, I've explained in the email - we need to make sure Ports and PortRanges fields on UnitInfo in the megawatcher are never set to nil but empty slices instead
[08:19] <TheMue> dimitern: yes, seen it. it's only to get a better feeling for the situation which leaded to this error and maybe reproduce it
[08:21] <dimitern> TheMue, you can test it using juju-gui and the ubuntu charm in a local env, as described in the steps
[08:22] <dimitern> TheMue, and looking at the machine-0.log at TRACE level for "Deltas" (which is part of the changes reported by the AllWatcher)
[08:23] <TheMue> ok
[08:24] <dimitern> TheMue, read through it and try it out, if still unclear - let's chat on the standup
[08:24] <TheMue> dimitern: yep, will do
[08:24] <dimitern> TheMue, cheers - and please add a card for it and move your other one once merged
[08:25] <dimitern> (but edit it a bit to reflect what you did in state - it's not a sub-package change as it says)
[08:31] <TheMue> dimitern: cards are created/changed, only waiting for merging now
[08:32] <dimitern> TheMue, +1, cool
[09:42] <Muntaner> good morning o/
[09:46] <Muntaner> guys, I'm using Juju with my laptop on a cloud private OpenStack server. Another laptop now wants to bootstrap the same environment: is this possible?
[10:18] <Muntaner> solved :)
[10:28] <voidspace> dimitern: http://reviews.vapour.ws/r/1025/
[10:36] <dimitern> voidspace, LGTM
[10:36] <voidspace> dimitern: great :-)
[10:38] <voidspace> dimitern: although it looks like we're blocked at the moment
[10:38] <dimitern> voidspace, really? I can't see any blockers
[10:38] <dimitern> hmm topic needs updating
[10:39] <dimitern> voidspace, http://juju.fail/ - all green
[10:43] <TheMue> voidspace: dimitern: I added a review too, only regarding the logging format
[10:44]  * TheMue is OCR today ;)
[10:48] <dimitern> TheMue, thanks, I've replied
[10:49] <TheMue> dimitern: ah, ok, misinterpreted the output. thanks
[10:49] <dimitern> TheMue, np  :)
[10:49] <voidspace> yeah, I think the (...) format to distinguish method calls is good
[10:51] <TheMue> voidspace: yes, reading it this way sounds logical in traces
[10:51] <voidspace> TheMue: cool, thanks for looking at the PR
[10:51] <TheMue> yw
[10:53] <voidspace> dimitern: you should close your old review (and PR probably)
[10:59] <dimitern> voidspace, will do, cheers
[10:59] <dimitern> TheMue, as OCR have a look at this please http://reviews.vapour.ws/r/1026/
[10:59]  * TheMue looks ;)
[11:08] <natefinch> ahh my god, my country for a relational DB
[11:09] <natefinch> yes, let's duplicate the same information in 20 places, that sounds like a fantastic idea
[11:11] <TheMue> dimitern: you've got a review
[11:11] <dimitern> TheMue, tyvm
[11:11] <TheMue> natefinch: morning natefinch
[11:11] <natefinch> good morning :)
[11:12] <TheMue> natefinch: some wishes for a new persistency layer? ;)
[11:12] <natefinch> TheMue: honestly, I think if we just didn't duplicate data in our current one, it would be a lot better.  As it is, I'm surprised we don't have more problems with inconsistencies
[11:14] <natefinch> for example, in our list of machines, we say what jobs each machine has... cool, ok... but then we also have a separate list in the stateServers collection of which machines are state servers.... why don't we just calculate that from the machines that have JobManageEnviron?
[11:15] <TheMue> e.g. always available in a view, or even a materialized view
[11:16] <TheMue> *sigh*
[11:27] <dimitern> dooferlad, LGTM on http://reviews.vapour.ws/r/1010/ - thanks!
[11:27] <dooferlad> dimitern: thanks!
[11:50] <hazmat> just got a jujuclient bug that looks like a serious core issue imo..  allwatcher blows up in the middle of consuming the event stream.. bug 1425669
[11:50] <mup> Bug #1425669: AllWatcher next internal failure for previously removed service. <canonical-bootstack> <is> <juju-core:New> <python-jujuclient:New> <https://launchpad.net/bugs/1425669>
[11:54] <natefinch> hazmat: reading the bug,  I can't really tell what the repro steps are... it looks like "deploy a (subordinate) service, destroy the service" ... then what?
[11:56] <hazmat> natefinch: then do an allwatcher and consume
[11:56] <hazmat> s/consume/next on the allwatcher
[12:00] <Muntaner> guys
[12:00] <Muntaner> I'm writing my first charm
[12:00] <Muntaner> and have some questions
[12:03] <wallyworld> axw: i think it makes sense to model a volume backed filesystem using a volume tag attr, since ten as you say, there will always be a FileSystem object for filesystem storages. we can model it and see how it evolves
[12:05] <dimitern> hazmat, I've commented on that bug to ask for clarification
[12:05] <dimitern> hazmat, is the failure that Next returns an error or that the changes it returned have errors in them?
[12:05] <hazmat> dimitern: next returns error
[12:06] <hazmat> dimitern: that EnvError exception only triggers if the Error flag is set in the response, else its an app exception
[12:07] <hazmat> dimitern: natefinch: unrelated, but similiar to an end user.. i've also seen issues where the subordinates services are not in the watches as well bug 1421315
[12:07] <mup> Bug #1421315: subordinate service not appearing in watch output <oil> <juju-core:Triaged> <juju-deployer:Triaged by hazmat> <https://launchpad.net/bugs/1421315>
[12:07] <dimitern> hazmat, subordinates won't appear unless there's a relation to their principal
[12:08] <hazmat> noted
[12:09] <hazmat> dimitern:  so a definied service won't appear in the watch output?
[12:09] <hazmat> dimitern: thats a regression btw
[12:10] <hazmat> 0 units, but service def should be in  results returned in the watch
[12:11] <dimitern> hazmat, a subordinate service AIUI it's not really defined until there's a relation to a principal
[12:12] <dimitern> hazmat, I have to double check though
[12:12] <hazmat> dimitern: of course it is
[12:13] <hazmat> dimitern: it has state
[12:13] <hazmat> its a service with no units, there are is subordinate checks on add-unit/remove-unit
[12:14] <dimitern> hazmat, ok, that's correct yes
[12:14] <dimitern> hazmat, no units, but the subordinate service exists
[12:14] <hazmat> anyways.. the point is more that a change in behavior on the watch here (if thats what is) is a serious regression.. but of course it could just be a bug.
[12:15] <dimitern> hazmat, I'm looking into that Next() issue now with AllWatcher
[12:15] <dimitern> we *really* need tests for the AllWatcher in core
[12:35] <dimitern> dooferlad, the trunk port of the fix for bug 1415961 becomes more important with the failing maas ci jobs
[12:35] <mup> Bug #1415961: juju gives up on bootstrapping with 'bootstrap instance started but did not change to Deployed state' <bootstrap> <maas-provider> <oil> <juju-core:Triaged by dooferlad> <juju-core 1.22:Fix Released by wallyworld> <https://launchpad.net/bugs/1415961>
[12:36] <rick_h_> dimitern: as things like the gui rely on the allwatcher to know when services are added/etc a subordinate with no units should still go across the watcher so we can show it and allow a GUI user to relate it to an existing service in the environment. Just my .02 as a consumer of things.
[12:36] <rick_h_> morning and all that as /me looks at scrollback
[12:37] <dimitern> rick_h_, morning, and yes - I agree; I've narrowed down a few possible places that could be causing this
[12:37] <dooferlad> dimitern: On it now.
[12:37] <dimitern> dooferlad, thanks!
[12:37] <rick_h_> dimitern: ty, adding my feedback to the bug and let me know if there's anything we can do to help.
[12:38] <dimitern> rick_h_, cheers; it will be useful to know how far back this issue goes - is it a 1.22 and 1.23 (or just the latter), is it older
[12:38] <rick_h_> dimitern: hmm, do you all have a good pattern for git bisecting things now that juju is in git and such?
[12:39] <dimitern> rick_h_, not that I know of
[12:41] <dimitern> TheMue, hey, I'm 99% sure now the bug you're working on is caused by state/megawatcher.go:116 (since the unit is not yet assigned)
[12:43] <dimitern> TheMue, however, since you're on it anyway, the original fix I proposed will still fix that and possibly other cases where the slices can be nil
[12:45] <perrito666> ericsnow: ping
[12:45] <TheMue> great, will look at it. just came back from lunch and now reviewing an other PR
[12:47] <dimitern> TheMue, thanks
[13:17] <dooferlad> TheMue: One for your review queue http://reviews.vapour.ws/r/1028/ :-)
[13:17] <TheMue> dooferlad: *click*
[13:20] <TheMue> dooferlad: where do I find those 600s?
[13:24] <coreycb> bodie_, awesome, thanks
[13:33] <dooferlad> TheMue: I just ported this to trunk, didn't actually check the original commit messages!
[13:48] <TheMue> dimitern: so in case we've got this IsNotAssigned, we return no error. should we then retry until we get them or we've got a timeout?
[13:49] <dimitern> TheMue, no, we can't retry there - we're being called inside the multiwatcher loop
[13:50] <dimitern> TheMue, however, when we get NotAssignedError, it's ok to return []network.PortRange{}, []network.Port{}, nil
[13:51] <TheMue> dimitern: ah, fine, this would have been my solution otherwise to avoid those nils ;)
[13:53] <dimitern> TheMue, the watcher will call us again if the unit gets assigned, but we don't know when (or if)
[13:54] <TheMue> dimitern: we cannot know exactly when, but if in case of an assignment should be clear, shouldn't it?
[13:55] <dimitern> TheMue, yes :) I meant "when or even if ever"
[13:55] <TheMue> ;)
[13:57] <dimitern> TheMue, also, as I was just investigating the possible cause for bug 1425669
[13:57] <mup> Bug #1425669: AllWatcher next internal failure for previously removed service. <canonical-bootstack> <is> <juju-core:New> <python-jujuclient:New> <https://launchpad.net/bugs/1425669>
[13:58] <TheMue> dimitern: of 1.20?
[13:58] <dimitern> TheMue, what?
[13:58] <TheMue> dimitern: only seen versions: juju-core 1.20.14
[13:59] <dimitern> TheMue, my point was - can you add to your fix a couple of checks right after we call st.Unit(name) and to do the right thing if it returns NotFoundError - there are only 2 places in state/megawatcher.go -  line 107 and 187
[13:59] <dimitern> TheMue, ah, that's where they're seeing this
[14:01] <dimitern> TheMue, so about those checks - if errors.IsNotError(err) { return "", "", nil } in getUnitAddresses, and the same as above for getUnitPortRangesAndPorts - two empty slices and nil error
[14:03] <TheMue> dimitern: ok, will add it there
[14:04] <dimitern> TheMue, thanks
[14:04] <TheMue> dimitern: got to thank you for your investigation
[14:05] <dimitern> TheMue, np, I'm on the watch for new blockers hehe
[14:05] <TheMue> dimitern: *bg*
[14:24] <jw4> trivial fmt string fix: http://reviews.vapour.ws/r/1029/ PTAL
[14:25] <dimitern> jw4, this is already fixed
[14:26] <jw4> dimitern, cool, tx - I didn't see it in the lastest master... must still be merging
[14:27] <dimitern> jw4, ah, sorry I might be wrong
[14:28] <hazmat> dimitern: what about  1425669 is it incomplete? the client interaction api calls are known .. unless your asking for all api calls ever against that env.
[14:29] <dimitern> jw4, indeed - there was a similar % instead of %v in allocate address
[14:29] <dimitern> jw4, LGTM then
[14:29] <jw4> dimitern, ta
[14:29] <dimitern> hazmat, I'm asking for more logs
[14:30] <hazmat> k
[14:30] <perrito666> natefinch: brt
[14:32] <dimitern> hazmat, it's not obvious what led to that issue, so it's important to be able to follow the API calls through the logs
[14:33] <dimitern> hazmat, since we don't even have the juju status output or more than a few words describing the deployment
[14:44] <rick_h_> dimitern: jrwren is working on checking the subordinate thing againts the versions of juju and should have notes back shortly
[14:45] <rick_h_> dimitern: just fyi
[14:45] <beisner> hi all.  in test driving juju/devel, i'm still getting beta3 tools.  (WARNING failed to find 1.22-beta4 tools, will attempt to use 1.22-beta3)   why is that?
[14:48] <mgz> beisner: can you look at the simplestreams junk, add --debug and retry
[14:48] <beisner> mgz, yep will do, thx
[14:56] <dimitern> rick_h_, awesome, tyvm
[14:57] <Muntaner> hi developers o/
[14:57] <Muntaner> I'm writing my first charm and wanted to ask some questions
[15:03] <Muntaner> I have a web application that needs apache2 and mysql
[15:04] <Muntaner> When it's prompted the first time, in wordpress style, there is a web page installation
[15:04] <Muntaner> and it asks me the mysql server ip
[15:04] <Muntaner> how should I integrate this with the existing charms?
[15:05] <Muntaner> should I install mysql and apache2 "inside" my web application charm?
[15:08] <Muntaner> (dunno if I explained myself)
[15:15] <dimitern> Muntaner, hey, for charm questions, #juju is a better place to ask << lazyPower, mbruzek, marcoceppi, jcastro, can any of you guys help here? ^^
[15:15] <jcastro> yeah sure, come on over to #juju!
[15:15] <Muntaner> ok dimitern so, sorry :)
[15:17] <mattyw> dimitern, ping?
[15:20] <dimitern> Muntaner, no worries at all :)
[15:20] <dimitern> mattyw, hey
[15:21] <jrwren> beisner: you get anywhere looking for 1.22-beta4 tools?
[15:22] <jrwren> dimitern: I can't repro this subordinate allwatcher issue with juju 1.21.3 or 1.22-beta3. I do not have a good way to test any other versions.
[15:23] <dimitern> jrwren, ok, thanks for the update - will you comment on the bug as well please?
[15:23] <jrwren> dimitern: yes.
[15:23] <beisner> jrwren, mgz - fyi debugging sstreams on serverstack.   it seems juju is trying to query a "index2.sjson" which is the current mystery.  http://paste.ubuntu.com/10449788/
[15:23] <dimitern> jrwren, cheers
[15:23] <beisner> as that initial query url doesn't match what is defined in keystone catalog (where we expect juju to first ask)
[15:24] <jrwren> beisner: ah, private cloud, a bit different than I'm trying. I just happened to get the same issue when I wanted to test something with 1.22-beta4
[15:25] <beisner> jrwren, it could be that our private stuff is all fine, and that that the beta4 tools really are awol, but i don't know how to confirm that.
[15:25] <ericsnow> sinzui: when will we have a milestone in lp for 1.24?
[15:27] <sinzui> ericsnow, I can create one now
[15:27] <ericsnow> sinzui: thanks!
[15:29] <sinzui> ericsnow, reload to see the milestone
[15:30] <ericsnow> sinzui: perfect!
[15:38] <ericsnow> cmars: could you give me a review on http://reviews.vapour.ws/r/1002/?
[15:39] <ericsnow> cmars: http://reviews.vapour.ws/r/983/ could you some extra eyes too if you can :)
[15:40] <ericsnow> frankban: ^^^ I suppose my plea applies to you too :)
[15:40] <cmars> ericsnow, will do, currently in standup
[15:40] <ericsnow> cmars: thanks!
[15:40] <frankban> ericsnow: I think I am missing some context
[15:41] <ericsnow> frankban: on the patches or on my request?
[15:42] <ericsnow> frankban: the patches will add systemd support to juju
[15:42] <frankban> ericsnow: on everything, I was offline I guess
[15:42] <ericsnow> frankban: the request is because you are OCR :)
[15:42] <ericsnow> frankban: ah
[15:43] <ericsnow> frankban: I was asking for a review of http://reviews.vapour.ws/r/1002/ and http://reviews.vapour.ws/r/983/
[15:43] <frankban> ericsnow: I am not aware of being a juju-core reviewer
[15:45] <ericsnow> frankban: oops, wrong Frank ;P
[15:45] <frankban> ericsnow: np ;-)
[15:45] <ericsnow> TheMue: ^^^
[15:46] <TheMue> ericsnow: lokking
[15:46] <ericsnow> TheMue: thanks!
[15:56] <sinzui> dimitern, the i386 test suite will be reported as a failure in the next hour. There are errors in logs, but the test didn't get all its retries because of aws didn't provide instances. I elected to let us start testing new revision then wait 2 more for 386
[15:58] <dimitern> sinzui, ok, my fix that disables flaky tests (and the new ppc64 build failure) has landed
[15:59] <TheMue> ericsnow: in #1002, do you have the same troubles with dependencies.tsv as me in the last change?
[15:59] <ericsnow> ericsnow: I didn't have any trouble updating it, if that's what you mean
[15:59] <ericsnow> TheMue: ^^^
[16:00] <ericsnow> TheMue: though reviewboard is having some kind of trouble
[16:00] <TheMue> ericsnow: take a look at the review board in the diff from 3 to 4
[16:02] <ericsnow> TheMue: you mean between 2 and 3?
[16:03] <TheMue> ericsnow: oh, there already, yes. I started from the end. ;)
[16:03] <ericsnow> The it's just showing up because I rebased :)
[16:03] <cmars> ericsnow, looking at 1002 now. weird error in reviewboard on the dependencies.tsv, is that due to a conflict?
[16:04] <sinzui> dimitern, your new revisions just started testing
[16:05] <dimitern> sinzui, great! I'll check the progress
[16:05] <ericsnow> cmars: the patch doesn't touch dependencies.tsv (it shows up due to a rebase)
[16:06] <ericsnow> cmars, TheMue: actually that's not true
[16:06] <ericsnow> I pulled in the latest testing repo
[16:07] <TheMue> ericsnow: #983 has a similar problem
[16:08] <ericsnow> TheMue: weird, I'll fix that
[16:08] <TheMue> ericsnow: thx
[16:08] <ericsnow> TheMue: (983 adds a dep on the go systemd bindings)
[16:09] <ericsnow> TheMue: glad you noticed that
[16:09] <TheMue> :)
[16:11] <cmars> ericsnow, there's also an error displaying service/common/common.go in 1002 (on page 2)
[16:12] <ericsnow> cmars: notice on the right of the file list that it says "deleted" :)
[16:13] <cmars> ericsnow, oh yeah, up at the top. ok
[16:13] <cmars> weird
[16:13] <ericsnow> cmars: reviewboard isn't super helpful on that
[16:17] <alexisb> voidspace, have you met your son yet?
[16:18] <voidspace> oops, wrong channel
[16:18] <voidspace> alexisb: not yet
[16:18] <voidspace> still waiting
[16:21]  * ericsnow was just wondering that too
[16:22] <beisner> mgz, jrwren -  interesting, even when i set     tools-metadata-url: https://streams.canonical.com/tools  i still get "failed to find 1.22-beta4 tools, will attempt to use 1.22-beta3"
[16:23] <jrwren> beisner: right. that is what I was using.
[16:24] <beisner> but local provider bootstrap builds and uploads tools ok of course
[16:24] <jrwren> beisner: hrm... really?!?!
[16:24] <mgz> beisner: you ahve the right devel setting in your envrionments.yaml yeah? (just checking the obvious)
[16:25] <beisner> yep just install devel on my home laptop.
[16:25] <beisner> mgz yep, on the private cloud enviro:  http://paste.ubuntu.com/10450285/    have tried with and without  tools-metadata-url: https://streams.canonical.com/tools
[16:28] <beisner> ahh but i can --upload-tools to beta4 ok on the private cloud
[16:32] <mgz> beisner: I can't see anything obviously wrong with the streams, did you pastebin a failing bootstrap with --debug set?
[16:35] <beisner> mgz, debug:  http://paste.ubuntu.com/10449788/
[16:35] <beisner> mgz, it seems juju is trying to query a "index2.sjson" which is the current mystery.   not sure where juju is getting that url.  keystone catalog doesn't show it afaict.
[16:36] <beisner> mgz, L33 is where we expect juju to ask.   http://paste.ubuntu.com/10449937/
[16:51] <perrito666> is any of you running a vmaas?
[16:53] <mbruzek> jog: I see the tests PASSed for kubernetes http://reports.vapour.ws/charm-tests-by-charm/kubernetes .
[16:53] <mbruzek> Thanks for your help jog.
[16:54] <mbruzek> jog, or abentley It looks like the HP tests passed as well, but they do not show up in the results.  http://juju-ci.vapour.ws:8080/job/charm-bundle-test-hp/49/console  Do either of you know why?
[16:54] <abentley> mbruzek: otp
[16:55] <mbruzek> abentley: ack.
[16:55] <mbruzek> I see the upload to s3 succeeded.  My understanding is if that step fails no report, so I am confused what is going on.
[16:56] <mbruzek> ping me when available
[16:58] <dimitern> perrito666, I am
[16:58] <perrito666> 2 things 1) requirements in terms of hardware? 2) have a script to create it? :p
[16:59] <katco> dimitern: hey just to let you know, i ran into a ton of issues with goamz's v4 signing support, and this is what's been taking a long time
[17:00] <katco> dimitern: i'm planning on working until it's complete, but i wanted to let you know.
[17:00] <dimitern> katco, ok, do you intend to land it today?
[17:00] <katco> dimitern: if i can, yes. it's my primary focus.
[17:00] <katco> dimitern: would you mind sending me an email or something regarding the changes we need to forward-port?
[17:01] <katco> dimitern: that way if you're not around i can start on that?
[17:02] <dimitern> perrito666, so I'm running vmaas on my laptop, so you'll need lots of RAM (1 GB preferred for the cluster controller kvm - the kvm 4  VMs  I have commissioned use 512 MB only), SSD is helpful as well,
[17:02] <dimitern> katco, ok, I'm making a note to do that
[17:03] <dimitern> perrito666, as for a script I don't think so - however dooferlad recently installed one and used some scripts to automate adding vms
[17:03] <katco> dimitern: ty
[17:04] <perrito666> dimitern: I have a laptop with 8G which I use only for that (i work in another)
[17:04] <dimitern> perrito666, it should work fine - if it's not using a really old CPU
[17:05] <perrito666> dimitern: mmm its an i5 2xxx I wonder what you call old
[17:05] <dooferlad> perrito666: that will be fine.
[17:05]  * perrito666 debates if he should not go buy a cheap desktop for this
[17:06] <ericsnow> TheMue, cmars: Thanks for the reviews.
[17:06] <dooferlad> perrito666: as long as you have virtualisation support, which that CPU does, you can use KVM and run a few VMs.
[17:07] <TheMue> ericsnow: yw, still have #1002 open while fighting with own troubles in parallel
[17:07] <ericsnow> TheMue: no worries
[17:07] <perrito666> dimitern: tx, In fact I do run a windows vm there for windows tests with kvm
[17:08] <dimitern> perrito666, that's fine - mine is actually a puny i3 M 350
[17:23] <ericsnow> TheMue, cmars: note that davecheney's ship-it on rb #983 was inadvertent
[17:23] <perrito666> oh spock died
[17:23] <TheMue> ericsnow: yep, seen his later comment
[17:23] <perrito666> :(
[17:24] <TheMue> perrito666: what? haven't seen. :'(
[17:24] <perrito666> TheMue: just  learned, very sad moment... I clearly am a nerd
[17:25] <TheMue> perrito666: he has been part of my youth *sigh*
[17:28]  * perrito666 announces a star trek marathon to his whife and gets an "are you insane?" look
[17:29] <TheMue> perrito666: hehe, you'll need some time for it, indeed
[17:42] <dooferlad> dimitern: my goodness, that took a lot of test prodding!
[17:43] <dimitern> dooferlad, what did?
[17:43] <dimitern> dooferlad, ah, yeah :/
[17:43] <dooferlad> dimitern: that change that you just updated the bug on
[17:43] <dimitern> dooferlad, I'm thinking of proposing a PR to skip TestAddRemoveSet and TestConfigEvents
[17:44] <dimitern> sinzui, what do you think? ^^
[17:47] <dooferlad> dimitern: I certainly would like to see the replicaset tests run faster. At least one of those fails was EC2 losing its Ubuntu archive mirror though, so updating the test script to retry the apt-get steps would help in that case
[17:47] <sinzui> dimitern, I know the first is unreliable and if You believe  it is not trusty worthy, then please skip it.
[17:49] <dimitern> dooferlad, actually juju should be doing the retry - we retry apt-get install but not apt-get update or upgrade
[17:49] <sinzui> dimitern, in general if the test cannot be trusted, it isn't worthy of failing the entire test suite. I don't think tests can print warning to the log though
[17:49] <mgz> dimitern: I would not mind TestAddRemoveSet dying
[17:50] <dimitern> dooferlad, sinzui even has failure cause for that
[17:50] <jog> mbruzek, I just got out of a meeting, I'll have a look at the charm reporting
[17:50] <mbruzek> jog thank you
[17:50] <dimitern> sinzui, mgz, I'm not saying we should forget about fixing them, but skipping them temporarily (under a high tech dept bug) will definitely speed up merges
[17:50] <mbruzek> jog I saw the hp one pass
[17:51] <dooferlad> dimitern: I am talking about this script, lines 140 - 143 http://bazaar.launchpad.net/~juju-qa/juju-ci-tools/trunk/view/head:/run-unit-tests
[17:51] <dooferlad> dimitern: that has no retry that I can see
[17:53] <sinzui> dooferlad, we can fix that in a few minutes
[17:53] <sinzui> and 141 too
[17:54] <sinzui> dooferlad, also note the call to $FIXUP_SOURCES which switch to true ubuntu archives which are much more reliable than cloud mirrors
[17:55] <sinzui> dooferlad, I think I can have the reties in place in 1 hours
[17:55] <dooferlad> sinzui: I can submit a patch if you want
[17:56] <sinzui> you sure can, just using OR "|" will suffice
[17:56] <dimitern> dooferlad, I know what you're talking about :) but in all fairness failing on apt-get update is a juju issue, not a CI job one
[18:00] <dooferlad> sinzui: http://juju-ci.vapour.ws:8080/job/github-merge-juju/2318/console isn't using archive.ubuntu.com. Looks like we don't use --force-archive, though looking at the sed command, it would break the job completely (I think).
[18:00] <sinzui> dooferlad, ah...
[18:00] <sinzui> dooferlad, I will fix now
[18:01] <ericsnow> alexisb: ping
[18:01] <dooferlad> dimitern: The failure I an talking about is pre-juju in the test. EC2 dropped a net connection while we were setting up the VM.
[18:01] <sinzui> dooferlad, retry
[18:02] <sinzui> dooferlad, mgz, I know that git-merge-juju once used --force-archive I think we dropped it by accident
[18:02] <dooferlad> sinzui: Oh, that change has landed now. It just took three attempts.
[18:02] <alexisb> ericsnow, omw
[18:02] <ericsnow> alexisb: k
[18:02] <dimitern> dooferlad, oh, good catch then, my bad :)
[18:04] <dooferlad> sinzui: don't enable --force-archive with "sudo sed s/ec2.archive.ubuntu.com/archive.ubuntu.com/ /etc/apt/sources.list -i" in the script. The EC2 mirror could be http://us-east-1.ec2.archive.ubuntu.com/ubuntu/, which would result in us-east.archive.ubuntu.com...
[18:04] <mgz> sinzui: I don't remember any reason not to have --force-archive
[18:04] <dooferlad> mgz ^^
[18:05] <mgz> we can fix the sed if we want the effect of always using archive.ubuntu.com
[18:05] <dooferlad> indeed. We just need to not just enable the flag :-)
[18:06] <sinzui> mgz, maybe we do want to do that. No cloud has proven to have mirrors as reliable as ubuntu
[18:07] <sinzui> dooferlad, retying the update and upgrade is also a good addition
[18:09] <dooferlad> I think sed s/http:\\/\\/.*.archive.ubuntu.com/http:\\/\\/archive.ubuntu.com/ /etc/apt/sources.list is what we want.
[18:09] <dooferlad> so many backslashes
[18:13] <dooferlad> In fact, more backslashes are probably good: sed s/http:\\/\\/\\.*.archive\\.ubuntu\\.com/http:\\/\\/archive.ubuntu.com/ /etc/apt/sources.list :-)
[18:15] <sinzui> dooferlad, sed can use commas as delimiters. s,bad,good,g
[18:15] <sinzui> I don't use / since I work with urls all the time
[18:15] <dooferlad> sinzui: ah, I tend to avoid sed completely myself. Good tip!
[18:16] <sinzui> dooferlad, yeah, and avoiding sed is a plus. mgz and I want to switch to python. we have something that runs the test, but not provision the instance
[18:17] <dooferlad> sinzui: sounds like a good plan
[18:17] <mgz> one of those jobs we'll get to at a sprint or something
[18:29] <perrito666> dooferlad: dimitern says you have some scripts to help automate vmaas?
[18:30] <dooferlad> perrito666: yep, just installing nodes. PM me your email address and i will forward the instructions
[19:19] <ericsnow> cmars: thanks for the reviews; I've addressed nearly all your comments
[19:26] <ericsnow> TheMue: you EOD?  regardless, thanks for the review :)
[20:10] <perrito666> dooferlad: did you have issues with the vnc display after installing maas?
[20:35] <dimitern> perrito666, what issues?
[20:36] <dimitern> natefinch, cmars, can I get a review on this please? http://reviews.vapour.ws/r/1031/ - this is the penultimate step towards landing container addressability
[20:36] <cmars> dimitern, taking a look
[20:37] <jw4> dimitern: do folks use the word penultimate in casual conversation where you live?
[20:38] <dimitern> jw4, no
[20:38] <dimitern> :)
[20:38] <jw4> :)
[20:38] <perrito666> dimitern: well vnc shows a black screen with a couple of white garbage dots at the top
[20:38] <dimitern> jw4, but I like it as it's shorter than "second to last" or something
[20:38] <perrito666> dimitern: I use ssh, but still
[20:38] <jw4> dimitern: +1
[20:39] <dimitern> perrito666, why vnc? can't you use the virt-manager's vm consoles?
[20:39] <dimitern> cmars, cheers
[20:39] <perrito666> dimitern: my virt manager uses vnc by default, I changed it to use another one next reboot
[20:40] <dimitern> perrito666, ha! mine uses vnc as well - now that I've actually checked :)
[20:40] <perrito666> dimitern: lol
[20:41] <dimitern> perrito666, is that the maas server vm or one of the maas vm nodes?
[20:42] <perrito666> the maas server vm
[20:42] <perrito666> still not have nodes :=
[20:42] <perrito666> :)
[20:42] <perrito666> aghh wrong kb distribution
[20:43] <dimitern> perrito666, right, so you've installed it - that's the first boot after?
[20:44] <perrito666> dimitern: yup
[20:48] <natefinch> man, I wish reviewboard would show me the changes in the area where a comment was resolved, so I can see *how* the comment was resolved.
[20:52] <ericsnow> cmars: you made some good points in your reviews (thanks!)
[20:55] <cmars> ericsnow, sure
[21:00] <natefinch> ericsnow: you have a ship it on GCE
[21:00] <ericsnow> natefinch: thanks!
[21:05]  * natefinch goes back to doing terrible things to the HA code
[21:31] <katco> ericsnow: wwitzel3: grats on all the hard work on GCE
[21:31] <ericsnow> katco: thanks!
[21:31] <natefinch> ^^ x100
[21:31] <ericsnow> katco: I'm happy with where it ended up
[21:31] <katco> that's awesome :)
[21:31] <ericsnow> katco: perhaps the largest patch I may ever land in my life :)
[21:32] <katco> ericsnow: lol
[21:32] <perrito666> natefinch: remember you hve to do terrible things to hr too :p
[21:32] <natefinch> ericsnow: oh, I don't know, you can do better ;)
[21:32] <ericsnow> natefinch: don't push me!
[21:47] <perrito666> dooferlad: wheneer you are around I found a couple of bugs :p but nothing big, your script is useful
[21:48] <dimitern> katco, ping
[21:49] <katco> dimitern: pong!
[21:50] <dimitern> katco, hey, before I go, have a look at this https://github.com/go-amz/amz/compare/v2...v3-unstable
[21:51] <katco> dimitern: all looks fairly mechanical
[21:51] <katco> dimitern: i didn't realize the putwithheaders was a forward-port. my pr has that as well, so that's good :)
[21:51] <dimitern> katco, so it turns out the changes are very few - s3/s3.go, s3/s3_test.go, ec2/ec2t_test (one sort.Strings added), README.md (you might leave this), and AUTHORS.md
[21:52] <katco> dimitern: yeah
[21:52] <dimitern> katco, yeah - that's all apart from the import paths and travis CI script config, eg.
[21:53] <dimitern> katco, for easy migration of the import paths check rogpeppe's govers tool - really cool
[21:53] <katco> dimitern: it's looking like i'll probably be able to propose this a little after my EoD (fingers crossed). will you be able to look at it any time this weekend (sorry)
[21:53] <dimitern> katco, ok, I'll have a look at some point, np
[21:53] <dimitern> katco, but I need to get going now
[21:53] <natefinch> ericsnow: looks like there's something missing for one of the tests for providerRegistrySuite.TestSupportedEnvironCommonProviders
[21:53] <dimitern> katco, I'm sure you'll take care of it nicely :)
[21:53] <katco> dimitern: ok, i'll be checking in. i'll try and land it into juju this weekend
[21:54] <katco> dimitern: i hope so, but gosh it could use another pair of eyes :)
[21:54] <dimitern> katco, sweet! no worries
[21:54] <katco> dimitern: ty for all of your hard work/overtime
[21:55] <dimitern> katco, np, we're all in the same boat after all :)
[21:55] <ericsnow> natefinch: (╯°□°)╯︵ ┻━┻
[21:55] <katco> dimitern: that we are! heave! ho! :p
[21:55] <dimitern> ;) happy weekends y'all
[21:55] <katco> dimitern: tc
[22:36] <marcoceppi> perrito666: you around, we're having fun with windows!
[23:04] <perrito666> marcoceppi: did I miss the fun?
[23:04] <jw4> perrito666 sounds hopeful
[23:08] <perrito666> marcoceppi: I am about to vanish unless you tell me not to
[23:09] <marcoceppi> perrito666: got like 5 mins to hangout?
[23:09] <lazyPower> perrito666: did you deploy the drupal6 charm during testing or just the nova-hyperv charm?
[23:09] <perrito666> sure, pass the url
[23:09] <lazyPower> oh, if you join the hangout - i'll hit you up there :D
[23:09] <marcoceppi> perrito666: see pm
[23:09] <lazyPower> lots of juju core questions and whats been tested questions
[23:12] <perrito666> marcoceppi: trying to get in
[23:14] <marcoceppi> perrito666: we'll sync with you on Monday, nothing vital for today anymore
[23:15] <perrito666> marcoceppi: Ill reboot the computer
[23:15] <perrito666> and get in, no trouble