[01:12] <Caguax> I am deploying juju on my maas server. I am having an issue with DNS. When I bootstrap the server that is getting bootstrap is getting the ip of the maas server as DNS. I will like to specify The DNS. Any one knows how to do this ?
[01:16] <bigjools> Caguax: edit the dhcp template
[01:25] <bigjools> Caguax: did you see myanswer?
[01:26] <Caguax> bigjools: what populates  'dns_server'  on the dhcp.template option domain-name-servers {{dhcp_subnet['dns_servers']}};
[01:26] <bigjools> Caguax: just remove everything from {{ to }} and put your desired IP in
[01:27] <bigjools> normally the region calculates the value depending on your region's external facing IP
[01:28] <Caguax> bigjools: ok, I think that would do the trick, but should named be running ?
[01:28] <bigjools> Caguax: if you installed maas-dns, it starts it up
[01:28] <bigjools> if you're using an external DNS service, you don't need that
[01:28] <Caguax> bigjools: I think I did install maas-dns...any way I can verify ?
[01:29] <bigjools> dpkg -l maas-dns
[01:29] <Caguax> bigjools: I ran apt-get install maas-dns and it return 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[01:29] <bigjools> it's installed
[01:30] <bigjools> it's not hurting anything
[01:34] <Caguax> I thought that when I choose to manage an interface and use dhcp+dns, the maas server will be use as a relay. I am just trying to understand why is not working when I use manage interface w/ dhcp+dns and the dns server ip that is hand off is the maas server ip
[01:34] <bigjools> what is not working, exactly?
[01:35] <bigjools> and which version of maas are you using?
[01:40] <Caguax> When I deploy a node the ip that it uses for dns is the maas server. And the node can't resolve names. I am using the latest from trusty
[01:41] <bigjools> it should work fine if you set dhcp+dns management on the cluster interface
[01:41] <bigjools> ummm
[01:41] <bigjools> can you check the zone file and see if it's correct
[01:41] <Caguax> Yep that what I thought...but I am missing something :(
[01:41] <bigjools> it should have a CNAME in it for the node
[01:48] <Caguax> it does..let be try to bootstrap juju and try again
[01:48] <Caguax> zone.cisco.com:luflores-juju IN CNAME 10-122-229-113
[03:15] <Caguax> bigjools: you still there ?
[03:23] <bigjools> Caguax: yeah
[03:31] <Caguax> bigjools: The is that I am getting ServFail, this tcpdump...http://paste.openstack.org/show/85464/
[03:33] <bigjools> that's pretty unintelligible
[03:33] <Caguax> bigjools: My maas server is 10.122.229.25 and the upstream DNS is 172.18.106.25...It looks like it gets response but it is not pass to the node 10.122.229.113
[03:33] <bigjools> how are you querying the dns server?
[03:34] <Caguax> I ssh to the node (10.122.229.113) and do a nslookup www.cisco.com
[03:37] <bigjools> did you set the forwarders on the maas dns server?
[03:38] <Caguax> Yes, 'Upstream DNS used to resolved domain not managed by this MAAS'
[03:39] <Caguax> and it looks it use it, base on the tcpdump
[03:40] <bigjools> ok
[03:41] <bigjools> ummm, not sure what's up then, the dns server is configured ok
[03:41] <bigjools> doesn't seem like a maas problem per-se
[03:41] <bigjools> can you do the same lookup from the 10.122.229.25 host itself?
[03:47] <Caguax> Yes, on the MAAS server it work fine
[03:47] <bigjools> so you may have a firewall problem?
[03:47] <Caguax> https://gist.github.com/luflores/eae5459783c3914be010
[03:47] <bigjools> can you do any local lookups on the node?
[03:48] <Caguax> MAAS and Node are on the same lan, no FWs
[03:49] <bigjools> I have the same set up here and it all works ok so I'm not sure how I can help :(
[03:49] <bigjools> can you look up the node's own DNS from itself?
[03:51] <Caguax> on the node nslookup to localhost fails too...here how it looks
[03:51] <Caguax> https://gist.github.com/luflores/decfdb9a6d05262e1099
[03:54] <Caguax> bigjools: Thanks for all the help so far....it is kinda later here...I am going to sleep this one off and cont. tomorrow
[03:54] <Caguax> thanks gain
[03:55] <bigjools> Caguax: ok np
[03:55] <bigjools> Caguax: wait - the node is looking up on localhost?
[03:55] <bigjools> ah
[03:55] <bigjools> Caguax: can you do "nslookup luflores-juju" on luflores-juju
[03:56] <Caguax> That fails too :(
[03:56] <bigjools> there's your problem then
[03:56] <bigjools> there must be some firewalling or something else getting in the way, replies are not getting back to your node
[03:57] <Caguax> Let me think about it....and troubleshoot it a bit more
[03:58] <Caguax> I'll connect later tomorrow now post my findings
[03:58] <bigjools> ok.  I am UTC+10 so I won't be around early, assuming you're a Californian :)
[04:00] <Caguax> I am US East Coast :)
[04:00] <Caguax> so bit late here
[04:01] <bigjools> oh, well, yes it is late then
[04:01] <Caguax> good night :)
[04:01] <bigjools> night
[07:14] <rvba> bigjools: I was wondering where the error message "Static IP Address with this Ip already exists." was coming from… but now I realized it a message generate by Django because the field 'ip' on StaticIPAddress is unique…
[07:15] <rvba> it's*
[07:15] <bigjools> rvba: yes I guessed it was a Django message from the weird capitalisation
[07:15] <rvba> Yep :)
[07:15] <bigjools> hence my questions to Andreas
[07:22] <rvba> bigjools: https://code.launchpad.net/~rvb/maas/fix-cap-static-ip/+merge/225606
[07:24] <bigjools> rvba: approved with remark :)
[07:24] <rvba> bigjools: yeah, I hesitated to make it just 'IP'.  But it doesn't seem right to me.
[07:25] <bigjools> rvba: it seems perfect to me
[07:25] <rvba> IP = the protocol
[07:25] <bigjools> it's the field verbose name
[07:25] <rvba> IP address = … the IP address
[07:26] <bigjools> not the works of Shakespeare
[07:26] <bigjools> ;)
[07:26] <rvba> heh
[07:26] <rvba> Well, okay…  I don't care so much as long as it's properly capitalized.
[09:08] <rvba> jtv: gmb: I found other spurious test failures but they happen infrequently: maybe you'll see what's wrong by looking at the stacktrace: http://paste.ubuntu.com/7745766/ and http://paste.ubuntu.com/7741493/
[09:08]  * gmb looks
[09:09] <gmb> rvba: That looks like an isolation problem at first glance.
[09:09] <gmb> But I don’t know OTTOMH why it’s happening.
[09:10] <rvba> gmb: that would explain why I can't seem to recreate the problems when I run just the failing test.
[09:10] <gmb> Yeah.
[09:11] <rvba> On the other hand, the entire DB should be wiped out between tests.
[09:15] <gmb> Indeed.
[09:45] <bigjools> right test case being used?
[09:47] <gmb> jtv: I’ve updated https://code.launchpad.net/~gmb/maas/fix-guess_server_address/+merge/225164, if you have the time or brain power.
[09:49] <rvba> bigjools: yes, it's using APITestCase which derives from MAASServerTestCase.
[11:03] <gmb> rvba: Are you still investigating that isolation weirdness?
[11:03] <gmb> Any luck?
[11:04] <rvba> gmb: no, I want to test my DNS thingy first.  (I've been running the test in isolation for hours and it didn't fail so it *really* looks like an isolation problem)
[11:05] <gmb> rvba: I’m r-o-u-f -ing the test module, but still nothing.
[11:06]  * gmb switches to r-o-u-f -ing maasserver.tests
[11:06] <rvba> I'll go back to r-o-u-f -ing make test
[11:11]  * gmb lunch
[11:12] <gmb> Might as well since this is just loop-de-looping
[11:36] <bigjools> rvba, gmb, allenap, jtv: how are things looking for a beta of 1.6 on Monay?
[11:36] <bigjools> Monday.  /me whacks D key
[11:37] <rvba> allenap: what about the problem Andreas had?  The one about having to re-download all the images?
[11:37] <jtv> bigjools: I can hold the branch I've got ready, and land it after.
[11:38] <jtv> (It's not ready for production until the follow-up branches land.)
[11:38] <bigjools> jtv: ok
[11:38] <bigjools> jtv: I will cut a new release branch anyway
[11:39] <rvba> bigjools: I think we need to do a bit more upgrade testing (I'm doing part of this QA right now) to be confident the release is going to be solid.  But I guess that's probably okay for a beta release.  What do you say?
[11:39] <bigjools> rvba: yes
[11:39] <bigjools> that's the intention of a beta
[11:39] <bigjools> I need to know in more detail what happened to boot resources between 1.5 and 1.6
[11:40] <rvba> I agree.  Hence my question to allenap who was looking into it (I think).
[11:43] <allenap> rvba: I’ve not been able to figure out why that might have happened during upgrade. Nothing in the code or packaging looks likely to have done it, but I’ll try to recreate it this afternoon.
[11:43] <rvba> allenap: cool, thanks.
[11:43] <allenap> rvba, bigjools: It’s not nice, but I don’t think it’s a blocker.
[11:44] <bigjools> what happened apart from moving the config out?
[11:44] <bigjools> anything?
[11:45] <rvba> When Andreas upgraded he apparently "lost" all the alread-downloaded images.
[11:45] <rvba> already*
[11:45] <bigjools> no I mean in the coe
[11:45] <bigjools> code
[11:45] <bigjools> dammit D key
[11:45] <allenap> bigjools: An extra layer was added to the directory hierarchy for boot resources apparently.
[11:45] <bigjools> oh - OS?
[11:46] <bigjools> and no migration script was written I suppose
[11:46] <allenap> I’m trying to figure that out.
[11:47] <bigjools> ok thanks allenap
[12:11] <rvba> allenap: I just upgraded from 1.5.1 to 1.6 (I'm testing something related to DNS) and I "lost" my images too.
[12:18] <rvba> allenap: when I hit "import boot images", I got all the images reported *instantly*… which seems to indicate the images can be found where they are, it's just a matter of forcing a report or something.
[12:22] <allenap> rvba: That’s good, and makes sense. Now, what do we do about that for 1.6? Can we prompt MAAS to do a report from the command-line, and thus the postinst?
[12:22] <rvba> allenap: something doesn't make sense to me: why are the existing images (in the DB) wiped out during upgrade?
[12:25] <allenap> rvba: My guess is that the importer needs to run again to create the new directory structure... which would mean we have to run the importer (not just the reporter).
[12:27] <rvba> allenap: hang on, I forgot something: to speed things up I have a script that keeps a copy of the bootresource dir and restores it each time I install a new MAAS package.  I guess this means I didn't really test what a real user would experiment.
[12:28] <rvba> allenap: I guess you need to try a real upgrade to see what happens.
[12:28] <allenap> rvba: Okay.
[12:32] <rvba> allenap: if you try it on canonistack, do not forget to move /var/lib/maas/boot-resources to /mnt otherwise you won't be able to import the images (/ is too small for that).
[12:33] <allenap> rvba: Ta. I’m going to try it at home first.
[12:33] <rvba> (I usually use canonistack when testing things related to the images because the import is much faster there)
[12:34] <allenap> rvba: It always takes me about 5 hours to actually get a usable instance there :-.
[12:34] <allenap> :-/ even
[12:35] <rvba> I really need to polish and then publish the scripts I use for this.  All it takes is one command and 5 minutes of waiting.
[12:49]  * gmb -> afk for a bit
[14:29] <LiveOne> HI!
[15:23] <d4rkn3t> Hello everyone, please I need help on MaaS, and bind9. The problem is when I try to make the bootstrap of the node via Juju the command ssh has an error in the connection session, Bind not resolve the hostname. If I try to use ssh with the node's IP it works. Is there someone can help me, please?
[15:34] <rvba> d4rkn3t: Can you test if the MAAS DNS server can resolve your node's hostname by running this on the MAAS server:  `host <hostname>.<domain> localhost`
[15:36] <d4rkn3t> rvba:  I've not set a domain, I've set just the hostname on /etc/hosts file on Region Controller.
[15:36] <rvba> d4rkn3t: Do you mean that you're not using MAAS' DNS server?
[15:38] <d4rkn3t> I use it, I've set it on the cluster section the interface in "Manage DHCP and DNS"
[15:39] <d4rkn3t> rvba: and I see the zone in /etc/bind/maas/..... If I try to add the hostname with its IP on hosts file it works
[15:40] <rvba> d4rkn3t: the point of the DNS server is that you don't have to fiddle with /etc/hosts.
[15:41] <rvba> d4rkn3t: the domain by default is '.maas'.
[15:41] <d4rkn3t> it's right,
[15:42] <d4rkn3t> if I edit a zone I see this "@   IN    SOA maas. nobody.example.com. (
[15:42] <d4rkn3t>               0000000115 ; serial
[15:42] <d4rkn3t>               600 ; Refresh
[15:42] <d4rkn3t>               1800 ; Retry
[15:42] <d4rkn3t>               604800 ; Expire
[15:42] <d4rkn3t>               300 ; TTL
[15:42] <d4rkn3t>               )
[15:42] <d4rkn3t> "
[15:42] <rvba> MAAS manages the zone file itself.  You shouldn't have to change it manually.
[15:44] <d4rkn3t> you right, but it not works I've also try to start the node without use Juju trying to connect via ssh used one time the IP, and it's works, then used hostname and it's not works
[15:46] <rvba> Back to my original suggestion, can you try running the command I pasted above?
[15:48] <d4rkn3t> rvba: ok, the command used in juju is this "ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication no" -i /home/richardsith/.juju/ssh/juju_id_rsa -i /home/richardsith/.ssh/id_rsa ubuntu@MaaSCCSvr1Node1 /bin/bash"
[15:49] <d4rkn3t> if I try to run it changing the hostname "@MaaSCCSvr1Node1" with its IP the ssh connection works
[15:49] <LiveOne> Hi.. u suggest using MAAS and JuJu to manage Openstack ?  good route for baremetal offsite dedicated severs
[15:49] <LiveOne> private/public
[15:50] <rvba> d4rkn3t: I understand; now we need to make sure MAAS' DNS server is working as expected; to do that I suggest running the command I pasted above.
[15:50] <d4rkn3t> rvba: ops without "@"
[15:52] <d4rkn3t> host MaaSCCSvr1Node1. localhost
[15:52] <d4rkn3t> Using domain server:
[15:52] <d4rkn3t> Name: localhost
[15:52] <d4rkn3t> Address: ::1#53
[15:52] <d4rkn3t> Aliases:
[15:52] <d4rkn3t> Host MaaSCCSvr1Node1. not found: 3(NXDOMAIN)
[15:53] <rvba> d4rkn3t: you need to use the default domain 'maas'.  host MaaSCCSvr1Node1.maas localhost
[15:53] <d4rkn3t> rvba: ops sorry the result is this "host MaaSCCSvr1Node1.maas localhost
[15:53] <d4rkn3t> Using domain server:
[15:53] <d4rkn3t> Name: localhost
[15:53] <d4rkn3t> Address: ::1#53
[15:53] <d4rkn3t> Aliases:
[15:53] <d4rkn3t> MaaSCCSvr1Node1.maas is an alias for 1-1-2-21.maas.
[15:53] <d4rkn3t> 1-1-2-21.maas has address 1.1.2.21
[15:53] <d4rkn3t> "
[15:53] <rvba> Okay, so the DNS server works fine.
[15:54] <d4rkn3t> rvba: where is the problem????
[15:54] <rvba> Now, on the machine where you run Juju, you need to edit /etc/resolv.conf to add 'nameserver <IP of the MAAS server>'
[15:55] <rvba> This way, Juju will use MAAS' DNS server to resolve the node's IPs.
[15:56] <d4rkn3t> I've done it
[15:56] <d4rkn3t> but Juju and MaaS are installed on the same machine
[15:59] <rvba> d4rkn3t: it's not clear to me why Juju doesn't seem to be using the domain 'maas' but an easy workaround is to add 'search maas' at the top of your resolv.conf file.
[16:01] <rvba> d4rkn3t: if they are on the same machine then you need to put 'nameserver 127.0.0.1' in resolv.conf
[16:04] <d4rkn3t> I'm trying to change the nameserver
[16:10] <d4rkn3t> wait, I want to explain which the virtual environment is: I've created a VM as Region Cluster and 2 VM as Cluster Controller then I've added 2 node to RC. After to changed their status in ready I've installed juju on RC and run the command to bootstrap the node
[16:30] <d4rkn3t> rvba: I've resolved that....I've added 127.0.0.1 on RC and then add .maas on FQDN....thanks a lot for your support
[16:40] <rvba> d4rkn3t: welcome