=== CyberJacob is now known as CyberJacob|Away
=== freeflying_away is now known as freeflying
[02:23] <_bjorne> is someone live here?
[02:25] <_bjorne> i have some problem with maas clients.. only one client run dist-upgrade and install lxc and mongodb, the other one is not do that... can somone give some information? i have try in 12.04 and 13.10 and get same problem...
=== CyberJacob|Away is now known as CyberJacob
=== EntropyWorks_ is now known as EntropyWorks
[08:46] <jtv> bigjools, rvba: having a look at how to remove the POWER_TYPE enum.  It does seem desirable, but we do encode a lot of knowledge about power parameters for each type.
[08:47] <jtv> Maybe we could step outside that whole system for unknown power types.
[08:50] <rvba> Let me have a look at the enum to refresh my memory.
[08:52] <rvba> jtv: I'm not entirely sure why you think we can get rid of that particular enum.
[08:53] <rvba> The DISTRO_SERIES enum we can probably get rid of.
[08:53] <jtv> Julian mentioned it as a potential work item.
[08:53] <rvba> Hum, then it's not very clear to me how we can do that.
[08:55] <jtv> Not to me either.  That's why I'm looking.  :)
[08:56] <jtv> rvba, could I beg you for a review of https://code.launchpad.net/~jtv/maas-test/check-for-dhcp-server/+merge/198001 ?
[08:56] <rvba> Sure, I'll have a look right now.
[08:56] <jtv> Thanks.
[09:02] <rvba> jtv: btw, I've got a postgresql-related question for you.
[09:03] <rvba> jtv: it's about the backup/restore script allenap and I have worked on recently.
[09:03] <rvba> jtv: the backup/restore procedure for the pg db errors and I'd like your opinion about that.
[09:04] <rvba> jtv: can you ssh ubuntu@10.55.60.195 and join the byobu session there?
[09:05] <jtv> rvba: coming!
[09:05] <jtv> rvba: I'm in.
[09:06] <rvba> jtv: so I'm running backup and then restore and the pg restoration fails.
[09:07] <jtv> I wonder why plpgsql is even mentioned.
=== mthaddon` is now known as mthaddon
[09:29] <melmoth> hi there.  I have been asked if there is a way to forward maas logs in a remote syslog server. Anyone knows if this can be done ?
[09:38] <jtv> Don't think you can.  :/
[09:38] <jtv> Unless you can make your local syslog do it.
[09:39] <melmoth> if i understand correclty, the people who asked me already have a centralised syslog server, so the maas boxes send any stuff there.
[09:40] <melmoth> that is, any stuff that should have ended in /var/log/syslog , but apparently not stuff that end up in /var/log/maas/*
[09:40] <jtv> Ah, right — we don't send it to syslog yet.
[09:41] <jtv> ...rsync?
[09:42] <melmoth> i m not sure they would like that.
[09:42] <melmoth> anyway, my main question was if there was a known way. wich is not the case, knowing that was helpfull anyway, thanks :)
[09:42] <jtv> Sorry!
[09:43] <rvba> jtv: I don't see why we can't run the restore script as the postgres user.
[09:44] <jtv> Because there's no peer authentication for that login in the hba config.
[09:45] <jtv> We'd need some configuration to say "it's OK for <system user> to log into <database> as <DB user>."
[09:45] <jtv> (When using peer authentication, that is, but that's probably what we want here.)
[09:46] <rvba> I see.  The backup/restore script must be run as root (there is even a check in the code for this) so we can switch to the postgres user.
[09:46] <jtv> But I don't think it'd be desirable to twiddle that config here.
[09:46] <jtv> I'm not sure root is allowed to do that by default.
[09:46] <rvba> But the changes you've made seem to work already… ?
[09:46] <rvba> Well, you've reverted them now.
[09:47] <jtv> That was the switch from "directory" format.
[09:47] <jtv> I still don't know why that made the difference.  :(
[09:47] <jtv> Yes, easy to reproduce.
[09:47] <jtv> Also of course, the default format is pretty slow.
[09:48] <jtv> No postgres "ident" entry for root→postgres by default.
[09:48] <jtv> The way to get around that is to sudo to the postgres system user.
[10:00] <jtv> rvba: it's coming to the point where I think the database should simply be dropped before restoring.
[10:00] <jtv> The dump can re-create the database, and then the maas user will be its owner.
[10:00] <jtv> At that point the permissions errors will go away.
[10:30] <jtv> rvba: changes to use the default format are now in place (but cleaner than before).  It'll be slow and bloated, but also simple.
[10:30] <rvba> jtv: just checking, the dhcp stuff doesn't introduce any new dependency right?
[10:30] <jtv> Not any more.
[10:30] <rvba> jtv: cool, thanks for your help.  I'll incorporate your changes into the branch.
[10:30] <rvba> All right.
[10:30] <jtv> It was going to import the code from maas, but that's what I took out today.
[10:31] <Martin_____> If I only need to be able to deploy Ubnutu to bare metal. Is MAAS a good solution for me or should I take a look at Razor/Cobbler or Foreman? I will hand over the clients to puppet as soon as they are installed.
[10:32] <Martin_____> I like that MAAS can handle power on and off.
[10:32] <jtv> (If you have the hardware for it, of course :)
[10:32] <jtv> Deploying Ubuntu to bare metal is exactly what MAAS does, so that sounds like a good match.
[10:33] <jtv> You _can_ integrate with Juju to deploy actual software, but you don't have to.
[10:34] <Martin_____> jtv: I don't at the moment want to use juju as we have our stuff in puppet.
[10:34] <jtv> rvba: you'll want to try that restore in a situation where the database does not exist yet as well, or at least one where it's empty.
[10:34] <rvba> jtv: well, the db is kind of empty in the testing machine.
[10:34] <rvba> s/in/on/
[10:34] <jtv> Martin_____: that's fine.  You ask maas to allocate you a machine (optionally with constraints), and you get an installed and running machine that you can ssh into with your registered key.
[10:35] <rvba> jtv: I'm getting rid of the VM now.
[10:35] <jtv> rvba: "kind of" — not "completely."  :)  The dump will also re-create tables, set permissions, and so on.
[10:35]  * jtv gets out of the VM
[10:37] <Martin_____> jvt: Whats with the linux bridge interfaces that are installed on the nodes. Is it for the LXC containers?
[10:53] <rvba> jtv: once your branch is merged, I'll give it a go in the lab.  Just for safety.
[11:09] <jtv> Good man.
[11:10] <jtv> And thanks for the review.
[11:13] <gmb> rvba: Before your EoD will you let Jeff know that maas-test is done and prod him re: testing? It'd be lovely if we could announce this internally at least next week.
[11:13] <rvba> gmb: already done :)
[11:13] <gmb> Sweet!
[11:23] <rvba> jtv: I found a problem with the dhcp stuff
[11:24] <jtv> That was quick.
[11:24] <rvba> jtv: http://paste.ubuntu.com/6529295/
[11:25] <rvba> the authbind problem.
[11:25] <rvba> Maybe we should simply force the user to run maas-test with sudo…
[11:25] <rvba> Since it's used everywhere.
[11:26] <jtv> That's how I've been running it...  Completely forgot that it wasn't standard.
[11:26] <jtv> But yes, we do sudo all over the place anyway...
[11:26] <jtv> When not ourselves, then inside uvtool.
[11:26] <rvba> Yes.
[11:27] <jtv> I can have a must-be-run-as-root patch up in no time.
[11:27] <jtv> Since main() is still fresh in my memory, and I've added a first test for it.
[11:27] <rvba> http://paste.ubuntu.com/6529316/
[11:28] <jtv> Hey, don't I recognize that from the maas-backup code?  :)
[11:28] <rvba> heh
[11:28] <jtv> Why the args.test?
[11:29] <rvba> Oh, that's just a shortcut in maas-backup to simulate a run.
=== jtv1 is now known as jtv
[11:31] <jtv> rvba: power loss.  Amazing how little drama that is nowadays.  Anyway... ISTM patching geteuid() in tests makes more sense than a test argument, no?
[11:31] <rvba> jtv: definitely.  But in maas-{backup,restore} we have no tests (yet), hence the shortcut.
[11:36] <jtv> Ah OK
[11:36] <jtv> So I _did_ know that exact code.  :)'
[11:36] <rvba> :)
[11:38] <jtv> And before 2014 starts, I think I'll just update the copyright on main.py from 2012 to 2013.  :)
[11:38] <jtv> Sorry, test_main.py.
[14:10] <_bjorne> Do someone know how im restart cloud-init script so i can debug it? i have some problem with some nodes, only one node run dist-upgrade and installs lxxc and mongodb for me.
[14:12] <_bjorne> the node dont pick up user-data and cloud-config for me.
[14:39] <gmb> rvba, allenap: I have a branch for reporting, finally! It's not completely tested, but the bit that isn't tested is one small chunk, and I'm going to write tests for that this afternoon. But the functionality is done: https://code.launchpad.net/~gmb/maas-test/add-reporting/+merge/198067
[14:39] <gmb> Sorry it's a bit lengthy.
[14:41] <allenap> gmb: \o/ I have to travel now, but I’ll take a look later unless rvba beats me to it (hint).
[15:14]  * gmb -> also travelling; bbiab
=== freeflying is now known as freeflying_away
=== freeflying_away is now known as freeflying
[15:28] <roaksoax> allenap: around?
[15:28] <roaksoax> i guess he is not
[15:35] <_bjorne> how is cloud-init funtion in clients? can i debug it on some way manual?
=== freeflying is now known as freeflying_away
[16:11] <allenap> roaksoax: Hi there, what’s up?
[16:12] <roaksoax> allenap: just wante dto ask how does the mprovisioning server detect the architecture being pxe booted, but i found this : https://code.launchpad.net/~racb/maas/arch-detect/+merge/127458
[16:12] <roaksoax> so that pretty much answered my question
[16:13] <allenap> Cool :)
=== CyberJacob is now known as CyberJacob|Away
=== freeflying_away is now known as freeflying