Thanks for the feedback! Our test cluster is Centos6 VM-based, and I may spin up a new Centos7 VM in that to see how well it behaves at some point. Our primary cluster is bare-metal, and spinning up a new cluster == doubling the number of machines in the cluster == very expensive; so that's not option for us.
With centos6 moving into a long-term update phase that isn't expected to support some new hardware (as of q2 2016)[*] and later no new hardware (as of q2 2017) there may be an increased need to support this upgrade path as well. Would it be worth opening a JIRA to request this support as an actual feature so the various actions on the clusters gets tested? [*] https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates -- this is redhat, but centos6 follows the redhat6 lifecycle/patches On Thu, Jan 14, 2016 at 6:54 AM, Sumit Mohanty <[email protected]> wrote: > As far as I remember, when installing a cluster you can choose a cluster with > mixed OS. Ambari can pick the correct repo based on the OS. However, as Greg > said, for an installed cluster it may be a different issue. In general, > centos6 and centos7 repo contents are compatible but I am not 100% sure. > > One path to try is to do an Add Host with centos7. I expect Add Host to pick > the right repo URL based on the OS. If you must use local repo then you need > to edit the already stored repo details in the DB to make sure that > centos7/rhel7 one is pointing to your local centos7 repo. If the above works > as expected then you can try Remove Host/Upgrade/Add Host for the Slave > nodes. Its just that you need to remember what components are deployed on the > host and add those back. > > For master services, Remove/Add hosts do not work well especially for > NameNodes. But NameNode can be moved. > > Another option is to Add a Slave host with CentOS6 and then upgrade and see > what more is needed to get that to work. If this option works for you then it > might be the fastest way to upgrade the OS. Assuming no binary issue, this > option may require modifying CentOS7 repo to be the same as the CentOS6 repo > in the Ambari DB and repoinfo.xml files. > >>> Your best option is probably to spin up a new cluster with the new OS and >>> migrate the data. > +1 to this option > ________________________________________ > From: Greg Hill <[email protected]> > Sent: Thursday, January 14, 2016 6:37 AM > To: [email protected] > Subject: Re: Multiple CentOS versions in same stack? > > Honestly, I don't know that anyone has ever tried, but I have a feeling it > might not work out well. The 'repo' is specified at the stack level, so > you'd have to make a new cluster after modifying the repo url on the stack > in order for the new nodes to even know to use a different repo from the > old nodes for installing packages. Also, the os_family and os_type is in > the ambari-server configs and isn't overrideable per-node, unless there's > some hidden feature I'm not aware of. > > Your best option is probably to spin up a new cluster with the new OS and > migrate the data. > > Greg > > On 1/13/16, 6:20 PM, "Andrew Robertson" <[email protected]> wrote: > >>Has anyone ever tried to run an Ambari cluster with hosts at different >>centos versions (or some nodes with one OS like centos and other nodes >>with something else?) >> >>Any reason this wouldn't be advised? >> >>I'm considering upgrading from centos 6 -> centos 7. Given the >>current centos 6 -> 7 upgrade path is "reinstall", this make take some >>time to accomplish and I'd end up with a mix of both machine types in >>the cluster during this time. >> >>I don't see any reasons this would not work - but I also don't see >>anything that explicitly states this is a tested/advised config >>either. >> >>Thanks! >
