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

Join cartridge development? #6

Open
thePanz opened this issue Oct 24, 2015 · 4 comments
Open

Join cartridge development? #6

thePanz opened this issue Oct 24, 2015 · 4 comments

Comments

@thePanz
Copy link

thePanz commented Oct 24, 2015

First of all:thank you @boekkooi for your work with PHP-FPM and Nginx cartridges! :)

I got pointed to your work by @thefill, and being able to use Nginx and PHP 5.6 on Openshift is amazing! I encountered also a fork of this cartridge made by @exileed that updated the available PHP versions to 5.6.13 and 5.5.29 respectively.

Is there a 'not-so-far-future' where all theses cartridges will be available under an organization to join forces? Since OpenShift is not listening to user voices to have Nginx and a maintained version of PHP available this can be a good move from the community :)

PS :Openshift still offers PHP 5.3 and 5.4 (both of them no more maintained) and the request to have PHP 5.5 is still "under review" from January 2014 (https://openshift.uservoice.com/forums/258655-ideas/suggestions/6291553-php-5-5-x-please) :(

@boekkooi
Copy link
Owner

Hi @thePanz

First of all my work for supporting different versions of nginx and php on openshift was done as a proof of concept. I just wanted to proof that is was possible and I never expected that this many people would use it, mainly because I expected Openshift/RedHat to update there php versions and add nginx support.

As I see it a joined system of pre-build nginx and php versions would be great! There are a few problems that would need to be solved for this to happen.

First there will need to be a place where we can host pre-build versions of software (a.k.a. a repository). This is not really hard but since I don't have a server around where I can put these files and the github really is not the correct place, a server needs to be found.

Secondly the current openshift-cartridge-php needs to be modified to download the php version and extract it (a.k.a. download the usr/php-<version> dir). This is really no work at all since it just adds another wget/curl and a extract command.

Thirdly we need a better way to automate the building of versions since versions can only be build on openshift. This is also not rocket science but it is needed, if we want everyone to use the same and/or latest versions to avoid custom forks.

The last problem that I see is that because openshift is working on there docker version we will get this all working and they change the platform at that time.

If you want every one to join forces I'm in!!! but I won't be able to take a leading role because I currently don't have the time.

@thePanz
Copy link
Author

thePanz commented Oct 25, 2015

Dear @boekkooi, thank you for your reply!
I totally agree on your plan for code cleanup and fixes to have a fully working environment! Honestly I miss the OpenShift blog post you linked (from August 2014): from the OpenShift blog I can see that something is moving in such directory, but no news on the "OpenShift Online" front. Again, I am with you regarding the last problem you mentioned about having OpenShift changing their platform with no notice.
Since we can't predict when it will happen, I believe that merging the efforts with these cartridges can be a first solution: trying to not disperse the forces. As an example: I am using @exileed fork with the updated php 5.6 branch (running on @askmatey's fork of openshift-cartridge-nginx with the 1.9.5 version); where should I open a bug issue? I may open the issue affecting all the cartridges on a fork no more monitored. I am not against forks, but I'd like to provide a "reference" repository where PRs are sent and merged.

Of course, the cost of maintaining and updating all the PHP and NGINX release is too high if it is done singularly (I am also using OpenShift for a personal side project, thus having a very limited time), but given the number of already available contributors won't be such a pain :) Having a github organization would help?

Regarding the 'compiled data storage': I am aware that GitHub provides Large File Storage (LFS) support that can be used to store (compressed?) compiled libraries. Compiling will still require a dedicated gear to be executed and compiled code to be committed in the repo.
Keeping the repository light could be done by removing the obsolete 'blobs' from the GIT tree once an updated major release of PHP/Nginx is committed; but still requires some extra work.

Hope tto not having bothered you too much, let's wait for the other collaborator's reactions :)

@boekkooi
Copy link
Owner

Just as a quick note it looks like LFS is a possibility see the api for more details

@boekkooi
Copy link
Owner

boekkooi commented Jun 6, 2016

So this issue has been dead for a while but I just created a branch that uses LFS for the compiled versions and it works nicely.
Have a look at https://github.com/boekkooi/openshift-cartridge-php/tree/lfs or give it a try rhc cartridge add -a myapp http://cartreflect-claytondev.rhcloud.com/github/boekkooi/openshift-cartridge-php?commit=lfs.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants