Adding Software Pallets

Creating Software Pallets

There may come a point where it makes sense to create your own pallets. There are three types: RPM only, configuration only, and configuration + RPMS.

Pallets allow you to install and configure applications you have created or downloaded. It's a simple way to keep multiple versions or to do patching/upgrading.

All pallets come in the ISO format. They can be pulled form the web for OS distributions, or created from a directory or remote yum/zypper repository by mirroring.

RPM-only pallets are the simplest to create.

The default OS pallet that comes with stackios a minimal CentOS distribution - designed to get you a basic frontend that installs basic backends. If you're looking for a minimal distribution, this is it.

If you have heavier software needs, additional software can be added in the form of pallets. Typically, the full CentOS distribution plus updates are added to a frontend to extend the software available.

Adding an OS pallet

These commands work with all OSs, but CentOS is the example.

Download the full CentOS 7.4 ISOs from a CentOS mirror.

You can use: CentOS-7-x86_64-DVD-1708.iso

but I usually use:

CentOS-7-x86_64-Everything-1708.iso

Once they're downloaded, scp the ISOs to the frontend and add them. /export is usually the largest disk partition so I usually put them there.:

scp CentOS*.iso [email protected]:/export

ssh [email protected]

cd /export

# stack add pallet CentOS-7-x86_64-Everything-1708.iso

List pallets:

# stack list pallet
NAME           VERSION      RELEASE ARCH   OS     BOXES
stacki         5.0          redhat7 x86_64 redhat default
os             7.4          redhat7 x86_64 redhat defaults
CentOS         7            redhat7 x86_64 redhat

There can be only one OS pallet for a given box. So enable the CentOS pallet and disable the "os" pallets

Enable the CentOS pallet:

# stack enable pallet CentOS

Disable the OS pallet and listing it to make sure:

# stack disable pallet os

NAME           VERSION      RELEASE ARCH   OS     BOXES
stacki         5.0          redhat7 x86_64 redhat default
os             7.4          redhat7 x86_64 redhat
CentOS         7            redhat7 x86_64 redhat default

RPM-only Pallet

Creating an RPM-only pallet is the same for both stacki 6 and 7. Only the URLs and repos are going to be different. This assumes your frontend has access to the internet. If not, put up a VirtualBox frontend on your desktop/laptop and create the pallets there and then put them on the real frontend.

Creating pallet from a path.

One very common thing I do is to grab the updates from CentOS for my particular CentOS version. We'll create a mirror of the updates two ways. The first is the simplest and most direct. You're going to use the "stack create mirror" command.

"stack create mirror" does a reposync from a URL or a repoid AND creates an ISO from the downloaded RPMs, which makes it a pallet.

So let's build the command line to do this.

You'll cd to your largest partition, default partitioning makes /export or /state/partition1 the largest partition.

# cd /export

Let's see what our options are:

# stack create mirror

[root@stackitest ~]# stack create mirror
error - must supply a URL argument or a "repoid"
{path} [arch=string] [name=string] [newest=boolean] [repoconfig=string] [repoid=string] [urlonly=boolean] [version=string]

(You can add a "help" on the end of "stack create mirror" for more detail.)

Since we know our path is http://mirror.centos.org/centos-6/6.6/updates/x86_64/Packages/ we'll just use the path.

# stack create mirror http://mirror.centos.org/centos-6/6.6/updates/x86_64/Packages/

We only want the newest RPMs so we'll set newest to true.

# stack create mirror http://mirror.centos.org/centos-6/6.6/updates/x86_64/Packages/ newest=true

If you want to see what you're going to get you can set urlonly=true, and you'll get an RPM listing and no downloads:

# stack create mirror http://mirror.centos.org/centos-6/6.6/updates/x86_64/Packages/ newest=true urlonly=true

Default "name" is updates and default "version" is the version of the stacki pallet. So we'll change them to be descriptive. I usually set the version to the date I make the pull, and I'll set the name so you can see an example:

# stack create mirror http://mirror.centos.org/centos-6/6.6/updates/x86_64/Packages/ newest=true name=CentOS-updates version=`date +%m%d%Y`

And now you wait. Depending on your site bandwidth, this could be a while for very large repositories. This is probably a good time to go to lunch.

Once the download finishes, you'll have an ISO appropriately named in the directory you ran this command in, just add and enable it.

# stack add pallet CentOS-updates-07282015-0.x86_64.disk1.iso
# stack enable pallet CentOS-Updates

Creating pallet from a repoid.

Sometimes there's an application you want to install, and a repoconfig file exists for it.

For this example we'll use Datastax Cassandra.

Go to the Cassandra install docs. You'll notice about half-way down they give you the repoconfig you'll need to get this from yum.

Copy that and put it in a file. I've put it in /export/datastax.repo, only I've disabled it.

# cat /export/datastax.repo

[datastax]
name = DataStax Repo for Apache Cassandra
baseurl = http://rpm.datastax.com/community
enabled = 0
gpgcheck = 0

Let's do a few things:

• I'm going to feed the name of this file to "repoconfig" parameter to get all the needed Cassandra RPMs.
• The version is "2.1" because that's this version of Cassandra from Datastax.
• I only want the newest RPMs because who knows what people dump into their repositories so "newest=true".
• The "repoid", in this case "datastax," tells "create mirror" the repo to pull from. Some repoconfigs might have more than one stanza. For example, if Datstax had included a [datastax-extras] or [datastax-updates], stanzas you could pull those RPMs by setting repoid to the correct name.

# stack create mirror name=datastax-cassandra version=2.1 repoconfig=/export/datastax.repo repoid=datastax newest=true

Now breathe. In/out. Long deep breaths. Or, hell, just go get another cup of coffee. When it's done you should see something like this:

root@stackitest export]# ls /export/datastax
datastax-cassandra-2.1-0.x86_64.disk1.iso  i386  noarch  roll-datastax-cassandra.xml  x86_64

Note, the directory is the name of the "repoid" and the newly created file is in this directory.

Do the pallet dance:

# stack add pallet /export/datastax/datastax-cassandra-2.1-0.x86_64.disk1.iso
# stack enable pallet datastax-cassandra

Now you can use the Datastax Cassandra RPMs on the cluster. Use the extend-backend.xml to add the appropriate RPMs and configuration settings per the Datastax install document.

Some things to be aware of: you can add the datastax.repo file to /etc/yum.repos.d and the same thing will work. In this case you do not have to supply the "repoconfig" parameter to the "stack create mirror" command.

So why did I do it this way? Well, from a management stand-point, I don't want someone enabling a repo in /etc/yum.repos.d I don't want enabled. I use the frontend as the fulcrum point to my cluster. I don't put any services on it other than installation and monitoring. All elements of an application are run on backend nodes because they are usually better protected (private network), and the application should keep running even if the Stacki frontend goes down. If I have a repo that may inadvertently be enabled, I may end up with an application on my frontend I don't want. In my mind it's good cluster hygiene, yes, a little paranoid and neurotic, buy hygiene nonetheless. It may be, however, you have limited machines and you don't want to waste the frontend, then use it. Rocks does it. StackIQ initially did it. It saves having to set up all the keys SSH access from a backend node acting as the frontend for an application to the rest of the cluster. Just know what you're getting.