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:42 |
davecheney | that's awesome, that check caught something | 00:58 |
davecheney | i'm pretty sure that race is already tracked in a bug | 00:59 |
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:07 |
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:08 |
davecheney | oh, and it looks like gomaasapi is being used | 01:09 |
davecheney | that happened on the 5th ? | 01:09 |
davecheney | ok, time to fix that race | 01:10 |
thumper | I did notice that martin did add it before christmas | 01:13 |
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:14 |
thumper | blahdeblah: what is the rationale for this? | 01:15 |
blahdeblah | I'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 |
davecheney | thumper: that was added to 1.6 | 01:20 |
davecheney | i'm surprised it made it into the versino in xenial | 01:20 |
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:21 |
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:22 |
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:36 |
davecheney | gb ? i mean rb | 01:37 |
davecheney | actual change is here, https://github.com/juju/gomaasapi/pull/3/files#diff-cef8a1746ed33f0946c8dc5017058f15R599 | 01:37 |
* thumper sees if it has a bot | 01:45 | |
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:46 | |
davecheney | thumper: https://github.com/juju/juju/pull/4146 | 01:51 |
davecheney | passes stress.bash on my machine | 01:51 |
thumper | done | 01:52 |
davecheney | i'm sort of surprised that fix worked | 01:52 |
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:53 |
thumper | :) | 01:54 |
cherylj | Can I get a quick review? http://reviews.vapour.ws/r/3562/ | 02:01 |
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:06 |
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:08 |
davecheney | cherylj: sorry, thumper approved it | 02:14 |
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:15 |
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:20 |
mwhudson | oh heh 1.6~beta2 is in xenial | 02:21 |
mwhudson | who uploaded that? | 02:21 |
davecheney | ¯\_(ツ)_/¯ | 02:22 |
mwhudson | oh xnox | 02:22 |
cherylj | fatal error: concurrent map writes? oh I see gomaasapi in the stack now. | 02:23 |
mwhudson | which means i should update golang-race-detector-runtime too i guess | 02:25 |
cherylj | looks like the other master failures were joyent issues | 02:26 |
davecheney | joyent provider also has long standing races | 02:27 |
cherylj | davecheney: and we had to move to another (more crowded) region recently | 02:29 |
thumper | huh... who woulda thunk it | 03:01 |
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:02 | |
=== MerryChristmas is now known as benonsftware | ||
=== benonsftware is now known as benonsoftware | ||
thumper | anyone? http://reviews.vapour.ws/r/3568/ | 03:57 |
thumper | davecheney: ^^ ? | 04:00 |
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:03 |
thumper | ah | 04:04 |
thumper | GH | 04:04 |
thumper | davecheney: yeah, nicer on one line | 04:04 |
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:08 |
* thumper tries to beat the bot | 04:09 | |
* 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:10 |
davecheney | Lovely | 04:11 |
thumper | did for both Uint and Time | 04:11 |
* thumper manually merges | 04:12 | |
thumper | davecheney: before I manually merge, want to add a mark to GH? | 04:13 |
* thumper departs | 04:45 | |
=== mwhudson is now known as Guest92985 | ||
=== Guest92985 is now known as mwhudson | ||
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:36 |
voidspace | frobware: you got an LGTM by the way | 09:46 |
frobware | voidspace, much obliged. | 09:52 |
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:57 |
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:58 |
dooferlad | frobware: I gave him a +1. Guess we can discuss in the standup | 09:59 |
frobware | dooferlad, yep | 09:59 |
voidspace | omw | 10:00 |
voidspace | frobware: dooferlad: standup | 10:01 |
frobware | voidspace, you tried merging into master. http://reviews.vapour.ws/r/3560/ | 11:13 |
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:42 |
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:51 |
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:54 |
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:18 |
voidspace | frobware: oops | 12:19 |
frobware | voidspace, close... | 12:19 |
voidspace | frobware: will close and recreate PR | 12:19 |
frobware | voidspace, dooferlad: http://reviews.vapour.ws/r/3570/ - thx | 12:27 |
voidspace | frobware: dooferlad: attempt two (onto the right branch!) http://reviews.vapour.ws/r/3571/ | 12:30 |
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:34 |
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:35 |
frobware | dooferlad, LGTM except for jam's comment. | 12:37 |
frobware | (or observation) | 12:37 |
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:38 |
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:39 |
voidspace | frobware: what's a bond raw device? | 12:40 |
frobware | voidspace, it is to protect these stanzas of this form: http://pastebin.ubuntu.com/14574966/ | 12:41 |
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:42 |
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:43 |
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:44 |
frobware | voidspace, if we did eth0/1 in that example. you would get br-bond0 and br-eth0 (and br-eth1). | 12:45 |
voidspace | frobware: ok, thanks | 12:47 |
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:48 |
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:50 |
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:51 |
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:54 |
frobware | voidspace, test is in the case that uses networkDHCPWithBondInitial | 12:55 |
frobware | voidspace, ah, you mean if the bond0 config is static? | 12:56 |
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:57 |
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:58 |
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 | 12:59 |
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:00 |
voidspace | maybe with a comment that it's not a likely case and this is defensive code | 13:01 |
frobware | voidspace, you know what would be better here... if we moved the tests to python and then looked at the coverage. | 13:13 |
voidspace | frobware: heh, indeed | 13:21 |
=== benji is now known as Guest37973 | ||
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:09 |
jamespage | mgz, blimey - so retries was intentional! | 14:17 |
mgz | jamespage: yeah, though I'm not sure how well publicised it was, didn't get any responses on the list | 14:18 |
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:19 |
mgz | I thought I had responded at the time, but I guess I just poked bogdan about it on irc | 14:20 |
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:22 |
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:28 |
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:31 |
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> | 14:37 |
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:21 |
bogdanteleaga | I was waiting for somebody to get hit by it for a while :p | 15:22 |
bogdanteleaga | I think the reasoning was that hooks are supposed to be idempotent anyway, so it wouldn't hurt to always do it | 15:23 |
jamespage | bogdanteleaga, hook idempotency is important and a good feature, but if somethings failed, it breaks out of that assumption I think | 15:47 |
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:49 |
bogdanteleaga | how does the opt-in thing sound? | 15:50 |
perrito666 | bogdanteleaga: opt-in? | 15:51 |
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:53 |
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:55 |
bogdanteleaga | cherylj, yup, but why not make the granularity at charm level? | 15:57 |
bogdanteleaga | perrito666, won't that happen regardless of retries? | 15:57 |
perrito666 | bogdanteleaga: if the hook is idempotent, that would not be a problem :p | 15:58 |
bogdanteleaga | perrito666, aren't we working with the assumption that they are? | 15:59 |
katco | natefinch: happy tuesday :) | 16:06 |
perrito666 | that looks extremely like the prelude to bad news :p | 16:07 |
perrito666 | I hate making changes in status | 16:08 |
natefinch | katco: happy tuesday | 16:09 |
katco | natefinch: just wanted to check in and see if you needed anything for your card (or anything else) | 16:10 |
natefinch | katco: nope, think I'm good. Card seems pretty straight forward. | 16:11 |
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:12 |
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:13 |
katco | natefinch: we'll discuss @ 15:15 | 16:14 |
natefinch | katco: ok | 16:14 |
voidspace | frobware: dooferlad: mega-monster-master-merge landed | 16:29 |
voidspace | frobware: dooferlad: do we have openstack meeting now? | 16:29 |
dooferlad | voidspace: will ping you if anyone turns up | 16:30 |
voidspace | dooferlad: ok | 16:32 |
voidspace | hmm... so far changes on master to provider/maas/environs.go *are* on the merged maas-spaces | 16:43 |
voidspace | that's encouraging | 16:43 |
voidspace | ok, so found the first "lost" changes | 17:06 |
katco | natefinch: also, ericsnow needed a review on this: http://reviews.vapour.ws/r/3551/diff/# | 17:09 |
natefinch | katco: thanks for bringing that to my attention, I hadn't gone to look at reviewboard this morning | 17:10 |
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:29 |
lazypower | perrito666 chaos_wolf.png | 17:36 |
lazypower | perrito666 http://i.imgur.com/p2jAdlk.jpg | 17:41 |
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:01 |
mup | Bug #1535838 opened: Juju won't let me use some instance types on AWS <juju-core:New> <https://launchpad.net/bugs/1535838> | 18:25 |
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:28 |
beisner | from the maas perspective, machine is "deployed" without error | 18:29 |
=== benji_ is now known as benji | ||
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:37 |
beisner | mgz, indeed. got a new run going now. | 18:38 |
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:41 |
cmars | bogdanteleaga, was going to ask you as well ^^, though it's probably past your eod | 18:42 |
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:43 |
bogdanteleaga | best thing you can do is rdp into it, or winrm manually | 18:44 |
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:46 |
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:49 |
beisner | yw, cherylj ! | 18:52 |
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:56 |
ericsnow | natefinch: consistent serialization in the various places where we need to | 18:57 |
natefinch | ericsnow: This feels like it's mixing concerns. The formatted stuff is getting mixed into the api<->non-api conversions... | 19:02 |
ericsnow | katco, natefinch: quick review please: https://github.com/juju/utils/pull/188 | 19:04 |
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:05 |
* 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:06 |
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:10 |
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:12 |
ericsnow | natefinch: I don't see how anything is being tied to tightly to anything else | 19:13 |
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:14 |
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:15 |
natefinch | ericsnow: and we don't even use the fingerprint field from serialized for the formatter, which is a red flag | 19:16 |
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:17 |
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:19 |
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:20 |
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 | 19:21 |
thumper | morning folks | 20:00 |
perrito666 | thumper: morning | 20:00 |
katco | natefinch: moonstone | 20:01 |
cherylj | frobware, dooferlad, if you're still around, can you checkout beisner's comment above? | 20:03 |
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:31 |
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:32 |
mup | Bug #1535891 opened: Feature request: Custom/user definable cloud-init user-data <juju-core:New> <https://launchpad.net/bugs/1535891> | 20:37 |
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:17 |
perrito666 | menn0: lemme go check | 21:18 |
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:19 |
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:20 |
menn0 | perrito666: thanks. I'm up to speed with that but it's good to have the link to the spec. | 21:21 |
perrito666 | menn0: tx for reviewing that, it is a boring long change | 21:23 |
frobware | cherylj, I answered in the bug. make sense? | 21:23 |
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:25 |
frobware | cherylj, I can try now, but I may curtail if it goes too long. | 21:26 |
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:27 |
cherylj | frobware: heh okay. Let me know your results when you EOD and we'll make the call to ship it or not | 21:28 |
beisner | frobware, cherylj - ++comment @ "that bug" | 21:43 |
frobware | beisner, I'm struggling to understand why (in my own head) the additional nameserver entries become a problem? | 21:44 |
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:45 |
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:46 |
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:47 |
frobware | beisner, they _are_ attached to the iface. In your case 'auto eth3'. | 21:48 |
beisner | http://pastebin.ubuntu.com/14577099/ | 21:48 |
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:49 |
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:50 |
frobware | beisner, if you read $(man resolvconf) there is the notion that an interface can have a dns-* option. | 21:51 |
frobware | beisner, and, AFAICT, there are few mentions of nameservers in the ifupdown package. http://pastebin.ubuntu.com/14577985/ | 21:53 |
mup | Bug #1535916 opened: juju upgrade-charm should recognize the force flag <adoption> <compatibility> <juju-core:New> <https://launchpad.net/bugs/1535916> | 21:56 |
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:58 |
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. | 21:59 |
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:02 |
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:03 |
frobware | beisner, can you cut+paste the output from that state using ip -d link | 22:04 |
beisner | frobware, ip -d link: http://pastebin.ubuntu.com/14578067/ | 22:06 |
beisner | i've got to depart, EOD, but can be back online in ~+4hrs. | 22:08 |
frobware | beisner, cherylj: see discussion on #maas | 22:08 |
cherylj | frobware: I'm following :) | 22:09 |
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:13 |
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:14 |
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:15 |
perrito666 | menn0: tx a lot | 22:18 |
perrito666 | menn0: I agree a lot with your review, tx | 22:19 |
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:23 |
cherylj | frobware: so what's your thought now? to ask maas / curtin to create juju-br0? | 22:26 |
frobware | cherylj, too much of a change right here, right now. but it's something to discuss for ongoing releases. | 22:27 |
cherylj | frobware: okay. For 1.25.3, do you need to change what you have now? | 22:28 |
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. | 22:30 |
=== axw_ is now known as axw | ||
mup | Bug #1336473 changed: Support new t2 instance types on AWS <ec2-provider> <juju-core:Fix Released> <https://launchpad.net/bugs/1336473> | 23:26 |
mup | Bug #1336473 opened: Support new t2 instance types on AWS <ec2-provider> <juju-core:Fix Released> <https://launchpad.net/bugs/1336473> | 23:29 |
mup | Bug #1336473 changed: Support new t2 instance types on AWS <ec2-provider> <juju-core:Fix Released> <https://launchpad.net/bugs/1336473> | 23:32 |
mup | Bug #1336473 opened: Support new t2 instance types on AWS <ec2-provider> <juju-core:Fix Released> <https://launchpad.net/bugs/1336473> | 23:35 |
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:40 |
anastasiamac | perrito666: u typed messages? | 23:41 |
perrito666 | anastasiamac: I did | 23:41 |
anastasiamac | perrito666: i did not see any ;( | 23:41 |
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:44 |
wallyworld | axw: anastasiamac: will be afk for a bit, electrician on way to my house | 23:50 |
anastasiamac | wallyworld: \o/ | 23:50 |
anastasiamac | wallyworld: i've pm-ed u too | 23:51 |
axw | wallyworld: see you later, minus arm and leg | 23:51 |
anastasiamac | :D | 23:51 |
mpontillo | frobware: 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!