davecheneythumper: ready for 1:1 ?01:46
thumperdavecheney: yeah, you early?01:49
davecheneynot in the chat yet01:49
davecheneyjust jumping in now01:50
davecheneythumper: https://docs.google.com/document/d/1EWnZX0NU5Ib0PYCfrr0Hz1TgsHOtuy2HYIN5SIuUQx0/edit01:56
wallyworldmenn0: i can't see where toBsonD is defined04:06
menn0wallyworld: it's in collection.go (it's also used for other things)04:06
menn0wallyworld: all multi-env related util funcs are about to get moved to their own file04:07
wallyworldah, my master branch must be out of date04:07
menn0i'm actually doing that right now04:07
menn0I think toBsonD laned on Friday night04:07
wallyworldmakes, sense, i'm on master from friday am04:07
anastasiamaci read it as "i'm master friday am" :D04:08
mupBug #1489896 changed: Juju cannot upgrade to 1.26-alpha1 <blocker> <ci> <regression> <upgrade-juju> <juju-core:Fix Released by gz> <https://launchpad.net/bugs/1489896>04:17
axwanastasiamac: mind if I take the card "Add status for filesystems" off you?05:05
axwanastasiamac: I want to do the rescheduling one, but it needs this first05:06
axwwallyworld: if I add status to filesystems, can that change go into 1.25? it'll need an upgrade step07:18
wallyworldaxw: depends on how we word the change. if it's done as a bug in status, we could i think07:19
wallyworldbut we could leave till 1.2607:19
wallyworldi don't think it's that urgent imho07:19
wallyworldwhat do you think?07:20
axwwallyworld: could leave it I think. there's no CLI for filesystems anyway07:20
anastasiamacaxw: so to answer ur question - no, I do not mind :D07:44
axwanastasiamac: that's good, because I did it already ;)07:44
anastasiamacaxw: in general, I think names on any card in this lane are indicative... just pick up next in priority :D07:44
anastasiamacaxw: \o/ ur amazing! tyvm :D07:45
mupBug #1490480 opened: juju apt proxy vs MaaS <juju-core:New> <https://launchpad.net/bugs/1490480>10:24
mupBug #1490552 opened: local hostname not in /etc/hosts <juju-core:New> <https://launchpad.net/bugs/1490552>13:03
natefinchericsnow: standup14:07
fwereadetasdomas, re RB251914:13
tasdomasfwereade, yes?14:13
fwereadetasdomas, I'm not completely convinced that either is right -- what's the thinking behind choosing that one?14:14
fwereadetasdomas, because we do have that verifyWaiting14:14
fwereadetasdomas, 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
fwereadetasdomas, and that is actually fine, I think14:15
tasdomasfwereade, you mean running the config-changed hook after uniter's restart?14:16
fwereadetasdomas, 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 twice14:16
fwereadetasdomas, yeah14:16
tasdomasfwereade, yeah - I think that's how it works currently14:16
tasdomasfwereade, there was an email from Ian last week where he asked me to hold off on implementing an explicit run-config-changed resolver for now14:17
tasdomasfwereade, and the way config version is handled right now (aiui it's a transient state variable), config-changed does get run after restart14:18
fwereadetasdomas, yeah14:19
fwereadetasdomas, shit it14:19
fwereadetasdomas, LGTM14:19
* fwereade sighs at himself14:19
tasdomasfwereade, that's how I look at the code I write - good to know I'm not alone ;-]14:20
mbruzekWho is working on the CentOS support in juju?14:36
jcastrothe cloudbase guys14:52
mupBug #1490603 opened: TestSubnets fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1490603>14:58
* perrito666 suddenly remembers he owes them a couple of reviews14:58
jcastroHi, I have questions about: https://bugs.launchpad.net/juju-core/+bug/148947714:59
mupBug #1489477: m4 instance types not supported on AWS <benchmarking> <ec2-provider> <feature> <juju-core:Triaged> <https://launchpad.net/bugs/1489477>14:59
jcastrowhen targetted to 1.26 does that mean we won't get this until January?14:59
alexisbjcastro, in a stable release yes15:00
alexisbwe are feature frozen for 1.25 already15:01
jcastrois there a way so we can make it so that getting new instance types is easier in older jujus?15:01
jcastrosupporting a new instance type 8 months after launch is going to be problematic.15:01
perrito666is that really a feature?15:02
natefinchjcastro, 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
jcastroyeah, and on top of that we have this: https://bugs.launchpad.net/juju-core/+bug/137351615:02
mupBug #1373516: Switch default instance type from m1.small to t2.small/m3.medium for EC2 provider <ec2-provider> <juju-core:Triaged> <juju-core 1.26:Triaged> <https://launchpad.net/bugs/1373516>15:02
bogdanteleagasomebody from CI around?15:02
katcojcastro: someone will be picking that up shortly15:03
natefinchjcastro: moonstone is going to be working on that one in the coming couple weeks15:03
jcastronatefinch: I agree with you 100%, also same with AMIs15:03
alexisbkatco, I just want to clarify that it is targeted for 1.26, correct?15:04
katcoalexisb: at this point, yes15:04
natefinchjcastro: 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
katcoalexisb: i think the only one we said we'd target for a 25.1 was http://pad.lv/148655315:04
jcastrohttps://bugs.launchpad.net/juju-core/+bug/1489484 is the bug I filed for that one natefinch15:05
mupBug #1489484: Juju should support passing an AMI to deploy <charmers> <ci> <ec2-provider> <feature> <juju-core:Triaged> <https://launchpad.net/bugs/1489484>15:05
natefinchalexisb, 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:05
natefinchwell, one fairly common problem15:06
jcastroyeah the problem with the default instance types is that m1.smalls are being phased out15:06
natefinchwhich we knew a year ago :/15:06
jcastroso if you deploy a bundle today with AWS and it's over a few nodes, it has a good chance of failing15:06
jcastroso 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
alexisbthis sounds like a regression of behavior due to lack of current support15:07
alexisbso we have a case for a 1.25 fix15:07
jcastroit's more like when amazon says deprecated they'll actually stop handing out those instances15:07
alexisbjcastro, it is my first day back after being out but we will discuss this in the release call today and get it prioritized appropriately15:07
jcastrodon't worry it gets worse15:07
katcoalexisb: wb btw :)15:08
jcastrowe'll have to fix it for every version we support15:08
alexisbwell we will need to make a more doable line for that, ie what is in updates on lts is the oldest we will support15:08
alexisbkatco, thank you and thank you all for holding the fort while I was away15:09
jcastrobut we should probably figure out a general workflow for "aws announced new instance types"15:09
natefinchjcastro: absolutely15:09
perrito666we could really use a declarative, external, list of those things15:10
jcastrothey call their older ones previous generations: https://aws.amazon.com/blogs/aws/ec2-update-previous-generation-instances/15:10
jcastroso I think as long as we try to stay off that list for any defaults we should be fine15:10
natefinchjcastro: 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
jcastrothat goes for bundles who declare instance types too, so it affects eco as well15:10
jcastronatefinch: we used to have `default-instance-id` in environments.yaml, no idea why it was removed15:11
natefinchjcastro: 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
jcastronatefinch: I wonder though, if we can ask AWS programatically for the support status of an instance type15:12
natefinchjcastro: metadata/environments/15:12
jcastroso juju can just W: unsupported instancetype foo, please use instancetype bar15:12
natefinchjcastro: 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 system15:15
=== akhavr1 is now known as akhavr
ericsnowfwereade: do you think there's room for a "run arbitrary commands" worker on the machine agent?  (juju-run would leverage this rather than SSH)15:46
fwereadeericsnow, quite possibly16:03
fwereadeericsnow, it has crossed my mind that the ability to provide an execution context is pretty much completely independent of the unit agent16:03
ericsnowfwereade: for vsphere and rackspace providers we are using an SSH connection manage a local firewall, but would use that instead16:03
fwereadeericsnow, and tasdomas et al have been busily extracting it from uniter so it's becoming more plausible16:04
ericsnowfwereade: plus, apparently it would help juju-run on windows16:04
ericsnowfwereade: k16:04
ericsnowbogdanteleaga: ^^^16:04
fwereadeericsnow, that firewall -- an implementation of the environ methods used by firewaller? or something entiirely different?16:05
ericsnowfwereade: we have to manually implement a firewall on the local machine (iptables) for the sake of the provider16:06
fwereadeericsnow, ! (in a good way)16:06
fwereadeericsnow, that's awesome, I think16:06
fwereadeericsnow, because the environ-based firewalling has many weak points16:07
ericsnowfwereade: it's a naive implementation of what I believe core is planning to do more completely as a later feature16:07
fwereadeericsnow, but I'm still not sure why we need to ssh into the machines?16:07
fwereadeericsnow, cool16:07
ericsnowfwereade: to run the iptables commands :)16:07
fwereadeericsnow, shouldn't that be a local worker doing that stuff?16:07
ericsnowfwereade: for the firewall stuff I expect that a worker would be a better approach, but for now we SSH16:07
bogdanteleagaericsnow, fwereade, I think the same reasoning goes for juju run then as well, it doesn't need to be an "run arbitrary commands" worker16:10
fwereadebogdanteleaga, 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 commands16:11
=== akhavr1 is now known as akhavr
marcoceppinatefinch jcastro aws doesn't like that, but we could make it a simple stream, couldn't we?16:30
marcoceppiinstance types supported/depricated and how they translate to generic  constraints16:30
marcoceppithen we can iterate it outside of a core release16:31
jcastromarcoceppi: yeah, having to update juju with this kind of metadata seems like not-the-right-way to do it16:32
jcastroespecially since we have to ping simplestreams for other stuff anyway16:32
mupBug #1490649 opened: TestSortingAndFilteringBeforeCachingRespectsPreferIPv6 <ci> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1490649>17:25
mupBug #1490649 changed: TestSortingAndFilteringBeforeCachingRespectsPreferIPv6 <ci> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1490649>17:31
=== jog__ is now known as jog
mupBug #1490649 opened: TestSortingAndFilteringBeforeCachingRespectsPreferIPv6 <ci> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1490649>17:43
mupBug #1490653 opened: TestMissingSocket <ci> <test-failure> <juju-core:Incomplete> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1490653>17:49
mupBug #1490656 opened: TestBlockAddRelation <ci> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1490656>17:49
natefinchkatco: 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:57
katconatefinch: or at least delay them until ps gets coded up17:58
natefinchkatco: yeah, that's what I meant. Cool.18:07
natefinchgah, launchpad....  There's a 1.26 series version of the bug that is assigned to a 1.25 milestone?   on bug 137351618:09
mupBug #1373516: Switch default instance type from m1.small to t2.small/m3.medium for EC2 provider <ec2-provider> <juju-core:Triaged> <juju-core 1.26:Triaged> <https://launchpad.net/bugs/1373516>18:09
natefinchkatco: I guess we decided that one should be in 1.25? ^18:10
mupBug #1490665 opened: maas provider: juju bootstrap tools download errors hard to debug <cloud-archive> <landscape> <juju-core:New> <https://launchpad.net/bugs/1490665>18:10
katconatefinch: i think we were going to talk about it in the release standup18:11
katconatefinch: but probably?18:11
natefinchkatco: kk18:11
natefinchgah, 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:06
perrito666natefinch: i dont follow19:11
katconatefinch: 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 manner19:12
natefinchperrito666: 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:12
natefinchkatco: 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
katconatefinch: eek... i am modifying that area of the code right now. hope we're not stomping on each other19:13
natefinchkatco: I might be reading the tests wrong though... they're kind of hard to read19:14
ericsnownatefinch: 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
natefinchericsnow: absolutely19:14
ericsnownatefinch: thanks19:15
katconatefinch: 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 else19:19
mupBug #1489142: cpu-power constraint conflicts with with instance-type when trying to launch a t2.medium <constraints> <juju-core:Triaged> <juju-core 1.24:In Progress by cox-katherine-e> <https://launchpad.net/bugs/1489142>19:19
natefinchkatco: 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:20
katconatefinch: ahhh19:21
katconatefinch: in that case, maybe the bug is invalid? when t1 is gone will it pick a correct instance?19:21
natefinchkatco: I'll try commenting out the existence of m1.small and see what happens... that may well work19:23
natefinchkatco: it's not invalid, because we'll always try and fail with an m1.small first19:24
natefinchkatco: 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
natefinchtested that and it works19:30
katconatefinch: that doesn't seem quite right... min. constraints are a truth19:31
katconatefinch: we shouldn't bend them to get the right answer19:31
natefinchkatco: 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:32
natefinchthis would just be tweaking it so that we also exclude m1.small19:33
katconatefinch: 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 instances19:33
natefinchkatco: 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:36
katconatefinch: can i ask you to set this one on the shelf a bit? after my code lands it may become much easier19:37
katconatefinch: 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 tweak19:38
=== jog_ is now known as jog
natefinchkatco: 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
natefinchkatco: 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:44
katconatefinch: i should have a patch up for review tomorrow19:45
natefinchkatco: cool.19:45
katcoericsnow: wwitzel3: it looks like we need to modify the wpm spec to conform to the decisions that have been made19:47
ericsnowkatco: k19:47
natefinchlike not calling it WPM anymore? ;)19:48
natefinchWM just doesn't have the same ring19:48
natefinch"The P is silent"19:49
natefinchericsnow: why do the components need a datadir now?20:32
ericsnownatefinch: for WPM we need to a place to store plugin data20:33
ericsnownatefinch: otherwise there are situations where the status worker won't work right20:33
natefinchericsnow: can you explain?  What plugin data are we storing?  And why not store whatever data we need in the database?20:36
ericsnownatefinch: we store all sorts of things locally already for other "components"20:37
ericsnownatefinch: for WPM we need to store the path to the executable (for the feature tests)20:37
natefinchericsnow: seems like a lot of code churn and added complexity just to support something only used for feature tests20:45
ericsnownatefinch: I'm open to suggestions on an alternative :)20:45
natefinchericsnow: 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:47
ericsnownatefinch: that doesn't resolve the problem though20:48
natefinchericsnow: I thought the problem was the plugin executable20:48
ericsnownatefinch: wait, you're suggesting re-writing the plugin?20:48
natefinchericsnow: 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:49
natefinchericsnow: assuming I'm at all understanding the problem correctly, which I may not be.20:50
ericsnownatefinch: we already have a plugin that we use during the feature tests20:50
ericsnownatefinch: it is not trivial to re-write that in Go in order to make it a lib20:50
natefinchericsnow: I may be misunderstanding the problem.  Why did we have to add the data directory, when it wasn '20:52
natefinchwasn't needed before?20:52
ericsnownatefinch: it *was* needed before :)20:52
natefinchericsnow: but it's new in your patch....20:52
ericsnownatefinch: my patch fixes that particularly brokenness20:53
ericsnownatefinch: I'm going to pull that part of the patch out into a separate one so it's a bit more clear20:55
natefinchericsnow: cool20:56
natefinchericsnow: I'll look so more tonight.  Been looking at both the reviews you pointed me to earlier.20:59
=== natefinch is now known as natefinch-afk
ericsnownatefinch-afk: thanks20:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!