[Rocks-Discuss] Getting Ready for Beta of Rocks 5.5/6.0 (Mamba)
Philip Papadopoulos
We are inching closer to the next version of Rocks. We're trying something
new: the same Rocks code base for CentOS 5.7 and CentOS 6.2 and
could use some help in uncovering issues. There are some engineering
changes, but the intent is that Mamba behaves similarly to
Viper (5.4.3). The idea is to make the move to 6.0 and then work on some
new/re-architected feature.
Mamba supports the new naming convention of Ethernet devices, choice of
public and private interface when building the frontend, support for
frontends with only a single physical interface (builds a virtual
interface for the private), a rewritten tracker, updated
sec-channel-server, a new building recipe, managing the differences between
5 and 6, and a variety of bug fixes.
We're starting now on splitting out Xen-specific (since Xen is not natively
supported on CentOS 6) and virtualization-agnostic tools so that we can
support
KVM on 6 and Xen on 5.
If you are interested in actually testing, I'd ask you to sign up at
https://docs.google.com/spreadsheet/viewform?formkey=dHhabEhDbXFGMjB6M3pwbHJ4aUpqYWc6MQ
You'll be asked for which versions you want to test.
Expect the Beta sometime in the last week of March.
Best,
Phil
--
Philip Papadopoulos, PhD
University of California, San Diego
858-822-3628 (Ofc)
619-331-2990 (Fax)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.sdsc.edu/pipermail/npaci-rocks-discussion/attachments/20120316/622d79bd/attachment.html
Adrian Sevcenco
> Hi Folks,
> We are inching closer to the next version of Rocks. We're trying something
> new: the same Rocks code base for CentOS 5.7 and CentOS 6.2 and
> could use some help in uncovering issues. There are some engineering
> changes, but the intent is that Mamba behaves similarly to
> Viper (5.4.3). The idea is to make the move to 6.0 and then work on some
> new/re-architected feature.
>
> Mamba supports the new naming convention of Ethernet devices, choice of
> public and private interface when building the frontend, support for
> frontends with only a single physical interface (builds a virtual
> interface for the private), a rewritten tracker, updated
> sec-channel-server, a new building recipe, managing the differences between
> 5 and 6, and a variety of bug fixes.
>
> We're starting now on splitting out Xen-specific (since Xen is not natively
> supported on CentOS 6) and virtualization-agnostic tools so that we can
> support
> KVM on 6 and Xen on 5.
>
> If you are interested in actually testing, I'd ask you to sign up at
> https://docs.google.com/spreadsheet/viewform?formkey=dHhabEhDbXFGMjB6M3pwbHJ4aUpqYWc6MQ
> You'll be asked for which versions you want to test.
>
> Expect the Beta sometime in the last week of March.
>
> Best,
> Phil
>
Like:
1. on the login node to have installed the torque utils and be
configured automatically ? (in order to be able to qstat and qsub to the
torque server)
2. to have already installed some additional repos (but disabled for
safety) at least on frontend : epel, rpmforge, and for additional
hardware support elrepo and kernel-ml (also from elrepo)
3. had some way to update the repository from frontend (like sync-ing
packages from mirrors or mirroring an repo) in order to have
automatically the updated packages on nodes
Thanks!
Adrian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1984 bytes
Desc: S/MIME Cryptographic Signature
Url : https://lists.sdsc.edu/pipermail/npaci-rocks-discussion/attachments/20120317/84bfffa6/smime.p7s
Philip Papadopoulos
<Adrian....@cern.ch>wrote:
you'd have to ask roy for that -- he graciously maintains the Torque roll.
>
> 2. to have already installed some additional repos (but disabled for
> safety) at least on frontend : epel, rpmforge, and for additional
> hardware support elrepo and kernel-ml (also from elrepo).
>
Hmmm... two-edged sword here. But I'm not opposed. How about this,
you send me the exact repo lines and I can add them
>
> 3. had some way to update the repository from frontend (like sync-ing
> packages from mirrors or mirroring an repo) in order to have
> automatically the updated packages on nodes
>
How far does
rocks create mirror
get you?
I use this every rebuild of Rocks to create an updates roll in addition to
the base OS
roll.
-P
>
> Thanks!
> Adrian
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 1984 bytes
> Desc: S/MIME Cryptographic Signature
> Url :
> https://lists.sdsc.edu/pipermail/npaci-rocks-discussion/attachments/20120317/84bfffa6/smime.p7s
>
>
--
Philip Papadopoulos, PhD
University of California, San Diego
858-822-3628 (Ofc)
619-331-2990 (Fax)
-------------- next part --------------
An HTML attachment was scrubbed...
Ali Nazemian
Regards.
--
A.Nazemian
-------------- next part --------------
An HTML attachment was scrubbed...
Roy Dragseth
> > configured automatically ? (in order to be able to qstat and qsub to the
> > torque server)
>
> you'd have to ask roy for that -- he graciously maintains the Torque roll.
login nodes will be fully integrated in the next version of the torque roll.
It is currently under testing for Rocks 5.4.3 and will be retested for
5.5/6.0. It remains to be seen if two separate versions are needed.
r.
Adrian Sevcenco
>> 2. to have already installed some additional repos (but disabled for
>> safety) at least on frontend : epel, rpmforge, and for additional
>> hardware support elrepo and kernel-ml (also from elrepo).
>>
> Hmmm... two-edged sword here. But I'm not opposed. How about this,
> you send me the exact repo lines and I can add them
rpmforge:
http://wiki.centos.org/AdditionalResources/Repositories/RPMForge
wget
http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm
rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt
rpm -K rpmforge-release-0.5.2-2.el5.rf.*.rpm
rpm -i rpmforge-release-0.5.2-2.el5.rf.*.rpm
epel:
http://fedoraproject.org/wiki/EPEL
wget
http://dl.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm
rpm --import http://fedoraproject.org/static/217521F6.txt
rpm -K epel-release-5-4.noarch.rpm
rpm -i epel-release-5-4.noarch.rpm
elrepo:
http://elrepo.org/tiki/tiki-index.php
rpm --import http://elrepo.org/RPM-GPG-KEY-elrepo.org
rpm -Uvh http://elrepo.org/elrepo-release-5-3.el5.elrepo.noarch.rpm
and for the users of kernel-ml (vanilla kernel) a must read:
http://elrepo.org/tiki/kernel-ml
by default are enabled :
elrepo, epel, rpmforge .. but i imagine that they can be make disabled
afterwards ...
Thanks!
Adrian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1984 bytes
Desc: S/MIME Cryptographic Signature
Url : https://lists.sdsc.edu/pipermail/npaci-rocks-discussion/attachments/20120318/0e936000/smime.p7s
Adrian Sevcenco
>> packages from mirrors or mirroring an repo) in order to have
>> automatically the updated packages on nodes
>>
> How far does
> rocks create mirror
> get you?
>
> I use this every rebuild of Rocks to create an updates roll in addition to
> the base OS
> roll.
well .. i get the roll, i enabled and recreate distro .. and then how
can i update my frontend (without re-installing)?
also .. if the base os is at 5.6, is it required to make updates for
5.6, 5.7, 5.8 or can i do only for 5.8?
is it possible that a carefully made exclude in yum.conf would allow to
keep normal centos repos and to be able to upgrade and update the distro?
Thanks!
Adrian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1984 bytes
Desc: S/MIME Cryptographic Signature
Url : https://lists.sdsc.edu/pipermail/npaci-rocks-discussion/attachments/20120318/a377e91c/smime.p7s
Adrian Sevcenco
instructions about what to test :)
Thanks!
Adrian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1984 bytes
Desc: S/MIME Cryptographic Signature
Url : https://lists.sdsc.edu/pipermail/npaci-rocks-discussion/attachments/20120318/ae840f74/smime.p7s
Adrian Sevcenco
> So for 2. I have the following working on my alpha of Mamba:
>
> Centos updates repo is available, but disabled (as are elrepo, epel, and
> rpmforge)
> Checking for updates:
great!
>> 3. had some way to update the repository from frontend (like sync-ing
>> packages from mirrors or mirroring an repo) in order to have
>> automatically the updated packages on nodes
>>
>
> If these are downloaded/installed on the frontend, they are available in
> /var/cache/yum/updates/packages (or similar).
>
> Those packages can be copied to /export/rocks/install/contrib/<rocks
> version>/<arch>/RPMS
> and then the Rocks distro can be re-created with
> # cd /export/rocks/install
> # rocks create distro
>
> At that point, the packages have been integrated into the main
> distribution. You can either yum update your
> nodes or reinstall them.
>
> In other words, Mamba will load the gun for you, but you still have to pull
> the trigger.
great!!! a small rsync done after each yum update is more than enough :)
(maybe even an cron job with yum --downloadonly and rsync of rpms to
export/.. )
Thanks a lot!!
Adrian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1984 bytes
Desc: S/MIME Cryptographic Signature
Url : https://lists.sdsc.edu/pipermail/npaci-rocks-discussion/attachments/20120328/d8be4ebd/smime.p7s
Rémy Dernat
in yum repositories to download last rolls would be great, with "yum
update" command... without breaking all our cluster.
-------------- next part --------------
An HTML attachment was scrubbed...