[Rocks-Discuss] Rocks Cluster Releases
LiPi -
about it.
Its a simple question. It's about release versions policy of Rocks Clusters
distribution.
Actually we are dealing with "Rocks 5.4 (Maverick)" that it's based on the
latest CentOS 5.6 release. I'm wrong?
My question is: How are the Rocks releases planned? In a few days Centos 6
will go out (http://qaweb.dev.centos.org/qa/calendar) and I'm thinking
to begin a new cluster with Rocks Cluster, but I don't know if it's better
to wait some time to have a new and fresh release of Rocks.
As you can see, I'm discovering Rocks Cluster, so I'm not very familiarized
with this distro. I'm not able to find the "work policies" and these kind of
information.
Thank you!.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.sdsc.edu/pipermail/npaci-rocks-discussion/attachments/20110604/d56f8a1d/attachment.html
LaoTsao
Sent from my iPad
Hung-Sheng Tsao ( LaoTsao) Ph.D
Philip Papadopoulos
> Hello all, I have a little question and I can't find the answer and info
> about it.
>
> Its a simple question. It's about release versions policy of Rocks Clusters
> distribution.
>
> Actually we are dealing with "Rocks 5.4 (Maverick)" that it's based on the
> latest CentOS 5.6 release. I'm wrong?
>
Rocks 5.4 uses CentOS 5.5 as a base (the installation kernel is 5.5).
However, when you build a cluster, you can provide the Centos 5.6 CDs/DVD in
place
of our trimmed "os" roll.
e.g.
root@---.rocksclusters.org's password:
Last login: Fri Jun 3 15:47:06 2011 from triton-38.sdsc.edu
Rocks 5.4 (Maverick)
Profile built 19:24 01-Jun-2011
[root@--- ~]# cat /etc/redhat-release
CentOS release 5.6 (Final)
> My question is: How are the Rocks releases planned? In a few days Centos 6
> will go out (http://qaweb.dev.centos.org/qa/calendar) and I'm thinking
> to begin a new cluster with Rocks Cluster, but I don't know if it's better
> to wait some time to have a new and fresh release of Rocks.
>
> As you can see, I'm discovering Rocks Cluster, so I'm not very familiarized
> with this distro. I'm not able to find the "work policies" and these kind
> of
> information.
>
> Thank you!.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> https://lists.sdsc.edu/pipermail/npaci-rocks-discussion/attachments/20110604/d56f8a1d/attachment.html
>
>
--
Philip Papadopoulos, PhD
University of California, San Diego
858-822-3628 (Ofc)
619-331-2990 (Fax)
-------------- next part --------------
An HTML attachment was scrubbed...
LiPi -
So, which are the release policies or where can I find info. about it?
-------------- next part --------------
An HTML attachment was scrubbed...
Philip Papadopoulos
In general, we have new production quality releases of Rocks every 9 months
-- but that can
vary based upon a number of factors.
If you are looking for a release date based on CentOS 6.0, we don't have
one. Version 6.0 is not out
in production (truthfully, it has been promised for many months). We
probably will wait some time after
that for 6.0 to stabilize. Right now we are concentrating on items for a
5.6 native build. The 5.6 components of it are done, but we are working on
fixing some Rocks-specific capabilities.
-P
Marc Beaumont
Quick Monday morning question.
Does anyone know if it's possible to make SGE use an empty node before using
spare slots on a node that is currently running a job.
e.g.
If I have 4 nodes, each 12 cores.
2 jobs get started that need 8 cores each. The first goes onto node 1, the
second onto node 2.
If I then submit a 4 slot job, it would go onto a node with something on
already, 1 or 2, but I would want it to go onto the empty node 3.
Is there an option in SGE to do this?
Cheers.
Marc Beaumont
Senior IT Support Engineer
Aircraft Research Association
**********************************************************************
This email contains information that is private and confidential and is intended only for the addressee.
If you are not the intended recipient please delete it and notify us immediately by e-mailing the sender.
Note: All email sent to or from this address may be accessed by someone other than the recipient, for
system management and security reasons.
Aircraft Research Association Ltd. Registered in England, Registration No 503668 Registered Office:
Manton Lane, Bedford MK41 7PF England VAT No GB 196351245
**********************************************************************
LiPi -
http://www.debian.org/releases/, the time between releases, if there
are
testing releases, in which Centos ver. is based every release or Rocks, etc.
You semi-answered me. Thank you.
Regarding the other part of my question, I'm concerned about using an old
version of the O.S.: Centos 5.6 still uses the kernel 2.6.18 and we are
actually in version 2.6.39, and the mainline for 3.0 is out!. There are also
libraries, compilers, packages, etc. that are improved in newer versions, so
I think that my concern is justified.
I don't know if I'm right or not because I'm new in these world
(clustering). How do you feel about these questions?
2011/6/5 Philip Papadopoulos <philip.pa...@gmail.com>
Ian Kaufman
> http://www.debian.org/releases/, the time between releases, if there
> are
> testing releases, in which Centos ver. is based every release or Rocks, etc.
>
> You semi-answered me. Thank you.
Basically, since ROCKS is developed and built against CentOS, ROCKS is
currently at the mercy of the CentOS release schedule. So, ROCKS
versions will not always match up against CentOS releases. Which is
why ROCKS 5.4 matches up to CentOS 5.5 (and that is one of the closest
release version numbering matches). There is a good chance that when
CentOS 6.0 (and 6.1 should follow quickly) comes out, ROCKS 6.0 will
lag behind as they wait for CentOS 6.X to stabilize and then start
work.
>
> Regarding the other part of my question, I'm concerned about using an old
> version of the O.S.: Centos 5.6 still uses the kernel 2.6.18 and we are
> actually in version 2.6.39, and the mainline for 3.0 is out!. There are also
> libraries, compilers, packages, etc. that are improved in newer versions, so
> I think that my concern is justified.
>
> I don't know if I'm right or not because I'm new in these world
> (clustering). How do you feel about these questions?
>
I am not 100% sure your concerns are justified. Red Hat (and thus
CentOS) back port many of the fixes and driver enhancements found in
newer kernels into the 2.6.18 version they ship (hence the versioning
2.6.18-238.12.1 being the latest). Same with some of the other
packages, compilers and libraries. Yes, if you stick with the
core/stock CentOS version you may miss out on the newest version of,
say, Octave, but in some cases, there isn't much difference in the
newer versions, and in other cases, you can install the latest
versions from other repositories (or recompile the src RPM yourself
and make a local repo). And, yes, it is possible to install the latest
gcc or php5 this way.
There is a reason why Red Hat (and thus CentOS and other RHEL
rebuilds) maintains certain versions with specific OS releases. They
want to ensure stability for their enterprise customers.
Ian
--
Ian Kaufman
Research Systems Administrator
UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu
Ian Kaufman
> http://www.debian.org/releases/, the time between releases, if there
> are
> testing releases, in which Centos ver. is based every release or Rocks, etc.
>
> You semi-answered me. Thank you.
Basically, since ROCKS is developed and built against CentOS, ROCKS is
currently at the mercy of the CentOS release schedule. So, ROCKS
versions will not always match up against CentOS releases. Which is
why ROCKS 5.4 matches up to CentOS 5.5 (and that is one of the closest
release version numbering matches). There is a good chance that when
CentOS 6.0 (and 6.1 should follow quickly) comes out, ROCKS 6.0 will
lag behind as they wait for CentOS 6.X to stabilize and then start
work.
>
> Regarding the other part of my question, I'm concerned about using an old
> version of the O.S.: Centos 5.6 still uses the kernel 2.6.18 and we are
> actually in version 2.6.39, and the mainline for 3.0 is out!. There are also
> libraries, compilers, packages, etc. that are improved in newer versions, so
> I think that my concern is justified.
>
> I don't know if I'm right or not because I'm new in these world
> (clustering). How do you feel about these questions?
>
I am not 100% sure your concerns are justified. Red Hat (and thus
Vlad Manea
I use the memory in order to get free nodes:
#!/bin/bash
#submit job through SGE queuing system
#
#$ -l mf= 28G
#$ -cwd
#$ -j y
#$ -S /bin/bash
#$ -N "name of your job"
#$ -pe mpi 4
export OMP_NUM_THREADS=4
./your code here
Hope this helps,
Vlad
Alain Péan
> Basically, since ROCKS is developed and built against CentOS, ROCKS is
> currently at the mercy of the CentOS release schedule. So, ROCKS
> versions will not always match up against CentOS releases. Which is
> why ROCKS 5.4 matches up to CentOS 5.5 (and that is one of the closest
> release version numbering matches). There is a good chance that when
> CentOS 6.0 (and 6.1 should follow quickly) comes out, ROCKS 6.0 will
> lag behind as they wait for CentOS 6.X to stabilize and then start
> work.
Why not begin the devoppement if Rocks 6.0 on Scientifix Linux 6.0,
which is released since two months, and has already an alpha for 6.1 ?
It has always been possible to provides the two systems CDs of a 'true
reecompilation of RHEL', that is for example SL instead of CentOS.
At the end, it would possible for the Rocks team to afford CentOS,
instead of SL 6.x, if needed...
Alain
Chi Chan
<philip.pa...@gmail.com> wrote:
> Rocks 5.4 uses CentOS 5.5 as a base (the installation kernel is 5.5).
> However, when you build a cluster, you can provide the Centos 5.6 CDs/DVD in
> place of our trimmed "os" roll.
Are there known dependencies on the "os" roll that would cause issues
if we use RHEL 6.1 or the free clones (eg. Oracle Linux 6.1)?
A few minutes ago, I read on the news that Oracle Linux 6.1 was
released last week.
http://www.channelregister.co.uk/2011/06/06/oracle_linux_6_1/
One thing I would like to try is the new "Unbreakable Enterprise
Kernel" and see if there are speedups in my workloads, Oracle claims
that its improved kernel has:
* Improved IRQ balancing
* Reduced lock contention across the kernel to improve performance on
large NUMA systems
* Improved network I/O via receive packet steering and RDS improvements
* Improved virtual memory performance
http://blogs.oracle.com/linux/entry/oracle_linux_6_1_has
--Chi
Philip Papadopoulos
We need to build the core on things that we know. Yes, we -could- look at
Scientific Linux, but we don't know
it and we don't know it's compatibility with RedHat Linux. RedHat is THE
de-facto standard bearer for enterprise class
Linux.
Not only do we have to worry about the installation environment, but we also
produce a set of Rolls for applications, schedulers,
etc. Compatibility of the installed software starts to become really
important from our viewpoint. The reality is that
CentOS is pretty darn good clone of RHEL and as a group they take great
pains to maintain "bug for bug" compatibility.
CentOS has recently had their problems getting timely releases out the door
(e.g. 5.6/6.0 are months behind the upstream
release). Certainly if they continue that pattern, we'll have to evaluate
other core OSes, but that isn't a small decision. And its not a change that
is going to happen in the "next few weeks".
-P
Ian Kaufman
>
> CentOS has recently had their problems getting timely releases out the door
> (e.g. 5.6/6.0 are months behind the upstream
> release). Certainly if they continue that pattern, we'll have to evaluate
> other core OSes, but that isn't a small decision. And its not a change that
> is going to happen in the "next few weeks".
Not sure if you have been following the whole CentOS saga, but while
SL has released 6.0, they have yet to release 6.1 which has critical
bug fixes, and they have yet to release 5.6 at all. CentOS prioritized
on 5.6, which is one reason why 6.0 is so late. CentOS also beat SL to
the 4.9 release by almost a month.
Another issue has to do with how Red Hat changed their internal builds
with 6.0, and how the distros themselves have to deal with the new
build procedure, reverse engineering what Red Hat did.
Finally, Red Hat updated all three supported distros during this time
period. SL and CentOS, as part of providing enterprise level "service"
to their install base, has nowhere near the same manpower as Red Hat,
but both are doing their best to provide timely updates to all three
enterprise level distros. Again, CentOS prioritized 5.6, 4.9 and then
6.0 to provide updates to their install base for 5.X and 4.X first. SL
prioritized on 6.0, 4.9 and then 5.6, providing the latest release of
TUV, then addressing updates to their install base. IMHO, I think the
CentOS team took the proper path. I suppose we'll have to waint and
see which distro is able to have complete releases for 4.9, 5.6 and
6.1 first ...
hung-sheng tsao
Oracle el is opensource and redhat compatible
--
Sent from my mobile device
Hung-Sheng Tsao, Ph.D. <lao...@gmail.com>
lao...@gmail.com
http://laotsao.wordpress.com
9734950840
Ian Kaufman
Open Source have not been very synonymous as of late (ZFS, GridEngine,
OpenSolaris to name a few but very high profile ones). I personally
wouldn't commit any effort to Oracle EL.
Ian
Philip Papadopoulos
I don't follow the blow-by-blow of the rebuilders -- but definitely
appreciate their hard work
to keep open-source also freely available in integrated forms. I also
appreciate the significant engineering
that Redhat puts in to make open source and enterprise quality offering.
We hung our hat on CentOS (Rocks used to do a full OS rebuild, too) and for
the moment are content to keep
relying on them.
I was aware already that RH changed the way things were done for building
the distro. anaconda changed too,
(Which has more impact on Rocks).
-p
--
Philip Papadopoulos, PhD
University of California, San Diego
858-822-3628 (Ofc)
619-331-2990 (Fax)
-------------- next part --------------
An HTML attachment was scrubbed...
Ian Kaufman
> the distro. anaconda changed too,
> (Which has more impact on Rocks).
>
> -p
Apparently RHEL 6.0 had a bug in anaconda, which was fixed in 6.1.
And, considering how important anaconda is, there are many who are
surprised that 6.0 was released with such a bug (and feel hat to some
degree RH shipped out 6.0 before they should have).
LiPi -
if a section were created into the Rocks webpage explaining some of the
ideas exposed here, regarding to the philosophy of the developers!.
2011/6/7 Ian Kaufman <ikau...@eng.ucsd.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
Alain Péan
> Finally, Red Hat updated all three supported distros during this time
> period. SL and CentOS, as part of providing enterprise level "service"
> to their install base, has nowhere near the same manpower as Red Hat,
> but both are doing their best to provide timely updates to all three
> enterprise level distros. Again, CentOS prioritized 5.6, 4.9 and then
> 6.0 to provide updates to their install base for 5.X and 4.X first. SL
> prioritized on 6.0, 4.9 and then 5.6, providing the latest release of
> TUV, then addressing updates to their install base. IMHO, I think the
> CentOS team took the proper path. I suppose we'll have to waint and
> see which distro is able to have complete releases for 4.9, 5.6 and
> 6.1 first ...
>
> Ian
Ian,
I think both CentOS and Scientific Linux took the right path, due to
their different policies. Scientific Linux backports security updates
from 5.6 to 5.5, so 5.5 release has always been safe. They do this in
24h to 48h, and they do this for every point release.
CentOS tries to stay 'bug to bug' compatible so does not backports
security or bug updates to previous point releases. So they took the
right path to prioritize 5.6 against 6.0. But if CentOS had succeeded to
release 6.0 in 6 to 8 weeks, as anticipated by Karanbir Singh last
November, there would not have such a problem. They released 5.0 in 4
weeks, back in 2007.
But, even with 5.6, it took three months to release it. How much time it
will take for 6.1 ?
The problem now, as outlined in other posts, is that when CentOS 6.0
will be released, there will be no security updates, as they are
released now for 6.1. So better to wait for 6.1.
That is a good reason to look for scientific Linux. In my opinion, as
6.0 is a completly new release, with a lot of changes, it is no more
difficult to learn SL 6.0 than CentOS 6.x. In my experience, there are
very few differences.
And for HPC, a scientific distribution seems something natural !
Alain
--
==========================================================
Alain Péan - LPP/CNRS
Administrateur Système/Réseau
Laboratoire de Physique des Plasmas - UMR 7648
Observatoire de Saint-Maur
4, av de Neptune, Bat. A
94100 Saint-Maur des Fossés
Tel : 01-45-11-42-39 - Fax : 01-48-89-44-33
==========================================================
LaoTsao
http://www.freerepublic.com/focus/f-chat/2309684/posts
Sent from my iPad
Hung-Sheng Tsao ( LaoTsao) Ph.D
LiPi -
Look at these post and at comments below... not very reliable. She doesn't
like CentOS because her experience
installing it on a netbook was bad.
http://ever-increasing-entropy.blogspot.com/2009/08/end-of-centos-netbook-experiment.html
http://www.oreillynet.com/pub/au/2654
2011/6/7 LaoTsao <lao...@gmail.com>