[00:06] <bigjools> smoser: anyone can, docs are in the source.
[00:06] <bigjools> what's up?
[00:27] <smoser> bigjools, theres just some invalid stuff there.
[00:27] <bigjools> file a bug
[00:32] <smoser> bigjools, https://code.launchpad.net/~smoser/maas/fix-ephem-doc/+merge/205675
[00:33] <bigjools> ta
[00:34] <bigjools> approved, it's landing now
[00:35] <bigjools> I'll regenerate the website docs a bit later
[00:51] <bjf> bigjools, if i want to take a node that is currently provisioned with saucy and reprovision it with precise do i need to delete the node from maas an go through a complete discovery/commisioning/allocation ?
[00:52] <bigjools> bjf: provisioned meaning "allocated" ?
[00:52] <bjf> bigjools, sure, maas fully installed saucy on it
[00:52] <bjf> bigjools, and now i want to put precise on it
[00:52] <bigjools> and it's up and allocated to a user?
[00:53] <bjf> bigjools, it's allocated to "maas" so my maas user i guess
[00:53] <bigjools> ok
[00:53] <bigjools> are you using the maas ui?
[00:53] <bigjools> or juju?
[00:53] <bjf> i'm not doing any juju, i'm trying to just use the maas-cli
[00:54] <bigjools> ok, stop the node, change its default series, then start it up again
[00:54] <bigjools> no need to delete - maas is better than that
[00:54] <bigjools> it's a cloud-like resource, remember
[00:54] <bjf> ok, i'll try that, i had no luck with that earlier, but i'll try it again
[00:54] <bigjools> you have to edit the node's default series
[00:55] <bjf> ack
[01:45] <bjf>  doing a "maas-cli <user> nodes list" doesn't show the "Release" or "Power parameters" for the nodes
[01:46] <bigjools> don't know what you mean by Release, but you need to be admin to see power IIRC
[01:46] <bjf> bigjools, Release is what will be installed on the node (saucy, precise, etc.). i am using the admin account
[01:47] <bigjools> oh, series
[01:47] <bjf> bigjools, the UI says "Release" but yes, the series
[01:47] <bigjools> hmm ok I think the power thing was something we wanted to show to admins only but didn't get around to it yet
[01:47] <bjf> ack
[01:47] <bigjools> power has creds in it
[01:48] <bigjools> and yes the distro series is not returned in the api data
[01:51] <bigjools> bjf: just read your email, still having cdu trouble?
[01:53] <bjf> bigjools, yes, unfortunately
[01:53] <bjf> bigjools, i'm able to work around it right now while i learn the ins and outs of MAAS
[01:53] <bigjools> bjf: it could be a bug in the template for cdu, but it's what we use in the QA lab so it ought to work
[01:54] <bjf> bigjools, i looked at the template and it looked right to me, it looked exacly like what i can do from the command line
[01:54] <bjf> bigjools, so, that's why i'm confused
[01:54] <bigjools>     ${fence_cdu} -a ${power_address} -n ${power_id} -l ${power_user} -p ${power_pass} -o "$@"
[01:55] <bjf> exactly
[01:55] <bigjools> ok
[01:55] <bigjools> are you issuing the command from the same machine as the cluster controller that would issue it?
[01:55] <bjf> yes
[01:56] <bigjools> can you see the power_on task appearing in the celery.log on the cluster?
[01:58] <bjf> got a traceback
[01:59] <bjf> http://paste.ubuntu.com/6912536/
[02:00] <bigjools> that's a power_off command failing
[02:00] <bjf> bigjools, i think i known what i'm doing wrong
[02:01] <bigjools> the log is a bit crap, it should be showing an error message but there's a bug that hides it
[02:01] <bjf> indeed, i'm just an idiot ... fixed
[02:01] <bigjools> ok :)
[02:01] <bigjools> what was it?
[02:02] <bjf> i normally use the web ui for the CDU and i'd cut/pasted the url into the IP address field for the power param
[02:02] <bjf> not *just* the ip addr
[02:02] <bigjools> ah!
[02:15] <bjf> bigjools, i'm using and existing dhcp server. the celery.log is getting lots of messages about dhcp leases file missing. any way to quiet those?
[02:15] <bigjools> make an empty leases file
[02:19] <bjf> bigjools, there is an empty one at /var/lib/dhcp/dhcpd.leases
[02:19] <bigjools> bjf: that's not the one maas uses
[02:19] <bigjools> /var/lib/maas/dhcp
=== mwhudson is now known as zz_mwhudson
=== zz_mwhudson is now known as mwhudson
[04:00] <bigjools> jtv: did you get a chance to look at my other branch?
[04:01] <jtv> Still reviewing Gavin's.
[04:03] <bigjools> ah I was going to look at that too, will take a peek shortly
[04:03] <bigjools> need to get maas-enlist recipe for the daily PPA
[04:04] <bigjools> since there isn't one :(
=== mwhudson is now known as zz_mwhudson
[06:16] <bradm> bigjools: oh, that ipmi stuff we were talking about a while back, I realised our maas controller isn't on the same network as the ilo and is unable to reach it, so it doesn't even matter what the settings are. :)
[06:16] <bigjools> bradm: !
[06:18] <bradm> bigjools: yeah.
[06:19] <bigjools> bradm: would it be at all scary if we only stored the MAC address of BMCs and ARPed the IP?
[06:20] <bradm> bigjools: we were chatting about the possibility of having a ssh proxy type provider that could run ipmitool for you, I wonder how well that'd go, then you could have a locked down box on the managemetn vlan
[06:21] <bigjools> another option yeah
[06:21] <bigjools> if you want to write the maas driver for that, I will accept the patch :)
[06:22] <bradm> right, we thought you wouldn't say no to that sort of thing :)
[06:22] <bradm> not saying it will happen, just that alexlist and I were chatting
[06:24] <bigjools> it's a great idea
[06:24] <bradm> its more a question of having time to write it
[06:45] <bigjools> it will be easier when we finish the driver api
=== zz_mwhudson is now known as mwhudson
=== freeflying is now known as freeflying_away
=== freeflying_away is now known as freeflying
=== freeflying is now known as freeflying_away
=== freeflying_away is now known as freeflying
=== freeflying is now known as freeflying_away
=== freeflying_away is now known as freeflying
=== freeflying is now known as freeflying_away
[09:40] <rvba> gmb: I see, manual import of the daily ephemerals for Trusty.  We use to have a config option for this.
[09:40] <gmb> rvba: Right. Be nice if we could have one again, really. Although we won't care all that much until 16.04...
[09:43] <rvba> gmb: well, it's not really related to LTS vs. non-LTS.  The option would be useful when you want to use the ephemerals of a non-released series (LTS or not).
[09:43] <gmb> rvba: Then we should definitely have a way of doing it. I'll file a bug.
[09:43] <gmb> (If there isn't one already)
=== mwhudson is now known as zz_mwhudson
[10:27] <rvba> gmb: How can I change the status of the bugs created by maas-test?  I'd like to make successes as fixed bugs right from the start.
[10:28] <allenap> rvba: There may be permissions issues with doing that. Some statuses can only be set by bug supervisors.
[10:28] <rvba> allenap: oh, I see.  I'll change the default set of tags then.
[10:31] <rvba> gmb: btw, didn't we want to include a unique system identifier in the title of the bugs reported by maas-test?
[10:32] <gmb> rvba: We talked about it, and then we went for including the whole lshw output and the original idea got lost.
[10:33] <rvba> Okay.
[10:33] <allenap> rvba: I wouldn’t worry about fixing everything now. We can always post-process them to normalise titles.
[10:36] <rvba> allenap: it's definitely not urgent indeed.
[10:36] <rvba> I was just wondering if this was in the works or not.
[10:36] <rvba> It's a bit painful to have all the bugs filed with the same title.  Not the end of the world though.
[10:43] <rvba> gmb: (back to the Trusty ephemeral problem) There is an easy workaround: enlist and commission using Precise, deploy using Trusty.
[10:43] <gmb> rvba: Aha! Hadn't thought of that.
[10:45] <rvba> gmb: I just tried it and it works all right: http://people.canonical.com/~rvb/config.png
[10:45] <gmb> Sweet
[11:31]  * gmb is remembering why maas-test is such a pain to develop... too much waiting around.
[11:39] <jtv> Has anyone else been unable to start a VM with uvtool under Trusty?  I found this helpful post: http://cartesianproduct.wordpress.com/2011/07/31/kvm-starting-the-default-network/
[11:41] <gmb> jtv: Interesting. I had problems on Friday but strangely enough it's working fine today with absolutely no modifications whatever.
[11:42] <gmb> But possibly I've killed a chicken I didn't know about or something.
[11:42] <jtv> It's been consistently broken for me since Trusty.
[11:42] <jtv> Ah yes.  The ritual slaughter of a chicken is sometimes done accidentally.  The Old Ones are odd that way.
[11:42] <jtv> Poor documenters.  Probably Unix geeks.
[11:43] <jtv> ‘What do you mean, “rm -rf *” has no way of stopping you from making a mistake?  It clearly says “no match” the second time you run it.’
[12:57] <allenap> Anyone have time for a very quick review? https://code.launchpad.net/~allenap/maas/docs-where-art-thou/+merge/205761
[13:01] <rvba> allenap: approved
[13:01] <allenap> rvba: Thanks.
[13:38] <allenap> rvba: LP didn’t register your vote on that docs mp. Could you try again?
[14:04] <rvba> allenap: done.
[14:04] <allenap> rvba: Ta.
[14:05] <allenap> rvba: Do you think this’ll break the build?
[14:06] <rvba> allenap: I don't see why it would.
[14:06] <rvba> allenap: are you thinking about the dependencies' upgrade?
[14:10] <allenap> rvba: Yep.
[14:10] <rvba> allenap: the lander is not in the lab anymore.
[14:10] <rvba> So we don't have the restriction we use to have.
[14:12] <allenap> rvba: Cool :)
[14:22] <rvba> allenap: btw, Julian is going to give you a slap on the hand for that commit message: it doesn't state what the problem was at all :).
[14:28] <rvba> allenap: ready for the ugly bug?
[14:31] <rvba> allenap: https://bugs.launchpad.net/maas/+bug/1278895
[14:32] <ubot5> Launchpad bug 1278895 in MAAS "When any of commissioning scripts fails, the error reported contains the list of the scripts that *didn't* fail" [High,In progress]
=== freeflying_away is now known as freeflying
[15:19] <allenap> rvba: It implies that it wasn’t working on Trusty :)
=== freeflying is now known as freeflying_away
[15:20] <rvba> allenap: yeah, but why?
[15:20] <rvba> :)
[15:20] <allenap> rvba: Sorry mother ;)
[15:21] <rvba> heh
[15:21] <allenap> rvba: I’ll have to answer to father later, name of bigjools.
[15:34] <gmb> rvba: So, this is interesting... On Trusty, maas-test is consistently hanging around the "Installing MAAS" point. Or rather the VM is hanging; I can be SSH'd into it and then my connection drops, but the machine doesn't go away and m-t just sits there for hours. I'll try and get some debugging information once I've finished with my test details branch.
[15:34] <gmb> I wonder if it's OOMing.
[15:36] <rbasak> gmb: if you call uvt-kvm with --log-console-output, you should see an OOM message in /var/log/libvirt/qemu/<machine> I think. If you don't use --log-console-output, then you can connect to the live console using "virsh console <name>".
[15:36] <rvba> gmb: when you say "on Trusty" do you mean the machine where maas-test runs or the virtual machine deployed by maas-test?
[15:37] <rvba> The former I suppose… ?
[15:37] <gmb> rvba: Trusty Host + default VM series, also Trusty host + trusty VM.
[15:37] <rvba> k
[15:37] <gmb> rbasak: Thanks for the tip. I'll try that out presently.
[15:42] <gmb> Wait, what?
[15:43]  * gmb might have just found a heisenbug.
[15:48] <tomixxx4> hello guys good news: now its the first time i was able to use the command "maas-cli maas node-groups import-boot-images" :D
[15:48] <tomixxx4> (i have re-installed ubuntu server and so on :P)
[15:49] <tomixxx4> before today, i always had to execute "sudo maas-import-pxe-files"
[15:58] <tomixxx4> after installation: do i have to hit the button "import boot images" in "settings" or is done automatically through commadn above?
[16:02] <tomixxx4> the node's output console says the following: "Unablte to locate configuration file : Boot failed"
[16:12] <tomixxx4> gmb: sorry, are u online? i have the problem that when a node is commissioning and tires to download its image, it prints out "TFTP prefix: Unable to locate configuration file. Boot failed"
[16:12] <tomixxx4> gmb: never had this before
[16:13] <gmb> tomixxx4: Hi, I am online, but I'm right in the middle of something that I can't switch away from. Let me see if there's someone else available to help you debug...
[16:13] <tomixxx4> gmb: kk
[16:15] <allenap> tomixxx4: It doesn’t automatically download pxe files; you do need to ask it to do it.
[16:15] <tomixxx4> allenap: hi, i have executed the command "$ maas-cli maas node-groups import-boot-images" on maas-server
[16:15] <tomixxx4> allenap: and the yellow warning message disappeared, as expected
[16:16] <allenap> tomixxx4: I suspect the error is because the files are not yet downloaded. Have a look in /var/lib/maas/tftp on the region controller (where the webapp runs).
[16:16] <tomixxx4> allenap: kk
[16:17] <allenap> tomixxx4: That disappears when the first thing gets downloaded. Unfortunately there’s no indication yet of when it’s finished.
[16:17] <tomixxx4> allenap: kk, i thought it is ok, if the yellow message disappears
[16:17] <tomixxx4> allenap: i mean, i thought this is signalling that everything is downloaded
[16:18] <tomixxx4> allenap: ty so far!
[16:24] <tomixxx4> allenap: what should iam looking for in the suggested folder above?
[16:33] <allenap> tomixxx4: Check that $arch/$subarch/$purpose/{linux,initrd.gz} exist (and maybe root.tar.gz too).
[16:34] <tomixxx4> allenap: yes, they exist, for example in "armhf/generic/quantal/commissioning"
[16:34] <tomixxx4> allenap: or "amd64/lucid/install&"
[16:35] <allenap> tomixxx4: I assume you mean amd64/generic/lucid/install. Btw, we don’t support installing Lucid with MAAS.
[16:35] <tomixxx4> allenap: yes, sorry
[16:36] <tomixxx4> allnap: also available: precise, quantal, sausy, trusty
[16:37] <tomixxx4> allenap: same for i386
[16:39] <tomixxx4> allenap: i never had this problem when i used the command sudo maas-import-pxe-files in prior installation-trials
[16:39] <allenap> tomixxx4: Can you try booting again?
[16:39] <tomixxx4> allenap: i try all the time. nodes reboot automatically after a time
[16:39] <allenap> tomixxx4: Fwiw, doing it via the UI/API ends up calling maas-import-pxe-files anyway.
[16:39] <tomixxx4> allenap: kk
[16:40] <allenap> (We want to rewrite maas-import-pxe-files, so are discouraging people from using it.)
[16:41] <tomixxx4> allenap: k
[16:41] <tomixxx4> allenap: are u a company behind maas?
[16:44] <allenap> tomixxx4: The core team work for Canonical, but MAAS is open source and we take contributions.
[16:44] <tomixxx4> allenap: kk
[16:45] <tomixxx4> allenap: a question is it important to set "Architecture" in "Edit node" screen to "i386" if i have intel-cpus in my nodes?
[16:45] <allenap> tomixxx4: How are you starting your nodes?
[16:45] <tomixxx4> allenap: well, i push the power button :-) i have no wake-on-lan
[16:47] <tomixxx4> allenap: boot failed again
[16:48] <allenap> tomixxx4: Have you acquired the node from MAAS, e.g. by calling maas-cli maas nodes acquire?
[16:49] <tomixxx4> allenap: no i have enlisted them via boot media, the same usb-boot-stick which i have used for my maas-server
[16:51] <tomixxx4> allenap: however, i do some NAT in order to connect nodes to i-net
[16:51] <allenap> tomixxx4: Have the nodes been through a commissioning cycle.
[16:51] <allenap> ?
[16:52] <tomixxx4> allenap: yes, because 2 nodes + 1 maas server work in a prviate network. the maas-server has a second interface card which connects the server to the outside internet network
[16:52] <tomixxx4> allenap: y, i have commissioned the nodes
[16:52] <tomixxx4> allenap: but now they stuck in "commissioning"
[16:53] <allenap> tomixxx4: Okay, that means they’re not finished; commissioning runs some scripts and tells MAAS the outcome. If successful, the node should be ‘ready’ (iirc).
[16:54] <tomixxx4> allenap: yeah, the nodes will become "ready" after pxe images are downloaded, as far as i remember. it worked when i tried it a week ago
[16:54] <tomixxx4> allenap: but you do not think there is a NAT-problem the cause?
[16:55] <tomixxx4> allenap: and the nodes are aware were to download their things? or do i have maybe to set http-proxy settings in maas dashboard?
[16:55] <allenap> tomixxx4: Is the NAT between the nodes and the MAAS installation?
[16:55] <tomixxx4> no, between the interface of the maas which connects the maas to the nodes and the other interface of the maas, which connects the maas to the internet
[16:58] <tomixxx4> allenap: the script which i have used in order to set up NAT, looks as follow: http://pastebin.ubuntu.com/6915994
[16:58] <tomixxx4> allenap: i have gotten it from gmb
[16:59] <tomixxx4> allenap: eth0 connects the server to the nodes, eth1 connects the server to i-net
[17:03] <allenap> tomixxx4: I’m really sorry, but I can’t get any deeper into this. Working with NAT and machines that do not have power control is outside of scope for MAAS. It may work, but unfortunately it’s not something I have the time or the expertise to help with.
[17:06] <tomixxx4> allenap: kk, ty
=== zz_mwhudson is now known as mwhudson
[23:03] <roaksoax> smoser: ping
[23:11] <bjf> bigjools, after reboot tftp was only listening to localhost. if i simply restarted maas-pserv it would start listening on the correct addr.  i found i needed to add IFACE=eth0 to the upstart job to correct this issue.
=== CyberJacob is now known as CyberJacob|Away