[01:46] thumper: ready for 1:1 ? [01:49] davecheney: yeah, you early? [01:49] not in the chat yet [01:50] just jumping in now [01:56] thumper: https://docs.google.com/document/d/1EWnZX0NU5Ib0PYCfrr0Hz1TgsHOtuy2HYIN5SIuUQx0/edit [04:06] menn0: i can't see where toBsonD is defined [04:06] wallyworld: it's in collection.go (it's also used for other things) [04:07] wallyworld: all multi-env related util funcs are about to get moved to their own file [04:07] ah, my master branch must be out of date [04:07] i'm actually doing that right now [04:07] I think toBsonD laned on Friday night [04:07] makes, sense, i'm on master from friday am [04:08] i read it as "i'm master friday am" :D [04:08] from* [04:17] Bug #1489896 changed: Juju cannot upgrade to 1.26-alpha1

[05:05] anastasiamac: mind if I take the card "Add status for filesystems" off you? [05:06] anastasiamac: I want to do the rescheduling one, but it needs this first [07:18] wallyworld: if I add status to filesystems, can that change go into 1.25? it'll need an upgrade step [07:19] axw: depends on how we word the change. if it's done as a bug in status, we could i think [07:19] but we could leave till 1.26 [07:19] i don't think it's that urgent imho [07:20] what do you think? [07:20] wallyworld: could leave it I think. there's no CLI for filesystems anyway [07:20] yep [07:44] axw: so to answer ur question - no, I do not mind :D [07:44] anastasiamac: that's good, because I did it already ;) [07:44] axw: in general, I think names on any card in this lane are indicative... just pick up next in priority :D [07:45] axw: \o/ ur amazing! tyvm :D [10:24] Bug #1490480 opened: juju apt proxy vs MaaS [13:03] Bug #1490552 opened: local hostname not in /etc/hosts [14:07] ericsnow: standup [14:13] tasdomas, re RB2519 [14:13] fwereade, yes? [14:14] tasdomas, I'm not completely convinced that either is right -- what's the thinking behind choosing that one? [14:14] tasdomas, because we do have that verifyWaiting [14:15] tasdomas, which *should* indeed queue a config-changed when we're back in a stable state -- once, that was the first thing we did in modeabide, now I presume that check is a bit below the upgrade check? [14:15] tasdomas, and that is actually fine, I think [14:16] fwereade, you mean running the config-changed hook after uniter's restart? [14:16] tasdomas, we *do* still get a config-changed guaranteed after bouncing, we just slip the upgrade in first so we don't have to do it twice [14:16] tasdomas, yeah [14:16] fwereade, yeah - I think that's how it works currently [14:17] fwereade, there was an email from Ian last week where he asked me to hold off on implementing an explicit run-config-changed resolver for now [14:18] fwereade, and the way config version is handled right now (aiui it's a transient state variable), config-changed does get run after restart [14:19] tasdomas, yeah [14:19] tasdomas, shit it [14:19] dammit [14:19] tasdomas, LGTM [14:19] * fwereade sighs at himself [14:20] fwereade, that's how I look at the code I write - good to know I'm not alone ;-] [14:36] biab [14:36] Who is working on the CentOS support in juju? [14:52] the cloudbase guys [14:58] Bug #1490603 opened: TestSubnets fails

[14:58] * perrito666 suddenly remembers he owes them a couple of reviews [14:59] Hi, I have questions about: https://bugs.launchpad.net/juju-core/+bug/1489477 [14:59] Bug #1489477: m4 instance types not supported on AWS

[14:59] when targetted to 1.26 does that mean we won't get this until January? [15:00] jcastro, in a stable release yes [15:00] ouch [15:01] we are feature frozen for 1.25 already [15:01] is there a way so we can make it so that getting new instance types is easier in older jujus? [15:01] supporting a new instance type 8 months after launch is going to be problematic. [15:02] is that really a feature? [15:02] jcastro, alexisb: my thought has always been that if someone types instancetype=foo ... we just pass foo to the provider, and not try to do our own validation on it. If it works, it works. If it doesn't, it doesn't. But don't artificially try to restrict what instance type we request for no reason. [15:02] yeah, and on top of that we have this: https://bugs.launchpad.net/juju-core/+bug/1373516 [15:02] Bug #1373516: Switch default instance type from m1.small to t2.small/m3.medium for EC2 provider

[15:02] somebody from CI around? [15:03] jcastro: someone will be picking that up shortly [15:03] jcastro: moonstone is going to be working on that one in the coming couple weeks [15:03] \o/ [15:03] natefinch: I agree with you 100%, also same with AMIs [15:04] katco, I just want to clarify that it is targeted for 1.26, correct? [15:04] alexisb: at this point, yes [15:04] jcastro: yeah, AMIs is a little different just because we don't currently support specifying them manually... but in general, yes, that would be nice, and probably not too hard. [15:04] alexisb: i think the only one we said we'd target for a 25.1 was http://pad.lv/1486553 [15:05] https://bugs.launchpad.net/juju-core/+bug/1489484 is the bug I filed for that one natefinch [15:05] Bug #1489484: Juju should support passing an AMI to deploy

[15:05] alexisb, katco: I think we should consider putting the default instance type one into 1.25 if possible. It should be a straightforward change, and is a cause of some fairly common problems. [15:06] well, one fairly common problem [15:06] yeah the problem with the default instance types is that m1.smalls are being phased out [15:06] which we knew a year ago :/ [15:06] so if you deploy a bundle today with AWS and it's over a few nodes, it has a good chance of failing [15:07] so you're like, oh no problem, I'll just use what AWS recommends, m3's and m4's, and why wouldn't I want to use m4's, they're cheap and fast. [15:07] this sounds like a regression of behavior due to lack of current support [15:07] so we have a case for a 1.25 fix [15:07] it's more like when amazon says deprecated they'll actually stop handing out those instances [15:07] jcastro, it is my first day back after being out but we will discuss this in the release call today and get it prioritized appropriately [15:07] nod [15:07] don't worry it gets worse [15:08] alexisb: wb btw :) [15:08] we'll have to fix it for every version we support [15:08] well we will need to make a more doable line for that, ie what is in updates on lts is the oldest we will support [15:09] katco, thank you and thank you all for holding the fort while I was away [15:09] but we should probably figure out a general workflow for "aws announced new instance types" [15:09] jcastro: absolutely [15:10] we could really use a declarative, external, list of those things [15:10] they call their older ones previous generations: https://aws.amazon.com/blogs/aws/ec2-update-previous-generation-instances/ [15:10] so I think as long as we try to stay off that list for any defaults we should be fine [15:10] jcastro: it would be nice if this kind of thing were configurable, so we could just update a configuration file at runtime and get new behavior. [15:10] that goes for bundles who declare instance types too, so it affects eco as well [15:11] natefinch: we used to have `default-instance-id` in environments.yaml, no idea why it was removed [15:12] jcastro: yeah, but I want something to configure juju's defaults outside of metadata.yaml, so users don't have to go google why their juju is broken and then go twiddle in the yaml by hand. [15:12] natefinch: I wonder though, if we can ask AWS programatically for the support status of an instance type [15:12] jcastro: metadata/environments/ [15:12] so juju can just W: unsupported instancetype foo, please use instancetype bar [15:15] jcastro: dunno... my guess is that they don't have that... they don't really like people being able to programmatically query the capabilities of their system [15:15] crazyness === akhavr1 is now known as akhavr [15:46] fwereade: do you think there's room for a "run arbitrary commands" worker on the machine agent? (juju-run would leverage this rather than SSH) [16:03] ericsnow, quite possibly [16:03] ericsnow, it has crossed my mind that the ability to provide an execution context is pretty much completely independent of the unit agent [16:03] fwereade: for vsphere and rackspace providers we are using an SSH connection manage a local firewall, but would use that instead [16:04] ericsnow, and tasdomas et al have been busily extracting it from uniter so it's becoming more plausible [16:04] fwereade: plus, apparently it would help juju-run on windows [16:04] fwereade: k [16:04] bogdanteleaga: ^^^ [16:05] ericsnow, that firewall -- an implementation of the environ methods used by firewaller? or something entiirely different? [16:06] fwereade: we have to manually implement a firewall on the local machine (iptables) for the sake of the provider [16:06] ericsnow, ! (in a good way) [16:06] ericsnow, that's awesome, I think [16:07] ericsnow, because the environ-based firewalling has many weak points [16:07] fwereade: it's a naive implementation of what I believe core is planning to do more completely as a later feature [16:07] ericsnow, but I'm still not sure why we need to ssh into the machines? [16:07] ericsnow, cool [16:07] fwereade: to run the iptables commands :) [16:07] ericsnow, shouldn't that be a local worker doing that stuff? [16:07] fwereade: for the firewall stuff I expect that a worker would be a better approach, but for now we SSH [16:08] :) [16:10] ericsnow, fwereade, I think the same reasoning goes for juju run then as well, it doesn't need to be an "run arbitrary commands" worker [16:11] bogdanteleaga, sure, I'm thinking of it as "having an internal Runner that can be used by some other workers" rather than just having a generic mechanism for injecting shell commands [16:11] brb === akhavr1 is now known as akhavr [16:30] natefinch jcastro aws doesn't like that, but we could make it a simple stream, couldn't we? [16:30] instance types supported/depricated and how they translate to generic constraints [16:31] then we can iterate it outside of a core release [16:32] marcoceppi: yeah, having to update juju with this kind of metadata seems like not-the-right-way to do it [16:32] especially since we have to ping simplestreams for other stuff anyway [17:25] Bug #1490649 opened: TestSortingAndFilteringBeforeCachingRespectsPreferIPv6

[17:31] Bug #1490649 changed: TestSortingAndFilteringBeforeCachingRespectsPreferIPv6

[17:33] SomeoneNeedsToFindOutHowToUseCommentsToDescribeAFunction === jog__ is now known as jog [17:43] Bug #1490649 opened: TestSortingAndFilteringBeforeCachingRespectsPreferIPv6

[17:49] Bug #1490653 opened: TestMissingSocket

[17:49] Bug #1490656 opened: TestBlockAddRelation

[17:57] katco: it occurs to me - if we're going to change workload status to be behind juju ps rather than juju status, maybe I should skip the feature tests for the work I did in juju status? [17:58] natefinch: or at least delay them until ps gets coded up [18:07] katco: yeah, that's what I meant. Cool. [18:09] gah, launchpad.... There's a 1.26 series version of the bug that is assigned to a 1.25 milestone? on bug 1373516 [18:09] Bug #1373516: Switch default instance type from m1.small to t2.small/m3.medium for EC2 provider

[18:10] katco: I guess we decided that one should be in 1.25? ^ [18:10] Bug #1490665 opened: maas provider: juju bootstrap tools download errors hard to debug

[18:11] natefinch: i think we were going to talk about it in the release standup [18:11] natefinch: but probably? [18:11] katco: kk [19:06] gah, how the **** are you supposed to know if the production code does the right thing if you mock out the data it bases its decision on? :/ [19:11] natefinch: i dont follow [19:12] natefinch: answer: different tests test different things. the test you're looking at most likely just tests that the function passes information on in the correct manner [19:12] perrito666: the code to choose which instance type to deploy is all kind of implicit in the values for the instance type's features... like CPU power etc. But when we test what gets deployed, we mock out that list. [19:13] katco: as far as I can tell, this is the only test that says "if you don't give FindInstanceType any constraints, what type does it return?" [19:13] natefinch: eek... i am modifying that area of the code right now. hope we're not stomping on each other [19:14] katco: I might be reading the tests wrong though... they're kind of hard to read [19:14] natefinch: when you get a chance could you follow up on a couple reviews: http://reviews.vapour.ws/r/2424/ and http://reviews.vapour.ws/r/2426/ [19:14] ericsnow: absolutely [19:15] natefinch: thanks [19:19] natefinch: fyi, i am fixing bug 1489142, so if you can try and focus on just finding where we declare the default and toggle that. i'll handle making sure specifying instance type overrides all else [19:19] Bug #1489142: cpu-power constraint conflicts with with instance-type when trying to launch a t2.medium

[19:20] katco: yep, that's what I'm trying to figure out. It looks like there's no actual default specified... it's just implicit in the default constraints that we set. We just set constraints that happen to work out so that we choose m1.small.... and there seems to be no test that actually tests that directly. [19:21] natefinch: ahhh [19:21] natefinch: in that case, maybe the bug is invalid? when t1 is gone will it pick a correct instance? [19:23] katco: I'll try commenting out the existence of m1.small and see what happens... that may well work [19:24] katco: it's not invalid, because we'll always try and fail with an m1.small first [19:30] katco: I can adjust the default minimum requirements to be more memory than the m1.small has, assuming m3.medium is what we want to pick by default (which is only 8.8 cents per hour instead of m1.small's 7 cents) [19:30] tested that and it works [19:31] natefinch: that doesn't seem quite right... min. constraints are a truth [19:31] natefinch: we shouldn't bend them to get the right answer [19:32] katco: this is just the default minimum constraints. It's how we're doing it right now. We set the minimum CPU power to exclude all the tiny instances that aren't generally useful (but you can get one if you explicitly set the CPU power lower) [19:33] this would just be tweaking it so that we also exclude m1.small [19:33] natefinch: if what we mean is "juju should have a default instance", we should probably codify that and not minimum constraints. if we really mean min. constraints, we should not change those but change the algorithm to not select invalid instances [19:36] katco: well... it's tricky. Right now there's only two ways to choose an instance type - set constraints, which can match anything, or pick an instance type explicitly. We don't have the idea of invalid instances. And m1.small is not exactly invalid... it's just a poor default because it's fairly often not available. [19:37] natefinch: can i ask you to set this one on the shelf a bit? after my code lands it may become much easier [19:38] natefinch: i'm sorry i didn't say that earlier. i had it in my mind that there was just a default somewhere we'd have to tweak === jog_ is now known as jog [19:44] katco: setting CPU Power to 300 instead of 100, and memory to 2048 happens to have the right outcome... however a more appropriate fix would be to mark all the 1st generation types as such, and exclude them by default unless you explicitly ask to include them. However, that's significantly more work. [19:44] katco: I'm happy to set it aside, but given that it's something we really should address for 1.25, let's not set it aside for too long. [19:45] natefinch: i should have a patch up for review tomorrow [19:45] katco: cool. [19:47] ericsnow: wwitzel3: it looks like we need to modify the wpm spec to conform to the decisions that have been made [19:47] katco: k [19:48] like not calling it WPM anymore? ;) [19:48] WM just doesn't have the same ring [19:49] "The P is silent" [20:32] ericsnow: why do the components need a datadir now? [20:33] natefinch: for WPM we need to a place to store plugin data [20:33] natefinch: otherwise there are situations where the status worker won't work right [20:36] ericsnow: can you explain? What plugin data are we storing? And why not store whatever data we need in the database? [20:37] natefinch: we store all sorts of things locally already for other "components" [20:37] natefinch: for WPM we need to store the path to the executable (for the feature tests) [20:45] ericsnow: seems like a lot of code churn and added complexity just to support something only used for feature tests [20:45] natefinch: I'm open to suggestions on an alternative :) [20:47] ericsnow: I think I'd just make it built in, and use an environment variable to enable it. At least that wouldn't require public API changes etc. [20:48] natefinch: that doesn't resolve the problem though [20:48] ericsnow: I thought the problem was the plugin executable [20:48] natefinch: wait, you're suggesting re-writing the plugin? [20:49] ericsnow: I'm suggesting not having an executable plugin and instead having it as a package like the docker package, except only enabled if there's an environment variable set. [20:50] ericsnow: assuming I'm at all understanding the problem correctly, which I may not be. [20:50] natefinch: we already have a plugin that we use during the feature tests [20:50] natefinch: it is not trivial to re-write that in Go in order to make it a lib [20:52] ericsnow: I may be misunderstanding the problem. Why did we have to add the data directory, when it wasn ' [20:52] wasn't needed before? [20:52] natefinch: it *was* needed before :) [20:52] ericsnow: but it's new in your patch.... [20:53] natefinch: my patch fixes that particularly brokenness [20:55] natefinch: I'm going to pull that part of the patch out into a separate one so it's a bit more clear [20:56] ericsnow: cool [20:59] ericsnow: I'll look so more tonight. Been looking at both the reviews you pointed me to earlier. === natefinch is now known as natefinch-afk [20:59] natefinch-afk: thanks