Is it possible to set up a VM on your existing MN? This might allow you to import your current xCAT DB, upgrade to the latest version and try booting a node or two off the VM instance.
Regards, Christian Caruthers Lenovo xESS IT Consultant Mobile: 757-289-9872 -----Original Message----- From: Russell Auld [mailto:[email protected]] Sent: Friday, January 13, 2017 6:34 PM To: xCAT Users Mailing list Subject: Re: [xcat-user] statefull vs. stateless images Upgrading is pretty painless. Unfortunately, there's no way to really know if there have been any code changes that will affect you. I got burned by a couple things when I upgraded from 2.9.x to 2.12.x. 1 - When I added some new nodes, and then ran makedhcp, the new DHCP stanzas were incompatible with my existing leases file. Simply running 'makedhcp -n' fixed the issue. It was never obvious to me that I should have regenerated the leases file after the upgrade. 2 - Some changes to the postbootscripts script resulted in postbootscripts no longer running for certain nodes. The issue was a particular corner-case, and has been fixed in v2.13.x. I think you should be able to revert to v2.9.x if the upgraded version doesn't work for you. You would need to backup your databases since the upgrade process can alter the table schemas. On Fri, 2017-01-13 at 21:10 +0000, Damir Krstic wrote: > 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 ------------------------------------------------------------------------------ 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
