RI-179 Make agent work on CentOS 7

[chamblin]

CentOS 7 is pretty new, but it uses Python 2.7 and does not have any Python paths in common with 2.6. So, post-install, we will check for the presence of a python2.7 lib directory and symlink it there.

Only the 64 bit version is available (as far as I can tell), so that's what I manually tested this on. There are a few Vagrant images, but none of them work, so I was unable to add integration tests for now, until CentOS 7 is a bit more mainstream.

Do you mind taking a look at this @divtxt ?

[divtxt]

The problem with this is that .pyc files generated by compileall will be specific to 2.6 so 2.7 won't be able to use them.

Ubuntu provides us a tool* that copies the tree and symlinks each individual .py file so that the .pyc files are distinct instead of being symlinks. * = https://github.com/PagerDuty/pdagent/blob/master/build-linux/deb/postinst#L49

Unfortunately, Redhat leaves the yak for us to shave.

I can think of a bunch of solutions to this:

1. Copy the tree in postinst instead of symlinking & run compileall on each copy separately. Remember to delete the copy during uninstall in prerm
2. Move the tree in postinst since pdagent only uses whichever version is default (/usr/bin/python). I'd recommend checking if the default python version is 2.7 rather than the existence of 2.7 (because that could be CentOS 6 users with 2.7 installed but 2.6 still default). Also, you'll may need to undo the move in prerm rather than just deleting to avoid a missing files uninstall errors.
3. Change the CentOS build to ship the code in /usr/share/pdagent/something/, check the python version and copy/symlink to the correct site-packages in postinst. Downside: changes files for existing customers so will need some extra care in upgrade testing.
4. Copy the tree at build time and ship two copies of the code for 2.6 and 2.7.

Your call on this. 3 & 4 are the "cleanest". 1 is the easiest. I'd recommend against #2.

[divtxt]

Also, we should check with ops about the solutions - probably @theckman

[divtxt]

Downside: changes files for existing customers so will need some extra care in upgrade testing.

This probably applies to all the options. :P

[chamblin]

Thanks Div. Hopefully ops has a good idea of which of your plans works best :)

[theckman]

I avoid CentOS at all costs so I'm not sure I have any good suggestions on the CentOS/RHEL way.

Is there a way to ship two separate packages? One for CentOS 6 and one for CentOS 7. Then we can guarantee our changes will not need to be tested on the other (as they won't exist there).

My reason for this suggestion is that it would be wise to think that we'll need to also support CentOS 8 when it comes out in a few years. And based on their current release cycle, CentOS 6, 7 and 8 will all need to be supported at that time.

If we were to split to separate packages, it may make our lives easier in the future when it comes to testing and deploying changes without worrying about CentOS exploding.

It also feels cleaner.

[divtxt]

I intentionally left out that option. :) RPM per CentOS version will involve a lot of work to change our build process and repo layout and we'd also have to worry about classifying it correctly for other redhat based distros e.g. Fedora. The CentOS 8 consideration is not valid because python 2.7 is the last python 2. (Also, CentOS 8 is probably 5 years away from GA :)

To me, option 3 is about equally clean, matches the layout in pdagent-integrations, and lets us keep the elegance of a single package for all CentOS versions.

[divtxt]

s/single package for all CentOS versions/single package for all versions of RH derived distros/

[chamblin]

How about this approach (#3) @divtxt

[divtxt]

👍 Sweet!

[divtxt]

LGTM - can you add a CentOS 7 vagrant box for automated tests?

[chamblin]

I think I have to just put everything in python2.6 and python2.7, unfortunately. The rpm doesn't know about my symlinking shenanigans, so it assumes the files I've symlinked in are the old package's versions, and promptly deletes them after an upgrade. @divtxt

[divtxt]

Sounds good.

(for future self: apparently, during upgrade, old version's obsolete files are removed after the new version's postinst is run)

[chamblin]

@divtxt Upgrade testing works with this solution (finally).

I took a look at some existing CentOS 7 Vagrant boxes but I wasn't able to get any of them up and running. We will eventually need one (maybe even to build it ourselves), but I'm OK with putting that on the backlog for now since it is less pressing than getting it to work.

[divtxt]

LGTM - 🚢

Re CentOS 7 box, yeah we can defer it since we're not regressing on existing platforms. :)
Captured here: #91