[02:17] <mup> Bug #1527020 opened: cannot build trusty ppc64el juju <ppc64el> <regression-update> <juju-core:Triaged> <gccgo-go (Ubuntu):New> <https://launchpad.net/bugs/1527020>
[02:46] <menn0> wallyworld: I know you're sprinting but any chance you could have a quick look at this one: http://reviews.vapour.ws/r/3404/
[03:02] <wallyworld> menn0: sure, looking
[03:03] <menn0> wallyworld: thank you
[03:03] <menn0> wallyworld: sorry to bug you at the sprint. there's not many ppl around today.
[03:04] <wallyworld> all good
[03:09] <wallyworld> menn0: lgtm, seems mechanical, justa question about what closes st now
[03:13] <menn0> wallyworld: it's closed by the caller
[03:13] <wallyworld> rightio
[03:13] <menn0> wallyworld: it probably should never have been closed there
[03:17] <menn0> wallyworld: just read the actual comment, rather than assuming I knew what you were talking about. that's a different thing. just replied.
[03:18] <menn0> wallyworld: thanks for the review
[03:18] <wallyworld> sure, np
[04:02]  * natefinch picks up the horse and gives it one more kick for good measure.
[04:03] <perrito666> natefinch: ??
[04:03] <natefinch> perrito666: see email
[04:04] <perrito666> uh, flamewar, nice
[04:04] <perrito666> btw, found the hat?
[04:04] <natefinch> no.. I'm going to call the hotel again tomorrow... but I think it's probably just gone.  boo.
[04:05] <perrito666> natefinch: I would say plane or train?
[04:06] <natefinch> perrito666: possibly plane, though I know I didn't wear it that day,  it might have been sitting in my coat pocket the whole time, only to fall out when I used the coat as a pillow on the plane.
[04:51] <perrito666> axw: wallyworld could any of you take a look at http://reviews.vapour.ws/r/3392/ ?
[04:55] <natefinch> dammit gofmt is sad
[04:58] <natefinch> stupidest reason for a CI build to fail :/
[05:00] <perrito666> natefinch: you are insensible man, why dont you care about gofmt feelings?
[05:01] <natefinch> the fix is deterministic.... the CI bot should just fix it for me.
[06:03] <wallyworld> urulama: final branch to enable add resources will land soon, maybe a couple of hours, still making a few changes before landing
[06:03] <urulama_> cool!
[06:21] <mup> Bug #1527068 opened: maas 1.8 static ips not released <ci> <destroy-environment> <maas-provider> <network> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1527068>
[06:27] <blahdeblah> Did someone say earlier that joyent was unhappy?
[07:17] <jam> blahdeblah: our internal cloud health checks seem to say that Joyent is Green (it had 1 red overnight)
[07:17] <jam> hmmm.... maybe I'm reading the chart wrong
[07:18] <jam> it looks like today is on the left, and time goes backwards to the right
[07:18] <jam> so Joyent has been on-and-off lately
[07:19] <jam> wwitzel3: katco: ericsnow: (natefinch) I have a question about the recent "create juju upload command" patch if anyone is around
[07:28] <blahdeblah> jam: Thanks; looks like it might be one particular instance; I've contacted support about it
[08:23] <frankban> wallyworld: hey, how is it going?
[08:24] <wallyworld> frankban: living the dream. finishing final branch to enable add-relation to work
[08:24] <wallyworld> will land soon
[08:24] <frankban> wallyworld: \o/
[08:24] <urulama> :D
[08:24] <wallyworld> final tests to fix, then :shipit:
[08:25] <frankban> great
[09:33] <dimitern> frobware, ping
[09:34] <dimitern> frobware, your 2 PRs look almost the same - did you mean to close the earlier one?
[09:54] <frobware> dimitern, nope
[09:55] <frobware> dimitern, I'll resubmit the second once the first has landed as it is dependent on the first and might need some agreement on where we put the file
[10:00] <dimitern> frobware, I see, ok
[10:39] <voidspace> dooferlad: dimitern: frobware: so now all unit tests pass, except one lxdclient test that also fails for me on upstream/master
[10:39] <voidspace> dooferlad: dimitern: frobware: I'll create a PR to land my branch on maas-spaces and then do fixes/tests as a new PR
[10:39] <voidspace> dooferlad: dimitern: frobware: ok?
[10:40] <frobware> voidspace, sounds good to me
[10:40] <voidspace> ok
[10:40] <dooferlad> voidspace: +1
[10:40] <frobware> voidspace, dooferlad, dimitern: http://reviews.vapour.ws/r/3398/
[10:40] <frobware> dimitern, if you could do some verification against your VLAN setup that would be great
[10:40] <dimitern> frobware, looking
[10:41] <dimitern> voidspace, sorry I missed your question earlier - that sgtm
[10:42] <voidspace> great
[10:48] <wallyworld> axw: i had to add an option to alias the offered service (on the todo list but needed now to support testing in a single env)
[10:49] <wallyworld> changes pushed
[10:49] <wallyworld> issue showed up in feature test
[10:49] <voidspace> dimitern: frobware: dooferlad: http://reviews.vapour.ws/r/3409/
[10:51] <axw> wallyworld: okey dokey, looking
[10:51] <dimitern> voidspace, looking in a bit
[10:51] <voidspace> dimitern: don't look too closely...
[10:53] <frobware> voidspace, looking
[10:57] <dimitern> voidspace, why did you need to embed *common.EnvironWatcher ?
[10:57] <voidspace> dimitern: to have access to the environ
[10:57] <voidspace> dimitern: we get it through the environwatcher
[10:57] <voidspace> dimitern: which means the api/apiserver need access to EnvironConfig api methods
[10:58] <dimitern> voidspace, from the client-side api proxy?
[10:58] <voidspace> dimitern: that's api/common
[10:58] <dimitern> voidspace, in the apiserver side you have *state.State, so you can call EnvironConfig
[10:58] <voidspace> dimitern: it's the api side of that interface
[10:58] <axw> wallyworld, reviewed
[10:58] <dimitern> voidspace, I don't think we need EnvironWatcher anymore
[10:59] <voidspace> dimitern: the environwatcher waits for the environ to be available and keeps it updated
[10:59] <voidspace> dimitern: it calls state.EnvironConfig
[10:59] <voidspace> dimitern: on the apiserver using EnvironWatcher exposes the api methods needed by the api side
[11:00] <dimitern> voidspace, I know what it used to do :) but the need to wait is long gone - there's always an environ config to read
[11:00] <voidspace> dimitern: so if we didn't use it I'd need to manually expose those methods
[11:00] <voidspace> dimitern: we want the provider in the worker, so we still need access to the EnvironConfig
[11:00] <voidspace> dimitern: so I can manually add that api method to the client and server if that's a better approach
[11:00] <voidspace> I'll add an XXX for that
[11:01] <dimitern> voidspace, I'd suggest the simpler approach like we used for the addresser
[11:01] <voidspace> dimitern: the addresser doesn't use the provider
[11:01] <dimitern> voidspace, ok to do it later - will add comments; basically if you expose SupportsDiscovery or something on the apiserver.DiscoverSpaces facade you don't need EnvironWatcher at all
[11:01] <voidspace> it delegates everything to the apiserver
[11:02] <voidspace> dimitern: we also need to list the spaces and subnets from the provider
[11:02] <voidspace> dimitern: in the discussion before we started this we said that the worker would have access to the provider and use the api for the state calls
[11:03] <voidspace> dimitern: so we can move provider access to the apiserver, it's just not the approach we decided at the start
[11:03] <dimitern> voidspace, yeah, ok
[11:03] <dimitern> voidspace, we'll iterate on that later
[11:07] <dimitern> voidspace, reviewed; on to frobware's now
[11:10] <voidspace> dimitern: thanks
[11:30] <axw> wallyworld, are you still going downstairs for hangout?
[11:30] <wallyworld> yep
[11:31] <axw> ok, will come down soonish
[11:33] <frobware> dimitern, dooferlad, voidspace, mpontillo: Chrome Version 47.0.2526.106 seems to work in MAAS today - I apt-get updated and got <- version and it behaves differently (correctly!) for the dropdowns.
[11:34] <voidspace> yay
[11:38] <frobware> voidspace, auto discovered space from your branch: http://pastebin.ubuntu.com/14072670/  whoop whoop! \o/
[11:41] <voidspace> frobware: great!
[11:58] <frobware> voidspace, the unit test failure you mentioned - is this it? http://pastebin.ubuntu.com/14072770/
[12:02] <voidspace> frobware: no
[12:02] <voidspace> frobware: mine isn't a panic
[12:02] <voidspace> frobware: it's in a lxdclient test, lxcbr0 not found
[12:02] <voidspace> hmm... I wonder if I even have lxc installed...
[12:03] <voidspace> I do
[12:03] <frobware> voidspace, my build was with go1.2. Just trying again with 1.4.2
[12:04] <voidspace> frobware: with 1.2 you won't get the lxd stuff anyway
[12:05] <frobware> voidspace, sure, but more concerned about the panic now
[12:07] <voidspace> frobware: right
[12:08] <voidspace> frobware: heh
[12:08] <voidspace> looking to see what test that is
[12:08] <voidspace> frobware: is that my branch?
[12:09] <voidspace> the panic is in imagmetadata, so I assume it's a test for that - I can't specifically see the test though
[12:09] <voidspace> make sure you have done a godeps invocation, sure you have but that *could* be the cause
[12:10] <frobware> voidspace, my rebuild-juju alias always does go deps
[12:10] <frobware> voidspace, same panic with 1.4.2
[12:10] <voidspace> frobware: which branch is this?
[12:11] <frobware> voidspace, maas-spaces-networking-api3
[12:11] <voidspace> frobware: weird
[12:11] <voidspace> frobware: and which test is it?
[12:11] <frobware> voidspace, yup
[12:12] <voidspace> nil pointer dereferences can usually be resolved
[12:38] <voidspace> dimitern: frobware: I've fixed the import order issues and added a TODO for getting rid of EnvironWatcher
[12:38] <voidspace> I'm going to hit $$merge$$
[12:39] <voidspace> frobware: we'll see if it panics for CI
[12:39] <voidspace> it doesn't panic for me
[12:39] <frobware> ack
[12:42] <dimitern> voidspace, cheers
[12:44] <frobware> voidspace, so maas-spaces passes for me
[12:45] <voidspace> frobware: ah, cool
[12:45] <voidspace> spurious then
[12:45] <frobware> voidspace, no... your branch does. :)
[12:45] <voidspace> frobware: oh, damn
[12:45] <voidspace> other way round...
[12:45] <voidspace> frobware: what test is it that panics?
[12:46] <frobware> voidspace, bah humbug
[12:46] <voidspace> (asking again as the first two times the question got lost... ;-)
[12:46] <frobware> voidspace http://pastebin.ubuntu.com/14073072/
[12:47] <frobware> voidspace, just checking again.
[12:47] <voidspace> frobware: that doesn't show the test
[12:47] <voidspace> I don't think
[12:47] <voidspace> there are no test files in that part of the panic
[12:47] <frobware> voidspace, I'm testing in .../cmd/jujud
[12:49] <voidspace> so one of the sub-packages there
[12:50] <voidspace> ah, I get a panic running it on its own
[12:50] <voidspace> I didn't in a full test run
[12:51] <voidspace> not sure yet if its the *same* panic
[12:51] <voidspace> in cmd/jujud/agent
[12:53] <voidspace> frobware: yep, looks the same
[12:53] <voidspace> I'm looking into it
[12:53] <frobware> voidspace, thanks. the test seems to take an entirety for me. just .../cmd/jujud/agent
[12:54] <frobware> voidspace, so you don't see that testing with `make check`/
[12:54] <voidspace> I don't do make check
[12:54] <voidspace> I do go test ./...
[12:59] <voidspace> frobware: looks like this is the test TestNewEnvironmentStartsNewWorkers in machine_test.go
[12:59] <voidspace> I'm on it anyway
[13:01] <frobware> voidspace, I see it with go test ./...  Weird.
[13:01] <frobware> voidspace, and make check
[13:01] <voidspace> frobware: the panic happens in a weird place, don't understand yet
[13:01] <voidspace> there is a discoverspaces worker, but the panic is opening the environ
[13:01] <voidspace> using the dummy environ
[13:02] <voidspace> ah, I have an idea.
[13:02] <voidspace> frobware: I've changed the dummy provider to return false for SupportsSpaceDiscovery
[13:02] <voidspace> when I come to write worker tests I'll make that configurable
[13:03] <voidspace> but for the general case it should be false
[13:03] <voidspace> I bet that was the problem
[13:03] <voidspace> although it showed up in a weird place
[13:03] <voidspace> we'll see anyway - running the test now
[13:04] <voidspace> nope, still panics
[13:04] <voidspace> there's something not configured right
[13:04]  * frobware steps out for some lunch
[13:32] <jam> dimitern: frobware: ping
[13:46] <mgz> no dooferlad today?
[13:46] <frobware> jam: pong
[13:47] <frobware> mgz, was around earlier
[13:47] <jam> hi frobware, I'm chatting about networks with Mark, and he was hoping for some updates to where we're at
[13:47] <dooferlad> mgz: I am here...
[13:47] <jam> do you have 10 min to join us?
[13:47] <frobware> sure
[13:47] <jam> frobware: https://plus.google.com/hangouts/_/canonical.com/juju-core-spec
[13:48] <mgz> dooferlad: ah, you were quiet. did you need some changes to provider/maas to go with your gomaasapi changes?
[13:48] <mgz> I get some test failures if I bump the dep
[13:49] <dooferlad> mgz: yea, voidspace made some changes to that bit of code.
[13:49] <dooferlad> mgz: I didn't intentionally break anything though.
[13:50] <mgz> can I cherrypick that to master? 's on maas-spaces I guess?
[13:51] <dooferlad> I guess so. I am not particularly familiar with what needs to come across.
[13:51]  * dooferlad will be back in 5
[13:53] <wallyworld> urulama: frankban_ : sorry about delay. code landed. this should work: juju deploy wordpress && juju deploy mysql && juju offer mysql local:/u/me/hosted-mysql && juju add-relation wordpress local:/u/me/hosted-mysql
[13:53] <wallyworld> not fully tested live
[13:54] <urulama> wallyworld: cool
[13:54] <frankban_> wallyworld: I'll test it now, thanks!
[13:54] <wallyworld> frankban_: i might be asleep, but ping back if there's an issue. should be easy to resolve anything
[13:55] <frankban_> wallyworld: sure, go relax and good night
[13:55] <wallyworld> frankban_: local url optional but needed in this case due to single environment. the service name in url needs to be different to locallly deployed mysql service name
[13:55] <wallyworld> so there's no name clash
[13:56] <frankban_> ack
[13:57] <wallyworld> will work on proper multi-env support for initial deploy maybe tomorrow
[14:01] <dooferlad> dimitern: I need some help with testing this uniter stuff when you have a moment.
[14:23] <mup> Bug # changed: 1524906, 1524914, 1524915, 1524958, 1526003
[14:26] <mup> Bug # opened: 1524906, 1524914, 1524915, 1524958, 1526003
[14:32] <mup> Bug # changed: 1524906, 1524914, 1524915, 1524958, 1526003
[14:35] <mup> Bug # opened: 1524906, 1524914, 1524915, 1524958, 1526003
[14:38] <mup> Bug # changed: 1524906, 1524914, 1524915, 1524958, 1526003
[14:39] <dimitern> dooferlad, hey, sorry got distracted with testing - sure, HO?
[14:39] <dooferlad> yep
[14:40] <dimitern> dooferlad, I'll join the standup one in 2m
[14:40] <dooferlad> dimitern: sounds good
[14:42] <dimitern> dooferlad, i'm in
[15:04] <natefinch> ericsnow, wwitzel3: did I miss the shortest standup ever?
[15:15] <frobware> dimitern, did you find any issues with the bridge script?
[15:34] <frobware> voidspace, did you find out what the issues was?
[15:42] <ericsnow> natefinch: moonstone
[15:42] <voidspace> frobware: not yet, more logging
[15:42] <voidspace> frobware: seems like an impossible bug (uninitialised member of Config struct)
[15:43] <voidspace> :qa
[15:43] <voidspace> damn, wrong window
[15:51] <voidspace> frobware: found it
[15:51] <voidspace> frobware: that test uses an environment that needs to explicitly setup singular workers
[15:52] <voidspace> so I needed to add the discoverspaces worker to a list of workers to start
[15:52] <voidspace> frobware: pushing now
[15:52] <frobware> voidspace, great. but there's a queue forming. :)
[15:53] <voidspace> hah
[15:56] <mgz> review please, blue team: http://reviews.vapour.ws/r/3413
[16:04] <cherylj> Could I also get a review?  http://reviews.vapour.ws/r/3399/
[16:04] <cherylj> small change, will enable us to actually test controller-rename :)
[16:06] <mgz> cherylj: swapsies
[16:07] <cherylj> mgz :)  Is there a reason you added in the "SetVersionJSON" calls in environ_whitebox_test.go?
[16:08] <voidspace> cherylj: I think I added those
[16:08] <voidspace> cherylj: the new default in gomaasapi included stuff we didn't want on by default
[16:08] <mgz> cherylj: see the second commit message, the tests assume a lack of devices support in the maas test server
[16:09] <mgz> and the latest rev of gomaasapi which gets pulled in with this move adds that capability flag
[16:10] <voidspace> mgz: ah, you're cherrypicking my changes
[16:10] <mgz> voidspace: I actually reinvented, there wasn't a clear commit to pick
[16:17] <cherylj> mgz, does the commit in dependencies.tsv need to be the commit of the merge?
[16:18] <cherylj> ex:  f342599c61c3303e707660701430297f229cdf6c, rather than what you have?
[16:18] <cherylj> (I've always done it that way and I don't know if it makes a difference)
[16:19] <mgz> cherylj: technically no, but it should be, I'll change that
[16:23] <frobware> voidspace, dooferlad, dimitern: http://reviews.vapour.ws/r/3414/
[16:26] <BrunoR> I pushed a new charm to launchpad about an hour ago, it shows up in 'charm list' but juju deploy cs:~my-lp-user/trusty/<charm-name> yields only an 'cannot resolve charm url' error
[16:28] <voidspace> frobware: looking
[16:29] <natefinch> BrunoR: it can take a few hours for the charm to show up in the charm store.  This is a limitation of the current architecture, but one that we have fixes for already in the pipeline.
[16:29] <voidspace> natefinch: ping
[16:29] <natefinch> voidspace: yo
[16:30] <voidspace> natefinch: it seems to me (you may disagree) that several of your recent emails to juju-core would have been better on the public list
[16:30] <voidspace> natefinch: any reason to keep them private?
[16:30] <natefinch> voidspace: I was trying to keep them limited in audience to avoid bikeshedding, and because they dealt with coding standards that may not apply to other teams.
[16:31] <natefinch> voidspace: I almost sent the last one to juju-dev....
[16:31] <BrunoR> natefinch: ok, thanks
[16:31] <voidspace> natefinch: I couldn't see anything that needed to be private, and I think "public by default" is a better policy
[16:32] <natefinch> voidspace: I wasn't trying to be private, I was trying to avoid starting a flamewar with people who aren't actually on the team
[16:32] <voidspace> natefinch: heh :-)
[16:32] <voidspace> none of seemed particularly inflammatory
[16:32] <voidspace> natefinch: I worry that we'll drift into private by default
[16:33] <voidspace> natefinch: before we had that list I think you'd have been happy sending them to juju-dev, which is probably a good test
[16:33] <natefinch> voidspace: happy is a strong word
[16:33] <voidspace> natefinch: you're a happy person :-)
[16:34] <natefinch> voidspace: as for not being inflammatory, I think you underestimate the average developers' capacity to argue about coding standards :)
[16:36] <voidspace> natefinch: juju-dev is hardly a hotbed for that, but I stand to be proven wrong...
[16:36] <voidspace> I'm sure I will be
[16:39] <voidspace> frobware: LGTM
[17:05] <voidspace> dooferlad: frobware: dimitern: my branch has landed
[17:05] <dooferlad> voidspace: Yay!
[17:05] <frobware> voidspace, thedac is going to try it later; will see if it discovers his lab. ;)
[17:05] <voidspace> dooferlad: so maas-spaces is now *officially* screwed with untested code and TODOs... \o/
[17:05] <voidspace> frobware: cool!
[17:06] <voidspace> frobware: there's lots of reasons why it might not work, but they should *all* be easy fixes
[17:06] <voidspace> should work though
[17:06] <voidspace> the happy path is pretty good
[17:06] <frobware> voidspace, I think it's important we plant a stick in the ground
[17:06] <dimitern> voidspace, awesome!
[17:06] <voidspace> frobware: cool
[17:07] <dimitern> voidspace, and more of that screwy stuff is coming
[17:07] <dimitern> :)
[17:08]  * dimitern steps out for ~30m
[17:09] <voidspace> dooferlad: are you off tomorrow? I don't recall
[17:09] <dooferlad> voidspace: yes
[17:09] <voidspace> dooferlad: enjoy your break!
[17:09] <voidspace> see you on the other side
[17:10] <dooferlad> voidspace: thanks! Have a great Christmas!
[17:13] <natefinch> ericsnow: btw, the juju upload PR did land
[17:13] <ericsnow> natefinch: sweet
[17:26] <mup> Bug #1522948 changed: ensure-availability on rackspace spawns endless machines <ci> <ensure-availability> <ha> <rackspace-provider> <juju-core:Fix Released> <https://launchpad.net/bugs/1522948>
[17:45] <dimitern> frobware, pig
[17:45] <dimitern> ping :) sorry
[17:47] <mgz> dimitern: how rude :P
[17:48] <dimitern> frobware, I'm testing your script - it appears to work, however I'm hitting the 15 character limit on the device name - instead of "juju-br-eth0.250" I get "juju-br-eth0.25"
[17:48] <dimitern> mgz, hey there
[17:48] <dimitern> mgz, you know moving gomaasapi now wasn't a great idea :P
[17:48] <dimitern> mgz, was it necessary for something else?
[17:53] <mgz> dimitern: I did mention this last week.
[17:53] <mgz> dimitern: I really don't mind where it lives, thought the long term cunning plan was to redo it entirely
[17:55] <dimitern> mgz, yeah, it's better on github, just doing it now introduced some churn with our maas-spaces feature and today I've seen import paths have changed (e.g. more merging to resolve)
[17:55] <frobware> dimitern, ooh. that could be really bad.
[17:56] <dimitern> frobware, yeah - the others worked though - no noticeable delay
[17:56] <frobware> dimitern, great. but if you had vlans 25 and 250 that would be bad, no?
[17:58] <frobware> dimitern, I can follow up with making the prefix 'br-'
[17:58] <dimitern> frobware, I guess a simple "juju-" vs "juju-br-" prefix will give us enough space up to "juju-eth0.4094"
[17:58] <dimitern> frobware, or even "br-" yeah
[17:59] <frobware> dimitern, we can annotate /e/n/i with a comment to say '# rendered by add-juju-bridge'
[17:59] <frobware> dimitern, maybe that could be our sentinel.
[18:00] <frobware> dimitern, if we didn't want to remove the script after it has run
[18:00] <dimitern> frobware, oh definitely
[18:00] <dimitern> frobware, I'd say "rendered by github.com/juju/juju/provider/maas/add-juju-bridge.py" ?
[18:01] <frobware> dimitern, so I have the run-once-only change up for review: http://reviews.vapour.ws/r/3414/
[18:01] <frobware> dimitern, I can work those changes in there now. It just depends on how critical this is vis-a-vis getting it laced through to the LXC configs
[18:01] <dimitern> frobware, or something like that; also I'll do a quick test now using "juju-" instead of "juju-br-" while reviewing your code
[18:03] <dimitern> frobware, also: scrolling up the console I can still see the full script being dumped
[18:03] <frobware> dimitern, that change hasn't landed. it is that review ^
[18:04] <frobware> dimitern, unless you've pulled that branch explicitly... ?
[18:04] <dimitern> frobware, nope, I saw that on maas-spaces tip
[18:04] <frobware> dimitern, maas-spaces doesn't have that change. i did it separately.
[18:05] <dimitern> frobware, I guess it's due to cloudcfg.AddScripts("set -xe", runcmd) we do in newCloudiintConfig
[18:05] <frobware> dimitern, you need this http://reviews.vapour.ws/r/3414/ in addition to the tip of maas-spaces
[18:06] <frobware> dimitern, that PR -- which hides the output -- is the review
[18:06] <dimitern> frobware, ok, I'll try "juju-" on 3414 then
[18:06] <frobware> dimitern, ack
[18:07] <frobware> dimitern, or 'br-'
[18:07] <frobware> dimitern, cut our losses as 'bond123' will probably blow it at some point. ;)
[18:07] <frobware> dimitern, or should that be bond007
[18:08] <dimitern> :)
[18:08] <dimitern> you can't have it all in 2 weeks hehe
[18:08] <mup> Bug #1527349 opened: Restoration of a backup will fail when moving to 2.0-alpha1 <juju-core:Triaged> <https://launchpad.net/bugs/1527349>
[18:11] <mup> Bug #1527349 changed: Restoration of a backup will fail when moving to 2.0-alpha1 <juju-core:Triaged> <https://launchpad.net/bugs/1527349>
[18:24] <mup> Bug #1527349 opened: Restoration of a backup will fail when moving to 2.0-alpha1 <juju-core:Triaged> <https://launchpad.net/bugs/1527349>
[18:28] <dimitern> frobware, reviewed
[18:29] <frobware> dimitern, ty
[18:31] <frobware> dimitern, becoming complicated? It's gone from a couple of lines of sed to ... ?
[18:33] <dimitern> frobware, what's that?
[18:33] <frobware> dimitern, I was just chuckling at one of your comments
[18:33] <dimitern> frobware, ah, well - I mean there's now a makefile, etc.
[18:33] <frobware> dimitern, becoming its own monster.
[18:35] <dimitern> :)
[18:36] <dimitern> frobware, btw the test worked with "juju-" - http://paste.ubuntu.com/14076709/
[18:36] <frobware> dimitern, bridge-hydra is what I should have called it
[18:36] <dimitern> :D
[18:36] <frobware> dimitern, one thing I discovered this wee is 'ip -d' -- try it as 'ip -d link show up'
[18:37] <frobware> dimitern, shows you kind of dev. ie., tun, bridge, vlan, etc.
[18:37] <dimitern> frobware, interesting - a bit more readable even
[18:38] <frobware> dimitern, I hesitated at putting that in because I couldn't see the option in the man page and wasn't sure how well it worked across all series.
[18:39] <frobware> dimitern, presumably the script output went away from your node boostrap
[18:40] <dimitern> frobware, yeah it did
[18:40] <dimitern> frobware, however, I've just realized spaces weren't discovered
[18:40] <frobware> dimitern, :(
[18:41] <dimitern> frobware, it your branch before voidspace's change have landed?
[18:42] <frobware> dimitern, discovery is at the tip of maas-spaces
[18:45] <dimitern> frobware, yeah, I'm trying to figure out why
[18:46] <frobware> dimitern, you mentioned something earlier today about 'disable... :true' because of vlans / bridge?  Am I recalling this correctly?
[18:46] <dimitern> frobware, git log shows your maas-spaces is behind the main repo
[18:48] <frobware> dimitern, my github branch - not in use
[18:49] <frobware> dimitern, I need to clean up.
[18:49] <frobware> dimitern, though I left that there because of the rebase troubles.
[18:54] <dimitern> frobware, well, please double check if you need a fresh fetch from upstream maas-spaces tip and rebase
[18:56] <dimitern> frobware, as the parent of the tip of your branch's commit is the one before voidspace's last one
[19:06] <frobware> dimitern, ah, yes. for that branch I know because I pushed it last night.
[19:07] <dimitern> frobware, ok :) I got worried for a moment
[19:07] <frobware> dimitern, the branch you're talking about is "maas-spaces-add-bridge-script-using-AddBootTextFile" not in fact "maas-spaces", correct?
[19:15] <dimitern> frobware, yeah
[19:15] <frobware> dimitern, you had me worried
[19:24] <mgz> okay, it's third-beer-o'clock, which is a very good time to leave irc
[19:37] <voidspace> g'night all
[20:02] <dooferlad> dimitern, frobware: Firstly, go to bed. Secondly, http://reviews.vapour.ws/r/3415/ is the NetworkConfig API call for your review.
[20:03] <natefinch> dooferlad: so.... you're telling them to go to bed, but then asking them to review your code? :)
[20:03] <dooferlad> natefinch: just trying to encourage a healty attitude to it being the evening while blowing my own trumpet.
[20:03] <natefinch> dooferlad: haha, fair enough
[20:06] <dimitern> dooferlad, great, thanks!
[20:06] <frobware> dooferlad, Can't. I'm in bed. :-p
[20:28] <natefinch> ericsnow: reviewing your resources in state patch
[20:28] <ericsnow> natefinch: thanks
[20:51] <mup> Bug #1525531 changed: precise upgrades fail in 1.25 and master <ci> <manual-provider> <precise> <regression> <upgrade-juju> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1525531>
[20:55] <menn0> anyone able to take a look at this one? : http://reviews.vapour.ws/r/3410/
[20:55] <menn0> I need to land this in order to progress
[21:05] <dimitern> menn0, reviewed
[21:06] <menn0> dimitern: thank you!
[22:22] <alexisb> dimitern, I am beginning to think you dont sleep
[23:41] <ericsnow> axw: ping
[23:41] <axw> ericsnow, pong
[23:42] <ericsnow> axw: are there any examples of how to use PutForEnvironmentRequest (from the blobstore code)?
[23:42] <axw> ericsnow, not that I can think of. I think it was meant to be used by resources
[23:43] <axw> ericsnow, wallyworld ^^
[23:44] <wallyworld> ericsnow: it's not used yet. it is to allow the case where a user proves owenrship of a file and hence creates a reference to it without having to upload
[23:47] <ericsnow> wallyworld: I was hoping to use the ref-counting for resources (i.e. to de-dupe the stored blobs to save space)
[23:48] <ericsnow> wallyworld: the whole ownership thing is irrelevant to me
[23:49] <wallyworld> ericsnow: du-dupe happens automatically anyway
[23:50] <ericsnow> wallyworld: ah!  including the ref-counting semantics?
[23:50] <wallyworld> ericsnow: and it's not ownership as such
[23:51] <wallyworld> it's saying i want to upload this file, i have a checksum, so if there's already the same file uploaded, don't do it again
[23:51] <wallyworld> that doesn't have to be a uman
[23:51] <wallyworld> human
[23:51] <wallyworld> and yes, ref counting is done
[23:51] <wallyworld> from memory
[23:51] <wallyworld> it's been ages since i looked at the code
[23:52] <wallyworld> but it should all just work
[23:52] <wallyworld> ericsnow: are you guys using all the resource manager stuff i did when we started working on resources?
[23:53] <ericsnow> wallyworld: I don't think so
[23:53] <wallyworld> :-(
[23:53] <ericsnow> wallyworld: where is it?
[23:53] <wallyworld> i gave all that info across
[23:53] <wallyworld> in a feature branch
[23:53] <wallyworld> resources i think
[23:54] <wallyworld> i had http endpoints to upload and stream out resources from state
[23:54] <ericsnow> wallyworld: I was under the impression that the spec had changed so significantly that it made sense to start over
[23:54] <wallyworld> nope, not that bit
[23:54] <ericsnow> wallyworld: cool, we'll take a look
[23:54] <wallyworld> you still need to store and retrieve resources from state
[23:54] <ericsnow> wwitzel3: ^^^
[23:54] <ericsnow> wallyworld: that's what I'm working on right now
[23:55] <wallyworld> and the work i did provided the http endpoints for that, just like we use for charms and tools
[23:55] <wallyworld> and backups
[23:55] <wallyworld> so a lot of the core boilerplate for what you need
[23:55] <wallyworld> to get blobs into and out of state
[23:56] <wallyworld> it was all wip but i think close to functional, been a while
[23:56] <wallyworld> it could also be used for store
[23:58] <ericsnow> wallyworld: cool, I'm taking a look
[23:58] <wallyworld> ericsnow: ok, more than happy to talk / hangout if needed
[23:58] <wallyworld> hopefully what's there will save you guys a lot of work
[23:58] <ericsnow> wallyworld: I may take you up on that at some point soon
[23:59] <wallyworld> not all will be relvant now
[23:59] <ericsnow> wallyworld: the bulk of the work lies in patches against the charm store
[23:59] <ericsnow> (since the spec is much simpler now)
[23:59] <wallyworld> cool :-)