#juju-dev 2013-12-23
<axw> hey wallyworld_, did you see my message on Friday about authorized_keys?
<wallyworld_> um
<axw> about modifying for the ubuntu user
<wallyworld_> if i did i forgot
<wallyworld_> i don't think i saw
<axw> wallyworld_: maybe I'm just missing something, but I don't see where the ubuntu user is specified when the worker modifies authorized_keys
<wallyworld_> it's not
<axw> shouldn't it be? that's what we log in as
<wallyworld_> the current auth keys file with the key from bootstrap doesn't specify the ubuntu user does it?
<wallyworld_> so i'm just adding additional keys in the same way
<axw> wallyworld_: I'm pretty sure cloud-init will put it in the ubuntu user's one
<axw> well, it must, since we log in as that during bootstrap
<wallyworld_> i assumed that the auth keys would be added to /home/ubuntu/.ssh/...
<wallyworld_> i guess it depends what ~ resolves to
<wallyworld_> i'm sure i checked though
<wallyworld_> and the ubuntu user auth keys file was the one that got updated
<wallyworld_> but now i'm doubting myself
<axw> wallyworld_: I didn't see it getting updated, but I did see /root/.ssh/authorized_keys had some updated keys in it
<wallyworld_> hmmm. maybe i didn't check then. but i thought i did
<wallyworld_> i'll do a fix if necessary
<axw> I'll have another look in a bit
<wallyworld_> i could have sworn i checked etc but maybe not
<wallyworld_> i guess if the processes are running as root, the ~ will not resolve to ubuntu
<axw> right
<wallyworld_> too bad that they are running as root :-(
<axw> I was wondering whether we should be using something less generic than "ubuntu" now
<wallyworld_> i sorta assumed perhaps that we would not do something that silly :-(
<axw> like create a "juju" user at init time
<axw> then manual provisioning would be less of a special case regarding key management
<wallyworld_> that makes sense. get ready for a whole lotta bikeshedding though :-)
<axw> :~(
<wallyworld_> well maybe not, there's always a first time :-)
<wallyworld_> so cloud init does explicitly rely on a specific user being set (default ubuntu)
<wallyworld_> so looks like i need to do a fix
<axw> okey dokey
<axw> wallyworld_: will things break horribly if the ubuntu user doesn't exist?
<axw> (manual provisioning doesn't yet create it)
<wallyworld_> i don't *think* so, but am not sure
<axw> no worries, I can test later
<wallyworld_> axw: i fixed the ssh auth keys user issue. turned out to be a bit of a bitch cause of the way our tests override ~. if you get a chance, could you take a look? https://codereview.appspot.com/40650049
<axw> wallyworld_: cool, thanks, will have a look now
<wallyworld_> ta
<wallyworld_> i tested live on hp cloud
<axw> wallyworld_: why not use osenv.Home() on Windows too?
<wallyworld_> axw: does windows support $HOME? i wasn't sure and didn't think it did
<axw> wallyworld_: just had a look, osenv.Home() does different things for Windows
<axw> not $HOME, but $HOMEDRIVE
<axw> or %HOMEDRIVE% at any rate :)
<wallyworld_> but will that return the user home dir
<wallyworld_> or the drive letter?
<axw> umm
<axw> wallyworld_: it's %HOMEDRIVE%%HOMEPATH%
<axw> with a slash in between
<wallyworld_> either way, our tests won't work on windows as is
<axw> true
<wallyworld_> so i think a todo is ok and we can fix the tests wheneever we want to run on windows
<axw> fair enough
<wallyworld_> our tests also just assume all paths with ~ are of the form ~/foo
<wallyworld_> axw: thanks for looking, i'll fix the little issues
<axw> wallyworld_: nps, thanks for fixing
<wallyworld_> including nuking bob :-)
<axw> :)
<wallyworld_> axw: that's merged now
<axw> wallyworld_: thanks!
<axw> I'll test it with manual later
<wallyworld_> np, thanks for letting me know about the issue
<wallyworld_> i'm off for a bit to take the dog for a bath. he rolled around in some shit at the park yesterday and he stinks :-(
<axw> grr, my wireless keeps dying
<wallyworld_> try another channel?
<axw> well it recovers if I restart networking, so I don't think it'd be interference
<natefinch> fwereade, are you around?
#juju-dev 2013-12-24
<wallyworld_> axw: i'm taking an early mark today, got stuff to do before xmas. have a good xmas and new year etc :-)
<axw> wallyworld_: thanks :)  you too, merry christmas!
#juju-dev 2014-12-22
<wallyworld> jam: we'll wait for fwereade to get back home before we start the meeting. i'll wait around until he pings
<jam> wallyworld: k
<wallyworld> jam: looks like fwereade isn't going to make it, did you want to discuss anyway?
#juju-dev 2014-12-23
<wallyworld> jam: fwereade: are you guys ok for a juju status catchup?
<jam> wallyworld: give me about 5 min, then yes
<wallyworld> sure, ok
<perrito666> hi
#juju-dev 2015-12-21
<mup> Bug #1528070 opened: fetching tools output shows template string <juju-core:New> <https://launchpad.net/bugs/1528070>
<mup> Bug #1528070 changed: fetching tools output shows template string <juju-core:New> <https://launchpad.net/bugs/1528070>
<mup> Bug #1528070 opened: fetching tools output shows template string <juju-core:New> <https://launchpad.net/bugs/1528070>
<mup> Bug #1528073 opened: Add the ability to force destroy a unit <juju-core:New> <https://launchpad.net/bugs/1528073>
<mup> Bug #1528073 changed: Add the ability to force destroy a unit <juju-core:New> <https://launchpad.net/bugs/1528073>
<mup> Bug #1528073 opened: Add the ability to force destroy a unit <juju-core:New> <https://launchpad.net/bugs/1528073>
<perrito666> go home mup, you are drunk
<menn0> perrito666: LOL
<menn0> thumper: http://reviews.vapour.ws/r/3425/ please
<mup> Bug #1488576 opened: TestAddresserWorkerStopsWhenAddressDeallocationNotSupported fails on pp64el <ci> <intermittent-failure> <ppc64el> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1488576>
<perrito666> anyone cares to review https://github.com/go-goose/goose/pull/17  ?
<mup> Bug #1488576 changed: TestAddresserWorkerStopsWhenAddressDeallocationNotSupported fails on pp64el <ci> <intermittent-failure> <ppc64el> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1488576>
<mup> Bug #1488576 opened: TestAddresserWorkerStopsWhenAddressDeallocationNotSupported fails on pp64el <ci> <intermittent-failure> <ppc64el> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1488576>
<menn0> thumper: any time to look at that review?
<menn0> wallyworld: ping?
<wallyworld> yo
<menn0> wallyworld: are you able to review something or are you flat out?
<wallyworld> am busy, is it smallish? :-)
<wallyworld> apiworkrs manifold?
<menn0> wallyworld: yep.
<menn0> wallyworld: it's not huge but not exactly small
<wallyworld> ok, will look real soon
<menn0> thumper: thanks. I need to get this landed as it's my last day for the year and others need it to progress.
<thumper> gah, looking now
<wallyworld> menn0: looks ok to my untrained eye, thanks for detailed covering letter on pr
<wallyworld> menn0: i assume live tested?
<menn0> wallyworld: indeed it is
<wallyworld> yay
<menn0> wallyworld: thanks very much for the review. i'll leave you alone now :)
<wallyworld> anytime, np
<wallyworld> i liked the channel helper a lot
<thumper> menn0: done
<menn0> wallyworld: \o/
<menn0> thumper: \o/
<thumper> just some import ordering
<menn0> thumper: I thought you were gone so I asked wallyworld to take a look
 * wallyworld likes to look
<thumper> not fully gone
<thumper> although I am now
<thumper> laters
<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?
<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.
<wallyworld> blahdeblah: juju can be deployed today with restricted outside access. we allow http-, ftp- and apt- proxies to be set
<blahdeblah> I'm more worried about inbound than outbound.
<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.
<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
<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
<wallyworld> they'd be able to give you a much better answer than me
<blahdeblah> wallyworld: cool - thanks
<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?
<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.
<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.
<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
<blahdeblah> but when you bootstrap, mongodb is still listening on all interfaces...
<wallyworld> could be, that bit i'm not sure of
<blahdeblah> I can confirm that it does :-)
<wallyworld> we just start mongo as a normal systemd service, not sure exactly what the confog is
<wallyworld> we should change mongo startup then maybe
<wallyworld> it's password protected but that doesn't stop DOS i guess
<blahdeblah> yeah; and doesn't guard against any potential mongodb zero-days
<blahdeblah> Here's a vanilla bootstrapped machine in Canonistack: https://pastebin.canonical.com/146540/
<blahdeblah> So we've got 4 services listening by default: ssh (should be OK by default, since there's no password), rsyslog, jujud & mongodb.
<wallyworld> blahdeblah: feel like raising a bug?
<blahdeblah> wallyworld: There might not be any bug; it might be just fine and I'm just not aware of the options available.
<wallyworld> blahdeblah: your concerns seem reasonable to me, but check with dimiter/andy maybe and see what they say
<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?
<blahdeblah> (And by add them, I mean provision through standard MAAS mechanisms.)
<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
<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>
<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.
<wallyworld> +1
<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?
<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.
<wallyworld> yup
<menn0> anyone able to take a look at this one? http://reviews.vapour.ws/r/3428/
<menn0> it's an easy one
<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.
<menn0> blahdeblah: sure, but it would be nice to make the default situation more secure
<blahdeblah> indeed
<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.
<blahdeblah> (even when I specifically targeted the right ports)
<blahdeblah> Not sure if this is a Canonistack thing though - will test again next chance I get
<menn0> blahdeblah: were you testing against a state server? rsyslog and mongodb definitely won't be there on non-state server Juju managed machines.
<blahdeblah> menn0: Yes - just bootstrapped a fresh Canonistack instance and did nothing other than login and check what was listening.
<menn0> blahdeblah: cool, just checking
<blahdeblah> Yeah, I was surprised it didn't even respond on the port...
<perrito666> does anyone know if mgz or sinzui are coming around today?
<voidspace> frobware: hangout issues
<voidspace> frobware: currently I can't get to the stdup
<voidspace> frobware: restarting firefox doesn't help
<voidspace> will try chrome
<voidspace> frobware: in chrome I have no working video and possibly not audio either *sigh*
<voidspace> looks like you're not there yet anyway
<voidspace> ah, now firefox works
<voidspace> a bit of manual url mangling does the trick
<voidspace> frobware: ping me if you're around
<voidspace> jam1: thanks
<mgz> cherylj: thanls for filing new bug, was getting confusing tracking in the other one
<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>
<cherylj> mgz: yeah, I should've done it sooner
<cherylj> but I guess I was lazy
<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>
<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>
<cherylj> voidspace: did you have any questions about this CI / MAAS issue?  Not sure how much of a handoff  you were given.
<voidspace> cherylj: that email I replied to was the handoff (of sorts), and I'm only in for today :-)
<voidspace> cherylj: do you have an easy repro?
<voidspace> cherylj: I'm just updating my vmaas - you said you could repro
<voidspace> I assume deploy a container...
<voidspace> I can see from the other bug it's a nameserver issue
<voidspace> I didn't *think* we set nameservers before (unless they were already in e/n/i) but I may be mistaken
<voidspace> easy to check though
<cherylj> voidspace: yes, just bootstrap a maas with 1.25.2 (without the address-allocation feature flag)
<cherylj> and deploy a container
<voidspace> cherylj: thanks
<cherylj> voidspace: we didn't before, but we didn't manually modify /e/n/i before for containers.
<voidspace> but now we modify /e/n/i even without address-allocation
<voidspace> right
<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.
<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>
<voidspace> cherylj: yeah, I'll take a look
<voidspace> it could be an easy fix
<cherylj> voidspace: I saw that for the host node, the dns information is written out to /e/n/i (I think by us?)
<mgz> voidspace: poke me if you want to test on finfolk directly as well
<voidspace> mgz: thanks
<cherylj> maybe look there for how we get it?
<voidspace> cherylj: I don't *think* we *add* dns information
<voidspace> cherylj: again, I maybe mistaken - that code has changed several times recently
<cherylj> voidspace: I just thought we might as it doesn't source /etc/network/interfaces.d
<cherylj> but I am not a networking expert by any means :)
<voidspace> cherylj: we modify /e/n/i - but only transform the existing to add and use bridges
<voidspace> cherylj: so the lack of sourcing interfaces.d is what we get from maas/curtin
<cherylj> voidspace: ah, ok
<voidspace> cherylj: by 1.25.2 do you mean 1.25 tip? there's no 1.25.2 tag
<cherylj> voidspace: yes
<voidspace> tnx
<mup> Bug #1528259 opened: undertakerSuite.TestAPICalls nil deref panic <ci> <i386> <panic> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1528259>
<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>
<frobware> voidspace, ping
<voidspace> frobware: pong
<voidspace> frobware: grabbing coffee brb
<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.
<voidspace> frobware: cool, thanks
<voidspace> frobware: I will have some questions for you
<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
<frobware> voidspace, right; and my poking around with PrepareContainerInterfaceInfo shows that no  DNS info is returned.
<frobware> voidspace, though that is also true for MAAS 1.8
<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
<voidspace> we only (used to) set dns info if it was in the original
<voidspace> but if it's there in the original we should be setting it
<frobware> voidspace, the original being on the host machine?
<voidspace> yep
<voidspace> prior to bootstrap
<voidspace> really going for coffee
<frobware> voidspace, the original for me has dns-nameservers and dns-search entries
<voidspace> frobware: ah right, so that's the bug
<voidspace> frobware: well, the cause
<frobware> voidspace, because it has entries?
<voidspace> frobware: no, that we're not preserving
<frobware> voidspace, so this is where I got to... when the provisioner makes the facade call where is that info being retrieved from?
 * frobware notes that his IRC client says 1m+ lag...
<voidspace> frobware: well, it's apiserver/provisioner/provisioner.go:prepareOrGetContainerInterfaceInfo
<voidspace> frobware: with different paths depending on if address-allocation is on or not
<voidspace> frobware: without address allocation we just ask the provider for the inferface info
<frobware> voidspace, so this still works OK with address allocation enabled
<voidspace> frobware: for the case when address-allocation is off, what specifically changed about /e/n/i rendering between 1.25.1 and tip?
<frobware> voidspace, the bridge script changed, IIRC.
<voidspace> frobware: I'm bootstrapping with 1.25.1 to see the difference in rendered output
<frobware> voidspace, doesn't dns info come from parsing /etc/resolv.conf, no /e/n/i?
<frobware> voidspace, lxc-broker:localDNSServers()
<voidspace> oh, we have that code too
<voidspace> I'd forgotten about that
<voidspace> but how would *that* change between the two...
<voidspace> (1.25.1 and 1.25.2)
<frobware> voidspace, precisely
<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?
<frobware> voidspace, so configureContainerNetwork is only called when address-allocation is enabled... and in configure...Network() we only call localDNSServers()
<voidspace> frobware: we only call that (localDNSServers) if address allocation is on
<voidspace> natch
<frobware> voidspace, heh!
<frobware> voidspace, so where did the info come from...?
<voidspace> frobware: soooo... between 1.25.1 and tip the rendered /e/n/i for the host is identical
<frobware> voidspace, not terribly surprised. but the confirmation is worthy.
<voidspace> frobware: so the base for the interface info comes from the maas provider NetworkInterfaces call
<voidspace> frobware: when the lxc container is deployed I get to see the container config
<voidspace> frobware: and it looks like  that doesn't populate DNSServers and DNSSearch fields on the network.InterfaceInfo
<voidspace> so it's not coming from there (this is 1.25.1 I'm looking at)
<frobware> voidspace, are you looking at func (environ *maasEnviron) NetworkInterfaces(instId instance.Id) ([]network.InterfaceInfo, error)?
<voidspace> yep
<voidspace> frobware: hmmm... prepareOrGetContainerInterfaceInfo is very different between 1.25.1 and tip I think
<frobware> voidspace, in lxc-broker?
<voidspace> frobware: apiserver/provisioner/provisioner.go
<voidspace> frobware: in 1.25.1 containers are provisioned to use dhcp from prepareOrGetContainerInterfaceInfo (it looks like)
<voidspace> frobware: and indeed that is the case
<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)
<voidspace> frobware: in 1.25.2 we render a manual interface
<frobware> voidspace, so is the root cause here the switch to dhcp
<voidspace> frobware: switch *from* dhcp
<frobware> voidspace, switch from...
<voidspace> frobware: why was that switch made?
<voidspace> it seems like a big change from 1.25.1 to 1.25.2
<voidspace> frobware: I've put this in the bug
<voidspace> frobware: I think it needs dimiter's comments as it was probably him who changed this
<frobware> cherylj, ping
<cherylj> what up frobware ?
<voidspace> cherylj: bug 1527217 updated
<mup> Bug #1527217: RethinkDB installation only works in Ubuntu <DragonFlow:New> <https://launchpad.net/bugs/1527217>
<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.
<voidspace> cherylj: dammit, bug 1528217
<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>
<voidspace> cherylj: in 1.25.1 containers used dhcp when address allocation was off
<cherylj> frobware: this was a consistent failure in 1.25.1  (non-uniqueness)
<cherylj> and something that broke.... autopilot maybe?
<frobware> cherylj, down to options 2 and 3 now.
<cherylj> yeah option 1 wasn't an option
<cherylj> I have to run, ping me on hangouts if you need me :(
<frobware> ack
<voidspace> frobware: just testing with a 1.25.2 and calling localDNSServers when address allocation off
<voidspace> seeing if that works
<voidspace> it's a really easy fix if it does...
<frobware> voidspace, I was about to do something similar.
<frobware> voidspace, after this call 'api.PrepareContainerInterfaceInfo' I was about to call localDNSServers and add.
<voidspace> bootstrapping now
<voidspace> yeah, that's what I've done
<frobware> voidspace, is this what you were thinking?
<frobware> ah
<voidspace> yep
<frobware> :)
<frobware> voidspace, localDNSServers() is nicely contained so should be able to augment preparedInfo
<voidspace> yep
<mgz> cherylj: review please, http://reviews.vapour.ws/r/3435 (not actually review, just anti-stupidity stamp)
<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
<jam> but looking at https://maas.ubuntu.com/docs/api.hmtl#node-interfaces doesn't seem to have the information.
<jam> it does seem to be in /api/1.0/subnets/{subnet_id} has a "dns_servers" field
<jam> and we do know what subnet a node_interface is on
<frobware> jam1: proposing a fix - just waiting to see if the unit tests still pass
<frobware> jam: ^^
<frobware> cherylj, mgz, voidspace, jam: http://reviews.vapour.ws/r/3436/ -- very limited testing, but I think independently tested by voidspace
<frobware> cherylj, addresses bug 1528217
<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>
<frobware> voidspace, you know... I'm not sure what I've proposed is a good fix.
<frobware> voidspace, because it applies the hosts /etc/resolv.conf to all interfaces.
<mgz> I need to read the previous pr again...
<frobware> voidspace, the switch to static IP allocation may have been a step too far for this change.
<natefinch> ericsnow: it makes me sad that the formatters return a []byte rather than writing to an io.Writer
<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
<frobware> voidspace, I'm wondering whether uniqueness could have been done with DHCP - as it previously was.
<frobware> mgz, understood but given where I am physically that's going to take a longer and is a little impractical too.
<mgz> wait, you're tim peake!?
<mgz> (kidding, if we can't do this today we can't do it, that's fine)
<frobware> mgz, not quite as far away but internet connectivity is a bit like wet string.
<voidspace> frobware: uniqueness and address (dhcp) are orthogonal I think, so it should be possible
<frobware> voidspace, agreed. uniqueness would have been a unique change.
<voidspace> :-)
<frobware> voidspace, I think my change does exactly what happens if address-allocation is enabled.
<frobware> voidspace, w.r.t. to setting the same value per interface.
<voidspace> right
<voidspace> for DNS servers and DNS search only
<voidspace> not doing the address allocation
<voidspace> right EOY!!
<voidspace> goodbye everyone
<voidspace> see you on the other side
<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.
<alexisb> mgz, frobware, the new behavior (ie going to static allocation) was needed for a bug fix? Or was needed for a maas update?
<frobware> alexisb, mgz: I believe it made uniqueness easier.
<mgz> well, I think I can see the addresses leaking bug from going over the previous merge
<frobware> mgz, Is it easy to slot this change in to see if it does unblock testing?
<frobware> mgz, or is that quite a big deal and a time sink?
<mgz> frobware: sure
<mgz> won't be quick, but can do it easily enough
<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
<alexisb> frobware, mgz we will want to make sure we have  a summary to jam on where we have left today
<alexisb> as he is around this week
<alexisb> well what is left for the week :)
<mgz> ah, that's good
<mgz> okay, I'll send the proposed change through as a feature branch now
<alexisb> mgz, thank you
<mgz> build revision 3455
<perrito666> mgz: still here?
<alexisb> perrito666, his is but with many demands
<alexisb> s/his/he
<mgz> perrito666: wotcha
<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
<natefinch> lol
<natefinch> safe travels perrito666
<perrito666> tx
<mgz> perrito666: I presume you're not in go-goose
<mgz> I can give it the magic letters
<perrito666> that might be a valid reason :) could any one on go-goose magic comment me?
<perrito666> :)
<perrito666> k, bye you all see you in... a lot of hours, cheers
<alexisb> safe travels perrito666
<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.
<ericsnow> wwitzel3: :(
<natefinch> wwitzel3: ericsnow's parting gift ;)
<wwitzel3> natefinch: I was pretty much recovered from that and then bam
<wwitzel3> Jessa is really sick too, she tried to go to work today and got worse and had to some home early
<natefinch> that sucks
<thumper> that moment when you realise you haven't started IRC
<natefinch> thumper: and then you realize it's the week of christmas and hardly anyone is online anyway
<thumper> :)
<alexisb> heya thumper welcome back (for 4 days)
<thumper> except 24th is a bonus day off
<thumper> and I've already finished monday
<thumper> so down to two
<natefinch> nice of them to give us my son's birthday off :)
<alexisb> thumper, I think that just means you have to work twice as hard in the two days ;)
<thumper> ha
 * thumper wanders off to make coffee
<thumper> oh ffs
 * thumper looks to merge master into dep-engine
<thumper> can we please stop releasing code?
<cherylj> if only...
<frobware> cherylj, mgz: around for 15 mins or so - did we draw any conclusions on the patch?
<cherylj> frobware: can you do a hangout?
<frobware> sure
<cherylj> alexisb: can you join?
<cherylj> https://plus.google.com/hangouts/_/canonical.com/cheryl-jennings?authuser=0
<alexisb> yes
#juju-dev 2015-12-22
<jog> axw, axw_, your commit to the structured-metadata branch didn't run through CI because it needs a version update, since 1.26-alpha3 was released to devel late last week.
<axw> jog, ok, thanks
 * thumper is done for another day
<thumper> laters folks
<frobware> jam, ping
<jam> frobware: pong
<jam> I heard you were up late trying to work on this stuff, thanks for helping me pick it up
<frobware> jam, If I ask MAAS for the DNS info it comes back empty
<frobware> jam, np - though I need to go out in about 10 mins
<jam> frobware: dns_servers for the subnet comes back with nothing? I wonder how maas is filling it out from DHCP.
<jam> I have the feeling there are some secret bits to configuration that neither MaaS nor we were realizing.
<frobware> jam, I took a path to least resistance. We already parse the hosts /etc/resolv.conf so I took that route here too.
<frobware> jam, if I `maas 9 nodes list |grep dns` I get no entries
<frobware> jam, well, I get  "dns_servers": []
<frobware> jam, when I say "already" that's what we do when address-allocation is enabled
<jam> frobware: k, I think the trick there is that maas has a space for people to set up dns servers for subnets that you define, but they don't actually put their own information into the one that they manage
<frobware> jam, I was almost confused by "space" there. :)
<jam> frobware: can we think of anything other than nameservers that DHCP would be setting up that we would be missing?
<jam> heh
<jam> Like routes ?
<frobware> jam, if you look at the containers /e/n/i it seems to do that itself
<jam> frobware: gateway IP seems to be in the DHCP message
<jam> but I'm guessing we know we need to set that up already?
<frobware> jam, hmm. so this is specified in the LXC config
<frobware> jam, and looking at my container I have a default route
<jam> so DHCP has a fair number of options, Router, Time Server, Name Server, Domain Name Server, Log Server, Cookie Server, LPR Server, Impress Server, Resource Location Server
<jam> Host Name, Boot File Size, Merit Dump File, Domain Name, Swap Server, Root Path, Extensions Path
<jam> I'm guessing we don't need to use all of those, but that would be the sort of thing that we need to be clear on what we are and aren't using as we switch away from DHCP
<frobware> jam, ac
<frobware> jam, ack
<jam> as long as its "ack" and not "ack!"  :)
<jam> (eek! (?) )
<frobware> jam, try ag. or pt.
<jam> heh. I'm happy with ack, just bringing levity.
<frobware> jam, and ag is nicely integrated with Emacs. But pt is written in go...
<jam> wouldn't it just be "p" in go ?
<jam> can't waste characters like that
<frobware> jam, depends on font size
<frobware> jam, is there anything else I can convey now? I'll check back in later but I suspect you'll be long gone.
<jam> frobware: no I think we're good. I'll take custody of your patch and add some tests, and do some due diligence that we aren't missing anything else.
<jam> frobware: thanks for helping on this during your holiday. enjoy your day
<frobware> jam, great and thank you!
<frobware> jam, so there was 1 unit tests failure. FAIL: client_validation_test.go:56: ClientValidationSuite.TestClaimLeaseName
<frobware> jam, I didn't see that for the single run I did locally
 * frobware needs to run - already late. Adios!
<jam> weird, that test passes here
<jam> seems like it is a random failure, but I'll investigate
<jam> jog_: when you're around give me a ping
<mup> Bug #1528572 opened: lxcBrokerSuite.TestStopInstance fails if a loopback is currently mounted <testing> <juju-core:Triaged> <https://launchpad.net/bugs/1528572>
<ericsnow> natefinch: can you see or hear me on the hangout?
<natefinch> ericsnow: trying to figure out the right place to convert Timestamp to used.  I guess the question is - do we expect Used to be printed out in the yaml output, or not?
<ericsnow> natefinch: convert it in the formatter
<ericsnow> natefinch: Used should be a field on the new "formatted" struct
<natefinch> ericsnow: ok, yeah, that's basically what I was wondering - should it be in the struct or is it purely a "view" of the data in tabular format.
<natefinch> ericsnow: I'm fine with it being in the struct
<ericsnow> natefinch: k
<natefinch> ericsnow: lol, just noticed resource.Type ... where there's only one valid value :/  (not your fault of course)   .... do we know what other values besides "file" might be used?
<ericsnow> natefinch: there was talk of other things like repos
<natefinch> ericsnow: that's interesting
<ericsnow> natefinch: haven't worried about it because the semantics aren't clear and I don't have time :)
<natefinch> ericsnow: right.
<jog> jam, pong
<perrito666> jam: hey can we schedule a time after the shutdown to go over security groups in aws so I make sure I dont screw anything?
<perrito666> oh, cmoom, blocked? that is so unfair
<natefinch> ericsnow: I note that the FormattedCharmResource has a bunch of fields not actually used in the tabular format... do you think we should drop them until they're asked for?
<ericsnow> natefinch: we expose them through the JSON and YAML formatters
<natefinch> ericsnow: yes, but there's not even anything in the spec about there being json and yaml formatters, let alone what fields are expected to be there
<ericsnow> natefinch: so are you arguing that we should drop them?  If so, why?
<rick_h_> natefinch: ericsnow any list commands should take fornstters so they're consistent
<natefinch> rick_h_: ok
<natefinch> ericsnow: just don't want to presume what should be displayed
<ericsnow> natefinch: understood
<natefinch> ericsnow: less to maintain
<natefinch> rick_h_: there's a limited amount of information shown in the two list resources commands, as written in the spec.  Presumably this is to keep the tabular format small.  But what should we put in the yaml/json?  In theory, there's a lot more we can put in there, but my initial assumption would be to just put in the same data as in tabular
<ericsnow> natefinch: we should put everything in there, which is what we've done
<natefinch> ericsnow: "everything" is a rather fungible concept, though
<natefinch> I guess that's why we do demos :)
<ericsnow> natefinch: :)
 * perrito666 imagines juju status returning even the source code for juju itself
<rick_h_> natefinch: ericsnow i'm notnsure what thenlist of all metadats is but i'd think a basic dump of known details that matched up with a show command
<rick_h_> natefinch: ericsnow but to be bqckward compatible best tonstart with less and add sipport than tonrekove later as anbackward incompatiblenchange
<natefinch> yeah, I was just thinking that... once we start writing things out, we have to support those fields for forever
<natefinch> though obviously that's not written in stone until we merge to master ;)
<ericsnow> natefinch: let's table any changes there to after this iteration is complete (make a card)
<rick_h_> natefinch: so i'm open tona list and starting feedback from stakeholders on 'need it' vs 'nope'
<natefinch> ericsnow: sounds good
 * natefinch just invented a new word - charmtabular.
<natefinch> thumper: hope you're having a charmtabular day so far.
<thumper> pretty quiet so far
<thumper> get to just focus on hacking for a change
<natefinch> nice
<natefinch> I can tell I'm working with ericsnow's code, because everything gets a lot easier now that I have 5 windows open ;)
 * ericsnow opens another tab to read natefinch's message
<natefinch> haha
<natefinch> honestly, it's not so hard with two big monitors, it's doijng it all on one 15" monitor that's the real problem (for me)
<natefinch> ericsnow: this is a bad habit to get into: https://github.com/juju/charm/blob/v6-unstable/resource/fingerprint.go#L23
<natefinch> ericsnow: far better to make() the target slice the correct size and just use copy to copy it over
<ericsnow> natefinch: I started doing it when I saw it done in the stdlib :)
<natefinch> ericsnow: hmm... maybe append is smarter than I'm thinking
<natefinch> ericsnow: far better to make() the target slice the correct size and just use copy to copy it over
<natefinch> oops
<natefinch> ericsnow: I was just doing some benchmarking... I guess apend actually is smarter than I realized.  both are very very similar in memory usage and speed.
<natefinch> I figured append would be wasteful of space, but it looks like it's just rounding up a little on capacity
<mup> Bug #1528703 opened: juju unable to deploy juju-gui to lxc containers on servers with multiple networks <juju-core:New> <https://launchpad.net/bugs/1528703>
<mup> Bug #1528703 changed: juju unable to deploy juju-gui to lxc containers on servers with multiple networks <juju-core:New> <https://launchpad.net/bugs/1528703>
<mup> Bug #1528703 opened: juju unable to deploy juju-gui to lxc containers on servers with multiple networks <juju-core:New> <https://launchpad.net/bugs/1528703>
#juju-dev 2015-12-23
<jam> is anyone around that knows how to schedule another run of a feature branch?
<jam> I can find the "run-unit-tests-trusty-amd64" suite, and I can see it has a "Build Now" but I have no idea what goes into the "revision_build" string to make it actually work
<jam> I tried copying the content of other tests, and it doesn't seem to do what I want
<TheMue> To my old Juju colleagues, who may take a look into the channel:I wish you all a Merry Christmas, peaceful and happy days, and a lucky 2016.
<natefinch> Merry Christmas TheMue
<alexisb> Merry xmas to you TheMue
<alexisb> jam, jog would know
<alexisb> if you are still online
<jog> hi jam, which revision build did you want to see run-unit-tests-trusty-amd64 run against again?
<frobware> alexisb, cherylj: I didn't see any update in the bug - just curious
<alexisb> heya frobware
<alexisb> jog thinks your patch is the right route
<alexisb> sorry I mean jam not jog
<alexisb> but unit tests are still pending
<alexisb> jog (and I really mean jog this time) is working through some maas issues in CI that are unrelated (we believe) to the bug
<natefinch> wwitzel3: if I haven't missed you, have a good flight and a good holiday season, and it's been great working with you
<alexisb> :(
<natefinch> ...or as we'll be calling him later "Wayne the Betrayer"
<rick_h_> wayne 2.0 "the return"?
<natefinch> rick_h_: gotta be 4.0, he's already on v3 ;)
<natefinch> rick_h_: where are the screenshots?  http://blog.jujugui.org/2015/12/23/juju-gui-2-0-beta-released/
<mup> Bug #1528932 opened: No images error when deploying services <ci> <juju-core:New> <juju-core structured-metadata:Triaged> <https://launchpad.net/bugs/1528932>
<natefinch> ericsnow: you have reviews for all your open reviews
<ericsnow> natefinch: thanks
<ericsnow> natefinch: no ship-it on http://reviews.vapour.ws/r/3403/?
<natefinch> ericsnow: oh, I think I needed to go back and finish up.  i'll reread it
<ericsnow> natefinch: thanks!
<natefinch> man, I wish we didn't need a database type, an api type, a print-to-the-user type, and an everything-else type for each logical type in the system :/
<natefinch> I know *why* we do it... but, damn, that's a lot of boilerplate
<natefinch> ericsnow: the fact that this function says it can return an error screws up like 10 levels of functions that need to check for errors... except this function can't ever fail.  Why is it marked as returning an error? https://github.com/juju/juju/pull/3981/files#diff-c8d4587dc7a3c49893cdc913b08253ffR111
<ericsnow> natefinch: because I expect it to return an error in the future and I'd rather not deal with adding all the error handling later
<natefinch> it doesn't seem like the kind of thing that can possible fail.  It's just wrapping state, which presumably at this stage, just exists
<natefinch> ericsnow: YAGNI
<mup> Bug #1528971 opened: clientSuite.TestClientWatchAll unit test <ci> <test-failure> <unit-tests> <juju-core:New> <juju-core cross-model-relations:Triaged> <https://launchpad.net/bugs/1528971>
<mup> Bug #1528975 opened: ClientValidationSuite.TestClaimLeaseName unit test <ci> <intermittent-failure> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1528975>
<mup> Bug #1528971 changed: clientSuite.TestClientWatchAll unit test <ci> <test-failure> <unit-tests> <juju-core:New> <juju-core cross-model-relations:Triaged> <https://launchpad.net/bugs/1528971>
<mup> Bug #1528975 changed: ClientValidationSuite.TestClaimLeaseName unit test <ci> <intermittent-failure> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1528975>
<mup> Bug #1528971 opened: clientSuite.TestClientWatchAll unit test <ci> <test-failure> <unit-tests> <juju-core:New> <juju-core cross-model-relations:Triaged> <https://launchpad.net/bugs/1528971>
<mup> Bug #1528975 opened: ClientValidationSuite.TestClaimLeaseName unit test <ci> <intermittent-failure> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1528975>
#juju-dev 2015-12-24
<mup> Bug #1529126 opened: cmdControllerSuite.TestControllerDestroy unittest <ci> <intermittent-failure> <test-failure> <unit-tests> <juju-core:New> <juju-core controller-rename:New> <https://launchpad.net/bugs/1529126>
#juju-dev 2017-12-26
<mup> Bug #1662272 changed: Agents stop running hooks and are hung <canonical-bootstack> <canonical-is> <juju-core:Expired> <https://launchpad.net/bugs/1662272>
