Hi Jarrod,
Thanks for the prompt answer. I agree with you re. stateless. Next hardware
purchase we will be going statefull.
to that end, we are running following version of xCAT:
[root@mgt rh]# rpm -qa |grep -i xcat
conserver-xcat-8.1.16-10.x86_64
xCAT-2.9.1-snap201503190326.x86_64
xCAT-genesis-base-x86_64-2.9-snap201504212134.noarch
elilo-xcat-3.14-4.noarch
xCAT-server-2.9.1-snap201503190325.noarch
grub2-xcat-1.0-2.noarch
perl-xCAT-2.9.1-snap201503190325.noarch
xCAT-buildkit-2.9.1-snap201503190326.noarch
ipmitool-xcat-1.8.11-3.x86_64
xCAT-client-2.9.1-snap201503190325.noarch
xCAT-genesis-scripts-x86_64-2.9.1-snap201503190326.noarch
syslinux-xcat-3.86-2.noarch
I think in order to deploy statefull version of RH7.3 we will need to
update our xCAT. What is the most painless way of upgrading from our
version to the latest stable RH 7 supporting version? Are there any gotchas
or recommended practices when it comes to upgrade of xCAT? Last time I had
to do this, instead of upgrading, I deployed a new xCAT server which was
not too painful but I don't have the notes of what I had to do to get it
going.
I would much rather just upgrade the xCAT on this server because the
machine itself is not that old (2 years or so now).
Anything I should back up before attempting upgrade as well?
Thanks,
Damir
On Fri, Jan 13, 2017 at 9:10 AM Jarrod Johnson <[email protected]> wrote:
> I think stateless makes a little less sense over time.
>
>
>
> 1) Local boot storage is cheaper and more durable than it used to
> be, and this is only going to get more extreme
>
> 2) Dynamism is probably better and more easily served by somethig
> like Singularity, which makes things easier for users to do their thing
> without the administrators having to accommodate.
>
> 3) Mitigating drift can be done in other ways. Stateless has
> traditionally had the side effect of mitigating accumulating ‘drift’ as
> people do things ad-hoc to OS images, by punishing those practices.
> Strictly speaking the same discipline can be self-imposed without downside,
> it just takes some willpower.
>
>
>
> *From:* Damir Krstic [mailto:[email protected]]
> *Sent:* Friday, January 13, 2017 9:20 AM
> *To:* xCAT Users Mailing list
> *Subject:* [xcat-user] statefull vs. stateless images
>
>
>
> We have been running our cluster using stateless images for over 6 years
> now. For the most part, things are running great. There are two reasons for
> our decision to run stateless:
>
> 1. our compute nodes originally did not have local hard drives
>
> 2. we envisioned a dynamic environment in which we would boot nodes
> frequently with different images to satisfy different research needs
>
>
>
> Today both of those points are invalid / do not apply. All of our compute
> nodes come with hard drives, and we have never really booted cluster with
> any images other than our "production" image. In addition, downtimes are
> really hard to come by in our environment, and we treat our cluster as
> production system.
>
>
>
> So, my question is, does it make sense to continue with stateless images,
> or would we be better served with statefull (installed on local disk)
> images.
>
>
>
> I question our today's method because:
>
> 1. stateless images are not trivial to build and update using genimage,
> putting mellanox drivers, gpfs etc. We don't do it often enough so every
> time we have to do it, we are re-inventing a wheel.
>
> 2. stateless images take up portion of compute node memory
>
>
>
> Are there any downsides to running a 700+ node cluster using statefull
> images? Like I said, we don't boot the cluster at all for many months at
> the time (we get a single downtime during the year), and most of the
> packages outside of normal RH installation are installed using postscripts.
>
>
>
> Let me know your thoughts.
>
>
>
> Thanks,
>
> Damir
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> xCAT-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/xcat-user
>
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
xCAT-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xcat-user
