[01:51] <roaksoax> bigjools: so i saw that things have been fixed differently
[01:55] <bigjools> roaksoax: yeah
[01:55] <bigjools> I left jtv to it
[01:56] <roaksoax> bigjools: alright, so I'm guessing i'm good to roll out a quantal tomorrow to the archives?
[01:56] <bigjools> hopefully!
[01:56] <bigjools> I just pushed a packaging change up
[01:56] <roaksoax> bigjools: to the precise branch
[01:56] <bigjools> both
[01:57] <roaksoax> bigjools: this one? https://code.launchpad.net/~julian-edwards/maas/packaging.precise/+merge/122177
[01:57] <bigjools> and this https://code.launchpad.net/~julian-edwards/maas/packaging/+merge/122181
[01:57] <bigjools> I uploaded the precise changes to the testing PPA too
[01:57] <roaksoax> bigjools: the 1st one is wrong cause you are proposing changes from the mprecise package to the quantal branch
[01:58] <roaksoax> bigjools: and the latter is not really necessary, as it is commented
[01:58] <roaksoax> bigjools: we should just drop that and make the change upstream
[01:58] <roaksoax> bigjools: do you agree?
[01:58] <bigjools> roaksoax: I superseded the first MP
[01:58] <bigjools> got the target branch wrong
[01:59] <bigjools> what change do you mean?
[01:59] <roaksoax> bigjools: we don't need to patch that actually
[02:00] <bigjools> roaksoax: I think you do, the tftp port needs to change
[02:00] <roaksoax> bigjools: yeah, I mean: -   # root: /var/lib/tftpboot
[02:00] <roaksoax> 19	+   # root: /var/lib/maas/tftp
[02:00] <bigjools> I had to change it to make the patch apply
[02:00] <roaksoax> bigjools: i'll fix that
[02:01] <bigjools> otherwise the source build fails
[02:01] <bigjools> how will you fix it?
[02:01] <bigjools> the upstream is correct
[02:01] <roaksoax> bigjools: ahh I see what's happening
[02:01] <roaksoax> bigjools: nevermind :)
[02:01] <bigjools> ok :)
[04:06] <bigjools> roaksoax: I think we need to be a bit kinder with the upgrade and migrate the images to the new locate.  Asking people to run the importer again to download 500+M is a little obnoxious.
[04:06] <bigjools> s/locate/location/
[13:53] <smoser> allenap, around?
[13:54] <smoser> i'm assuming i'm missing something. but if i 'bzr blame' some file (which i do all the time and don't understand how other people do not), is there a way to see the merge proposal that brought that code in?
[13:57] <rbasak> I know that bzr lp-find-proposal exists but I've never used it: http://doc.bazaar.canonical.com/plugins/en/launchpad-plugin.html
[13:58] <rbasak> smoser: ^^
[14:10] <allenap> smoser: Hi.
[14:10] <allenap> smoser: I don't know of a way to do that.
[14:11] <allenap> rbasak: That's a great find.
[14:11] <smoser> it seems useful.
[14:11] <smoser> but it seems crazy that nothing is storing that
[14:11] <smoser> it looks like that basically scrapes launchpad to find it.
[14:12] <smoser> rather than simply pulling data out of bzr
[14:13] <roaksoax> jtv: ping
[14:13] <allenap> "If you like sausages and lp-find-proposal, you should never watch either one being made."
[14:19] <flacoste> smoser: there is
[14:19] <flacoste> smoser: it's stored in the annotations somehow
[14:19] <flacoste> smoser: bzr qannotate allows you to see it
[14:19] <flacoste> but i don't know how to get it from the command line
[14:21] <smoser> flacoste, but then why would lp-find-proposal have restrictions like
[14:21] <smoser> " This works only if the selected branch was the merge proposal target, and if the merged_revno is recorded for the merge proposal."
[14:21] <flacoste> smoser: sorry, i was mistaken
[14:21] <flacoste> i'm looking a qannotate now and can't see to find it
[14:21] <flacoste> i thought i was going straight from qannotate to the merge proposal
[14:22] <flacoste> but now that i think of it
[14:22] <roaksoax> allenap: after enlistment, if I turn on the machine, I see a PXE error:
[14:22] <flacoste> i think i was looking the merge message matching the revno in my mail archives
[14:22] <smoser> flacoste, what is the bot that merges ?
[14:22] <roaksoax> "Could not find kernle image: amd64/generic/precise/poweroff/linux"
[14:22] <smoser> to maas trunk
[14:22] <flacoste> and that email contains the link to the merge proposal
[14:22] <smoser> we could just make that bot record it.
[14:22] <flacoste> smoser: PQM, or tarmac
[14:22] <flacoste> for maas, it's tarmac
[14:23] <flacoste> it could very easily save it
[14:23] <flacoste> in annotations
[14:23] <flacoste> since it operates based on merge proposal
[14:23] <allenap> roaksoax: That's from get_boot_purpose(). That means the node hasn't been accepted (well, isn't commissioning or allocated).
[14:24] <roaksoax> allenap: right, but PXE fails and the machine does not power off
[14:24] <roaksoax> allenap: PXE tries to get a linux image under poweroff dir
[14:24] <allenap> smoser: Can you take a look at https://code.launchpad.net/~allenap/maas/tftp-permissions/+merge/122288, another go at fixing bug 1042865.
[14:24] <allenap> ?
[14:26] <roaksoax> allenap: wasn't that supposed to be fixed in https://code.launchpad.net/~jtv/maas/bug-1042865
[14:26] <allenap> roaksoax: Yeah, I know. We don't have a boot image that'll just turn off the machine. Perhaps we ought to put in a reboot there? Ideally we *want* to just shut down the machine, but that's not implemented.
[14:26] <allenap> roaksoax: Yeah, but I don't think it works.
[14:26] <roaksoax> allenap: it doens';t just re-opened the bug
[14:26] <roaksoax> allenap: let me test your fix though
[14:28] <allenap> Ta.
[14:31] <smoser> allenap, wait.
[14:31] <smoser> didn't https://code.launchpad.net/~jtv/maas/bug-1042865/+merge/121990 claim to fix that ?
[14:32] <roaksoax> smoser: it doesn't just tested it
[14:32] <smoser> really?
[14:32] <smoser> that is weird.
[14:32] <smoser> allenap, can't we just fix this right?
[14:32] <smoser> the right place to fix it is in maas-provision install-pxe-image
[14:33] <smoser> that should take *copy* data, set permissions appropriately, and leave the directory in tact
[14:33] <smoser> it is very strange for it to remove the directory you give it.
[14:33] <allenap> smoser: Yeah, I'm inclined to revert the existing fix and land roaksoax's.
[14:33] <smoser> where is roaksoax ?
[14:33] <allenap> https://code.launchpad.net/~andreserl/maas/maas_set_correct_file_permissions/+merge/121974
[14:33] <smoser> and basically you're only fixing one of the potential callers of that code
[14:33] <smoser> by fixing maas-import-ephemerals
[14:34] <allenap> smoser: I agree. roaksoax, I can add tests to your proposal, then we can revert jtv's and land that.
[14:34] <smoser> yeah, i think that roak's is correct (except for it still has the strange behavior of deleting data that you give it)
[14:35] <allenap> smoser: Yeah, I argued that that was weird at the time it first landed, iirc, but let's leave that behaviour for now.
[14:35] <smoser> allenap, yeah, i'll just be careful not to type 'maas-import-pxe /'
[14:36] <roaksoax> allenap: go for it
[14:36] <allenap> Cool.
[14:38] <roaksoax> allenap: hold on i mean on reverting back to my foix
[14:38] <roaksoax> allenap: still downloading the ephemerals
[14:39] <smoser> roaksoax, you should run that stuff on canonistack
[14:39] <smoser> it takes like 30 seconds tops
[14:39] <roaksoax> smoser: yeah but i'm gonna test the rest of the stuff to see whether I upload to the archives
[14:39] <roaksoax> it just needs 2 more misn
[14:39] <smoser> you can do that on canonistack too
[14:39] <smoser> :)
[14:40] <smoser> its really neat. you can request systems via an api, and use them, and then throw them out
[14:40] <roaksoax> smoser: can you enslist and etc?
[14:40] <smoser> they're calling it "the cloud"
[14:40] <smoser> roaksoax, yeah, that pastebin i showed you yesterday i walked through enlistment and commissioning.
[14:41] <roaksoax> smoser: ahh sorry I didn't ewview it since my internet connect failed misserably
[14:41] <roaksoax> smoser: can you pastebinit agian please
[14:43] <smoser> http://pad.daviey.com/maas-ephemeral-image-test
[14:43] <roaksoax> allenap: yeah it works
[14:43] <allenap> roaksoax: I still think I ought to fix it properly, in install-pxe-image.
[14:43] <smoser> roaksoax, the basic set of ideas will still work, but we'll have to change some of the implementation for uantal.
[14:43] <roaksoax> allenap: yep, I would argue that's the place where it should be fixed
[14:44] <smoser> i was doing that yesterday when i opened the bug on "have to push buttons in the UI"
[14:44] <smoser> anyone listening know how to add an admin user without typing in a password for that user ?
[14:44] <smoser> i swear at one point we could do that
[14:49] <roaksoax> allenap: could you also check the named.conf.maas permissions are set correctly
[14:49] <roaksoax> allenap: now they get set as 755 by maas
[14:49] <roaksoax> err
[14:49] <roaksoax> 744
[14:49] <roaksoax> when should probably be 644
[14:49] <allenap> smoser: bin/maas createsuperuser --noinput, I think.
[14:50] <roaksoax> that's just weird
[14:50] <allenap> roaksoax: Okay, that's a separate bug.
[14:50] <allenap> One thing at a time.
[14:52] <roaksoax> allenap: yeah sorry I thought the branch addressed DNS permissions too
[14:56] <roaksoax> allenap: this branch: https://code.launchpad.net/~andreserl/maas/maas_set_correct_file_permissions/+merge/121974 took care of them
[14:57] <smoser> i'm curious.
[14:58] <smoser> is it possible to limit the dhcp server that maas runs to a certain set of interfaces?
[14:58] <smoser> it seems like for a dhcp server, this is generally a requirment.
[14:58] <roaksoax> allenap: hold on, so you are working on my proposal which mas rejected by jtv?
[15:01] <allenap> roaksoax: Yeah, though only in spirit. I'm starting with tests.
[15:01] <roaksoax> allenap: hehe ok, cause the atomic_write took care of the DNS permissions too
[15:01] <allenap> smoser: Should be possible. We need to do that for the maas-as-router story.
[15:02] <roaksoax> allenap: btw, given the above gets fixed today, we can upload to the archives a quantal version today
[15:04] <allenap> roaksoax: We don't need a quantal version yet, so don't put time into that. We're still thinking about SRU right now.
[15:05] <roaksoax> allenap: heh, the Precise packaging is based on the quantal one
[15:05] <roaksoax> allenap: so if it doesn't work in quantal, then it wont work in precise
[15:05] <roaksoax> allenap: so for me releasing to precise means I can SRU
[15:05] <allenap> Right, okay.
[15:05] <roaksoax> allenap: cause we cannot SRU if we don't have a quantal version
[15:05] <roaksoax> :)
[15:06] <allenap> roaksoax: Does MAAS need to be fully operational on Quantal, or just build?
[15:06] <roaksoax> allenap: for now build and work
[15:06] <roaksoax> allenap: it currentlyu builds and work
[15:06] <roaksoax> allenap: the nly thing yet to be considered is DHCP
[15:08] <roaksoax> allenap: btw.., how is MAAS inserting the hostnames into the DNS server?
[15:08] <roaksoax> allenap: i don't see the files being modified and inserting a deployed system into it
[15:08] <roaksoax> allenap: unless this has to work wiht MAAS DHCP
[15:12] <allenap> roaksoax: I can't remember. rvba can talk about that next week.
[15:12] <roaksoax> allenap: alright, so we have a broken MAAS
[15:12] <roaksoax> allenap: cause juju wont work
[15:12] <roaksoax> without MAAS DNS
[15:13] <roaksoax> YaaaaaaaaaaaaaaaaaaaaaaaaaY
[15:13] <roaksoax> which means it won't work with external DNS/DHCP
[15:17] <allenap> roaksoax: Juju will work with IP addresses, but it's being given hostnames by the MAAS API. We can change that.
[15:19] <roaksoax> allenap: I just noticed that an enlisted node ended up not having its hostname
[15:19] <roaksoax> allenap: the one provided by the DNS server
[15:19] <roaksoax> i need to re-check this
[15:19] <roaksoax> hold on
[15:21] <smoser> allenap, so after '--noinput' how do i set a password without being prompted?
[15:24] <allenap> smoser: Sorry, s/createsuperuser/createadmin/, then bin/maas createadmin --username ... --email ... --password ...
[15:26]  * allenap is not friends with django-admin (which is what `maas` is)
[15:27] <smoser> allenap, thanks.
[15:27] <smoser> roaksoax, so i installed maas from ppa
[15:31] <smoser> i clicked the nice little button so i could run dhcp
[15:31] <smoser> but i dont see any dhcp processes running
[15:31] <smoser> (i expected 'ps -axw | grep dh' to show something other than dhclient)
[15:34] <roaksoax> smoser: tail -f /var/log/maas/celery.log
[15:34] <smoser> so what was supposed to happen when i clicked that 'manage dhcp' button?
[15:34] <roaksoax> smoser: the issue i think would be the fact that dhcpd.conf needs to be rewritten
[15:34] <roaksoax> smoser: that would rewrite the dhcpd.conf
[15:34] <smoser> stack trace
[15:35] <roaksoax> smoser: most likely due to lack of permissions of doing so
[15:35] <smoser> http://paste.ubuntu.com/1178033/
[15:35] <roaksoax> s/of doing so/to do so
[15:35] <smoser> right
[15:35] <roaksoax> smoser: yeah that's it
[15:35] <smoser> so what do i do to work around?
[15:35] <roaksoax> smoser: TBH I haven't gotten there yet :)
[15:36] <roaksoax> smoser: chown maas:root dhcpd.conf
[15:36] <smoser> will somethign re-try ?
[15:37] <roaksoax> smoser: yes
[15:38] <roaksoax> smoser: or you can restart pserv/celery
[15:38] <roaksoax> maas-pserv maas-celery
[15:38] <smoser> that will *restart* it?
[15:38] <smoser> sudo restart maas-pserv ; sudo restart maas-celery
[15:38] <smoser> thats probably what i wanted
[15:39] <smoser> hm.. still no dhcpd running
[15:41] <roaksoax> smoser: what does celery say now
[15:41] <smoser> http://paste.ubuntu.com/1178038/
[15:42] <roaksoax> no idea then
[15:42] <roaksoax> it might be related to the same i'm seeing with DNS
[15:42] <roaksoax> not config output written
[15:43] <smoser> just to be forthcoming...
[15:43] <smoser> i did install with: sudo DEBIAN_FRONTEND=noninteractive apt-get --assume-yes install maas </dev/null
[15:45] <roaksoax> yeah that should have done anything to do with it
[15:45] <roaksoax> smoser: btw.. your ephemeral image is not getting the hostname  from the DNS server
[15:45] <roaksoax> and passing it to maas-enlist right?
[15:46] <smoser> enlistment just does whatever it is told to do
[15:47] <smoser> hold on. looking for what it is told to do
[15:47] <roaksoax> smoser: right, idk why I think I was enlisting the machine passing the correct hostname
[15:47] <roaksoax> smoser: but today I see it doesn't
[15:47] <roaksoax> so that's why i was like WTF
[15:47] <smoser> contrib/preseeds_v2/enlist_userdata
[15:48] <roaksoax> smoser: ok, so how do you think we should detect the hostname from the DNS server?
[15:49] <smoser> should we?
[15:50] <roaksoax> smoser: yes
[15:50] <roaksoax> smoser: debian installer does it, and that's how we pass the hostname
[15:50] <roaksoax> smoser: so we need to do the equivalent in the image
[15:50] <roaksoax> smoser: that is usefull when we have externa; DNS/DHCP
[15:51] <roaksoax> otherwise we are screwed :)
[15:51] <smoser> roaksoax you just want the hostname ?
[15:52] <roaksoax> smoser: yes
[15:54] <roaksoax> smoser: so my devenv it passes DNS name as "node01" and the image should be able to obtain that DNS name and pass it back to maas
[15:54] <roaksoax> on the enlistment
[15:54] <roaksoax> smoser: if it is "maas.andres.home" it should also grab that and pass it
[15:54] <roaksoax> smoser: so I think it would be all of that
[15:54] <allenap> smoser, roaksoax: My latest fix: https://code.launchpad.net/~allenap/maas/maas-set-correct-file-permissions/+merge/122310
[15:55] <allenap> I'll also revert the previous fix for this bug.
[15:56] <smoser> allenap, wel..
[15:56] <smoser> its curious that you're doing chmod after you've put the files in place
[15:56] <smoser> given the big worry there about a race condition
[15:57] <smoser> (which honestly is not really that large a concern, as this weill be very small window and not a common operation)
[15:58] <smoser> but why wouldn' tyou fix permissions before you move it into place?
[15:59] <smoser> note, if this is threaded code we have a read-update-write race condition there also
[16:03] <smoser> roaksoax, one thing you could do...although its not perfect is just get the ip address of the right nic and try to reverse lookup of that.
[16:04] <smoser> the data for the lease is actually in /var/lib/dhcp/dhclient.*
[16:06] <roaksoax> smoser: uhmmm right, i guess i could do that... which will not work on d-i though
[16:06] <roaksoax> but we obtain that in a different way
[16:06] <smoser> how do you obtain it in di?
[16:07] <roaksoax> smoser: from debconf
[16:07] <roaksoax> database
[16:08] <smoser> roaksoax, why do you care about di?
[16:09] <roaksoax> smoser: CD
[16:09] <smoser> ok. so
[16:10] <smoser> a.) that is 2 completely different paths.  in 1, you're giving code to cloud-init to run, and in he other you're running code off the cd.
[16:10] <smoser>  so these dont have to be the same at all
[16:10] <smoser> b.) what we can do is figure out how the installer does it (if that is seen as the "correct" way) and mimic that in the code that we feed to cloud-init.
[16:11] <smoser> it is of note, that cloud-init does get messy here.
[16:14] <roaksoax> smoser: right
[16:16] <roaksoax> smoser: so I think the best approach would be to mimic what the installer is doing to get the hostname
[16:16] <roaksoax> smoser: but maybe this comes from DHCP itself
[16:16] <roaksoax> smoser: we;ll have to ask cjwatson
[16:17] <roaksoax> smoser: though he's on hollidays
[16:17] <roaksoax> smoser: and I wanted to upload to qauntal today :(
[16:46] <smoser> roaksoax, it *does* come from dhcp
[16:46] <smoser> its part of the dhcp response
[16:47] <smoser> (see the leases file)
[16:50] <roaksoax> smoser: yep
[17:24] <allenap> smoser: Good catch, thanks. Can you +1 https://code.launchpad.net/~allenap/maas/maas-set-correct-file-permissions/+merge/122310?
[17:28] <smoser> allenap, shoot
[17:28] <smoser> one mrore thing
[17:28] <smoser> please revert other changes.
[17:31] <allenap> smoser: I've added that now.
[17:32] <allenap> Launchpad seems to be on a go-slow.
[17:34] <allenap> smoser: I have to go, so if you're happy to +1 that mp, please land it too. Thanks! Have a good weekend, roaksoax too!
[17:34] <roaksoax> allenap: you too
[17:34] <smoser> allenap, also remove the "All files we create here are public"...
[17:35] <smoser> the umask is just not necessary
[17:35] <smoser> (that was also inserted in a untested attempt to fix those perms)
[17:35] <allenap> smoser: Remove that entire hunk?
[17:35] <smoser> yeah.
[17:35] <smoser> at very leas the comment is wrong
[17:36] <smoser> as that umask has no affect on the permissions of tftp
[17:37] <allenap> smoser: Done.
[17:37] <roaksoax> smoser: does the pehemeral image knows from what interface its booting obtaining DHCP address in use?
[17:38] <roaksoax> allenap: if still around and can do a quick review for the maas-import-pxe-files
[17:38] <roaksoax> bug i just filed
[17:38] <roaksoax> allenap: http://paste.ubuntu.com/1178248/
[17:39] <smoser> roaksoax, well, it can get it, yes (in the pxelinux case)
[17:39] <allenap> roaksoax: That *looks* fine to me, but without tests it's hard to say for sure. As long as you've given it a run, then cool.
[17:39] <smoser> in arm, it can't figure that out.
[17:39] <smoser> pxelinux tells linux the interface.
[17:39]  * allenap really goes.
[17:39] <smoser> roaksoax, i dont understan why you'd change maas-import-ephemerals there.
[17:40] <roaksoax> smoser: because maas-import-ephemerals goes : "There's a new image that we need to update. We have updated it, then we are going to install it with maas-provision"
[17:41] <roaksoax> smoser: but "what if there's no image to update from the remote site, then do nothing"
[17:41] <smoser> well, one could say "well, dont delete data!"
[17:42] <smoser> but i'll buy your argument.
[17:42] <roaksoax> smoser: we are not deleting, we are re-installing the ephemeral image with maas-provision
[17:42] <smoser> allenap, but i wont buy your argument of "no way to know". unit tests passing do not tell you if something is actually functional.
[17:42] <smoser> if they did, then we'd have functional maas right now.
[17:43] <smoser> *actual* test is sometimes required
[17:44] <smoser> allenap, i +1'd your MP
[17:51] <guimaluf> my maas node cannot install any apt-get cause is using the maas server as proxy. what should I do to enable proxy on maas server?
[17:53] <smoser> guimaluf, it should be running a proxy
[17:53] <smoser> because it should hvae squid-deb-proxy installed
[17:59] <guimaluf> smoser, I can install my maas node, so my squid-deb-proxy it's running and working
[17:59] <guimaluf> smoser, but after the installation process my node cannot reach the apt proxy
[18:02] <smoser> it should be able to
[18:02] <smoser> sorry i dont have any more suggestions thatn that.
[18:02] <smoser> you'll just have to debug it from the installed system.
[18:03] <smoser> roaksoax, how do i set kernel options in maas for tftp and such
[18:03] <roaksoax> smoser: i'm wondering the same thing actually :)
[18:09] <roaksoax> smoser: the commissioning image doesn't have nslookup installed, does it?
[18:09] <smoser>  /usr/share/pyshared/provisioningserver/pxe
[18:09] <smoser> thats where you change
[18:09] <smoser> see files there.
[18:09] <smoser> beautifully located in /usr/share
[18:10] <smoser> pyshared even
[18:11] <roaksoax> yep, that's the problem, they read them from there
[18:11] <smoser> roaksoax, it has 'host' (bind9-host)
[18:12] <roaksoax> smoser: so, do you think we should do that in maas enlist, and get the dns name from there?
[18:13] <smoser> well, you can. and in many cases it will work.
[18:13] <smoser> i think it sprobably good enough
[18:13] <smoser> as you dont really care about the hostname
[18:13] <smoser> hm..
[18:14] <smoser> actually, its probably good enough for now.
[18:14] <smoser> as the image is only going to bring up 1 interface
[18:14] <roaksoax> yep
[18:14] <smoser> but you aren't guaranteed that the thing would be reverse-lookupable
[18:14] <roaksoax> indeed
[18:14] <roaksoax> but it is just a wild guess
[18:15] <smoser> (note, there is a bug in the image, in that it has hard coded 'eth0', but eth0 might not be plugged in. it actually needs to figure out the booted network adatper and use it)
[18:15] <smoser> its probably sufficient for wild guess
[18:15] <smoser> but its not specifically identical to what the dhcp server gave it.
[18:18] <roaksoax> ight
[18:18] <roaksoax> right
[18:20] <allenap> smoser: I agree, about giving it a proper run. However, unit testing can get a long way there. More than anything, it's a guard against regression, and so a way to make changes with more confidence.
[18:28] <smoser> allenap, good deal. now lets try to get something functional.
[18:28] <smoser> roaksoax, you want a bug for the celery issue i ran into earlier (dhcpd.conf perms) ?
[18:28] <roaksoax> smoser: please
[18:29] <smoser> bug 1044228
[18:39] <allenap> rbasak: Looks like it's safe to land https://code.launchpad.net/~racb/maas/arm_kernel_parameters/+merge/122241.
[18:44] <rbasak> allenap: ok, thanks. I was going to run make lint to see what you meant. I should do that every time really - I was only running make test. Whitespace around []s?
[18:57] <smoser> roaksoax, http://paste.ubuntu.com/1178373/
[18:58] <smoser> but
[18:58] <smoser> $ ls -l /etc/dhcp/dhcpd.conf
[18:58] <smoser> -rw-r--r-- 1 maas root 3602 Jul 10 21:29 /etc/dhcp/dhcpd.conf
[18:58] <roaksoax> smoser: that's DNS
[18:59] <smoser> you are correct
[18:59] <smoser> duh.
[18:59] <roaksoax> make user maas chown /etc/bind/maas and files under
[18:59] <smoser> what config is it there?
[18:59] <smoser> is there a bug for that?
[19:01] <roaksoax> smoser: yeah that's fixed
[19:01] <roaksoax> smoser: haven't yet released
[19:03] <smoser> do you know what bug it was?
[19:03] <roaksoax> smoser: please review/approve: https://code.launchpad.net/~andreserl/maas/maas_preseed_userdata_hostname/+merge/122340
[19:04] <roaksoax> smoser: and is bug #1042868
[19:04] <smoser> roaksoax, that will give the full dns name retuned
[19:04] <smoser> is that what you wanted?
[19:04] <smoser> if you want short we need host=${host%.*}
[19:04] <roaksoax> smoser: that's perfect
[19:04] <smoser> ok
[19:11] <roaksoax> smoser: forgot to approve :)
[19:11] <smoser> roaksoax, is this known to you?? http://paste.ubuntu.com/1178402/
[19:12] <smoser> approved
[19:12] <roaksoax> smoser: yes I've seen it before, can't recall whether it was also a permissions issue
[19:13] <roaksoax> or was just upstream issue
[19:49] <allenap> rbasak: Yeah, the whitespace. I have a branch in progress to check lint during a test run, so soon it won't be possible to land with lint :)
[20:08] <smoser> roaksoax, well, heres where i got with trying to test this so far.
[20:08] <smoser>  http://paste.ubuntu.com/1178515/
[20:08] <smoser> i can't get dns or dhcp to consitently work.
[20:08] <smoser> dhcp doesn't start, so i didn't bother trying to boot an instance on a bridge
[20:09] <roaksoax> smoser: ok cool
[20:09] <roaksoax> smoser: we'll hvae to have a seirous talk with rvba :)
[20:09] <roaksoax> hahah
[20:10] <smoser> roaksoax, how would you recommend i get the dhcp settings from maas?
[20:10] <smoser> that i answered when it questioned me during install
[20:10] <smoser> gateway, dhcp range ...
[20:10] <smoser> i guess i need gateway is the one i really need.
[20:10] <roaksoax> smoser: yeah, so that supposedly creates the master DHCP dataase
[20:11] <smoser> it does not. not that i could convince at least.
[20:11] <smoser> for now i'll read it out of debconf
[20:12] <roaksoax> smoser: right but it should write the dhcpd.conf
[20:12] <roaksoax> which doesn't seem to do
[20:12] <roaksoax> to do it
[20:15]  * roaksoax bbl
[20:51] <smoser> roaksoax, i'm thinking we shoudl drop the "zimmer" from vdenv
[20:52] <smoser> and rather have it assume you have maas installed on the system
[20:52] <smoser> it makes it less realistic to run it on your laptop though i guess.
[23:57] <roaksoax> smoser: i agree