| mup | Bug #1528070 opened: fetching tools output shows template string <juju-core:New> <https://launchpad.net/bugs/1528070> | 00:49 |
|---|---|---|
| mup | Bug #1528070 changed: fetching tools output shows template string <juju-core:New> <https://launchpad.net/bugs/1528070> | 00:52 |
| mup | Bug #1528070 opened: fetching tools output shows template string <juju-core:New> <https://launchpad.net/bugs/1528070> | 00:58 |
| mup | Bug #1528073 opened: Add the ability to force destroy a unit <juju-core:New> <https://launchpad.net/bugs/1528073> | 01:34 |
| mup | Bug #1528073 changed: Add the ability to force destroy a unit <juju-core:New> <https://launchpad.net/bugs/1528073> | 01:37 |
| mup | Bug #1528073 opened: Add the ability to force destroy a unit <juju-core:New> <https://launchpad.net/bugs/1528073> | 01:52 |
| perrito666 | go home mup, you are drunk | 01:56 |
| menn0 | perrito666: LOL | 02:19 |
| menn0 | thumper: http://reviews.vapour.ws/r/3425/ please | 02:35 |
| mup | Bug #1488576 opened: TestAddresserWorkerStopsWhenAddressDeallocationNotSupported fails on pp64el <ci> <intermittent-failure> <ppc64el> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1488576> | 03:04 |
| perrito666 | anyone cares to review https://github.com/go-goose/goose/pull/17 ? | 03:05 |
| mup | Bug #1488576 changed: TestAddresserWorkerStopsWhenAddressDeallocationNotSupported fails on pp64el <ci> <intermittent-failure> <ppc64el> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1488576> | 03:10 |
| mup | Bug #1488576 opened: TestAddresserWorkerStopsWhenAddressDeallocationNotSupported fails on pp64el <ci> <intermittent-failure> <ppc64el> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1488576> | 03:13 |
| menn0 | thumper: any time to look at that review? | 03:25 |
| menn0 | wallyworld: ping? | 03:30 |
| wallyworld | yo | 03:30 |
| menn0 | wallyworld: are you able to review something or are you flat out? | 03:30 |
| wallyworld | am busy, is it smallish? :-) | 03:31 |
| wallyworld | apiworkrs manifold? | 03:31 |
| menn0 | wallyworld: yep. | 03:32 |
| menn0 | wallyworld: it's not huge but not exactly small | 03:32 |
| wallyworld | ok, will look real soon | 03:32 |
| menn0 | thumper: thanks. I need to get this landed as it's my last day for the year and others need it to progress. | 03:33 |
| thumper | gah, looking now | 03:48 |
| wallyworld | menn0: looks ok to my untrained eye, thanks for detailed covering letter on pr | 03:50 |
| wallyworld | menn0: i assume live tested? | 03:50 |
| menn0 | wallyworld: indeed it is | 03:51 |
| wallyworld | yay | 03:51 |
| menn0 | wallyworld: thanks very much for the review. i'll leave you alone now :) | 03:51 |
| wallyworld | anytime, np | 03:52 |
| wallyworld | i liked the channel helper a lot | 03:52 |
| thumper | menn0: done | 03:54 |
| menn0 | wallyworld: \o/ | 03:54 |
| menn0 | thumper: \o/ | 03:54 |
| thumper | just some import ordering | 03:55 |
| menn0 | thumper: I thought you were gone so I asked wallyworld to take a look | 03:55 |
| * wallyworld likes to look | 03:55 | |
| thumper | not fully gone | 03:55 |
| thumper | although I am now | 03:55 |
| thumper | laters | 03:55 |
| blahdeblah | wallyworld/anyone: Any features present or planned that will allow us to provision machine 0 via MAAS with a reasonably locked-down host firewall? | 04:13 |
| blahdeblah | I'm working on juju envs for our archive & NTP servers and we have the requirement to provision into subnets which have no network-based security. | 04:14 |
| wallyworld | blahdeblah: juju can be deployed today with restricted outside access. we allow http-, ftp- and apt- proxies to be set | 04:14 |
| blahdeblah | I'm more worried about inbound than outbound. | 04:14 |
| blahdeblah | The network doesn't impose restricted outside access; it provides unrestricted inbound & outbound access, and we don't want to leave our nodes unprotected at any stage of the provisioning process. | 04:15 |
| wallyworld | the main inbound access for the state server is to allow connections from agents on machines running workloads. i believe the networking folks are looking at features this cycle to make that easier | 04:15 |
| wallyworld | blahdeblah: you'd also need inbound access for clients to talk to the state server. i'd pose the question to andy or dimiter on the saphire team | 04:16 |
| wallyworld | they'd be able to give you a much better answer than me | 04:17 |
| blahdeblah | wallyworld: cool - thanks | 04:18 |
| blahdeblah | wallyworld: Just to clarify: when you say state server, that's jujud-machine-0 (i.e. the thing that listens on 17070), or is it mongodb itself? | 04:24 |
| blahdeblah | The point here is that we need to deploy in a zero-restrictions environment, but we don't want to allow unrestricted inbound access. | 04:24 |
| blahdeblah | Essentially, we don't want to be the mugs with an unprotected mongodb exposed to the whole Internet, nor do we want to expose juju/ssh/mongodb/rsyslog in such a way that people can hammer it with brute force attacks all day. | 04:24 |
| wallyworld | blahdeblah: actually, the current terminology is "juju controller". it is not necessarily machine 0, but till now has been that mostly. and the inbound connection is to the juju agent not mongo; nothing external talks to mongo | 04:25 |
| blahdeblah | but when you bootstrap, mongodb is still listening on all interfaces... | 04:26 |
| wallyworld | could be, that bit i'm not sure of | 04:26 |
| blahdeblah | I can confirm that it does :-) | 04:26 |
| wallyworld | we just start mongo as a normal systemd service, not sure exactly what the confog is | 04:26 |
| wallyworld | we should change mongo startup then maybe | 04:27 |
| wallyworld | it's password protected but that doesn't stop DOS i guess | 04:27 |
| blahdeblah | yeah; and doesn't guard against any potential mongodb zero-days | 04:27 |
| blahdeblah | Here's a vanilla bootstrapped machine in Canonistack: https://pastebin.canonical.com/146540/ | 04:28 |
| blahdeblah | So we've got 4 services listening by default: ssh (should be OK by default, since there's no password), rsyslog, jujud & mongodb. | 04:29 |
| wallyworld | blahdeblah: feel like raising a bug? | 04:30 |
| blahdeblah | wallyworld: There might not be any bug; it might be just fine and I'm just not aware of the options available. | 04:31 |
| wallyworld | blahdeblah: your concerns seem reasonable to me, but check with dimiter/andy maybe and see what they say | 04:31 |
| blahdeblah | I may be worrying about nothing. If we put the controller behind a firewall, we can still deploy the nodes themselves outside the firewall, correct? As long as they have access to tcp:17070, we should be able to add them? | 04:32 |
| blahdeblah | (And by add them, I mean provision through standard MAAS mechanisms.) | 04:33 |
| perrito666 | does anyone know if https://github.com/go-goose/goose uses juju bot? there are commits that would suggest that it does, but my $$merge$$ has been ignored | 05:01 |
| mup | Bug #1229507 changed: create a machine job for machines/environments that provide local storage <local-provider> <manual-provider> <tech-debt> <juju-core:Won't Fix> <https://launchpad.net/bugs/1229507> | 05:53 |
| === ashipika1 is now known as ashipika | ||
| === ashipika1 is now known as ashipika | ||
| menn0 | blahdeblah, wallyworld: rsyslog is going away very soon. jujud needs to be open unless we can 100% know the addresses or networks agents will be talking to juju from (hard to get right all the time I suspect). mongodb should really be locked down so that it's only open to the other state servers if possible. | 08:52 |
| wallyworld | +1 | 08:52 |
| blahdeblah | menn0: That's all pretty much as expected - is there a best practices guide giving more detail about options for locking it down in publicly-accessible networks? | 08:54 |
| menn0 | blahdeblah, wallyworld: locking down mongodb will be somewhat tricky though given that the state servers share information with each other via mongodb. Requires some thought. | 08:54 |
| wallyworld | yup | 08:54 |
| menn0 | anyone able to take a look at this one? http://reviews.vapour.ws/r/3428/ | 08:55 |
| menn0 | it's an easy one | 08:55 |
| blahdeblah | wallyworld, menn0: BTW, this is all academic if I can get it working with the bootstrap behind a locked-down firewall and the units themselves on the public Internet. | 08:56 |
| menn0 | blahdeblah: sure, but it would be nice to make the default situation more secure | 08:56 |
| blahdeblah | indeed | 08:56 |
| blahdeblah | FWIW, I tried it against one of my Canonistack instances, and ssh & jujud were the only things which nmap (in its default config) found. | 08:57 |
| blahdeblah | (even when I specifically targeted the right ports) | 08:57 |
| blahdeblah | Not sure if this is a Canonistack thing though - will test again next chance I get | 08:58 |
| menn0 | blahdeblah: were you testing against a state server? rsyslog and mongodb definitely won't be there on non-state server Juju managed machines. | 09:02 |
| blahdeblah | menn0: Yes - just bootstrapped a fresh Canonistack instance and did nothing other than login and check what was listening. | 09:03 |
| menn0 | blahdeblah: cool, just checking | 09:03 |
| blahdeblah | Yeah, I was surprised it didn't even respond on the port... | 09:03 |
| perrito666 | does anyone know if mgz or sinzui are coming around today? | 09:10 |
| === bruno1 is now known as BrunoR | ||
| === Makyo is now known as Guest60455 | ||
| voidspace | frobware: hangout issues | 10:02 |
| voidspace | frobware: currently I can't get to the stdup | 10:02 |
| === _stowa_ is now known as _stowa | ||
| voidspace | frobware: restarting firefox doesn't help | 10:09 |
| voidspace | will try chrome | 10:09 |
| voidspace | frobware: in chrome I have no working video and possibly not audio either *sigh* | 10:10 |
| voidspace | looks like you're not there yet anyway | 10:10 |
| voidspace | ah, now firefox works | 10:11 |
| voidspace | a bit of manual url mangling does the trick | 10:11 |
| voidspace | frobware: ping me if you're around | 10:11 |
| voidspace | jam1: thanks | 12:04 |
| mgz | cherylj: thanls for filing new bug, was getting confusing tracking in the other one | 13:25 |
| mup | Bug #1528217 opened: 1.25.2 doesn't set up DNS information with MAAS <blocker> <ci> <maas> <network> <regression> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1528217> | 13:27 |
| cherylj | mgz: yeah, I should've done it sooner | 13:27 |
| cherylj | but I guess I was lazy | 13:27 |
| mup | Bug #1528217 changed: 1.25.2 doesn't set up DNS information with MAAS <blocker> <ci> <maas> <network> <regression> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1528217> | 13:30 |
| mup | Bug #1528217 opened: 1.25.2 doesn't set up DNS information with MAAS <blocker> <ci> <maas> <network> <regression> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1528217> | 13:39 |
| cherylj | voidspace: did you have any questions about this CI / MAAS issue? Not sure how much of a handoff you were given. | 13:52 |
| voidspace | cherylj: that email I replied to was the handoff (of sorts), and I'm only in for today :-) | 13:53 |
| voidspace | cherylj: do you have an easy repro? | 13:53 |
| voidspace | cherylj: I'm just updating my vmaas - you said you could repro | 13:53 |
| voidspace | I assume deploy a container... | 13:53 |
| voidspace | I can see from the other bug it's a nameserver issue | 13:54 |
| voidspace | I didn't *think* we set nameservers before (unless they were already in e/n/i) but I may be mistaken | 13:54 |
| voidspace | easy to check though | 13:54 |
| cherylj | voidspace: yes, just bootstrap a maas with 1.25.2 (without the address-allocation feature flag) | 13:54 |
| cherylj | and deploy a container | 13:54 |
| voidspace | cherylj: thanks | 13:54 |
| cherylj | voidspace: we didn't before, but we didn't manually modify /e/n/i before for containers. | 13:55 |
| voidspace | but now we modify /e/n/i even without address-allocation | 13:55 |
| voidspace | right | 13:55 |
| cherylj | voidspace: I put in two cloud-configs in bug 1525280. One from 1.25.0 that worked, and one from 1.25.2 that caused the problem, if you want to look at the difference. | 13:55 |
| mup | Bug #1525280: 1.25.1 with maas 1.8: devices dns allocation uses non-unique hostname <maas-provider> <network> <regression> <juju-core:Triaged> <juju-core 1.25:Fix Committed by dimitern> <https://launchpad.net/bugs/1525280> | 13:55 |
| voidspace | cherylj: yeah, I'll take a look | 13:56 |
| voidspace | it could be an easy fix | 13:56 |
| cherylj | voidspace: I saw that for the host node, the dns information is written out to /e/n/i (I think by us?) | 13:56 |
| mgz | voidspace: poke me if you want to test on finfolk directly as well | 13:56 |
| voidspace | mgz: thanks | 13:56 |
| cherylj | maybe look there for how we get it? | 13:56 |
| voidspace | cherylj: I don't *think* we *add* dns information | 13:56 |
| voidspace | cherylj: again, I maybe mistaken - that code has changed several times recently | 13:57 |
| cherylj | voidspace: I just thought we might as it doesn't source /etc/network/interfaces.d | 13:58 |
| cherylj | but I am not a networking expert by any means :) | 13:58 |
| voidspace | cherylj: we modify /e/n/i - but only transform the existing to add and use bridges | 13:59 |
| voidspace | cherylj: so the lack of sourcing interfaces.d is what we get from maas/curtin | 13:59 |
| cherylj | voidspace: ah, ok | 13:59 |
| voidspace | cherylj: by 1.25.2 do you mean 1.25 tip? there's no 1.25.2 tag | 14:00 |
| cherylj | voidspace: yes | 14:00 |
| voidspace | tnx | 14:00 |
| mup | Bug #1528259 opened: undertakerSuite.TestAPICalls nil deref panic <ci> <i386> <panic> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1528259> | 15:48 |
| mup | Bug #1528261 opened: jujud won't start, log shows a lot of "cannot set addresses of machine XXX: cannot find transaction ObjectIdHex("xxxxxx"); <juju-core:Incomplete> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1528261> | 15:48 |
| frobware | voidspace, ping | 16:11 |
| voidspace | frobware: pong | 16:14 |
| voidspace | frobware: grabbing coffee brb | 16:14 |
| frobware | voidspace, I'm sure you've seen some info on the resolv.conf issue - I can add context here based on what I've tried. Note: I have limited internet connectivity as I'm not at home atm. | 16:14 |
| voidspace | frobware: cool, thanks | 16:15 |
| voidspace | frobware: I will have some questions for you | 16:15 |
| voidspace | frobware: I can confirm the issue - bootstrap with 1.25 tip, deploy a container, ssh to that container and hostnames can't be resolved | 16:16 |
| frobware | voidspace, right; and my poking around with PrepareContainerInterfaceInfo shows that no DNS info is returned. | 16:16 |
| frobware | voidspace, though that is also true for MAAS 1.8 | 16:17 |
| voidspace | frobware: but we wouldn't expect to be setting dns info if there wasn't any in the original /e/n/i I don't think | 16:17 |
| voidspace | we only (used to) set dns info if it was in the original | 16:17 |
| voidspace | but if it's there in the original we should be setting it | 16:17 |
| frobware | voidspace, the original being on the host machine? | 16:17 |
| voidspace | yep | 16:18 |
| voidspace | prior to bootstrap | 16:18 |
| voidspace | really going for coffee | 16:18 |
| frobware | voidspace, the original for me has dns-nameservers and dns-search entries | 16:19 |
| voidspace | frobware: ah right, so that's the bug | 16:20 |
| voidspace | frobware: well, the cause | 16:20 |
| frobware | voidspace, because it has entries? | 16:20 |
| voidspace | frobware: no, that we're not preserving | 16:21 |
| frobware | voidspace, so this is where I got to... when the provisioner makes the facade call where is that info being retrieved from? | 16:22 |
| * frobware notes that his IRC client says 1m+ lag... | 16:24 | |
| voidspace | frobware: well, it's apiserver/provisioner/provisioner.go:prepareOrGetContainerInterfaceInfo | 16:35 |
| voidspace | frobware: with different paths depending on if address-allocation is on or not | 16:36 |
| voidspace | frobware: without address allocation we just ask the provider for the inferface info | 16:36 |
| frobware | voidspace, so this still works OK with address allocation enabled | 16:39 |
| voidspace | frobware: for the case when address-allocation is off, what specifically changed about /e/n/i rendering between 1.25.1 and tip? | 16:41 |
| frobware | voidspace, the bridge script changed, IIRC. | 16:42 |
| voidspace | frobware: I'm bootstrapping with 1.25.1 to see the difference in rendered output | 16:54 |
| frobware | voidspace, doesn't dns info come from parsing /etc/resolv.conf, no /e/n/i? | 16:55 |
| frobware | voidspace, lxc-broker:localDNSServers() | 16:55 |
| voidspace | oh, we have that code too | 16:55 |
| voidspace | I'd forgotten about that | 16:56 |
| voidspace | but how would *that* change between the two... | 16:56 |
| voidspace | (1.25.1 and 1.25.2) | 16:56 |
| frobware | voidspace, precisely | 16:59 |
| frobware | voidspace, so what I was trying to understand earlier is when we make the api facade call does that come out of persisted data? | 16:59 |
| frobware | voidspace, so configureContainerNetwork is only called when address-allocation is enabled... and in configure...Network() we only call localDNSServers() | 17:02 |
| voidspace | frobware: we only call that (localDNSServers) if address allocation is on | 17:02 |
| voidspace | natch | 17:02 |
| frobware | voidspace, heh! | 17:02 |
| frobware | voidspace, so where did the info come from...? | 17:02 |
| voidspace | frobware: soooo... between 1.25.1 and tip the rendered /e/n/i for the host is identical | 17:03 |
| frobware | voidspace, not terribly surprised. but the confirmation is worthy. | 17:04 |
| voidspace | frobware: so the base for the interface info comes from the maas provider NetworkInterfaces call | 17:04 |
| voidspace | frobware: when the lxc container is deployed I get to see the container config | 17:04 |
| voidspace | frobware: and it looks like that doesn't populate DNSServers and DNSSearch fields on the network.InterfaceInfo | 17:07 |
| voidspace | so it's not coming from there (this is 1.25.1 I'm looking at) | 17:07 |
| frobware | voidspace, are you looking at func (environ *maasEnviron) NetworkInterfaces(instId instance.Id) ([]network.InterfaceInfo, error)? | 17:07 |
| voidspace | yep | 17:07 |
| voidspace | frobware: hmmm... prepareOrGetContainerInterfaceInfo is very different between 1.25.1 and tip I think | 17:10 |
| frobware | voidspace, in lxc-broker? | 17:11 |
| voidspace | frobware: apiserver/provisioner/provisioner.go | 17:12 |
| voidspace | frobware: in 1.25.1 containers are provisioned to use dhcp from prepareOrGetContainerInterfaceInfo (it looks like) | 17:14 |
| voidspace | frobware: and indeed that is the case | 17:15 |
| frobware | voidspace, which I think I mentioned in the bug. I'm guessing this is where the /etc/resolv.conf entries come from (i.e., the dhcp lease) | 17:15 |
| voidspace | frobware: in 1.25.2 we render a manual interface | 17:16 |
| frobware | voidspace, so is the root cause here the switch to dhcp | 17:16 |
| voidspace | frobware: switch *from* dhcp | 17:16 |
| frobware | voidspace, switch from... | 17:16 |
| voidspace | frobware: why was that switch made? | 17:16 |
| voidspace | it seems like a big change from 1.25.1 to 1.25.2 | 17:16 |
| voidspace | frobware: I've put this in the bug | 17:19 |
| voidspace | frobware: I think it needs dimiter's comments as it was probably him who changed this | 17:19 |
| frobware | cherylj, ping | 17:24 |
| === tvansteenburgh1 is now known as tvansteenburgh | ||
| cherylj | what up frobware ? | 17:28 |
| voidspace | cherylj: bug 1527217 updated | 17:29 |
| mup | Bug #1527217: RethinkDB installation only works in Ubuntu <DragonFlow:New> <https://launchpad.net/bugs/1527217> | 17:29 |
| frobware | cherylj, the non-uniqueness of MAAS hostnames was an always failure or something intermittent? Asking because one option is to revert the change. Seconds to see if we can get the lxc-broker to add DNS info. Third rework the patch to not use manual allocation. | 17:29 |
| voidspace | cherylj: dammit, bug 1528217 | 17:30 |
| mup | Bug #1528217: 1.25.2 doesn't set up DNS information with MAAS <blocker> <ci> <maas> <network> <regression> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1528217> | 17:30 |
| voidspace | cherylj: in 1.25.1 containers used dhcp when address allocation was off | 17:30 |
| cherylj | frobware: this was a consistent failure in 1.25.1 (non-uniqueness) | 17:31 |
| cherylj | and something that broke.... autopilot maybe? | 17:31 |
| frobware | cherylj, down to options 2 and 3 now. | 17:31 |
| cherylj | yeah option 1 wasn't an option | 17:31 |
| cherylj | I have to run, ping me on hangouts if you need me :( | 17:32 |
| frobware | ack | 17:32 |
| voidspace | frobware: just testing with a 1.25.2 and calling localDNSServers when address allocation off | 17:38 |
| voidspace | seeing if that works | 17:38 |
| voidspace | it's a really easy fix if it does... | 17:38 |
| frobware | voidspace, I was about to do something similar. | 17:38 |
| frobware | voidspace, after this call 'api.PrepareContainerInterfaceInfo' I was about to call localDNSServers and add. | 17:39 |
| voidspace | bootstrapping now | 17:39 |
| voidspace | yeah, that's what I've done | 17:39 |
| frobware | voidspace, is this what you were thinking? | 17:39 |
| frobware | ah | 17:39 |
| voidspace | yep | 17:39 |
| frobware | :) | 17:39 |
| frobware | voidspace, localDNSServers() is nicely contained so should be able to augment preparedInfo | 17:40 |
| voidspace | yep | 17:42 |
| mgz | cherylj: review please, http://reviews.vapour.ws/r/3435 (not actually review, just anti-stupidity stamp) | 18:03 |
| jam1 | frobware: voidspace: should we be getting dns servers from MAAS?, I'm thinking that's where we would have gotten it via DHCP in the past | 18:13 |
| === jam1 is now known as jam | ||
| jam | but looking at https://maas.ubuntu.com/docs/api.hmtl#node-interfaces doesn't seem to have the information. | 18:13 |
| jam | it does seem to be in /api/1.0/subnets/{subnet_id} has a "dns_servers" field | 18:15 |
| jam | and we do know what subnet a node_interface is on | 18:16 |
| frobware | jam1: proposing a fix - just waiting to see if the unit tests still pass | 18:22 |
| frobware | jam: ^^ | 18:22 |
| frobware | cherylj, mgz, voidspace, jam: http://reviews.vapour.ws/r/3436/ -- very limited testing, but I think independently tested by voidspace | 18:38 |
| frobware | cherylj, addresses bug 1528217 | 18:38 |
| mup | Bug #1528217: 1.25.2 doesn't set up DNS information with MAAS <blocker> <ci> <maas> <network> <regression> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1528217> | 18:38 |
| frobware | voidspace, you know... I'm not sure what I've proposed is a good fix. | 18:39 |
| frobware | voidspace, because it applies the hosts /etc/resolv.conf to all interfaces. | 18:40 |
| mgz | I need to read the previous pr again... | 18:40 |
| frobware | voidspace, the switch to static IP allocation may have been a step too far for this change. | 18:41 |
| natefinch | ericsnow: it makes me sad that the formatters return a []byte rather than writing to an io.Writer | 18:41 |
| mgz | frobware: something like this may be good for master, but for 1.25 if it's at all possible to restore the old dhcp behaviour when the feature flag isn't set I'd prefer that | 18:42 |
| frobware | voidspace, I'm wondering whether uniqueness could have been done with DHCP - as it previously was. | 18:42 |
| frobware | mgz, understood but given where I am physically that's going to take a longer and is a little impractical too. | 18:43 |
| mgz | wait, you're tim peake!? | 18:43 |
| mgz | (kidding, if we can't do this today we can't do it, that's fine) | 18:44 |
| frobware | mgz, not quite as far away but internet connectivity is a bit like wet string. | 18:44 |
| voidspace | frobware: uniqueness and address (dhcp) are orthogonal I think, so it should be possible | 18:48 |
| frobware | voidspace, agreed. uniqueness would have been a unique change. | 18:48 |
| voidspace | :-) | 18:49 |
| frobware | voidspace, I think my change does exactly what happens if address-allocation is enabled. | 18:49 |
| frobware | voidspace, w.r.t. to setting the same value per interface. | 18:49 |
| voidspace | right | 18:49 |
| voidspace | for DNS servers and DNS search only | 18:50 |
| voidspace | not doing the address allocation | 18:50 |
| voidspace | right EOY!! | 18:50 |
| voidspace | goodbye everyone | 18:50 |
| voidspace | see you on the other side | 18:50 |
| frobware | voidspace, I was concerned that we would now just give each interface the same DNS info - but that seems true for address-allocation anyway. | 18:50 |
| alexisb | mgz, frobware, the new behavior (ie going to static allocation) was needed for a bug fix? Or was needed for a maas update? | 18:55 |
| frobware | alexisb, mgz: I believe it made uniqueness easier. | 18:56 |
| mgz | well, I think I can see the addresses leaking bug from going over the previous merge | 18:56 |
| frobware | mgz, Is it easy to slot this change in to see if it does unblock testing? | 18:58 |
| frobware | mgz, or is that quite a big deal and a time sink? | 18:58 |
| mgz | frobware: sure | 18:58 |
| mgz | won't be quick, but can do it easily enough | 18:59 |
| frobware | mgz, I need to take a break. I'll check back in a bit. if there's no chatter I won't be around until tomorrow evening | 19:01 |
| alexisb | frobware, mgz we will want to make sure we have a summary to jam on where we have left today | 19:03 |
| alexisb | as he is around this week | 19:03 |
| alexisb | well what is left for the week :) | 19:03 |
| mgz | ah, that's good | 19:03 |
| mgz | okay, I'll send the proposed change through as a feature branch now | 19:16 |
| alexisb | mgz, thank you | 19:17 |
| mgz | build revision 3455 | 19:18 |
| perrito666 | mgz: still here? | 19:44 |
| alexisb | perrito666, his is but with many demands | 19:45 |
| alexisb | s/his/he | 19:45 |
| mgz | perrito666: wotcha | 19:46 |
| perrito666 | ok then, ignore me, I just was curious about the merge bot on goose commpletely ignoring me but ill let you people with that question hanging in the air whiile spend the next 35hs on a plane, cheers | 19:46 |
| natefinch | lol | 19:46 |
| natefinch | safe travels perrito666 | 19:46 |
| perrito666 | tx | 19:47 |
| mgz | perrito666: I presume you're not in go-goose | 19:49 |
| mgz | I can give it the magic letters | 19:49 |
| perrito666 | that might be a valid reason :) could any one on go-goose magic comment me? | 19:49 |
| perrito666 | :) | 19:49 |
| perrito666 | k, bye you all see you in... a lot of hours, cheers | 19:50 |
| alexisb | safe travels perrito666 | 19:52 |
| wwitzel3 | ericsnow, natefinch: I'm finally up and around moving if you need anything, don't know how reliable I will be, I got super sick over the weekend and I was out of it today. | 20:03 |
| ericsnow | wwitzel3: :( | 20:03 |
| natefinch | wwitzel3: ericsnow's parting gift ;) | 20:04 |
| wwitzel3 | natefinch: I was pretty much recovered from that and then bam | 20:05 |
| wwitzel3 | Jessa is really sick too, she tried to go to work today and got worse and had to some home early | 20:06 |
| natefinch | that sucks | 20:06 |
| === akhavr1 is now known as akhavr | ||
| thumper | that moment when you realise you haven't started IRC | 20:31 |
| natefinch | thumper: and then you realize it's the week of christmas and hardly anyone is online anyway | 20:39 |
| thumper | :) | 20:40 |
| alexisb | heya thumper welcome back (for 4 days) | 20:50 |
| thumper | except 24th is a bonus day off | 20:51 |
| thumper | and I've already finished monday | 20:51 |
| thumper | so down to two | 20:51 |
| natefinch | nice of them to give us my son's birthday off :) | 20:51 |
| alexisb | thumper, I think that just means you have to work twice as hard in the two days ;) | 20:53 |
| thumper | ha | 20:53 |
| * thumper wanders off to make coffee | 20:53 | |
| === akhavr1 is now known as akhavr | ||
| === akhavr1 is now known as akhavr | ||
| === akhavr1 is now known as akhavr | ||
| thumper | oh ffs | 22:23 |
| * thumper looks to merge master into dep-engine | 22:24 | |
| thumper | can we please stop releasing code? | 22:24 |
| cherylj | if only... | 22:26 |
| frobware | cherylj, mgz: around for 15 mins or so - did we draw any conclusions on the patch? | 22:26 |
| cherylj | frobware: can you do a hangout? | 22:26 |
| frobware | sure | 22:27 |
| cherylj | alexisb: can you join? | 22:28 |
| cherylj | https://plus.google.com/hangouts/_/canonical.com/cheryl-jennings?authuser=0 | 22:28 |
| alexisb | yes | 22:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!