[06:56] <rvba> jtv: My loop found 2 other spurious failures.  I'm trying to recreate them in isolation now…
[06:57] <jtv> What kind of failures?
[06:59] <rvba> http://paste.ubuntu.com/7740610/
[06:59] <rvba> http://paste.ubuntu.com/7740611/
[06:59] <rvba> (I've manually merged gmb's fix for bug 1336617)
[07:10] <rvba> bigjools: why did you remove the note in your documentation branch?  (I assume because not letting MAAS manage the DHCP server isn't supported)
[07:15] <bigjools> rvba: because what it said is not true any more
[07:15] <rvba> bigjools: ah, right.
[07:17] <william_home> jtv: did you found a pointer for me where i can start to look at why the ephemeral images don't use a local mirror ?
[07:18] <william_home> i have time to investigate it myself but need a bit guidance
[07:18] <jtv> william_home: the problem I think is mainly one of getting the http_proxy etc. variables set in the "user data."
[07:18] <jtv> That's what goes into cloud-init IIRC.
[07:19] <jtv> If we could inject our own variable definitions into /etc/profile that way, we'd be home safe.
[07:20] <william_home> ok, so if understand it right Maas has al the bits working but the issue is more that cloud init does not take the parameters like a local archive
[07:20] <jtv> Right.  Probably, cloud-init would take the parameters if we knew how to pass them.
[07:21] <jtv> We started out with a model where a client (such as Juju) provided the user data, and we just passed it on unchanged.  In that model, we have no way that I know of to do this.  But I believe now the user data has become more of a pluggable thing.
[07:22] <jtv> src/metadataserver/commissioning/user_data.py might be a good starting point.
[07:23] <jtv> That's where we generate user data for commissioning.
[07:23] <william_home> and how does that info go to the node starting the ephemeral image?
[07:24] <william_home> does it get passed from the kernel cmdline?
[07:24] <jtv> As I recall, cloud-init on the booting image requests it from the maas metadata service.
[07:24] <jtv> The metadata service's purpose is to provide such information to bootstrapping nodes.
[07:26] <william_home> jtv: thanx,  I will start my search
[07:26] <jtv> We have a simple framework for sending multiple files to a commissioning node.  (It's also in use for auto-enlisting nodes now).  The main generate_user_data function composes a big script out of "snippets" that we have in etc/templates/maas/templates
[07:26] <william_home> yes i have seen that, i had to patch the ipmi detect file for doing import glob
[07:27] <william_home> that is still around in precise -updates maas 1.4
[07:27] <william_home> otherwise the node never gets the ready state
[07:27] <jtv> rvba has worked with userdata more recently...  rvba, to get the commissioning scripts working with an http proxy and/or local archive, do you think it would be enough to make the commissioning user-data inject the settings into /etc/profile?
[07:29] <rvba> jtv: let me have a look at the code…
[07:32] <rvba> jtv: yeah, I believe getting cloudinit to set http_proxy in /etc/profile should do the trick.
[07:33] <bigjools> why would "make doc" do this:
[07:33] <bigjools> bin/sphinx: 1: cd: can't cd to /home/ed/canonical/maas/sandbox/docs/_build
[07:33] <rvba> o_O
[07:33] <bigjools> the dir doesn't exist
[07:35] <jtv> bigjools: that's just like a bug which Gav recently fixed...
[07:35] <bigjools> what creates the _build dir?
[07:35] <jtv> *cough* *cough* mumble
[07:36] <bigjools> buildout... SAY NO MORE
[07:36] <rvba> heh
[07:36]  * bigjools distcleans in rough hope
[07:37] <bigjools> bin/database --preserve run -- bin/maas-region-admin syncdb --noinput
[07:37] <bigjools> pg_ctl: could not start server
[07:37] <bigjools> lol
[07:37] <bigjools> sigh
[07:38] <bigjools> distclean has fixed it
[07:38] <bigjools> weird
[07:42] <bigjools> rvba: http://paste.ubuntu.com/7740740/
[07:43] <rvba> nice
[07:44] <bigjools> looks quite nice after rendering it
[07:44]  * bigjools enlanderates
[07:47] <bigjools> rvba: urgh, *another* spurious test failure?
[07:47] <rvba> Two of them even.
[07:47] <bigjools> jeez, where are they coming from all of a sudden
[07:47] <rvba> (I only filed one bug thus far)
[07:48] <rvba> Well, me running the whole test suite in a loop :)
[07:48]  * bigjools moves the DHCP feature card to done-done and rejoices
[07:50] <rvba> bigjools: about that;  reading your change to the doc I'm thinking about the upgrade path to 1.6: since we don't populate the DNS zone with mappings from the dynamic range it means an existing deployment will be quite broken after you upgrade right?
[07:51] <rvba> I mean, unless you configure the static range *and* re-allocate all your nodes.
[07:52] <bigjools> rvba: mmm it won't be broken until the zone is re-written on the first node allocation
[07:52] <bigjools> then all the deployed nodes lose their DNS
[07:52] <bigjools> oh bugger
[07:52] <rvba> bigjools: the DNS config is rewritten when the package gets re-installed
[07:53] <rvba> s/re-installed/upgraded/
[07:53] <bigjools> then oh bugger without the preamble
[07:53] <rvba> bugger indeed
[07:53] <rvba> We kept the code so it's just a matter of flipping a switch.
[07:53] <bigjools> I have to run, but I can talk about this in half an hour
[07:54] <rvba> Okay
[07:54] <bigjools> rvba: the solution is to give dynamic nodes DNS entries :/
[07:54] <bigjools> one-line code change
[07:54] <rvba> I know.  Like I said, it's easy.
[07:54] <bigjools> but that is uuuuugly
[07:54] <bigjools> let;'s have a think
[07:54] <bigjools> TTYL
[07:54] <rvba> k
[07:55] <rvba> bigjools: we could restrict the dynamic mappings sent to the DNS machinery to the MAC addresses that correspond to allocated nodes.
[09:25] <rvba> gmb: care to have a look at https://code.launchpad.net/~rvb/maas/bug-1337190/+merge/225444 ?
[09:31] <gmb> rvba: Certainly
[09:31] <rvba> Ta
[09:32] <gmb> rvba: A pithy fix. Me like.
[09:33] <rvba> gmb: as you can imagine, the problem manifests itself very rarely.  I had to resort to run-one-until-failure to debug that one :).
[09:34] <gmb> rvba: Yeah, been there, done that :)
[09:34] <rvba> heh
[09:45] <rvba> And another one: https://code.launchpad.net/~rvb/maas/none-interf/+merge/225447
[09:57] <rvba> gmb: care to have a look? ^ It's tiny.
[09:57] <gmb> rvba: Already reviewed it :)
[09:57] <rvba> Nice; thank you gmb.
[11:19] <william_home> rvba: i don't see any reference that apt_mirror is used by cloud-init anywhere, is that right?
[11:20] <william_home> http_proxy seems to work and otherwise the maas instance gets used with squid-deb-proxy
[11:21] <william_home> when i manually do a wget to the maas instance getting the cloud-cofig-url i see that in the response i get the local mirror setting in apt_mirror: and i see apt_proxy: which is set to the maas instance
[11:21] <william_home> so apt_proxy gets used during init but not the local mirror archive
[12:00] <allenap> jtv: Istr that you made some changes to the boot resources downloading stuff?
[12:42] <william_home> rvba: when i do a manual cloud-init in a node commisioning then i get only apt_proxy in /var/lib/cloud/instance/cloud-config.txt
[12:43] <jtv> allenap: some changes when?
[12:43] <william_home> when adding manually in that file apt_mirror: http:/xyz/ubuntu and then run cloud-init modules --mode=config then my sources.list gets updated accordingly
[12:44] <allenap> jtv: I dunno… at some time :) Did you add another level to the fs hierarchy?
[12:45] <rvba> william_home: looks like apt_mirror overrides apt_proxy somehow.
[12:45] <jtv> allenap: Not me, but the OS is now an extra layer.
[12:46] <william_home> rvba: i think not, because apt_proxy does get set but apt_mirror never gets into the cloud-config.txt file
[12:46] <rvba> william_home: ah, you're right, apt_mirror is only used in the curtin (i.e. fast path installed) user data.
[12:46] <rvba> installer*
[12:47] <william_home> rvba: but is it possible to do this also for a node in commisionng mode? else ipmi packages cannot be installed and never gets in the ready state
[12:49] <rvba> william_home: the configuration you've done (setting apt_mirror in the preseed template) seems like the proper way to do this.
[12:49] <william_home> I'm trying to build a maas/juju/openstack cluster but i have no internet connection whatsoever so i'm left to a local mirror for everything
[12:50] <william_home> also the preseed does not seem to work.
[12:50] <rvba> Right.  MAAS assumes the connection to the Ubuntu archive can be done without the global proxy.  Which I guess can be considered as a bug.
[12:50] <allenap> Indeed, I’d say that’s a bug.
[12:51] <william_home> that bug is already open but i think the fix is simple
[12:52] <william_home> could maas also for a node in commisioning mode push the apt_mirror variable?
[12:54] <allenap> Was that you rvba or gmb? (Adding an OS directory layer to the boot resources hierarchy)
[12:54] <rvba> I don't recall doing it.
[12:55] <rvba> william_home: that's one way to do it.  But now I'm wondering why http_proxy is not considered when retrieving packages.
[12:55] <allenap> I’ll go and dig it out then. I might even have done it, who knows :-/
[12:56] <william_home> rvba: when using a proxy I still have to use a local mirror
[12:56] <william_home> archive.ubuntu.com is internally not resolveable
[12:56] <william_home> i could add some hooks for that but making maas use local mirror is better i guess
[12:57] <william_home> My environment has an airgap for the internet
[12:59] <rvba> By default, the nodes will use the squid-deb proxy on the region controller.  I suggest you configure it to talk to the mirror you want to use.
[13:01] <william_home> rvba: thats what I did already but on the commisioning node the sources.list still holds http://archive.ubuntu.com/ubuntu as the main archive while the apt_proxy is set to the maas node
[13:02] <william_home> the proxy get asked for archive.ubuntu.com and not for my local mirror
[13:04] <rvba> Did you enlist your nodes using the UI/API or did you get them auto-enlisted by booting them up and letting them register themselves with your MAAS server?
[13:05] <william_home> rvba: I preconfigured them in the maas environment
[13:05] <william_home> setup ipmi and added the right mac address
[13:08] <gmb> allenap: I believe it was one of Blake / Jason.
[13:08] <gmb> Or it might have been me.
[13:08] <rvba> william_home: did you change the "Main archive" config option?
[13:08] <allenap> Hehe, welcome to the far side of the hill gmb :)
[13:09] <gmb> :)
[13:10] <gmb> allenap: No, it wasn’t me; that must’ve been part of the CentOS/Windows support work.
[13:11] <william_home> rvba: yes, that one is pointing to the local mirror and when doing a wget to the maas-cloud-config-url......preseed, then I see that the apt_mirror: http://xyz/ubuntu and also the apt_proxy is there
[13:11] <william_home>  but it is not there when cloud-init init gets called which writes the cloud-config,txt file
[13:13] <william_home> so if cloud-init calls the cloud-config url for all metadata things it does not get the apt_mirror variable but does get the apt_proxy var
[13:16] <rvba> apt_mirror should clearly be set for the commissioning preseed as well.
[15:44] <MilesDenver> Is there a good place to ask preseed questions?  Like #preseed :)  I'm trying to set a puppet user with specific uid, but Preseed hangs on me
[15:45] <MilesDenver> http://pastebin.com/eDKH4yvU
[15:48] <rvba> MilesDenver: you should probably try freenode#server.
[15:49] <william_home> rvba: think it is solved now
[15:49] <MilesDenver> ty
[15:53] <rvba> william_home: what did you do?
[15:53] <william_home> I now updated the template file (removed the node from the interface) and readded it
[15:53] <william_home> the template file gets served from the database
[15:53] <william_home> like a cache
[15:53] <william_home> that costed me a lot off time, not a programmer
[15:54] <william_home> :)
[15:55] <william_home> so now i added apt_mirror: http://{{main_archive_hostname}}/{{main_archive_directory}} to user_data_config.template
[15:55] <william_home> readded the node
[15:55] <william_home> and ran cloud-init in it on the rebooted node
[15:56] <william_home> now i got also my local mirror in the cloud-config.txt file
[15:57] <MilesDenver> William: what file are you working in?  I'm trying to learn and you seem to be on to something
[15:57] <william_home> the only thing that you have todo manually is adding the local mirror in /etc/squid-deb-proxy/mirror-dstdomain.acl
[15:58] <rvba> gmb: I'm about to sign off for the day but maybe you'll fancy having a look at this spurious failure: http://paste.ubuntu.com/7742482/
[15:58] <gmb> rvba: Sure.
[15:59] <william_home> restart squid-deb-proxy and add the above oneliner to /etc/maas/templates/commisioning-user-data/user_data_config.template
[15:59] <rvba> Seems related to what you fixed the other day.
[16:00] <william_home> rvba: so adding the oneliner should do the trick and maas should also update the squid-deb-proxy dstdomain acl
[16:01] <rvba> william_home: right, that is bug 1300266.
[16:01]  * gmb resorts to run-one-until-failure
[16:02] <gmb> rvba: OH!
[16:02] <gmb> I can see why.
[16:02] <gmb> I’ts because I’m an eejit.
[16:02] <gmb> (which also explains how I use my apostrophes)
[16:02] <rvba> heh
[16:02] <william_home> rvba: yes, and the oneliner should go into the documentation or the template file should be updated, https://bugs.launchpad.net/maas/+bug/1288502
[16:03] <william_home> or maybe not a one liner but something with if statement like the apt_proxy in the same file
[16:04] <rvba> gmb: I also have http://paste.ubuntu.com/7741493/ which seems to be about using make_network*s* instead of make_network.
[16:05] <gmb> Hrm.
[16:05] <rvba> But that's just a guess.
[16:06] <william_home> MilesDenver: did i answer your question in the mean time?
[16:06] <william_home> :)
[16:08] <william_home> rvba: should I do something like adding this info to the lp report 1288502?
[16:09] <MilesDenver> william_home: yes, thanks.  I poked around a bit.
[16:15] <rvba> william_home: yes, that would be great.
[16:36] <dogfood> I have a DNS question, why is the hostname a cname?
[16:36] <dogfood> and not an an A record?
[16:37] <dogfood> as this is causing issued when attempting to install CDH5.
[16:42] <gmb> dogfood: That will change in MAAS 1.6, which we’ll be releasing soon (not quite sure when yet)
[16:42] <gmb> Not sure of the historical reasons for having a cname there though.
[16:42] <dogfood> when adding a node to CDH5 I use the FQDN from the region controller webUI, say hadoop-1.maas.company.com. However CDH5 does a forward and reverse lookup and uses the 10-122-75-116.maas.company.com FQDN.
[16:45] <dogfood> gmb: What will the change be in 1.6? Will the ip based FQDN be removed?
[16:46] <gmb> dogfood: Sorry, the DNS entry for the hostname will become a real A record rather than a CNAME.
[16:46] <dogfood> gmb: but the reverse DNS entry will still point to the ip based FQDN (10-122-75-116.maas.company.com) ?
[16:47] <gmb> dogfood: I’m not sure; let me check and get back to you.
[16:47] <dogfood> gbm: thank you
[16:53] <gmb> dogfood: AFAICT from a quick look at the code, the reverse entry will no longer point to the ip-based FQDN; it should work properly using the FQDN from the region.
[16:55] <dogfood> gmb: any idea on the 1.6 release?
[16:56] <dogfood> not looking for a definite time frame, just a rough idea on when it might be release?
[16:57] <gmb> dogfood: Next couple of weeks, I’d hope. We’re in the process of finalising that.
[16:58] <dogfood> gmb: thanks for looking at the code and getting back to me. I really  appreciated it.
[16:58] <gmb> dogfood: No problem, glad I could help :).
[22:31] <Caguax> Hi all, if I want to pass a different DNS server for a managed interface? How I can specific this? When I select dhcp+dns the DNS that it is passed is my maas server which is not running named. I want to pass my main DNS not my maas server