bigjools | smoser: anyone can, docs are in the source. | 00:06 |
---|---|---|
bigjools | what's up? | 00:06 |
smoser | bigjools, theres just some invalid stuff there. | 00:27 |
bigjools | file a bug | 00:27 |
smoser | bigjools, https://code.launchpad.net/~smoser/maas/fix-ephem-doc/+merge/205675 | 00:32 |
bigjools | ta | 00:33 |
bigjools | approved, it's landing now | 00:34 |
bigjools | I'll regenerate the website docs a bit later | 00:35 |
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:51 |
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:52 |
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:53 |
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:54 |
bjf | ack | 00:55 |
bjf | doing a "maas-cli <user> nodes list" doesn't show the "Release" or "Power parameters" for the nodes | 01:45 |
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:46 |
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:47 |
bigjools | and yes the distro series is not returned in the api data | 01:48 |
bigjools | bjf: just read your email, still having cdu trouble? | 01:51 |
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:53 |
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:54 |
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:55 |
bigjools | can you see the power_on task appearing in the celery.log on the cluster? | 01:56 |
bjf | got a traceback | 01:58 |
bjf | http://paste.ubuntu.com/6912536/ | 01:59 |
bigjools | that's a power_off command failing | 02:00 |
bjf | bigjools, i think i known what i'm doing wrong | 02:00 |
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:01 |
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:02 |
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:15 |
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 | 02:19 |
=== mwhudson is now known as zz_mwhudson | ||
=== zz_mwhudson is now known as mwhudson | ||
bigjools | jtv: did you get a chance to look at my other branch? | 04:00 |
jtv | Still reviewing Gavin's. | 04:01 |
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:03 |
bigjools | since there isn't one :( | 04:04 |
=== mwhudson is now known as zz_mwhudson | ||
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:16 |
bradm | bigjools: yeah. | 06:18 |
bigjools | bradm: would it be at all scary if we only stored the MAC address of BMCs and ARPed the IP? | 06:19 |
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:20 |
bigjools | another option yeah | 06:21 |
bigjools | if you want to write the maas driver for that, I will accept the patch :) | 06:21 |
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:22 |
bigjools | it's a great idea | 06:24 |
bradm | its more a question of having time to write it | 06:24 |
bigjools | it will be easier when we finish the driver api | 06:45 |
=== 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 | ||
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:40 |
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) | 09:43 |
=== mwhudson is now known as zz_mwhudson | ||
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:27 |
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:28 |
rvba | gmb: btw, didn't we want to include a unique system identifier in the title of the bugs reported by maas-test? | 10:31 |
gmb | rvba: We talked about it, and then we went for including the whole lshw output and the original idea got lost. | 10:32 |
rvba | Okay. | 10:33 |
allenap | rvba: I wouldn’t worry about fixing everything now. We can always post-process them to normalise titles. | 10:33 |
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:36 |
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:43 |
rvba | gmb: I just tried it and it works all right: http://people.canonical.com/~rvb/config.png | 10:45 |
gmb | Sweet | 10:45 |
* gmb is remembering why maas-test is such a pain to develop... too much waiting around. | 11:31 | |
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:39 |
gmb | jtv: Interesting. I had problems on Friday but strangely enough it's working fine today with absolutely no modifications whatever. | 11:41 |
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:42 |
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.’ | 11:43 |
allenap | Anyone have time for a very quick review? https://code.launchpad.net/~allenap/maas/docs-where-art-thou/+merge/205761 | 12:57 |
rvba | allenap: approved | 13:01 |
allenap | rvba: Thanks. | 13:01 |
allenap | rvba: LP didn’t register your vote on that docs mp. Could you try again? | 13:38 |
rvba | allenap: done. | 14:04 |
allenap | rvba: Ta. | 14:04 |
allenap | rvba: Do you think this’ll break the build? | 14:05 |
rvba | allenap: I don't see why it would. | 14:06 |
rvba | allenap: are you thinking about the dependencies' upgrade? | 14:06 |
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:10 |
allenap | rvba: Cool :) | 14:12 |
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:22 |
rvba | allenap: ready for the ugly bug? | 14:28 |
rvba | allenap: https://bugs.launchpad.net/maas/+bug/1278895 | 14:31 |
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] | 14:32 |
=== freeflying_away is now known as freeflying | ||
allenap | rvba: It implies that it wasn’t working on Trusty :) | 15:19 |
=== freeflying is now known as freeflying_away | ||
rvba | allenap: yeah, but why? | 15:20 |
rvba | :) | 15:20 |
allenap | rvba: Sorry mother ;) | 15:20 |
rvba | heh | 15:21 |
allenap | rvba: I’ll have to answer to father later, name of bigjools. | 15:21 |
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:34 |
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:36 |
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:37 |
gmb | Wait, what? | 15:42 |
* gmb might have just found a heisenbug. | 15:43 | |
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:48 |
tomixxx4 | before today, i always had to execute "sudo maas-import-pxe-files" | 15:49 |
tomixxx4 | after installation: do i have to hit the button "import boot images" in "settings" or is done automatically through commadn above? | 15:58 |
tomixxx4 | the node's output console says the following: "Unablte to locate configuration file : Boot failed" | 16:02 |
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:12 |
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:13 |
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:15 |
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:16 |
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:17 |
tomixxx4 | allenap: ty so far! | 16:18 |
tomixxx4 | allenap: what should iam looking for in the suggested folder above? | 16:24 |
allenap | tomixxx4: Check that $arch/$subarch/$purpose/{linux,initrd.gz} exist (and maybe root.tar.gz too). | 16:33 |
tomixxx4 | allenap: yes, they exist, for example in "armhf/generic/quantal/commissioning" | 16:34 |
tomixxx4 | allenap: or "amd64/lucid/install&" | 16:34 |
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:35 |
tomixxx4 | allnap: also available: precise, quantal, sausy, trusty | 16:36 |
tomixxx4 | allenap: same for i386 | 16:37 |
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:39 |
allenap | (We want to rewrite maas-import-pxe-files, so are discouraging people from using it.) | 16:40 |
tomixxx4 | allenap: k | 16:41 |
tomixxx4 | allenap: are u a company behind maas? | 16:41 |
allenap | tomixxx4: The core team work for Canonical, but MAAS is open source and we take contributions. | 16:44 |
tomixxx4 | allenap: kk | 16:44 |
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:45 |
tomixxx4 | allenap: boot failed again | 16:47 |
allenap | tomixxx4: Have you acquired the node from MAAS, e.g. by calling maas-cli maas nodes acquire? | 16:48 |
tomixxx4 | allenap: no i have enlisted them via boot media, the same usb-boot-stick which i have used for my maas-server | 16:49 |
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:51 |
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:52 |
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:53 |
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:54 |
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:55 |
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:58 |
tomixxx4 | allenap: eth0 connects the server to the nodes, eth1 connects the server to i-net | 16:59 |
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:03 |
tomixxx4 | allenap: kk, ty | 17:06 |
=== zz_mwhudson is now known as mwhudson | ||
roaksoax | smoser: ping | 23:03 |
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. | 23:11 |
=== CyberJacob is now known as CyberJacob|Away |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!