[01:20] <thumper> axw, wallyworld_: I'm prepared to trade review for review... mine is trivial
[01:20] <wallyworld_> ok
[01:20] <thumper> axw: and I'm replying to the maas-allocated one
[01:20] <axw> thumper: okey dokey
[01:20] <thumper> enfixorating it took longer than expected
[01:37] <axw> thumper: sorry, couldn't remember if we were doing a bug or blueprint for the API stuff.. thanks for fixing
[01:49] <thumper> np
[01:50] <thumper> gives me something to do and feel important :)
[02:56] <axw> thumper: did you mean to repropose the maas MP?
[02:56] <axw> there's a bunch of unrelated stuff in there now
[02:56] <thumper> no...
[02:56] <thumper> yes I know
[02:56] <thumper> I'll fixit
[02:56] <axw> k
[02:56] <thumper> dammit
[03:10] <thumper> axw: I'm trying to work out wtf happened
[03:10] <thumper> I had branched from 1.16
[03:11] <thumper> ugh
[03:11] <thumper> I know
[03:11]  * thumper goes to uncommit several
[03:43] <axw> thumper: when you're not busy, can you please take a look at https://codereview.appspot.com/14775044/
[03:43] <axw> a fix for one of the manual provisioning bugs
[03:44] <thumper> bigjools: can I get you to cast a quick eye over https://code.launchpad.net/~thumper/juju-core/maas-allocated/+merge/191090
[03:44] <thumper> bigjools: just to make sure I'm not doing something dumb?
[03:44] <thumper> axw: ack
[03:48] <bigjools> thumper: out of interest,  why the change to name the returned values?
[03:48] <bigjools> line 38 on diff
[03:49] <thumper> I was assigning to them before
[03:49] <thumper> but refactoring took it out
[03:49] <thumper> again
[03:49] <thumper> sometimes it is easier to have the named params
[03:49] <thumper> than to have empty declarations in the code
[03:50] <thumper> they are effectively function local variables
[03:50] <bigjools> yeah
[03:52] <bigjools> sheesh, I don't remember enough Go already to see what this is doing without looking stuff up
[03:52] <bigjools> did my best to banish it from my mind
[03:52] <thumper> axw: var allSeries = [...]string{"precise", "quantal", "raring", "saucy"} <- why the dots in [...] ?
[03:52]  * axw reminds himself
[03:52] <thumper> bigjools: it was more just the filter I cared about
[03:52] <thumper> bigjools: the rest of it I understand
[03:53] <bigjools> filter is fine
[03:53] <axw> thumper: why I did that instead of a slice... *shrug*, it's a little less overhead
[03:53] <bigjools> thumper: having said that
[03:53] <axw> [...]{...} is syntax for an array literal with the size taken from the number of elements
[03:53] <bigjools> thumper: it would be better to have the filtering done in gomaasapi
[03:54] <bigjools> as an optional state param
[03:54] <thumper> bigjools: agreed, but I felt that it was more work, and I think gomaasapi should give juju-core higher level objects to work with
[03:54] <thumper> rather than thin wrappers on a ReST api
[03:55] <thumper> axw: I just wasn't familiar with the syntax
[03:57] <thumper> bigjools: why exactly do we filter out unallocated ones?
[03:57] <bigjools> lol
[03:57] <thumper> I'll update the comment if you give me the reason
[03:57] <bigjools> thumper: nodes can be owned by the same user but not necessarily in use by juju
[03:57] <bigjools> juju just assumes it owns the world
[03:58] <bigjools> this change is not actually strictly necessary after the other work we did
[03:58] <thumper> by not strictly necessary...
[03:58] <thumper> do you mean it isn't needed at all?
[03:58] <bigjools> well, no :)
[03:58] <thumper> if it isn't, then we could flag it
[03:58] <bigjools> the agent_name work marks nodes that juju allocated
[03:58] <thumper> although I wish I knew that before I spent a day trying to massage it into shape
[03:59] <bigjools> I didn't know you were working on it, sorry
[03:59]  * thumper sighs
[03:59] <thumper> I'll strip the filter, but commit the changes because it makes the code more "correct"
[03:59] <thumper> and tweaks the tests
[03:59] <bigjools> ok
[04:14] <axw> wallyworld_, thumper : bot sez "no space left on device"
[04:14] <axw> do either of yo uhave access?
[04:14] <wallyworld_> i do
[04:15] <wallyworld_> which device?
[04:15] <axw> wallyworld_: /tmp
[04:15] <wallyworld_> ok
[04:15] <axw> thanks
[04:16] <wallyworld_> axw: try now
[04:29] <axw> fixed, ta
[05:19] <axw> wallyworld_: do you have any thoughts on this thread, before I land my change? https://lists.ubuntu.com/archives/juju-dev/2013-October/001651.html
=== thumper is now known as thumper-afk
[05:20] <wallyworld_> axw: just a sec, otp
[05:27] <wallyworld_> axw: i'm in 2 minds - i can see the need to keep the current behaviour. but seems like there's enough support to land it. especially now there are validation tools so they can verify the image id they will be getting.
[05:28] <axw> wallyworld_: how do the validation tools help? you mean, people can just set the image id explicitly to prevent unexpected images from being provisioned?
[05:29] <axw> ah never mind, I get it
[05:29] <wallyworld_> one source of confusion in changing the behaviour is: people will set up metadata to use precise image 1234 (to override the stock abcd)
[05:30] <wallyworld_> and if we fall back to abcd cause they stuffed up, that's bad
[05:30] <axw> yep
[05:30] <axw> and validation tools can help prevent that
[05:30] <wallyworld_> yeah, if people use them :-)
[05:30] <axw> heh :)
[05:31] <wallyworld_> so i'm sorta -0 on it
[05:31] <axw> we can add an option on datasources to prevent fallback
[05:32] <wallyworld_> yes. let's land this first as is i guess and do more work later if it comes up as an issue
[05:32] <axw> ok, sounds like a plan
[05:32] <wallyworld_> i still get a bit nervous about doing it, but oh well
[05:33] <wallyworld_> so long as it's documented and in the release notes
[05:35] <axw> good point, I don't think there's a card for it.. will create one
[05:37] <wallyworld_> main issue is it's a change in behaviour. and i'm not sure how upstream is set up to handle such things; ideally we'd be consistent but if not, double the need for doco
[06:41] <wallyworld_> jam: https://codereview.appspot.com/20730043/
[07:35] <jam> morning all
[07:37] <axw> morning jam
=== tasdomas` is now known as tasdomas
[08:02] <rogpeppe> mornin' all
[08:04] <axw> morning rogpeppe
[08:04] <rogpeppe> axw: hiya
[10:06] <mgz> mornin' all
[10:08] <dimitern> mgz, morning
[10:17] <rogpeppe> mgz, dimitern: yo!
[10:17] <rogpeppe> jam: i just posted a review of this: https://codereview.appspot.com/21000044/
[10:18] <dimitern> rogpeppe, hiya
[10:21] <rogpeppe> fwereade_: ping
[10:32] <fwereade_> rogpeppe, pong, sorry
[10:33] <rogpeppe> fwereade_: just wanted to point you at the HA doc that nate and i put together on friday. i imagine you'll have some comments to make: https://docs.google.com/a/canonical.com/document/d/1hGa2PNz6JyGFc7FjA-gX2_UnXRUGAZbS8O9TiS51bl8/edit
[10:33] <fwereade_> rogpeppe, sweet, tyvm
[10:47] <jam> rogpeppe: fwereade_: standup?
[10:47] <jam> https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig
[10:47] <jam> natefinch: ^^
[11:17] <jam> mgz: https://plus.google.com/hangouts/_/72cpj1004s1il9ggm12bsqttpg
[11:30] <mattyw> fwereade_, you remember a few weeks ago I was working on the mp for adding the owner to the addservice function? It just occured to me I never submitted it for review, I'm just doing it now, I have a feeling there's still lots to be done on it, but thought I'd submit it as a way of getting it moving again
[11:32] <natefinch> jam: ahh crap, daylight savings time. Sorry.
[11:53] <fwereade_> mattyw, ah, great, thanks, about to lunch but I'll take a look this pm
[11:54] <jam> natefinch: I expected as much
[11:54] <jam> I knew it was extra early for you, and wasn't sure if you'd be there. We should sort something out for you
[11:54] <natefinch> jam: I expected better of myself :)
[11:55] <mattyw> fwereade_, thanks. no hurry - I have plenty to keep me busy  (as I'm sure you do as well)
=== gary_poster|away is now known as gary_poster
=== rogpeppe1 is now known as rogpeppe
[13:45] <rogpeppe1> natefinch: ping
[14:54] <abentley> marcoceppi: Is it considered bad style to do apt-get upgrade in a charm?
[14:56] <marcoceppi> abentley: not nessisarily
[14:57] <abentley> marcoceppi: It seems to me that upgrading all the packages on your system should be an admin decision, not one that your charms make.
[14:57] <marcoceppi> abentley: charms are extremely opinionated encapsulation
[14:58] <marcoceppi> abentley: if the author thinks that's the best course of action, then so be it
[15:00] <abentley> marcoceppi: So the situation is that wordpress does apt-get upgrade.  This attempts to install cgroups-lite.  But I am running the local provides, so installing cgroups-lite fails (I assume because nested lxcs aren't permitted).  So the charm can't install.
[15:00] <abentley> s/provides/provider.
[15:00] <marcoceppi> what in the chain of deps requires cgroups-lite?
[15:01] <abentley> marcoceppi: None.  It's part of the base install.
[15:01] <natefinch> rogpeppe1: hey, sorry, kids got up late today.  What's up?
[15:01] <marcoceppi> well, that seems like a bigger problem tbh
[15:02] <abentley> marcoceppi: What's the bigger problem?  That the Ubuntu base install has cgroups-lite in it?
[15:02] <marcoceppi> abentley: yeah, that cgroups-lite isn't installing properly on lxc
[15:03] <abentley> marcoceppi: Yes, that's certainly a bug.  I just wondered whether it's also a bug that wordpress is trying to upgrade cgroups-lite.
[15:03] <abentley> marcoceppi: It's clearly irrelevant.  I was able to remove it, and the charm installed fine after that.
[15:04] <marcoceppi> abentley: there's an argument to make that it shouldn't as package versions could become mismatched between units, but the same can happen for long running deployments and updates to the simplestream data for images
[15:06] <abentley> marcoceppi: right.
[15:10] <abentley> marcoceppi: I figure charms are cannot by themselves ensure packages are in sync, and if juju changes to be able to ensure packages are in sync, it probably won't be necessary to do it in the charm.
[15:22] <rogpeppe1> natefinch: we should have another chat about the HA stuff
[15:24] <natefinch> rogpeppe1: cool, whenever is good for you
[15:25] <rogpeppe1> natefinch: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig?authuser=1
=== teknico1 is now known as teknico
=== gary_poster is now known as gary_poster|away
=== gary_poster|away is now known as gary_poster
=== dstroppa_ is now known as dstroppa
[16:48] <rogpeppe1> fwereade_: ping
[18:21] <rogpeppe1> natefinch: i've added some notes to the end of the HA document with some thoughts about HA failover and liveness
[18:22] <natefinch> rogpeppe1: cool
[19:19] <natefinch> rogpeppe2: you around?
[19:27] <thumper-afk> morning
=== thumper-afk is now known as thumper
[19:27] <thumper> hi natefinch
[19:27] <abentley> thumper: morning.  Can we chat about local provider when you're free?
[19:28] <thumper> abentley: sure, I need to kick the kids out shortly
[19:28] <thumper> after that?
[19:28] <natefinch> thumper: hi
[19:28] <abentley> thumper: great.
[19:35] <natefinch> thumper: finally had daylight savings over here... nice to have an extra hour of overlap with you.  Makes my afternoons less lonely :)
[19:35] <thumper> :)
[19:35] <thumper> I noticed that too
[19:36] <thumper> now if we could just hire someone on the west coast too
[19:36] <natefinch> Last I saw we had an opening for someone that they specifically wanted to have near San Fransisco for some reason.
[19:38] <natefinch> niemeyer: you around?
[20:09] <thumper> abentley: did you want irc or hangout?
[20:09] <abentley> thumper: Let's hang out.
[20:10]  * thumper waits
[20:10] <abentley> thumper: https://plus.google.com/hangouts/_/72cpiquo8sjrmfhcnqpq31pdi0?authuser=1&hl=en
=== rogpeppe2 is now known as rogpeppe
[21:02] <thumper> abentley: that fixed the install problem
[21:02] <thumper> abentley: just testing something else
[21:02] <abentley> thumper: Cool.
[21:15] <thumper> natefinch: https://codereview.appspot.com/21740043
[21:15] <natefinch> thumper: looking
[21:20] <thumper> natefinch: I initially wanted to move in the direction of nested lxc support
[21:20] <thumper> but I couldn't get lxc-start to work with the apparmor profile
[21:20] <thumper> so I gave up and went with the simple solution
[21:24] <thumper> abentley: no sinzui today?
[21:25] <abentley> thumper: No, he's taking the day off.
[21:25] <thumper> hmm...
[21:25] <thumper> we may want to release 1.16.3
[21:25] <thumper> to fix the local provider
[21:26] <natefinch> thumper: yeah, just disabling nested LXC seems like the best idea.  I doubt it'll be a big problem
[21:33] <thumper> abentley: can you do your CI dance with the trunk branch again once I get the fix landed?
[21:34] <abentley> thumper: Sure, but I need to leave in ~30 minutes.
[21:34] <thumper> ack
[21:34] <thumper> it may have to wait then...
[21:40] <thumper> natefinch: and if you can, the same for 1.16 https://codereview.appspot.com/21420045
[21:41] <natefinch> thumper: done
[21:41] <thumper> ta
[21:45] <natefinch> thumper: welcome.  If you get a chance, I'd like to get the code I wrote for specifying EC2 instance types as constraints in... since the code is slowly bitrotting.   https://codereview.appspot.com/14523052/
[21:46] <thumper> I looked at it at the end of last week, but I couldn't remember what we decided about landing the instance type from our burlingame conversations
[21:46] <thumper> do you recall?
[21:49] <natefinch> thumper: we decided to land it.  I asked specifically at the time
[21:50] <thumper> ok, I vote for landing and cleaning up the mess :)
[21:50]  * thumper goes to do a proper review
[21:50] <natefinch> :)
[21:53] <thumper> natefinch: why type and not instance-type?
[21:54] <thumper> I guess it doesn't matter
[21:54] <thumper> just wondering
[21:55] <natefinch> thumper: I thought instance type was too specific to EC2, but if it's more common than that, that's fine
[21:55] <thumper> I think that type should be fine
[21:56] <thumper> abentley: trunk now has lxc fix
[21:56] <abentley> thumper: okay.
[21:57] <natefinch> thumper: once nice bonus that code gives is that you see the type of the machine in juju status, instead of having to try to infer it.  So you'll see like "hardware: arch=amd64 cpu-cores=1 cpu-power=100 mem=1740M root-disk=8192M type=m1.small"
[21:57] <abentley> thumper: build started at http://162.213.35.28/job/juju-core-ci/97/console
[21:57] <thumper> natefinch: yep, noticed that
[21:57] <thumper> abentley: ta
[21:58] <natefinch> thumper: actually tempted to put type first in the printout, since it sorta defines the rest of the line
[21:58] <thumper> natefinch: well, line is alphabetical no?
[21:58] <thumper> eye naturally tracks to the end
[21:59] <natefinch> thumper: I think it's in the order we define, which happens to be alphabetical
[21:59] <thumper> natefinch: what happens with the mongo doc
[21:59] <thumper> and output
[21:59] <thumper> for environments that exist already?
[22:00] <natefinch> thumper: it should just default to empty.  admittedly I haven't tried it
[22:00]  * thumper nods
[22:00] <thumper> noticed the bson serialization code
[22:00] <thumper> omitempty *should* be fine
[22:00] <natefinch> thumper: yeah
[22:01]  * natefinch also said *should* ;)
[22:01]  * natefinch covers his ass
[22:02] <natefinch> Cool.   I'll do an upgrade test in the morning to double check,  and then merge it in.
[22:03]  * natefinch has reached end of day.
[22:03] <thumper> natefinch: ack
[22:03] <natefinch> thumper: thanks for the review
[22:04] <abentley> thumper: It errored.  Sorry, I don't have time to look at whether it's the same error as before.
[22:08] <thumper> abentley: kk
[22:26] <bigjools> good moaning
[22:27] <thumper> o/
[23:04] <marcoceppi> Can someone in here help out in #juju with a botched upgrade from 1.14 -> 1.16.2j