/srv/irclogs.ubuntu.com/2015/12/21/#juju-dev.txt

mupBug #1528070 opened: fetching tools output shows template string <juju-core:New> <https://launchpad.net/bugs/1528070>00:49
mupBug #1528070 changed: fetching tools output shows template string <juju-core:New> <https://launchpad.net/bugs/1528070>00:52
mupBug #1528070 opened: fetching tools output shows template string <juju-core:New> <https://launchpad.net/bugs/1528070>00:58
mupBug #1528073 opened: Add the ability to force destroy a unit <juju-core:New> <https://launchpad.net/bugs/1528073>01:34
mupBug #1528073 changed: Add the ability to force destroy a unit <juju-core:New> <https://launchpad.net/bugs/1528073>01:37
mupBug #1528073 opened: Add the ability to force destroy a unit <juju-core:New> <https://launchpad.net/bugs/1528073>01:52
perrito666go home mup, you are drunk01:56
menn0perrito666: LOL02:19
menn0thumper: http://reviews.vapour.ws/r/3425/ please02:35
mupBug #1488576 opened: TestAddresserWorkerStopsWhenAddressDeallocationNotSupported fails on pp64el <ci> <intermittent-failure> <ppc64el> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1488576>03:04
perrito666anyone cares to review https://github.com/go-goose/goose/pull/17  ?03:05
mupBug #1488576 changed: TestAddresserWorkerStopsWhenAddressDeallocationNotSupported fails on pp64el <ci> <intermittent-failure> <ppc64el> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1488576>03:10
mupBug #1488576 opened: TestAddresserWorkerStopsWhenAddressDeallocationNotSupported fails on pp64el <ci> <intermittent-failure> <ppc64el> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1488576>03:13
menn0thumper: any time to look at that review?03:25
menn0wallyworld: ping?03:30
wallyworldyo03:30
menn0wallyworld: are you able to review something or are you flat out?03:30
wallyworldam busy, is it smallish? :-)03:31
wallyworldapiworkrs manifold?03:31
menn0wallyworld: yep.03:32
menn0wallyworld: it's not huge but not exactly small03:32
wallyworldok, will look real soon03:32
menn0thumper: thanks. I need to get this landed as it's my last day for the year and others need it to progress.03:33
thumpergah, looking now03:48
wallyworldmenn0: looks ok to my untrained eye, thanks for detailed covering letter on pr03:50
wallyworldmenn0: i assume live tested?03:50
menn0wallyworld: indeed it is03:51
wallyworldyay03:51
menn0wallyworld: thanks very much for the review. i'll leave you alone now :)03:51
wallyworldanytime, np03:52
wallyworldi liked the channel helper a lot03:52
thumpermenn0: done03:54
menn0wallyworld: \o/03:54
menn0thumper: \o/03:54
thumperjust some import ordering03:55
menn0thumper: I thought you were gone so I asked wallyworld to take a look03:55
* wallyworld likes to look03:55
thumpernot fully gone03:55
thumperalthough I am now03:55
thumperlaters03:55
blahdeblahwallyworld/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
blahdeblahI'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
wallyworldblahdeblah: juju can be deployed today with restricted outside access. we allow http-, ftp- and apt- proxies to be set04:14
blahdeblahI'm more worried about inbound than outbound.04:14
blahdeblahThe 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
wallyworldthe 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 easier04:15
wallyworldblahdeblah: 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 team04:16
wallyworldthey'd be able to give you a much better answer than me04:17
blahdeblahwallyworld: cool - thanks04:18
blahdeblahwallyworld: 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
blahdeblahThe 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
blahdeblahEssentially, 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
wallyworldblahdeblah: 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 mongo04:25
blahdeblahbut when you bootstrap, mongodb is still listening on all interfaces...04:26
wallyworldcould be, that bit i'm not sure of04:26
blahdeblahI can confirm that it does :-)04:26
wallyworldwe just start mongo as a normal systemd service, not sure exactly what the confog is04:26
wallyworldwe should change mongo startup then maybe04:27
wallyworldit's password protected but that doesn't stop DOS i guess04:27
blahdeblahyeah; and doesn't guard against any potential mongodb zero-days04:27
blahdeblahHere's a vanilla bootstrapped machine in Canonistack: https://pastebin.canonical.com/146540/04:28
blahdeblahSo we've got 4 services listening by default: ssh (should be OK by default, since there's no password), rsyslog, jujud & mongodb.04:29
wallyworldblahdeblah: feel like raising a bug?04:30
blahdeblahwallyworld: There might not be any bug; it might be just fine and I'm just not aware of the options available.04:31
wallyworldblahdeblah: your concerns seem reasonable to me, but check with dimiter/andy maybe and see what they say04:31
blahdeblahI 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
perrito666does 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 ignored05:01
mupBug #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
menn0blahdeblah, 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+108:52
blahdeblahmenn0: 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
menn0blahdeblah, 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
wallyworldyup08:54
menn0anyone able to take a look at this one? http://reviews.vapour.ws/r/3428/08:55
menn0it's an easy one08:55
blahdeblahwallyworld, 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
menn0blahdeblah: sure, but it would be nice to make the default situation more secure08:56
blahdeblahindeed08:56
blahdeblahFWIW, 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
blahdeblahNot sure if this is a Canonistack thing though - will test again next chance I get08:58
menn0blahdeblah: were you testing against a state server? rsyslog and mongodb definitely won't be there on non-state server Juju managed machines.09:02
blahdeblahmenn0: Yes - just bootstrapped a fresh Canonistack instance and did nothing other than login and check what was listening.09:03
menn0blahdeblah: cool, just checking09:03
blahdeblahYeah, I was surprised it didn't even respond on the port...09:03
perrito666does anyone know if mgz or sinzui are coming around today?09:10
=== bruno1 is now known as BrunoR
=== Makyo is now known as Guest60455
voidspacefrobware: hangout issues10:02
voidspacefrobware: currently I can't get to the stdup10:02
=== _stowa_ is now known as _stowa
voidspacefrobware: restarting firefox doesn't help10:09
voidspacewill try chrome10:09
voidspacefrobware: in chrome I have no working video and possibly not audio either *sigh*10:10
voidspacelooks like you're not there yet anyway10:10
voidspaceah, now firefox works10:11
voidspacea bit of manual url mangling does the trick10:11
voidspacefrobware: ping me if you're around10:11
voidspacejam1: thanks12:04
mgzcherylj: thanls for filing new bug, was getting confusing tracking in the other one13:25
mupBug #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
cheryljmgz: yeah, I should've done it sooner13:27
cheryljbut I guess I was lazy13:27
mupBug #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
mupBug #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
cheryljvoidspace: did you have any questions about this CI / MAAS issue?  Not sure how much of a handoff  you were given.13:52
voidspacecherylj: that email I replied to was the handoff (of sorts), and I'm only in for today :-)13:53
voidspacecherylj: do you have an easy repro?13:53
voidspacecherylj: I'm just updating my vmaas - you said you could repro13:53
voidspaceI assume deploy a container...13:53
voidspaceI can see from the other bug it's a nameserver issue13:54
voidspaceI didn't *think* we set nameservers before (unless they were already in e/n/i) but I may be mistaken13:54
voidspaceeasy to check though13:54
cheryljvoidspace: yes, just bootstrap a maas with 1.25.2 (without the address-allocation feature flag)13:54
cheryljand deploy a container13:54
voidspacecherylj: thanks13:54
cheryljvoidspace: we didn't before, but we didn't manually modify /e/n/i before for containers.13:55
voidspacebut now we modify /e/n/i even without address-allocation13:55
voidspaceright13:55
cheryljvoidspace: 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
mupBug #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
voidspacecherylj: yeah, I'll take a look13:56
voidspaceit could be an easy fix13:56
cheryljvoidspace: I saw that for the host node, the dns information is written out to /e/n/i (I think by us?)13:56
mgzvoidspace: poke me if you want to test on finfolk directly as well13:56
voidspacemgz: thanks13:56
cheryljmaybe look there for how we get it?13:56
voidspacecherylj: I don't *think* we *add* dns information13:56
voidspacecherylj: again, I maybe mistaken - that code has changed several times recently13:57
cheryljvoidspace: I just thought we might as it doesn't source /etc/network/interfaces.d13:58
cheryljbut I am not a networking expert by any means :)13:58
voidspacecherylj: we modify /e/n/i - but only transform the existing to add and use bridges13:59
voidspacecherylj: so the lack of sourcing interfaces.d is what we get from maas/curtin13:59
cheryljvoidspace: ah, ok13:59
voidspacecherylj: by 1.25.2 do you mean 1.25 tip? there's no 1.25.2 tag14:00
cheryljvoidspace: yes14:00
voidspacetnx14:00
mupBug #1528259 opened: undertakerSuite.TestAPICalls nil deref panic <ci> <i386> <panic> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1528259>15:48
mupBug #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
frobwarevoidspace, ping16:11
voidspacefrobware: pong16:14
voidspacefrobware: grabbing coffee brb16:14
frobwarevoidspace, 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
voidspacefrobware: cool, thanks16:15
voidspacefrobware: I will have some questions for you16:15
voidspacefrobware: I can confirm the issue - bootstrap with 1.25 tip, deploy a container, ssh to that container and hostnames can't be resolved16:16
frobwarevoidspace, right; and my poking around with PrepareContainerInterfaceInfo shows that no  DNS info is returned.16:16
frobwarevoidspace, though that is also true for MAAS 1.816:17
voidspacefrobware: but we wouldn't expect to be setting dns info if there wasn't any in the original /e/n/i I don't think16:17
voidspacewe only (used to) set dns info if it was in the original16:17
voidspacebut if it's there in the original we should be setting it16:17
frobwarevoidspace, the original being on the host machine?16:17
voidspaceyep16:18
voidspaceprior to bootstrap16:18
voidspacereally going for coffee16:18
frobwarevoidspace, the original for me has dns-nameservers and dns-search entries16:19
voidspacefrobware: ah right, so that's the bug16:20
voidspacefrobware: well, the cause16:20
frobwarevoidspace, because it has entries?16:20
voidspacefrobware: no, that we're not preserving16:21
frobwarevoidspace, 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
voidspacefrobware: well, it's apiserver/provisioner/provisioner.go:prepareOrGetContainerInterfaceInfo16:35
voidspacefrobware: with different paths depending on if address-allocation is on or not16:36
voidspacefrobware: without address allocation we just ask the provider for the inferface info16:36
frobwarevoidspace, so this still works OK with address allocation enabled16:39
voidspacefrobware: for the case when address-allocation is off, what specifically changed about /e/n/i rendering between 1.25.1 and tip?16:41
frobwarevoidspace, the bridge script changed, IIRC.16:42
voidspacefrobware: I'm bootstrapping with 1.25.1 to see the difference in rendered output16:54
frobwarevoidspace, doesn't dns info come from parsing /etc/resolv.conf, no /e/n/i?16:55
frobwarevoidspace, lxc-broker:localDNSServers()16:55
voidspaceoh, we have that code too16:55
voidspaceI'd forgotten about that16:56
voidspacebut how would *that* change between the two...16:56
voidspace(1.25.1 and 1.25.2)16:56
frobwarevoidspace, precisely16:59
frobwarevoidspace, 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
frobwarevoidspace, so configureContainerNetwork is only called when address-allocation is enabled... and in configure...Network() we only call localDNSServers()17:02
voidspacefrobware: we only call that (localDNSServers) if address allocation is on17:02
voidspacenatch17:02
frobwarevoidspace, heh!17:02
frobwarevoidspace, so where did the info come from...?17:02
voidspacefrobware: soooo... between 1.25.1 and tip the rendered /e/n/i for the host is identical17:03
frobwarevoidspace, not terribly surprised. but the confirmation is worthy.17:04
voidspacefrobware: so the base for the interface info comes from the maas provider NetworkInterfaces call17:04
voidspacefrobware: when the lxc container is deployed I get to see the container config17:04
voidspacefrobware: and it looks like  that doesn't populate DNSServers and DNSSearch fields on the network.InterfaceInfo17:07
voidspaceso it's not coming from there (this is 1.25.1 I'm looking at)17:07
frobwarevoidspace, are you looking at func (environ *maasEnviron) NetworkInterfaces(instId instance.Id) ([]network.InterfaceInfo, error)?17:07
voidspaceyep17:07
voidspacefrobware: hmmm... prepareOrGetContainerInterfaceInfo is very different between 1.25.1 and tip I think17:10
frobwarevoidspace, in lxc-broker?17:11
voidspacefrobware: apiserver/provisioner/provisioner.go17:12
voidspacefrobware: in 1.25.1 containers are provisioned to use dhcp from prepareOrGetContainerInterfaceInfo (it looks like)17:14
voidspacefrobware: and indeed that is the case17:15
frobwarevoidspace, 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
voidspacefrobware: in 1.25.2 we render a manual interface17:16
frobwarevoidspace, so is the root cause here the switch to dhcp17:16
voidspacefrobware: switch *from* dhcp17:16
frobwarevoidspace, switch from...17:16
voidspacefrobware: why was that switch made?17:16
voidspaceit seems like a big change from 1.25.1 to 1.25.217:16
voidspacefrobware: I've put this in the bug17:19
voidspacefrobware: I think it needs dimiter's comments as it was probably him who changed this17:19
frobwarecherylj, ping17:24
=== tvansteenburgh1 is now known as tvansteenburgh
cheryljwhat up frobware ?17:28
voidspacecherylj: bug 1527217 updated17:29
mupBug #1527217: RethinkDB installation only works in Ubuntu <DragonFlow:New> <https://launchpad.net/bugs/1527217>17:29
frobwarecherylj, 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
voidspacecherylj: dammit, bug 152821717:30
mupBug #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
voidspacecherylj: in 1.25.1 containers used dhcp when address allocation was off17:30
cheryljfrobware: this was a consistent failure in 1.25.1  (non-uniqueness)17:31
cheryljand something that broke.... autopilot maybe?17:31
frobwarecherylj, down to options 2 and 3 now.17:31
cheryljyeah option 1 wasn't an option17:31
cheryljI have to run, ping me on hangouts if you need me :(17:32
frobwareack17:32
voidspacefrobware: just testing with a 1.25.2 and calling localDNSServers when address allocation off17:38
voidspaceseeing if that works17:38
voidspaceit's a really easy fix if it does...17:38
frobwarevoidspace, I was about to do something similar.17:38
frobwarevoidspace, after this call 'api.PrepareContainerInterfaceInfo' I was about to call localDNSServers and add.17:39
voidspacebootstrapping now17:39
voidspaceyeah, that's what I've done17:39
frobwarevoidspace, is this what you were thinking?17:39
frobwareah17:39
voidspaceyep17:39
frobware:)17:39
frobwarevoidspace, localDNSServers() is nicely contained so should be able to augment preparedInfo17:40
voidspaceyep17:42
mgzcherylj: review please, http://reviews.vapour.ws/r/3435 (not actually review, just anti-stupidity stamp)18:03
jam1frobware: voidspace: should we be getting dns servers from MAAS?, I'm thinking that's where we would have gotten it via DHCP in the past18:13
=== jam1 is now known as jam
jambut looking at https://maas.ubuntu.com/docs/api.hmtl#node-interfaces doesn't seem to have the information.18:13
jamit does seem to be in /api/1.0/subnets/{subnet_id} has a "dns_servers" field18:15
jamand we do know what subnet a node_interface is on18:16
frobwarejam1: proposing a fix - just waiting to see if the unit tests still pass18:22
frobwarejam: ^^18:22
frobwarecherylj, mgz, voidspace, jam: http://reviews.vapour.ws/r/3436/ -- very limited testing, but I think independently tested by voidspace18:38
frobwarecherylj, addresses bug 152821718:38
mupBug #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
frobwarevoidspace, you know... I'm not sure what I've proposed is a good fix.18:39
frobwarevoidspace, because it applies the hosts /etc/resolv.conf to all interfaces.18:40
mgzI need to read the previous pr again...18:40
frobwarevoidspace, the switch to static IP allocation may have been a step too far for this change.18:41
natefinchericsnow: it makes me sad that the formatters return a []byte rather than writing to an io.Writer18:41
mgzfrobware: 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 that18:42
frobwarevoidspace, I'm wondering whether uniqueness could have been done with DHCP - as it previously was.18:42
frobwaremgz, understood but given where I am physically that's going to take a longer and is a little impractical too.18:43
mgzwait, 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
frobwaremgz, not quite as far away but internet connectivity is a bit like wet string.18:44
voidspacefrobware: uniqueness and address (dhcp) are orthogonal I think, so it should be possible18:48
frobwarevoidspace, agreed. uniqueness would have been a unique change.18:48
voidspace:-)18:49
frobwarevoidspace, I think my change does exactly what happens if address-allocation is enabled.18:49
frobwarevoidspace, w.r.t. to setting the same value per interface.18:49
voidspaceright18:49
voidspacefor DNS servers and DNS search only18:50
voidspacenot doing the address allocation18:50
voidspaceright EOY!!18:50
voidspacegoodbye everyone18:50
voidspacesee you on the other side18:50
frobwarevoidspace, 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
alexisbmgz, frobware, the new behavior (ie going to static allocation) was needed for a bug fix? Or was needed for a maas update?18:55
frobwarealexisb, mgz: I believe it made uniqueness easier.18:56
mgzwell, I think I can see the addresses leaking bug from going over the previous merge18:56
frobwaremgz, Is it easy to slot this change in to see if it does unblock testing?18:58
frobwaremgz, or is that quite a big deal and a time sink?18:58
mgzfrobware: sure18:58
mgzwon't be quick, but can do it easily enough18:59
frobwaremgz, 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 evening19:01
alexisbfrobware, mgz we will want to make sure we have  a summary to jam on where we have left today19:03
alexisbas he is around this week19:03
alexisbwell what is left for the week :)19:03
mgzah, that's good19:03
mgzokay, I'll send the proposed change through as a feature branch now19:16
alexisbmgz, thank you19:17
mgzbuild revision 345519:18
perrito666mgz: still here?19:44
alexisbperrito666, his is but with many demands19:45
alexisbs/his/he19:45
mgzperrito666: wotcha19:46
perrito666ok 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, cheers19:46
natefinchlol19:46
natefinchsafe travels perrito66619:46
perrito666tx19:47
mgzperrito666: I presume you're not in go-goose19:49
mgzI can give it the magic letters19:49
perrito666that might be a valid reason :) could any one on go-goose magic comment me?19:49
perrito666:)19:49
perrito666k, bye you all see you in... a lot of hours, cheers19:50
alexisbsafe travels perrito66619:52
wwitzel3ericsnow, 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
ericsnowwwitzel3: :(20:03
natefinchwwitzel3: ericsnow's parting gift ;)20:04
wwitzel3natefinch: I was pretty much recovered from that and then bam20:05
wwitzel3Jessa is really sick too, she tried to go to work today and got worse and had to some home early20:06
natefinchthat sucks20:06
=== akhavr1 is now known as akhavr
thumperthat moment when you realise you haven't started IRC20:31
natefinchthumper: and then you realize it's the week of christmas and hardly anyone is online anyway20:39
thumper:)20:40
alexisbheya thumper welcome back (for 4 days)20:50
thumperexcept 24th is a bonus day off20:51
thumperand I've already finished monday20:51
thumperso down to two20:51
natefinchnice of them to give us my son's birthday off :)20:51
alexisbthumper, I think that just means you have to work twice as hard in the two days ;)20:53
thumperha20:53
* thumper wanders off to make coffee20:53
=== akhavr1 is now known as akhavr
=== akhavr1 is now known as akhavr
=== akhavr1 is now known as akhavr
thumperoh ffs22:23
* thumper looks to merge master into dep-engine22:24
thumpercan we please stop releasing code?22:24
cheryljif only...22:26
frobwarecherylj, mgz: around for 15 mins or so - did we draw any conclusions on the patch?22:26
cheryljfrobware: can you do a hangout?22:26
frobwaresure22:27
cheryljalexisb: can you join?22:28
cheryljhttps://plus.google.com/hangouts/_/canonical.com/cheryl-jennings?authuser=022:28
alexisbyes22:31

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