Skip to content
This repository has been archived by the owner on Jul 24, 2019. It is now read-only.

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

Open
wilreichert opened this issue Mar 6, 2017 · 7 comments
Labels
Milestone

Comments

@wilreichert
Copy link
Contributor

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
Copy link
Contributor

intlabs commented Mar 6, 2017

@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
Copy link
Contributor Author

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
Copy link
Contributor

alanmeadows commented Mar 6, 2017

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
Copy link
Contributor Author

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.

@v1k0d3n v1k0d3n changed the title Apache package differences in CentOS and Ubuntu break horizon and keystone charts bug: Apache package differences in CentOS and Ubuntu break horizon and keystone charts Mar 8, 2017
@v1k0d3n v1k0d3n added this to the 0.3.0 milestone Mar 8, 2017
@v1k0d3n v1k0d3n added the bug label Mar 8, 2017
@andrecolin
Copy link

@wilreichert are you still working on this?

@wilreichert
Copy link
Contributor Author

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
Copy link
Collaborator

v1k0d3n commented Mar 22, 2017

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.

@v1k0d3n v1k0d3n modified the milestones: 0.6.0, 0.3.0 Mar 22, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants