/srv/irclogs.ubuntu.com/2016/01/19/#juju-dev.txt

thumperbeautiful.... http://reports.vapour.ws/releases/3520/job/run-unit-tests-xenial-amd64/attempt/35300:42
thumperfatal error: concurrent map writes00:42
davecheneythat's awesome, that check caught something00:58
davecheneyi'm pretty sure that race is already tracked in a bug00:59
davecheneythumper: before the break we were talking about moving gomassapi to github01:07
davecheneyin fact i think at the time I was going to address the races in that package01:07
davecheneyand that prompted the move to gb01:07
davecheneyand that prompted the move to gh01:07
davecheneythumper i sent you an email about this on 1 dec last year01:07
davecheneyfollowing up it looks like martin made the switch https://github.com/juju/gomaasapi01:08
davecheneyi'll send a PR01:08
davecheneyand get stuck into those races01:08
davecheneyoh, and it looks like gomaasapi is being used01:09
davecheneythat happened on the 5th ?01:09
davecheneyok, time to fix that race01:10
thumperI did notice that martin did add it before christmas01:13
thumperdavecheney: did you add the concurrent map write fatal?01:14
blahdeblahAnyone see my Q from last night about getting list of all primaries on every instance of a subordinate?  Is here the right place to ask, or would I be better taking it to #juju?01:14
thumperblahdeblah: what is the rationale for this?01:15
blahdeblahI'm working on a subordinate to automatically publish unit public addresses in DNS with no additional code or user intervention.01:16
blahdeblah(And automatically drop units out of DNS if they fail status checks when update-status hook is called, but that's not really important here...)01:19
davecheneythumper: that was added to 1.601:20
davecheneyi'm surprised it made it into the versino in xenial01:20
davecheneymy guess is xenial is using some 1.6 beta01:21
thumperblahdeblah: sorry, can't help with that, but yes, either here or #juju01:21
blahdeblahAny suggestions about whether I'm on the right track or not (i.e. there isn't a way to query all primaries directly from a single subordinate unit)?01:22
davecheneythumper: https://github.com/juju/gomaasapi/pull/301:36
davecheneythis repo doesnt' appear to have gb or a bot01:36
thumper?01:36
davecheneygb ? i mean rb01:37
davecheneyactual change is here, https://github.com/juju/gomaasapi/pull/3/files#diff-cef8a1746ed33f0946c8dc5017058f15R59901:37
* thumper sees if it has a bot01:45
davecheneythumper: interesting01:46
davecheneythere is a bot, but no reviewboard01:46
davecheneycan't say I mind01:46
* thumper shrugs01:46
davecheneythumper: https://github.com/juju/juju/pull/414601:51
davecheneypasses stress.bash on my machine01:51
thumperdone01:52
davecheneyi'm sort of surprised that fix worked01:52
davecheneybut there is only one way in to the maas api01:53
davecheneyso sticking a lock right there did the job01:53
davecheneywhich is good01:53
davecheney'cos doing it propoerly was going to be days of work01:53
thumper:)01:54
cheryljCan I get a quick review?  http://reviews.vapour.ws/r/3562/02:01
cheryljdavecheney: did that PR fix one of the intermittent failures we're seeing on wily / xenial?02:06
davecheneycherylj: i cannot say for sure02:06
davecheneyif the failure wasn't related to maas02:06
davecheneythen probably not02:06
cheryljdavecheney: okay.  Please don't land anything else to master until we actually get a blessed revision and cut an alpha102:08
cheryljunless it fixes one of the failing tests :)02:08
davecheneycherylj: sorry, thumper approved it02:14
thumpercherylj: this fix was to fix the curse02:15
thumperon master02:15
davecheneyif it fails to merge I won't retry02:15
cheryljthumper, davecheney yeah, if it's to address a current test failure, that's fine02:20
cheryljthanks for doing that02:20
cheryljit wasn't clear that's what it was doing02:20
mwhudsonoh heh 1.6~beta2 is in xenial02:21
mwhudsonwho uploaded that?02:21
davecheney¯\_(ツ)_/¯02:22
mwhudsonoh xnox02:22
cheryljfatal error: concurrent map writes?  oh I see gomaasapi in the stack now.02:23
mwhudsonwhich means i should update golang-race-detector-runtime too i guess02:25
cheryljlooks like the other master failures were joyent issues02:26
davecheneyjoyent provider also has long standing races02:27
cheryljdavecheney: and we had to move to another (more crowded) region recently02:29
thumperhuh... who woulda thunk it03:01
thumpermarshalling (1<<64-1) as uint64 value becomes 0xffffffffffffffff, and unmarshalling works into uint6403:02
thumperbut other smaller values are 'int'03:02
* thumper goes to write a schema hole to push this through03:02
=== MerryChristmas is now known as benonsftware
=== benonsftware is now known as benonsoftware
thumperanyone? http://reviews.vapour.ws/r/3568/03:57
thumperdavecheney: ^^ ?04:00
davecheneythumper: responded04:03
thumperta04:03
davecheneyyou can tighten up the switch statement some04:03
davecheneyother than that, lgtm04:03
thumperdavecheney: I don't see it04:03
thumperah04:04
thumperGH04:04
thumperdavecheney: yeah, nicer on one line04:04
davecheneyand you move the case that used to fall through the switch into the switch body04:08
davecheneyi like methods than have a switch statement to end with a switch04:08
davecheneyyou know once you get into the switch, it can only hit one of the cases04:08
* thumper tries to beat the bot04:09
* thumper wonders if there is a bot on juju/schema04:10
davecheneythen you don't have to rememver, hmm, this switch case doesn't do anything ... oh, i have to keep reading the file04:10
davecheneyLovely04:11
thumperdid for both Uint and Time04:11
* thumper manually merges04:12
thumperdavecheney: before I manually merge, want to add a mark to GH?04:13
* thumper departs04:45
=== mwhudson is now known as Guest92985
=== Guest92985 is now known as mwhudson
mupBug #1460175 changed: apiserver_test authhttp_test SetUpTest.debugLogSuite failed <intermittent-failure> <ppc64el> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1460175>09:36
voidspacefrobware: you got an LGTM by the way09:46
frobwarevoidspace, much obliged.09:52
frobwaredooferlad, I will pick up the VLAN bugs/issues on 1.25.09:57
dooferladfrobware: thanks! I will get on with the demo page then.09:57
frobwaredooferlad, could you pick of the '@' for '=' first.09:58
dooferladfrobware: sure.09:58
frobwaredooferlad, we also need to help voidspace out with the merge of master into maas-spaces.09:58
dooferladfrobware: I gave him a +1. Guess we can discuss in the standup09:59
frobwaredooferlad, yep09:59
voidspaceomw10:00
voidspacefrobware: dooferlad: standup10:01
frobwarevoidspace, you tried merging into master. http://reviews.vapour.ws/r/3560/11:13
mupBug #1535678 opened: The MAAS bridge script only works for debian based interfaces(5) files. <maas-provider> <network> <juju-core:New> <https://launchpad.net/bugs/1535678>11:42
mupBug #1535678 changed: The MAAS bridge script only works for debian based interfaces(5) files. <maas-provider> <network> <juju-core:New> <https://launchpad.net/bugs/1535678>11:51
mupBug #1535678 opened: The MAAS bridge script only works for debian based interfaces(5) files. <maas-provider> <network> <juju-core:New> <https://launchpad.net/bugs/1535678>11:54
voidspacefrobware: hah12:18
voidspacefrobware: did I set up the branches the wrong way round12:18
frobwarevoidspace, I would say so12:18
voidspacefrobware: oops12:19
frobwarevoidspace, close...12:19
voidspacefrobware: will close and recreate PR12:19
frobwarevoidspace, dooferlad: http://reviews.vapour.ws/r/3570/ - thx12:27
voidspacefrobware: dooferlad: attempt two (onto the right branch!) http://reviews.vapour.ws/r/3571/12:30
dooferladvoidspace: if it is the same as before, but with the right branch target, it already has a +1 from me.12:34
voidspacedooferlad: it is12:34
voidspacefrobware: looking at yours12:34
dooferladvoidspace: +1 it is then12:35
voidspacedooferlad: thanks, I've hit $$merge$$ on it12:35
dooferladvoidspace, frobware: https://github.com/juju/juju/pull/414712:35
frobwaredooferlad, LGTM except for jam's comment.12:37
frobware(or observation)12:37
voidspacefrobware: add-juju-bridge.py:is_active, if an option is 'bond-master' then you return false12:38
voidspacefrobware: that's a separate, unrelated, change to the vlan bridging change - right?12:38
frobwarevoidspace, nope.12:39
voidspacefrobware: the big change is that in _bridge_vlan you no longer check active interfaces12:39
voidspacefrobware: ah, ok12:39
voidspacefrobware: what's bond-master?12:39
frobwarevoidspace, bond raw device now become special too12:39
voidspacefrobware: what's a bond raw device?12:40
frobwarevoidspace, it is to protect these stanzas of this form: http://pastebin.ubuntu.com/14574966/12:41
voidspacefrobware: ok, what are they?12:42
voidspacefrobware: why do we not bridge them?12:42
frobwarevoidspace, look at this example - http://pastebin.ubuntu.com/14574970/12:42
frobwarevoidspace, we have a bond but the bond has two vlans on (top of) it.12:42
voidspacefrobware: if it's manual wouldn't it be safe anyway?12:43
frobwarevoidspace, the correct bridging should be http://pastebin.ubuntu.com/14574972/12:43
frobwarevoidspace, no because bond0 becomes bridged. bond0 => br-bond0, so in those cases we shouldn't create bridged for eth0/eth1 (which are the bond raw devices).12:44
frobwarevoidspace, if we did eth0/1 in that example. you would get br-bond0 and br-eth0 (and br-eth1).12:45
voidspacefrobware: ok, thanks12:47
frobwarevoidspace, did I confuse things? does it make sense?12:48
frobwarevoidspace, it's too long since I did the actual change. :)12:48
voidspacefrobware: I'm just looking at the original code to see how we now treat that differently12:48
voidspacefrobware: as far as I can see, eth0 and eth1 in that example are manual, so they would both have been treated as inactive before anyway - even without checking for bond-master12:50
frobwarevoidspace, agreed.12:50
voidspacefrobware: that bond-master change (specifically) doesn't make any difference for the examples you showed12:51
voidspacethey would only change behaviour for  a bond-master that was dhcp / static12:51
voidspacefrobware: and that bond-master change isn't tested as far as I can see12:54
voidspacefrobware: other than that LGTM12:54
frobwarevoidspace, test is in the case that uses networkDHCPWithBondInitial12:55
frobwarevoidspace, ah, you mean if the bond0 config is static?12:56
voidspacefrobware: I mean a test case where is_active would have returned true before the change but returns false now12:57
voidspacefrobware: so yeah, a bond-master config that is either static or dhcp12:57
frobwarevoidspace, and we're talking for the raw eth0/eth1 device?12:58
voidspacefrobware: well, whatever sort of stanza that code is intended to be for12:58
voidspaceso yes I think12:58
voidspacebut a realistic example in the test would make the intent of the code clearer12:59
frobwarevoidspace, I'm now beginning to wonder if that's a case we can run into. a bond's raw devices should always be manual, therefore !active.12:59
voidspaceright12:59
voidspacethat was my half suspicion, if it's not a case we can ever hit then the code doesn't need to be there13:00
voidspacewith networking I don't mind it being there "just in case" though, but in which case there should be a test13:00
voidspacemaybe with a comment that it's not a likely case and this is defensive code13:01
frobwarevoidspace, you know what would be better here... if we moved the tests to python and then looked at the coverage.13:13
voidspacefrobware: heh, indeed13:21
=== benji is now known as Guest37973
mupBug #1465307 changed: 1.24.0: Lots of "agent is lost, sorry!" messages <landscape> <regression> <juju-core:Fix Released> <https://launchpad.net/bugs/1465307>14:09
jamespagemgz, blimey - so retries was intentional!14:17
mgzjamespage: yeah, though I'm not sure how well publicised it was, didn't get any responses on the list14:18
mupBug #1465307 opened: 1.24.0: Lots of "agent is lost, sorry!" messages <landscape> <regression> <juju-core:Incomplete> <https://launchpad.net/bugs/1465307>14:19
jamespagemgz, well is was -dev rather than straight up juju14:19
jamespagemgz, I responded in the bug and the ML - we should turn this off...14:19
mgzI thought I had responded at the time, but I guess I just poked bogdan about it on irc14:20
mupBug #1465307 changed: 1.24.0: Lots of "agent is lost, sorry!" messages <landscape> <regression> <juju-core:Incomplete> <https://launchpad.net/bugs/1465307>14:22
mupBug #1465307 opened: 1.24.0: Lots of "agent is lost, sorry!" messages <landscape> <regression> <juju-core:Incomplete> <https://launchpad.net/bugs/1465307>14:28
mupBug #1465307 changed: 1.24.0: Lots of "agent is lost, sorry!" messages <landscape> <regression> <juju-core:Fix Released> <https://launchpad.net/bugs/1465307>14:31
mupBug #1465307 opened: 1.24.0: Lots of "agent is lost, sorry!" messages <landscape> <regression> <juju-core:Fix Released> <https://launchpad.net/bugs/1465307>14:37
bogdanteleagajamespage: fwiw, from what I remember we had an attempt at making it opt-in, but then we decided it was a good idea to always do it15:21
bogdanteleagaI was waiting for somebody to get hit by it for a while :p15:22
bogdanteleagaI think the reasoning was that hooks are supposed to be idempotent anyway, so it wouldn't hurt to always do it15:23
jamespagebogdanteleaga, hook idempotency is important and a good feature, but if somethings failed, it breaks out of that assumption I think15:47
bogdanteleagajamespage, I think the assumption is they're still idempotent even if they fail (as in they will fail in the same way based on some condition)15:49
bogdanteleagahow does the opt-in thing sound?15:50
perrito666bogdanteleaga: opt-in?15:51
bogdanteleagaI was thinking about having a option in the charm to specify whether the author wants retries or not15:53
perrito666bogdanteleaga: that is a problem15:53
perrito666you see retrie is because of juju, not of the charm15:53
cheryljbogdanteleaga: we could also put it behind a config option15:53
bogdanteleagaperrito666: not sure I follow15:55
bogdanteleagacherylj, you're talking about environ config?15:55
cheryljbogdanteleaga: yeah.  like juju set-env auto-hook-retry=true15:55
perrito666bogdanteleaga: lets say the hook is update-status hook, and juju state server is for some reason not available, lets say upgrading, we dont want to have a charm in failed status just because state server happened to be upgrading15:55
bogdanteleagacherylj, yup, but why not make the granularity at charm level?15:57
bogdanteleagaperrito666, won't that happen regardless of retries?15:57
perrito666bogdanteleaga: if the hook is idempotent, that would not be a problem :p15:58
bogdanteleagaperrito666, aren't we working with the assumption that they are?15:59
katconatefinch: happy tuesday :)16:06
perrito666that looks extremely like the prelude to bad news :p16:07
perrito666I hate making changes in status16:08
natefinchkatco: happy tuesday16:09
katconatefinch: just wanted to check in and see if you needed anything for your card (or anything else)16:10
natefinchkatco: nope, think I'm good.  Card seems pretty straight forward.16:11
katconatefinch: ok, cool! also sent you a meeting invite for this afternoon. 15:15, and then we have the meeting at 15:3016:12
natefinchkatco: cool, I'll go read up for that, so I'm ready. what's the format, are we all going to talk to him at the same time?16:13
katconatefinch: we'll discuss @ 15:1516:14
natefinchkatco: ok16:14
voidspacefrobware: dooferlad: mega-monster-master-merge landed16:29
voidspacefrobware: dooferlad: do we have openstack meeting now?16:29
dooferladvoidspace: will ping you if anyone turns up16:30
voidspacedooferlad: ok16:32
voidspacehmm... so far changes on master to provider/maas/environs.go *are* on the merged maas-spaces16:43
voidspacethat's encouraging16:43
voidspaceok, so found the first "lost" changes17:06
katconatefinch: also, ericsnow needed a review on this: http://reviews.vapour.ws/r/3551/diff/#17:09
natefinchkatco: thanks for bringing that to my attention, I hadn't gone to look at reviewboard this morning17:10
perrito666downloading lxd images in a bar, the rest of the people using the wifi must be hating me17:29
perrito666a lot17:29
lazypowerperrito666 chaos_wolf.png17:36
lazypowerperrito666 http://i.imgur.com/p2jAdlk.jpg17:41
perrito666lazypower: actually I was drinking coffee and having lunch18:01
perrito666but given what they charged me, I presume the bw was more than paid :p18:01
lazypowerperrito666 thats fair. I feel that way about panera18:01
mupBug #1535838 opened: Juju won't let me use some instance types on AWS <juju-core:New> <https://launchpad.net/bugs/1535838>18:25
beisnercherylj, w/1.25.3 deb:  first bootstrap attempt failed (in a different way).  the machine's e/n/i looks good, and it is still reachable.  but `dpkg -l | grep juju` is empty.  error was:18:28
beisnerfailed to bootstrap environment: bootstrap instance started but did not change to Deployed state: instance "/MAAS/api/1.0/nodes/node-d4692494-8228-11e4-8078-d4bed9a84493/" is started but not deployed18:28
beisneri've got another bootstrap underway to see if i get the same.  logs, collected too.18:28
mupBug #1535838 changed: Juju won't let me use some instance types on AWS <juju-core:New> <https://launchpad.net/bugs/1535838>18:28
beisnerfrom the maas perspective, machine is "deployed" without error18:29
=== benji_ is now known as benji
mupBug #1535838 opened: Juju won't let me use some instance types on AWS <juju-core:New> <https://launchpad.net/bugs/1535838>18:37
mgzbeisner: did you use  --upload-tools?18:37
beisnermgz, indeed.  got a new run going now.18:38
cmarsnatefinch, question about windows workloads.. if I juju ssh to a windows workload, would I have access to powershell commands, or just cmd.exe ?18:41
cmarsbogdanteleaga, was going to ask you as well ^^, though it's probably past your eod18:42
bogdanteleagaI can do quick questions18:43
bogdanteleagayou can't ssh to a windows machine now18:43
bogdanteleagawe need winrm for that kind of functionality18:43
bogdanteleagaand it's not implemented yet18:43
bogdanteleagabest thing you can do is rdp into it, or winrm manually18:44
mgzsee bug 1426729 bug 142673018:46
mupBug #1426729: juju-run does not work on windows hosts <juju-agent> <run> <ssh> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1426729>18:46
mupBug #1426730: juju debug-hooks does not work on windows <charm> <juju-agent> <ssh> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1426730>18:46
beisnermgz, cherylj - 2nd and 3rd bootstraps a-ok.  now deploying some misc stuff to another unit and containers.  will holler back.18:49
cheryljthanks, beisner!18:49
beisneryw, cherylj !18:52
cmarsbogdanteleaga, mgz ok, thanks!18:56
natefinchericsnow: what's the point of the extra level of indirection of the serialization struct in this review? http://reviews.vapour.ws/r/3551/diff/#18:56
ericsnownatefinch: consistent serialization in the various places where we need to18:57
natefinchericsnow: This feels like it's mixing concerns.  The formatted stuff is getting mixed into the api<->non-api conversions...19:02
ericsnowkatco, natefinch: quick review please: https://github.com/juju/utils/pull/18819:04
ericsnownatefinch: how so?19:05
ericsnowkatco: with that utils patch + my current branch, resource-get is working! :)19:05
katcoericsnow: yes!19:05
* katco does a happy dance19:06
natefinchericsnow: awesome19:06
katcoericsnow: when i have more time, i'd love to hear what bugs you ran into19:06
ericsnowkatco: just read through the commit history of the branch :)19:06
katcoericsnow: good call19:06
natefinchericsnow: re: the serialized stuff: the logic to format a charmresource now lives outside the formatter, which is bad.  It should have all of that self-contained so that it's obvious that a change to that code changes the outputted text.  In addition, you've split the conversion into two steps, x -> String, string -> y, whereas before it was x -> y, making it clear that the conversion from x to y needs to be maintained (and making it easier to see19:10
natefinchwhere the data is coming from).19:10
natefinchericsnow: it feels like going too far with DRY. The conversions happen to be similar,  but they aren't required to be identical, and by merging it all into a single thing, you're tying things together too tightly.19:12
ericsnownatefinch: I don't see how anything is being tied to tightly to anything else19:13
ericsnownatefinch: across our implementation we have a consistent pattern of serialization19:14
ericsnownatefinch: I factored that out so that it is more maintainable19:14
natefinchericsnow: it was already maintainable, because they were confined to single functions that did exactly what we needed to maintain, convert X into Y.  Now everything is in two functions, convert X into serialized, convert serialized into Y.19:15
natefinchericsnow: and we don't even use the fingerprint field from serialized for the formatter, which is a red flag19:16
ericsnownatefinch: how is that a red flag?19:17
natefinchericsnow: it shows that the formats are only coincidentally the same.... and for example, that field is not the same.19:17
natefinchericsnow: and the code for IsPlaceholder is only used in the formatter, but the logic exists way far away in the serialized code19:19
natefinchericsnow: I could maybe be convinced of it being useful for api->resource/charmresource, but I really think it's inappropriate to put formatter logic anywhere but in the formatter.19:20
beisnercherylj, mgz - ok, some basic throw-it-at-the-wall success:  http://pastebin.ubuntu.com/14577040/  :-)    one odd thing, eth3 (unused) is getting some unexpected definitions in e/n/i.19:21
beisnerthough that is not impacting this particular deploy19:21
thumpermorning folks20:00
perrito666thumper: morning20:00
katconatefinch: moonstone20:01
cheryljfrobware, dooferlad, if you're still around, can you checkout beisner's comment above?20:03
cheryljsinzui: there are a couple other patches that we want in alpha1 that weren't tested in this blessed run.  Can we run master again?20:31
cheryljsinzui: it pulls in the MAAS fixes that we talked about in the standup20:32
sinzuicherylj: CI saw the commits and has already started a new test of master20:32
mupBug #1535891 opened: Feature request: Custom/user definable cloud-init user-data <juju-core:New> <https://launchpad.net/bugs/1535891>20:37
menn0perrito666: ping21:17
perrito666menn0: pong21:17
menn0perrito666: I'm looking at your XDG compatible PR21:17
menn0perrito666: what do you mean by "location for juju config files is not .config/juju or XDG_CONFIG_HOME/juju"21:17
perrito666menn0: lemme go check21:18
perrito666menn0: there, corrected, apologies21:19
menn0perrito666: it seems like the change is making it so the default juju home is indeed ~/.config/juju21:19
menn0perrito666: thanks21:19
perrito666menn0: it follows the xdg standard21:19
mupBug #1535891 changed: Feature request: Custom/user definable cloud-init user-data <juju-core:Opinion> <https://launchpad.net/bugs/1535891>21:19
menn0perrito666: yep I get it. The "not" was confusing :)21:20
perrito666it is either XDG_CONFIG_HOME/juju or ~/.config/juju depends if the first is defined, it usually isnt21:20
perrito666the standard dictates that the later is the default value21:20
perrito666extra context  -> http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html21:20
menn0perrito666: thanks. I'm up to speed with that but it's good to have the link to the spec.21:21
perrito666menn0: tx for reviewing that, it is a boring long change21:23
frobwarecherylj, I answered in the bug. make sense?21:23
cheryljfrobware: thanks for that update.  It is not clear to me whether or not you'd be comfortable releasing what we have.21:25
cheryljfrobware: should we wait for your additional testing?  or are we good to go?21:25
frobwarecherylj, I can try now, but I may curtail if it goes too long.21:26
cheryljfrobware: so then we should wait?  :)21:27
frobwarecherylj, I don't think we can get into the situation I envisage as we would always have at least one NIC up. If there are no NICs up (at all!) bootstrap is highly unlikely. :)21:27
cheryljfrobware: heh okay.  Let me know your results when you EOD and we'll make the call to ship it or not21:28
beisnerfrobware, cherylj - ++comment @ "that bug"21:43
frobwarebeisner, I'm struggling to understand why (in my own head) the additional nameserver entries become a problem?21:44
frobwarebeisner, the indentation is confusing on the dns- entries added by maas/curtin. They belong to an interface.21:45
beisnerfrobware, they *might* not.  it's just not consistent.  (why just eth3?  what happened to eth2 and eth1 if eth3 got that treatment?)  and it's new behavior from 1.25.0, 1.25.1 and 1.25.221:45
frobwarempontillo, ping - I have some questions regarding the rendering of /e/n/i from MAAS/curtin...21:46
beisnerso i'm just raising a flag that this could smell of some future trouble.21:46
frobwarebeisner, to me it appears that MAAS/curtin will always add a dns-nameserver entry to /e/n/i. The way that it does it makes it appear that they're top-level stanzas whereas they should be attached to the iface.21:47
frobwarebeisner, they _are_ attached to the iface. In your case 'auto eth3'.21:48
beisnerhttp://pastebin.ubuntu.com/14577099/21:48
beisnerfrobware, ^ exactly.   there is no longer a global dns-nameservers setting.  it's getting sucked into eth3's stanza.21:49
frobwarebeisner, I would agree that the association to eth3 is new, but then again that's because we were parsing it badly.21:49
beisnerwhereas without juju, there is a top-level definition of dns-nameservers.21:49
frobwarebeisner, I think the problem is that there's no notion of top-level dns-* stanzas.21:50
frobwarebeisner, if you read $(man interfaces) there's no mention of dns-*21:50
frobwarebeisner, if you read $(man resolvconf) there is the notion that an interface can have a dns-* option.21:51
frobwarebeisner, and, AFAICT, there are few mentions of nameservers in the ifupdown package. http://pastebin.ubuntu.com/14577985/21:53
mupBug #1535916 opened: juju upgrade-charm should recognize the force flag <adoption> <compatibility> <juju-core:New> <https://launchpad.net/bugs/1535916>21:56
beisnerfrobware, indeed.  everything i see also says dns-nameserver belongs inside the iface stanza.   so is it a bug that maas has been placing it at the top level all along?21:58
frobwarebeisner, I think the issue is that the indentation make it appear that dns-* options are top-level stanzas.21:59
beisnerfrobware, to be clear, top-level dns-nameserver does work in an e/n/i file, regardless of presence in the man pages.21:59
menn0perrito666: review done. I don't think it's quite there yet.21:59
beisnerfrobware, oh heck.   dns-search dellstack   gets dropped from top-level, AND it doesn't pull into eth0.   instead it's in eth3, which isn't even up.  i'm reasonably confident this is not desired.22:02
frobwarebeisner, does eth3 have an auto stanza?22:02
frobwarebeisner, if so, you can verify its UPness with: ip -d link22:03
beisnerfrobware, top is before juju, bottom is after juju.  http://pastebin.ubuntu.com/14577099/22:03
beisnerfrobware, eth2 and eth3 aren't even cabled up on these boxes.22:03
frobwarebeisner, can you cut+paste the output from that state using ip -d link22:04
beisnerfrobware, ip -d link:  http://pastebin.ubuntu.com/14578067/22:06
beisneri've got to depart, EOD, but can be back online in ~+4hrs.22:08
frobwarebeisner, cherylj: see discussion on #maas22:08
cheryljfrobware: I'm following :)22:09
frobwarecherylj, given the differing opinions, do we want to hold fire here? It seems we need to nail this down once and for all. :(22:13
cheryljbeisner: is it okay if we take another day or so to figure this all out?  are you guys working with something stable now?22:14
cheryljI think I missed him22:14
cheryljfrobware: we can pick this back up tomorrow.22:15
cheryljfrobware: but please do add an update to the bug with a current plan before you head off to bed22:15
perrito666menn0: tx a lot22:18
perrito666menn0: I agree a lot with your review, tx22:19
frobwarecherylj, what's interesting is that if `dns-*' is a top-level stanza this is pretty much how we were previously interpreting it.22:23
cheryljfrobware: so what's your thought now?  to ask maas / curtin to create juju-br0?22:26
frobwarecherylj, too much of a change right here, right now. but it's something to discuss for ongoing releases.22:27
cheryljfrobware: okay.  For 1.25.3, do you need to change what you have now?22:28
frobwarecherylj, no, don't believe so. but I just updated the bug. it's getting late for me to summarise what we have & do.22:30
=== axw_ is now known as axw
mupBug #1336473 changed: Support new t2 instance types on AWS <ec2-provider> <juju-core:Fix Released> <https://launchpad.net/bugs/1336473>23:26
mupBug #1336473 opened: Support new t2 instance types on AWS <ec2-provider> <juju-core:Fix Released> <https://launchpad.net/bugs/1336473>23:29
mupBug #1336473 changed: Support new t2 instance types on AWS <ec2-provider> <juju-core:Fix Released> <https://launchpad.net/bugs/1336473>23:32
mupBug #1336473 opened: Support new t2 instance types on AWS <ec2-provider> <juju-core:Fix Released> <https://launchpad.net/bugs/1336473>23:35
axwperrito666: FYI, your messages are coming up in the hangouts thingy in gmail/inbox23:40
perrito666axw: the writing in another chat was ajoke or I actually was on the wrong chat?23:40
axwperrito666: as opposed to the hangout video window23:40
axwperrito666: I guess because you're using your tablet or phone or whatever?23:40
perrito666mm that sucks23:40
perrito666axw: exactly, hangouts finds new ways of sucking23:40
anastasiamacperrito666: u typed messages?23:41
perrito666anastasiamac: I did23:41
anastasiamacperrito666: i did not see any ;(23:41
perrito666apparently there is no way to access the video chat from the mobile app23:44
mupBug #1336473 changed: Support new t2 instance types on AWS <ec2-provider> <juju-core:Fix Released> <https://launchpad.net/bugs/1336473>23:44
wallyworldaxw: anastasiamac: will be afk for a bit, electrician on way to my house23:50
anastasiamacwallyworld: \o/23:50
anastasiamacwallyworld: i've pm-ed u too23:51
axwwallyworld: see you later, minus arm and leg23:51
anastasiamac:D23:51
mpontillofrobware: sorry, I was out for an appt - back now. what's up?23:53

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