bug: Apache package differences in CentOS and Ubuntu break horizon and keystone charts

[wilreichert]

Ubuntu <--> CentOS

/usr/sbin/apache2 <--> /usr/sbin/httpd /etc/apache2/envvars <--> /etc/sysconfig/httpd /etc/apache2 <--> /etc/httpd /var/log/apache2 <--> /var/log/httpd

All the files referencing Ubuntu apache specifics

% grep -r apache2 *
horizon/templates/bin/_start.sh.tpl:source /etc/apache2/envvars
horizon/templates/bin/_start.sh.tpl:rm -rf /var/run/apache2/*
horizon/templates/bin/_start.sh.tpl:APACHE_DIR="apache2"
horizon/templates/bin/_start.sh.tpl:apache2 -DFOREGROUND
horizon/templates/deployment.yaml:              mountPath: /etc/apache2/sites-enabled/000-default.conf
horizon/templates/etc/_horizon.conf.tpl:    ErrorLog /var/log/apache2/horizon.log
horizon/templates/etc/_horizon.conf.tpl:    CustomLog /var/log/apache2/horizon-access.log combined
keystone/templates/bin/_start.sh.tpl:if [ -f /etc/apache2/envvars ]; then
keystone/templates/bin/_start.sh.tpl:   source /etc/apache2/envvars
keystone/templates/bin/_start.sh.tpl:exec apache2 -DFOREGROUND
keystone/templates/deployment.yaml:              mountPath: /etc/apache2/conf-enabled/wsgi-keystone.conf
keystone/templates/deployment.yaml:              mountPath: /etc/apache2/mods-available/mpm_event.conf

Perhaps it's worth discouraging people to use CentOS based images until it's been vetted more. I suspect the mariadb chart also suffers from distro related issues (haven't tracked down the exact issue yet) and we've barely started. I understand the project goal is to be image agnostic but distro quirks have been the bane of Linux for as long as people have been downloading stacks of Slackware floppies.

[intlabs]

@wilreichert I've been doing some work on this issue, and hope to have a PR available soon that resolves this. As you have identified the primary issue is the naming of the primary apache binary as either httpd or apache2, though there are also directory layout differences that we need to take into account. In the meantime, I've been testing with the CentOS Yaodu Image that has been set up to allow drop in replacement of .deb based images: https://github.com/yaodu/docker-keystone. This solution is obviously far from ideal and breaks SELinux support.

The PR I'm working on essentially provides mounting of the configMaps following the locations I setup within the Yaodu Image, which will enable us to use any RHEL related .rpm based distro: https://github.com/yaodu/docker-keystone/blob/master/dockerfiles/Dockerfile-centos#L58-L63, without breaking SELinux support, and restoring true Image agnostic operation.

[wilreichert]

I suppose it's impossible to identify the distro an image is using at chart make time? I don't see any other information to use besides a name which refers to an image in a repo that may or may not be accessible to the build machine.

[alanmeadows]

Ultimate flexibility would mean allowing the operator to specify the binary paths and directories leveraged by scripts as well as configmap mount destinations, and so on as overrides. There is already a plan to make the mounts values driven, but we want needing to override that to be a rare case not an every day use case. This level of flexibility could potentially result in an unsightly set of overrides if the assumptions started as Debian and needed to be changed to Redhat to operate that type of image.

Another alternative would be a set of supported FHS approaches, and in addition to the image itself, you must also elect one of these standard "blueprints" for us to follow on top of it and we will simply case all binary, mounts, and directories assumed around options such as "debian" or "redhat" or "suse" and so on. To manage this, we would not sprawl conditionals everywhere but make these variables and case them once and set them, either explicitly from an override or in the case of a supported FHS approach, set all binaries, mounts, directories and so on to that known distribution standard.

Thoughts?

[wilreichert]

When it comes to supporting multiple distros, setting a single parameter makes a lot more sense than multiple volume overrides. Especially if there was a standard case pattern for dealing with the differences as they arise. Apache is likely the worst offender here but undoubtedly others distro diffs are present. Beyond vendoring, what about the case of native packaged vs. pip source installs placing files in completely random locations? Does that have the potential to cause issues as well? i.e. pip defaults to /usr/local/lib/python2.7, kolla uses /var/lib/kolla/venv/lib/python2.7, native packages use /usr/lib/python2.7, etc.

[andrecolin]

@wilreichert are you still working on this?

[wilreichert]

I was holding off until #262 is merged since that would resolve a number of the mount issues. I'm happy to do a WIP PR to address Horizon though.

[v1k0d3n]

i'm going to push this item out for a future roadmap (by then we'll be in openstack proper, @wilreichert). but to address what you're asking for is going to take some planning. i'll be looking for some input on #262 from you, once you've had a chance to cut into it.