[00:42] <thumper> beautiful.... http://reports.vapour.ws/releases/3520/job/run-unit-tests-xenial-amd64/attempt/353
[00:42] <thumper> fatal error: concurrent map writes
[00:58] <davecheney> that's awesome, that check caught something
[00:59] <davecheney> i'm pretty sure that race is already tracked in a bug
[01:07] <davecheney> thumper: before the break we were talking about moving gomassapi to github
[01:07] <davecheney> in fact i think at the time I was going to address the races in that package
[01:07] <davecheney> and that prompted the move to gb
[01:07] <davecheney> and that prompted the move to gh
[01:07] <davecheney> thumper i sent you an email about this on 1 dec last year
[01:08] <davecheney> following up it looks like martin made the switch https://github.com/juju/gomaasapi
[01:08] <davecheney> i'll send a PR
[01:08] <davecheney> and get stuck into those races
[01:09] <davecheney> oh, and it looks like gomaasapi is being used
[01:09] <davecheney> that happened on the 5th ?
[01:10] <davecheney> ok, time to fix that race
[01:13] <thumper> I did notice that martin did add it before christmas
[01:14] <thumper> davecheney: did you add the concurrent map write fatal?
[01:14] <blahdeblah> Anyone 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:15] <thumper> blahdeblah: what is the rationale for this?
[01:16] <blahdeblah> I'm working on a subordinate to automatically publish unit public addresses in DNS with no additional code or user intervention.
[01:19] <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:20] <davecheney> thumper: that was added to 1.6
[01:20] <davecheney> i'm surprised it made it into the versino in xenial
[01:21] <davecheney> my guess is xenial is using some 1.6 beta
[01:21] <thumper> blahdeblah: sorry, can't help with that, but yes, either here or #juju
[01:22] <blahdeblah> Any 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:36] <davecheney> thumper: https://github.com/juju/gomaasapi/pull/3
[01:36] <davecheney> this repo doesnt' appear to have gb or a bot
[01:36] <thumper> ?
[01:37] <davecheney> gb ? i mean rb
[01:37] <davecheney> actual change is here, https://github.com/juju/gomaasapi/pull/3/files#diff-cef8a1746ed33f0946c8dc5017058f15R599
[01:45]  * thumper sees if it has a bot
[01:46] <davecheney> thumper: interesting
[01:46] <davecheney> there is a bot, but no reviewboard
[01:46] <davecheney> can't say I mind
[01:46]  * thumper shrugs
[01:51] <davecheney> thumper: https://github.com/juju/juju/pull/4146
[01:51] <davecheney> passes stress.bash on my machine
[01:52] <thumper> done
[01:52] <davecheney> i'm sort of surprised that fix worked
[01:53] <davecheney> but there is only one way in to the maas api
[01:53] <davecheney> so sticking a lock right there did the job
[01:53] <davecheney> which is good
[01:53] <davecheney> 'cos doing it propoerly was going to be days of work
[01:54] <thumper> :)
[02:01] <cherylj> Can I get a quick review?  http://reviews.vapour.ws/r/3562/
[02:06] <cherylj> davecheney: did that PR fix one of the intermittent failures we're seeing on wily / xenial?
[02:06] <davecheney> cherylj: i cannot say for sure
[02:06] <davecheney> if the failure wasn't related to maas
[02:06] <davecheney> then probably not
[02:08] <cherylj> davecheney: okay.  Please don't land anything else to master until we actually get a blessed revision and cut an alpha1
[02:08] <cherylj> unless it fixes one of the failing tests :)
[02:14] <davecheney> cherylj: sorry, thumper approved it
[02:15] <thumper> cherylj: this fix was to fix the curse
[02:15] <thumper> on master
[02:15] <davecheney> if it fails to merge I won't retry
[02:20] <cherylj> thumper, davecheney yeah, if it's to address a current test failure, that's fine
[02:20] <cherylj> thanks for doing that
[02:20] <cherylj> it wasn't clear that's what it was doing
[02:21] <mwhudson> oh heh 1.6~beta2 is in xenial
[02:21] <mwhudson> who uploaded that?
[02:22] <davecheney> ¯\_(ツ)_/¯
[02:22] <mwhudson> oh xnox
[02:23] <cherylj> fatal error: concurrent map writes?  oh I see gomaasapi in the stack now.
[02:25] <mwhudson> which means i should update golang-race-detector-runtime too i guess
[02:26] <cherylj> looks like the other master failures were joyent issues
[02:27] <davecheney> joyent provider also has long standing races
[02:29] <cherylj> davecheney: and we had to move to another (more crowded) region recently
[03:01] <thumper> huh... who woulda thunk it
[03:02] <thumper> marshalling (1<<64-1) as uint64 value becomes 0xffffffffffffffff, and unmarshalling works into uint64
[03:02] <thumper> but other smaller values are 'int'
[03:02]  * thumper goes to write a schema hole to push this through
[03:57] <thumper> anyone? http://reviews.vapour.ws/r/3568/
[04:00] <thumper> davecheney: ^^ ?
[04:03] <davecheney> thumper: responded
[04:03] <thumper> ta
[04:03] <davecheney> you can tighten up the switch statement some
[04:03] <davecheney> other than that, lgtm
[04:03] <thumper> davecheney: I don't see it
[04:04] <thumper> ah
[04:04] <thumper> GH
[04:04] <thumper> davecheney: yeah, nicer on one line
[04:08] <davecheney> and you move the case that used to fall through the switch into the switch body
[04:08] <davecheney> i like methods than have a switch statement to end with a switch
[04:08] <davecheney> you know once you get into the switch, it can only hit one of the cases
[04:09]  * thumper tries to beat the bot
[04:10]  * thumper wonders if there is a bot on juju/schema
[04:10] <davecheney> then you don't have to rememver, hmm, this switch case doesn't do anything ... oh, i have to keep reading the file
[04:11] <davecheney> Lovely
[04:11] <thumper> did for both Uint and Time
[04:12]  * thumper manually merges
[04:13] <thumper> davecheney: before I manually merge, want to add a mark to GH?
[04:45]  * thumper departs
[09:36] <mup> Bug #1460175 changed: apiserver_test authhttp_test SetUpTest.debugLogSuite failed <intermittent-failure> <ppc64el> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1460175>
[09:46] <voidspace> frobware: you got an LGTM by the way
[09:52] <frobware> voidspace, much obliged.
[09:57] <frobware> dooferlad, I will pick up the VLAN bugs/issues on 1.25.
[09:57] <dooferlad> frobware: thanks! I will get on with the demo page then.
[09:58] <frobware> dooferlad, could you pick of the '@' for '=' first.
[09:58] <dooferlad> frobware: sure.
[09:58] <frobware> dooferlad, we also need to help voidspace out with the merge of master into maas-spaces.
[09:59] <dooferlad> frobware: I gave him a +1. Guess we can discuss in the standup
[09:59] <frobware> dooferlad, yep
[10:00] <voidspace> omw
[10:01] <voidspace> frobware: dooferlad: standup
[11:13] <frobware> voidspace, you tried merging into master. http://reviews.vapour.ws/r/3560/
[11:42] <mup> Bug #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:51] <mup> Bug #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:54] <mup> Bug #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>
[12:18] <voidspace> frobware: hah
[12:18] <voidspace> frobware: did I set up the branches the wrong way round
[12:18] <frobware> voidspace, I would say so
[12:19] <voidspace> frobware: oops
[12:19] <frobware> voidspace, close...
[12:19] <voidspace> frobware: will close and recreate PR
[12:27] <frobware> voidspace, dooferlad: http://reviews.vapour.ws/r/3570/ - thx
[12:30] <voidspace> frobware: dooferlad: attempt two (onto the right branch!) http://reviews.vapour.ws/r/3571/
[12:34] <dooferlad> voidspace: if it is the same as before, but with the right branch target, it already has a +1 from me.
[12:34] <voidspace> dooferlad: it is
[12:34] <voidspace> frobware: looking at yours
[12:35] <dooferlad> voidspace: +1 it is then
[12:35] <voidspace> dooferlad: thanks, I've hit $$merge$$ on it
[12:35] <dooferlad> voidspace, frobware: https://github.com/juju/juju/pull/4147
[12:37] <frobware> dooferlad, LGTM except for jam's comment.
[12:37] <frobware> (or observation)
[12:38] <voidspace> frobware: add-juju-bridge.py:is_active, if an option is 'bond-master' then you return false
[12:38] <voidspace> frobware: that's a separate, unrelated, change to the vlan bridging change - right?
[12:39] <frobware> voidspace, nope.
[12:39] <voidspace> frobware: the big change is that in _bridge_vlan you no longer check active interfaces
[12:39] <voidspace> frobware: ah, ok
[12:39] <voidspace> frobware: what's bond-master?
[12:39] <frobware> voidspace, bond raw device now become special too
[12:40] <voidspace> frobware: what's a bond raw device?
[12:41] <frobware> voidspace, it is to protect these stanzas of this form: http://pastebin.ubuntu.com/14574966/
[12:42] <voidspace> frobware: ok, what are they?
[12:42] <voidspace> frobware: why do we not bridge them?
[12:42] <frobware> voidspace, look at this example - http://pastebin.ubuntu.com/14574970/
[12:42] <frobware> voidspace, we have a bond but the bond has two vlans on (top of) it.
[12:43] <voidspace> frobware: if it's manual wouldn't it be safe anyway?
[12:43] <frobware> voidspace, the correct bridging should be http://pastebin.ubuntu.com/14574972/
[12:44] <frobware> voidspace, 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:45] <frobware> voidspace, if we did eth0/1 in that example. you would get br-bond0 and br-eth0 (and br-eth1).
[12:47] <voidspace> frobware: ok, thanks
[12:48] <frobware> voidspace, did I confuse things? does it make sense?
[12:48] <frobware> voidspace, it's too long since I did the actual change. :)
[12:48] <voidspace> frobware: I'm just looking at the original code to see how we now treat that differently
[12:50] <voidspace> frobware: 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-master
[12:50] <frobware> voidspace, agreed.
[12:51] <voidspace> frobware: that bond-master change (specifically) doesn't make any difference for the examples you showed
[12:51] <voidspace> they would only change behaviour for  a bond-master that was dhcp / static
[12:54] <voidspace> frobware: and that bond-master change isn't tested as far as I can see
[12:54] <voidspace> frobware: other than that LGTM
[12:55] <frobware> voidspace, test is in the case that uses networkDHCPWithBondInitial
[12:56] <frobware> voidspace, ah, you mean if the bond0 config is static?
[12:57] <voidspace> frobware: I mean a test case where is_active would have returned true before the change but returns false now
[12:57] <voidspace> frobware: so yeah, a bond-master config that is either static or dhcp
[12:58] <frobware> voidspace, and we're talking for the raw eth0/eth1 device?
[12:58] <voidspace> frobware: well, whatever sort of stanza that code is intended to be for
[12:58] <voidspace> so yes I think
[12:59] <voidspace> but a realistic example in the test would make the intent of the code clearer
[12:59] <frobware> voidspace, 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] <voidspace> right
[13:00] <voidspace> that was my half suspicion, if it's not a case we can ever hit then the code doesn't need to be there
[13:00] <voidspace> with networking I don't mind it being there "just in case" though, but in which case there should be a test
[13:01] <voidspace> maybe with a comment that it's not a likely case and this is defensive code
[13:13] <frobware> voidspace, you know what would be better here... if we moved the tests to python and then looked at the coverage.
[13:21] <voidspace> frobware: heh, indeed
[14:09] <mup> Bug #1465307 changed: 1.24.0: Lots of "agent is lost, sorry!" messages <landscape> <regression> <juju-core:Fix Released> <https://launchpad.net/bugs/1465307>
[14:17] <jamespage> mgz, blimey - so retries was intentional!
[14:18] <mgz> jamespage: yeah, though I'm not sure how well publicised it was, didn't get any responses on the list
[14:19] <mup> Bug #1465307 opened: 1.24.0: Lots of "agent is lost, sorry!" messages <landscape> <regression> <juju-core:Incomplete> <https://launchpad.net/bugs/1465307>
[14:19] <jamespage> mgz, well is was -dev rather than straight up juju
[14:19] <jamespage> mgz, I responded in the bug and the ML - we should turn this off...
[14:20] <mgz> I thought I had responded at the time, but I guess I just poked bogdan about it on irc
[14:22] <mup> Bug #1465307 changed: 1.24.0: Lots of "agent is lost, sorry!" messages <landscape> <regression> <juju-core:Incomplete> <https://launchpad.net/bugs/1465307>
[14:28] <mup> Bug #1465307 opened: 1.24.0: Lots of "agent is lost, sorry!" messages <landscape> <regression> <juju-core:Incomplete> <https://launchpad.net/bugs/1465307>
[14:31] <mup> Bug #1465307 changed: 1.24.0: Lots of "agent is lost, sorry!" messages <landscape> <regression> <juju-core:Fix Released> <https://launchpad.net/bugs/1465307>
[14:37] <mup> Bug #1465307 opened: 1.24.0: Lots of "agent is lost, sorry!" messages <landscape> <regression> <juju-core:Fix Released> <https://launchpad.net/bugs/1465307>
[15:21] <bogdanteleaga> jamespage: 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 it
[15:22] <bogdanteleaga> I was waiting for somebody to get hit by it for a while :p
[15:23] <bogdanteleaga> I think the reasoning was that hooks are supposed to be idempotent anyway, so it wouldn't hurt to always do it
[15:47] <jamespage> bogdanteleaga, hook idempotency is important and a good feature, but if somethings failed, it breaks out of that assumption I think
[15:49] <bogdanteleaga> jamespage, 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:50] <bogdanteleaga> how does the opt-in thing sound?
[15:51] <perrito666> bogdanteleaga: opt-in?
[15:53] <bogdanteleaga> I was thinking about having a option in the charm to specify whether the author wants retries or not
[15:53] <perrito666> bogdanteleaga: that is a problem
[15:53] <perrito666> you see retrie is because of juju, not of the charm
[15:53] <cherylj> bogdanteleaga: we could also put it behind a config option
[15:55] <bogdanteleaga> perrito666: not sure I follow
[15:55] <bogdanteleaga> cherylj, you're talking about environ config?
[15:55] <cherylj> bogdanteleaga: yeah.  like juju set-env auto-hook-retry=true
[15:55] <perrito666> bogdanteleaga: 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 upgrading
[15:57] <bogdanteleaga> cherylj, yup, but why not make the granularity at charm level?
[15:57] <bogdanteleaga> perrito666, won't that happen regardless of retries?
[15:58] <perrito666> bogdanteleaga: if the hook is idempotent, that would not be a problem :p
[15:59] <bogdanteleaga> perrito666, aren't we working with the assumption that they are?
[16:06] <katco> natefinch: happy tuesday :)
[16:07] <perrito666> that looks extremely like the prelude to bad news :p
[16:08] <perrito666> I hate making changes in status
[16:09] <natefinch> katco: happy tuesday
[16:10] <katco> natefinch: just wanted to check in and see if you needed anything for your card (or anything else)
[16:11] <natefinch> katco: nope, think I'm good.  Card seems pretty straight forward.
[16:12] <katco> natefinch: ok, cool! also sent you a meeting invite for this afternoon. 15:15, and then we have the meeting at 15:30
[16:13] <natefinch> katco: 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:14] <katco> natefinch: we'll discuss @ 15:15
[16:14] <natefinch> katco: ok
[16:29] <voidspace> frobware: dooferlad: mega-monster-master-merge landed
[16:29] <voidspace> frobware: dooferlad: do we have openstack meeting now?
[16:30] <dooferlad> voidspace: will ping you if anyone turns up
[16:32] <voidspace> dooferlad: ok
[16:43] <voidspace> hmm... so far changes on master to provider/maas/environs.go *are* on the merged maas-spaces
[16:43] <voidspace> that's encouraging
[17:06] <voidspace> ok, so found the first "lost" changes
[17:09] <katco> natefinch: also, ericsnow needed a review on this: http://reviews.vapour.ws/r/3551/diff/#
[17:10] <natefinch> katco: thanks for bringing that to my attention, I hadn't gone to look at reviewboard this morning
[17:29] <perrito666> downloading lxd images in a bar, the rest of the people using the wifi must be hating me
[17:29] <perrito666> a lot
[17:36] <lazypower> perrito666 chaos_wolf.png
[17:41] <lazypower> perrito666 http://i.imgur.com/p2jAdlk.jpg
[18:01] <perrito666> lazypower: actually I was drinking coffee and having lunch
[18:01] <perrito666> but given what they charged me, I presume the bw was more than paid :p
[18:01] <lazypower> perrito666 thats fair. I feel that way about panera
[18:25] <mup> Bug #1535838 opened: Juju won't let me use some instance types on AWS <juju-core:New> <https://launchpad.net/bugs/1535838>
[18:28] <beisner> cherylj, 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] <beisner> failed 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 deployed
[18:28] <beisner> i've got another bootstrap underway to see if i get the same.  logs, collected too.
[18:28] <mup> Bug #1535838 changed: Juju won't let me use some instance types on AWS <juju-core:New> <https://launchpad.net/bugs/1535838>
[18:29] <beisner> from the maas perspective, machine is "deployed" without error
[18:37] <mup> Bug #1535838 opened: Juju won't let me use some instance types on AWS <juju-core:New> <https://launchpad.net/bugs/1535838>
[18:37] <mgz> beisner: did you use  --upload-tools?
[18:38] <beisner> mgz, indeed.  got a new run going now.
[18:41] <cmars> natefinch, question about windows workloads.. if I juju ssh to a windows workload, would I have access to powershell commands, or just cmd.exe ?
[18:42] <cmars> bogdanteleaga, was going to ask you as well ^^, though it's probably past your eod
[18:43] <bogdanteleaga> I can do quick questions
[18:43] <bogdanteleaga> you can't ssh to a windows machine now
[18:43] <bogdanteleaga> we need winrm for that kind of functionality
[18:43] <bogdanteleaga> and it's not implemented yet
[18:44] <bogdanteleaga> best thing you can do is rdp into it, or winrm manually
[18:46] <mgz> see bug 1426729 bug 1426730
[18:46] <mup> Bug #1426729: juju-run does not work on windows hosts <juju-agent> <run> <ssh> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1426729>
[18:46] <mup> Bug #1426730: juju debug-hooks does not work on windows <charm> <juju-agent> <ssh> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1426730>
[18:49] <beisner> mgz, cherylj - 2nd and 3rd bootstraps a-ok.  now deploying some misc stuff to another unit and containers.  will holler back.
[18:49] <cherylj> thanks, beisner!
[18:52] <beisner> yw, cherylj !
[18:56] <cmars> bogdanteleaga, mgz ok, thanks!
[18:56] <natefinch> ericsnow: 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:57] <ericsnow> natefinch: consistent serialization in the various places where we need to
[19:02] <natefinch> ericsnow: This feels like it's mixing concerns.  The formatted stuff is getting mixed into the api<->non-api conversions...
[19:04] <ericsnow> katco, natefinch: quick review please: https://github.com/juju/utils/pull/188
[19:05] <ericsnow> natefinch: how so?
[19:05] <ericsnow> katco: with that utils patch + my current branch, resource-get is working! :)
[19:05] <katco> ericsnow: yes!
[19:06]  * katco does a happy dance
[19:06] <natefinch> ericsnow: awesome
[19:06] <katco> ericsnow: when i have more time, i'd love to hear what bugs you ran into
[19:06] <ericsnow> katco: just read through the commit history of the branch :)
[19:06] <katco> ericsnow: good call
[19:10] <natefinch> ericsnow: 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 see
[19:10] <natefinch> where the data is coming from).
[19:12] <natefinch> ericsnow: 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:13] <ericsnow> natefinch: I don't see how anything is being tied to tightly to anything else
[19:14] <ericsnow> natefinch: across our implementation we have a consistent pattern of serialization
[19:14] <ericsnow> natefinch: I factored that out so that it is more maintainable
[19:15] <natefinch> ericsnow: 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:16] <natefinch> ericsnow: and we don't even use the fingerprint field from serialized for the formatter, which is a red flag
[19:17] <ericsnow> natefinch: how is that a red flag?
[19:17] <natefinch> ericsnow: it shows that the formats are only coincidentally the same.... and for example, that field is not the same.
[19:19] <natefinch> ericsnow: and the code for IsPlaceholder is only used in the formatter, but the logic exists way far away in the serialized code
[19:20] <natefinch> ericsnow: 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:21] <beisner> cherylj, 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] <beisner> though that is not impacting this particular deploy
[20:00] <thumper> morning folks
[20:00] <perrito666> thumper: morning
[20:01] <katco> natefinch: moonstone
[20:03] <cherylj> frobware, dooferlad, if you're still around, can you checkout beisner's comment above?
[20:31] <cherylj> sinzui: 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:32] <cherylj> sinzui: it pulls in the MAAS fixes that we talked about in the standup
[20:32] <sinzui> cherylj: CI saw the commits and has already started a new test of master
[20:37] <mup> Bug #1535891 opened: Feature request: Custom/user definable cloud-init user-data <juju-core:New> <https://launchpad.net/bugs/1535891>
[21:17] <menn0> perrito666: ping
[21:17] <perrito666> menn0: pong
[21:17] <menn0> perrito666: I'm looking at your XDG compatible PR
[21:17] <menn0> perrito666: what do you mean by "location for juju config files is not .config/juju or XDG_CONFIG_HOME/juju"
[21:18] <perrito666> menn0: lemme go check
[21:19] <perrito666> menn0: there, corrected, apologies
[21:19] <menn0> perrito666: it seems like the change is making it so the default juju home is indeed ~/.config/juju
[21:19] <menn0> perrito666: thanks
[21:19] <perrito666> menn0: it follows the xdg standard
[21:19] <mup> Bug #1535891 changed: Feature request: Custom/user definable cloud-init user-data <juju-core:Opinion> <https://launchpad.net/bugs/1535891>
[21:20] <menn0> perrito666: yep I get it. The "not" was confusing :)
[21:20] <perrito666> it is either XDG_CONFIG_HOME/juju or ~/.config/juju depends if the first is defined, it usually isnt
[21:20] <perrito666> the standard dictates that the later is the default value
[21:20] <perrito666> extra context  -> http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
[21:21] <menn0> perrito666: thanks. I'm up to speed with that but it's good to have the link to the spec.
[21:23] <perrito666> menn0: tx for reviewing that, it is a boring long change
[21:23] <frobware> cherylj, I answered in the bug. make sense?
[21:25] <cherylj> frobware: thanks for that update.  It is not clear to me whether or not you'd be comfortable releasing what we have.
[21:25] <cherylj> frobware: should we wait for your additional testing?  or are we good to go?
[21:26] <frobware> cherylj, I can try now, but I may curtail if it goes too long.
[21:27] <cherylj> frobware: so then we should wait?  :)
[21:27] <frobware> cherylj, 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:28] <cherylj> frobware: heh okay.  Let me know your results when you EOD and we'll make the call to ship it or not
[21:43] <beisner> frobware, cherylj - ++comment @ "that bug"
[21:44] <frobware> beisner, I'm struggling to understand why (in my own head) the additional nameserver entries become a problem?
[21:45] <frobware> beisner, the indentation is confusing on the dns- entries added by maas/curtin. They belong to an interface.
[21:45] <beisner> frobware, 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.2
[21:46] <frobware> mpontillo, ping - I have some questions regarding the rendering of /e/n/i from MAAS/curtin...
[21:46] <beisner> so i'm just raising a flag that this could smell of some future trouble.
[21:47] <frobware> beisner, 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:48] <frobware> beisner, they _are_ attached to the iface. In your case 'auto eth3'.
[21:48] <beisner> http://pastebin.ubuntu.com/14577099/
[21:49] <beisner> frobware, ^ exactly.   there is no longer a global dns-nameservers setting.  it's getting sucked into eth3's stanza.
[21:49] <frobware> beisner, I would agree that the association to eth3 is new, but then again that's because we were parsing it badly.
[21:49] <beisner> whereas without juju, there is a top-level definition of dns-nameservers.
[21:50] <frobware> beisner, I think the problem is that there's no notion of top-level dns-* stanzas.
[21:50] <frobware> beisner, if you read $(man interfaces) there's no mention of dns-*
[21:51] <frobware> beisner, if you read $(man resolvconf) there is the notion that an interface can have a dns-* option.
[21:53] <frobware> beisner, and, AFAICT, there are few mentions of nameservers in the ifupdown package. http://pastebin.ubuntu.com/14577985/
[21:56] <mup> Bug #1535916 opened: juju upgrade-charm should recognize the force flag <adoption> <compatibility> <juju-core:New> <https://launchpad.net/bugs/1535916>
[21:58] <beisner> frobware, 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:59] <frobware> beisner, I think the issue is that the indentation make it appear that dns-* options are top-level stanzas.
[21:59] <beisner> frobware, to be clear, top-level dns-nameserver does work in an e/n/i file, regardless of presence in the man pages.
[21:59] <menn0> perrito666: review done. I don't think it's quite there yet.
[22:02] <beisner> frobware, 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] <frobware> beisner, does eth3 have an auto stanza?
[22:03] <frobware> beisner, if so, you can verify its UPness with: ip -d link
[22:03] <beisner> frobware, top is before juju, bottom is after juju.  http://pastebin.ubuntu.com/14577099/
[22:03] <beisner> frobware, eth2 and eth3 aren't even cabled up on these boxes.
[22:04] <frobware> beisner, can you cut+paste the output from that state using ip -d link
[22:06] <beisner> frobware, ip -d link:  http://pastebin.ubuntu.com/14578067/
[22:08] <beisner> i've got to depart, EOD, but can be back online in ~+4hrs.
[22:08] <frobware> beisner, cherylj: see discussion on #maas
[22:09] <cherylj> frobware: I'm following :)
[22:13] <frobware> cherylj, given the differing opinions, do we want to hold fire here? It seems we need to nail this down once and for all. :(
[22:14] <cherylj> beisner: 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] <cherylj> I think I missed him
[22:15] <cherylj> frobware: we can pick this back up tomorrow.
[22:15] <cherylj> frobware: but please do add an update to the bug with a current plan before you head off to bed
[22:18] <perrito666> menn0: tx a lot
[22:19] <perrito666> menn0: I agree a lot with your review, tx
[22:23] <frobware> cherylj, what's interesting is that if `dns-*' is a top-level stanza this is pretty much how we were previously interpreting it.
[22:26] <cherylj> frobware: so what's your thought now?  to ask maas / curtin to create juju-br0?
[22:27] <frobware> cherylj, too much of a change right here, right now. but it's something to discuss for ongoing releases.
[22:28] <cherylj> frobware: okay.  For 1.25.3, do you need to change what you have now?
[22:30] <frobware> cherylj, no, don't believe so. but I just updated the bug. it's getting late for me to summarise what we have & do.
[23:26] <mup> Bug #1336473 changed: Support new t2 instance types on AWS <ec2-provider> <juju-core:Fix Released> <https://launchpad.net/bugs/1336473>
[23:29] <mup> Bug #1336473 opened: Support new t2 instance types on AWS <ec2-provider> <juju-core:Fix Released> <https://launchpad.net/bugs/1336473>
[23:32] <mup> Bug #1336473 changed: Support new t2 instance types on AWS <ec2-provider> <juju-core:Fix Released> <https://launchpad.net/bugs/1336473>
[23:35] <mup> Bug #1336473 opened: Support new t2 instance types on AWS <ec2-provider> <juju-core:Fix Released> <https://launchpad.net/bugs/1336473>
[23:40] <axw> perrito666: FYI, your messages are coming up in the hangouts thingy in gmail/inbox
[23:40] <perrito666> axw: the writing in another chat was ajoke or I actually was on the wrong chat?
[23:40] <axw> perrito666: as opposed to the hangout video window
[23:40] <axw> perrito666: I guess because you're using your tablet or phone or whatever?
[23:40] <perrito666> mm that sucks
[23:40] <perrito666> axw: exactly, hangouts finds new ways of sucking
[23:41] <anastasiamac> perrito666: u typed messages?
[23:41] <perrito666> anastasiamac: I did
[23:41] <anastasiamac> perrito666: i did not see any ;(
[23:44] <perrito666> apparently there is no way to access the video chat from the mobile app
[23:44] <mup> Bug #1336473 changed: Support new t2 instance types on AWS <ec2-provider> <juju-core:Fix Released> <https://launchpad.net/bugs/1336473>
[23:50] <wallyworld> axw: anastasiamac: will be afk for a bit, electrician on way to my house
[23:50] <anastasiamac> wallyworld: \o/
[23:51] <anastasiamac> wallyworld: i've pm-ed u too
[23:51] <axw> wallyworld: see you later, minus arm and leg
[23:51] <anastasiamac> :D
[23:53] <mpontillo> frobware: sorry, I was out for an appt - back now. what's up?