headers
Tsai Li Ming | 14 Sep 14:42
Gravatar

Re: Creating a multi-boot nodegroup


On Tuesday 14,September,2010 10:40 AM, George Goh wrote:
> Hi,
>
> Can someone show me how to create a proper multiboot nodegroup? I have tried
> the following, but the node disappears when moving a node from diskless to
> multiboot (this is not actually a diskless machine, I just don't want to
> touch the disks):
>
> <BEGIN TRANSCRIPT>
>
> [root <at> gg-kusu ~]# python
> Python 2.4.3 (#1, Sep  3 2009, 15:37:37)
> [GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> from kusu.core.database import *
>>>> db = DB('postgres', 'kusudb', 'apache')
>>>> multiboot = NodeGroups(ngname='localboot', nameformat='localboot#NNN',
> installtype='multiboot', type='compute')
>>>> multiboot.kparams = 'hd0'
>>>> multiboot.networks=[db.Networks.selectfirst_by(type='provision')]
>>>> db.flush()
>>>>
> [root <at> gg-kusu ~]# ngedit -l
> unmanaged :  : other
> installer-centos-5.5-x86_64 :  : installer
> compute-centos-5.5-x86_64 :  : compute
> compute-imaged-centos-5.5-x86_64 :  : compute-imaged
> compute-diskless-centos-5.5-x86_64 :  : compute-diskless
> groupA : clone : compute-diskless
(Continue reading)

Permalink | Reply | 1 comment |
headers
George Goh | 14 Sep 04:40

Creating a multi-boot nodegroup

Hi,

Can someone show me how to create a proper multiboot nodegroup? I have tried
the following, but the node disappears when moving a node from diskless to
multiboot (this is not actually a diskless machine, I just don't want to
touch the disks):

<BEGIN TRANSCRIPT>

[root <at> gg-kusu ~]# python
Python 2.4.3 (#1, Sep  3 2009, 15:37:37)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from kusu.core.database import *
>>> db = DB('postgres', 'kusudb', 'apache')
>>> multiboot = NodeGroups(ngname='localboot', nameformat='localboot#NNN',
installtype='multiboot', type='compute')
>>> multiboot.kparams = 'hd0'
>>> multiboot.networks=[db.Networks.selectfirst_by(type='provision')]
>>> db.flush()
>>>
[root <at> gg-kusu ~]# ngedit -l
unmanaged :  : other
installer-centos-5.5-x86_64 :  : installer
compute-centos-5.5-x86_64 :  : compute
compute-imaged-centos-5.5-x86_64 :  : compute-imaged
compute-diskless-centos-5.5-x86_64 :  : compute-diskless
groupA : clone : compute-diskless
groupB : clone : compute-diskless
localboot :  : compute
(Continue reading)

Permalink | Reply | 0 comments |
headers
George Goh | 31 Aug 06:21

Make cfmsync show status of individual updates

Hi,

I created a kit with component post scripts (these create a new nodegroup)
that run during cfmsync.

However, when I run `cfmsync -fp`, it seems to return immediately, with the
script seemingly running in the background.

Anyway, to bring this background output to the foreground?

Thanks,
-George
Permalink | Reply | 3 comments |
headers
George Goh | 26 Aug 10:38

Specifications for Kit API

Hi,

Are there any publicly available specifications of the various kit versions?

Thanks,
-George
Permalink | Reply | 1 comment |
headers
kura2lincah | 26 Sep 12:33
Picon
Gravatar

[ask] idea or topic for my final project that related to cluster

hello, I'm undergraduate student from indonesia.

I'm now in the final semester of my course.
I want to make a research for my final project that related to Kusu project.
Any idea about that? Like a method that has not been applied in the Kusu
project, features that will be implemented in the Kusu or new technology
that has not been researched in cluster (cluster generaly, not only Kusu
project). Hopefully my final project can help and contribute for Kusu
project.

I have been learn cluster method in months. and in Indonesia, only one
university that have a cluster research lab, and my campus dont have =).
maybe with this research I can make a lab for my campus.

thank you for your help and attention. I'm waiting for good news =)..

best regard
ilyanto
Permalink | Reply | 1 comment |
headers
Mike Heinz | 11 Apr 22:41

Newbie help needed!

Hello all,

I'm trying to package up a binary blob as a kit, but I'm getting a very
weird problem - it appears that the tarfile is only getting partially
expanded, and then nothing from the tarfile is ever added to the final
iso - yet buildkit doesn't report any errors. I've verified that the tar
file itself is okay - manually untarring it works fine. Any suggestions?

Thanks in advance.

--------
make.log
--------
[root <at> daytona OCS_SUPPORT]# buildkit make kit=qlogic_ofed 2>&1 | tee
make.log   mkisofs: Warning: -follow-links does not always work
correctly; be careful.
Unknown file type (unallocated) ./.. - ignoring and continuing.
Verifying the Kit Source directory found in
/home/mheinz/work/OCS_SUPPORT/qlogic_ofed..
Setting up BuildProfile for this kit..
Setting up a proper .rpmmacros for building this kit
Looking for the kitscript build.kit..
Found kitscript. Loading it..
Building kit for x86_64 architecture..
Building the package(s)..
Building the packages for component(s)..
Building the package for the kit..
Populating the packages directory with the Kit artifacts..
Generating kitinfo..
Creating the Kit iso..
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Mazur | 19 Mar 09:39

Automated tests no longer require nose version 0.9.3

Hello,

As of kusu trunk revision 3148[1] the automated tests will work with the
most recent version of nose[2][3], version 0.10.1 as of this writing.

Please feel free to upgrade your version of nose:

$ easy_install -U nose

*** Please upgrade right away if you are writing new tests!

The tests will still work with nose version 0.9.3 though so you don't
need to upgrade immediately if you are only running the existing tests.

It turns out the culprit was the capitalization of module fixture
functions (setUp() and tearDown()). At some point these functions were
no longer discovered and run if they were defined in CamelCase.
Renaming them in lower case solved the problem.

Note that only the module fixtures were affected (defined outside of
classes in any test file), not class fixtures.

Thanks,
Mike

[1] http://svn.osgdc.org/changelog/kusu/?cs=3148
[2] http://somethingaboutorange.com/mrl/projects/nose/
[3] http://code.google.com/p/python-nose/
Permalink | Reply | 0 comments |
headers
Lei AI | 28 Feb 11:27
Picon
Favicon

RE: Network problem while provisioning a compute node

Thanks for your help.
It's right, build a inner network use VMware ESX server will resolve this.

Regards,
--Lei
-----Original Message-----
From: kusu-devel-bounces <at> osgdc.org [mailto:kusu-devel-bounces <at> osgdc.org] On Behalf Of Mike Mazur
Sent: 2008年2月28日 16:12
To: Developers of Project Kusu
Cc: Meng Xu
Subject: Re: [Kusu-devel] Network problem while provisioning a compute node

Hi Lei,

On Thu, 28 Feb 2008 16:01:40 +0800
Tsai Li Ming <ltsai <at> osgdc.org> wrote:

> Try setting the network to /dev/vmnet4 on both the master(eth1) and
> node (eth0) under vmware.

Actually you should set eth0 on master to vmnet4, not eth1.

Basically the provision network should be on the same private vmnet.

Mike
_______________________________________________
Kusu-devel mailing list
Kusu-devel <at> osgdc.org
http://mail.osgdc.org/mailman/listinfo/kusu-devel
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lei AI | 28 Feb 08:23
Picon
Favicon

RE: Network problem while provisioning a compute node

Hi Liming:

The PXE configuration file:
[root <at> master pxelinux.cfg]# cat 01-00-0c-29-7c-ec-e2 
# PXE file for: compute-00-00
default localdisk
prompt 0

label localdisk
        localboot 0
label Reinstall
        kernel kernel-rhel-5-i386
        append initrd=initrd-rhel-5-i386.img syslog=192.168.0.1:514 niihost=192.168.0.1
ks=http://192.168.0.1/repos/1000/ks.cfg.192.168.0.1 ksdevice=eth0 text noipv6 kssendmac selinux=0

the kusu release file:
[root <at> master pxelinux.cfg]# cat /etc/kusu-release 
Kusu 0.7 (build 3103)

Regards,
--Lei
-----Original Message-----
From: kusu-devel-bounces <at> osgdc.org [mailto:kusu-devel-bounces <at> osgdc.org] On Behalf Of Tsai Li Ming
Sent: 2008年2月28日 15:18
To: Developers of Project Kusu
Cc: Meng Xu
Subject: Re: [Kusu-devel] Network problem while provisioning a compute node

Hi Lei,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lei AI | 28 Feb 07:52
Picon
Favicon

RE: Network problem while provisioning a compute node

Hi Mike:

Thanks, you are right, I re-install my installation host, change my network configuration and this
problem vanished.

A new problem is I always got an error message during provisioning:
 "Error downloading kick start file
Unable to download the kickstart file. Please modify the kickstart parameter below or press Cancel to
proceed as an interactive installation"

This error always occurs. If happened, I quit addhost screen, delete the host, and re-provision the host,
then it could be successfully installed occasionally.

Regards,
--Lei

-----Original Message-----
From: Mike Mazur [mailto:mmazur <at> osgdc.org] 
Sent: 2008年2月28日 13:09
To: Developers of Project Kusu
Cc: Lei AI; Meng Xu
Subject: Re: [Kusu-devel] Network problem while provisioning a compute node

Hi Lei,

On Thu, 28 Feb 2008 12:58:34 +0800
"Lei AI" <leiai <at> platform.com> wrote:

> I've installed a installation node on a Virtual Machine and configured
> its two network interfaces as following:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lei AI | 28 Feb 05:58
Picon
Favicon

Network problem while provisioning a compute node

Hi guys:

I've installed a installation node on a Virtual Machine and configured
its two network interfaces as following:

eth0      Link encap:Ethernet  HWaddr 00:0C:29:4B:29:35  

          inet addr:172.20.0.1  Bcast:172.20.255.255  Mask:255.255.0.0

          inet6 addr: fe80::20c:29ff:fe4b:2935/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:47381 errors:0 dropped:0 overruns:0 frame:0

          TX packets:64701 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:3006118 (2.8 MiB)  TX bytes:93917722 (89.5 MiB)

          Interrupt:177 Base address:0x1400 

eth1      Link encap:Ethernet  HWaddr 00:0C:29:4B:29:3F  

          inet addr:172.20.6.20  Bcast:172.20.6.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe4b:293f/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
(Continue reading)

Permalink | Reply | 1 comment |

Gmane