=== freeflying is now known as freeflying_away
[01:24] <melmoth> hey, i have machine that do not wake on lan when i accept and commission them with maas, but they do reboot if i use etherwake...
[01:25] <melmoth> any idea what could be the problem ? (note that i had to install etherwake manually to do the test, i would have expected to be installed already)
[01:29] <bigjools> melmoth: the template uses wakeonlan ahead of etherwake
[01:30] <bigjools> if you can't get wakeonlan working manually, edit the template.
[01:30] <melmoth> it works with etherwake
[01:30] <melmoth> ahh, i did not try with wakeonlan as acommand line tool
[01:31] <melmoth> not installed neither
[01:32] <melmoth> i dont undertsand. Is wakeonline an otther tool that do the same stuff as etherwake ?
[01:33] <melmoth> ahh, worng spelling wakeonlan it is
[01:40] <melmoth> bigjools, looks like wakeonlan does not work, do you know where is the template to change the command use ?
[01:41] <bigjools> depends on your maas version
[01:41] <bigjools> latest changes put it under /etc/maas/
[01:41] <bigjools> otherwise it's hiding in the source tree :(
[01:41] <bigjools> but search for ether_wake.template
[01:42] <melmoth> ok, thanks
[02:08] <melmoth> hmmm, readying the template it looked to me it was first trying wakeonlan if the binary was there, and then etherwake. so i apt-gte remove wakeonlan
[02:08] <melmoth> however, the node still dont start up automatically when i accept and comission them
[02:26] <melmoth> changing the maas sudoer file and adding a sudo before the call to etherwake did work. I think i found a bug....
[02:26] <bigjools> weird
[02:26] <bigjools> I've never had to sudo for that
[02:27] <melmoth> stuff is running under the maas user, and if i try to run etherwake under a non root user it complain and tell me i need ot be root
[02:27] <melmoth> so we try to use sudo as maas, but we were not on the sudoer file.
[02:27] <melmoth> and then when we had it working with sudo as maas manually, we change the template.
[02:28] <melmoth> i do not know if before etherwake was suppose to be run by a regular user, i never used it before
[02:28] <melmoth> nor did i use wakeonlan neither (but this one does not seem to complain about being a reular user)
[02:30] <bigjools> this is probably why we defaut to wakeonlan
=== freeflying_away is now known as freeflying
[03:44] <melmoth> i'm using maas 1.2+bzr1373+df (main one on precise), and when i try to bootstrap juju (juju-core 1.13.2-4~1703~) i have an error (BQD REQUEST) and maas.log   complain about 'this field cannot be blanc'....
[03:44] <melmoth> ... to be continued...
[03:45] <bigjools> use the maas package in -proposed
[03:45] <melmoth> it looks like bug 1204507 but we already have changed /usr/share/pyshqred/maasserver/models/filestoirage.py
[03:45] <ubot5> bug 1204507 in maas (Ubuntu Quantal) "MAAS rejects empty files" [Undecided,Confirmed] https://launchpad.net/bugs/1204507
[03:46] <melmoth> i ll give a try with the maas package in proposed.
[03:58] <melmoth> i dont find a proposed ppa, is it the same as maas-maintainers/dailybuilds ?
[03:58] <bigjools> -proposed is a pocket
[03:58] <melmoth> i m afraid i dont know what that mean
[03:58] <bigjools> check the bug for details
[03:58] <melmoth> ok
[03:59] <bigjools> it tells you how to use the package before it's released
[03:59] <mwhudson> melmoth: https://wiki.ubuntu.com/Testing/EnableProposed
[05:21] <MACscr> ok, so how do i get the mac addresses for maas? aka, whats the easiest way?
[05:31] <bigjools> you don't need to get them, enlistment detects them
[05:34] <MACscr> hmm, i need to figure out how i am going to do the dhcp
[05:35] <MACscr> right now im just testing at home and just have a simple tomato based router
[05:42] <melmoth> talking about dhcp we have a funny problem here, we are bootstraping...a node is picked up, it boot
[05:43] <melmoth> it gets an ip for the pxe server, download the installer, and when it need a new ip duroing the install stage, it never got one
[05:43] <melmoth> tcpdumping on the mass box, we see the pxe dhcp request, but not the installer one.
[05:44] <melmoth> frm the installed node console we checked it was doing a request on the right nic. So it looks like either a funny network (but who can detect if it s a pxe request or a reglar dhcp one)
[05:44] <melmoth> or a bug in the precise image installer...
[05:44] <melmoth> any idea ?
[05:49] <MACscr> hmm, can the maas dhcp server be setup to pretty much not give an ip to something thats not added as a node? i wont pfsense to do be my main dhcp server
[06:43] <melmoth> hmm, now on the bootstrap node, it complain about juju.go:89 state: connectin failed, will retry dial tcp 127.0.0.1:37017 connection refused
[06:43] <melmoth>  nothing is listening on this port
[06:43] <melmoth>  mongodb is installed
[06:43] <melmoth>  but it s not listening on this port, it s listening on 27017 and 28017
[06:45] <bigjools> MACscr: yes, edit the dhcp template to exclude MACs
[07:56] <MACscr> bigjools: hmm, after installing maas-dhcp, i cant even get maas to start anymore
[07:56] <MACscr> weird
[07:56] <MACscr> getting django connection errors
[09:10] <julianwa> roaksoax: ping
=== freeflying is now known as freeflying_away
[13:23] <roaksoax> julianwa: pong
[13:24] <roaksoax> jtv: when do you think the stuff dependent in djorm-ext-pgarray will land?
[13:31] <jtv> roaksoax: whenever you say it's OK, really.  :)  I was waiting until I knew we had the package.
[13:33] <roaksoax> jtv: wellit is still in the new queue
[13:38] <jtv> roaksoax: That's OK for now.  I can hold these branches for a few more days if need be.
[13:38] <roaksoax> ok cool thanks
[13:39] <jtv> I do wonder about one thing: the package seemed to use slightly different names in different places.  Is that normal?
[13:39] <jtv> I think the package is djorm-ext-pgarray and then it's imported as ext_pgarray or something.
[13:39]  * jtv checks
[13:39] <roaksoax> jtv: yep
[13:40] <jtv> Ah: I had to import "djorm_pgarray."
[13:40] <roaksoax> jtv: so the binary package will be python-djorm-ext-pgarray
[13:40] <julianwa> roaksoax: hey, about bug 1086162 - IPMI based power management default to IPMI 1.5 based authentication.  what's the 'another method'?
[13:40] <jtv> But I can still import it as djorm_pgarray?
[13:40] <ubot5> bug 1086162 in MAAS "IPMI based power management default to IPMI 1.5 based authentication" [High,Triaged] https://launchpad.net/bugs/1086162
[13:40] <julianwa> roaksoax: I met same problem on HP DL580 G7.
[13:41] <roaksoax> julianwa: you just have to tell the machines to use IPMI version 2
[13:41] <julianwa> roaksoax: everytime I need to change IPMI type to 2.0 manually. otherwise servers can't power on by MAAS.
[13:42] <roaksoax> julianwa: yep that's how it is right now
[13:42] <julianwa> roaksoax: it takes a lot time if there're many servers...
[13:42] <roaksoax> julianwa: you might want to file a bug instead saying that you have to manually select IPMI version 2
[13:43] <julianwa> roaksoax: yes. everytime a server is enlisted/commissioned, the IPMI type will change to 'auto_detect' which is not work.
[13:44] <julianwa> roaksoax: I have to change it back to 2.0 manually.
[13:44] <roaksoax> julianwa: yeah, so file a bug
[13:44] <julianwa> roaksoax: okay.
[13:48] <julianwa> roaksoax: thx :-)
=== freeflying_away is now known as freeflying
=== freeflying is now known as freeflying_away
=== freeflying_away is now known as freeflying
=== kentb is now known as kentb-out
=== CyberJacob is now known as CyberJacob|Away
=== CyberJacob|Away is now known as CyberJacob