New release (and a proposal) about ojs HOT 32 CLOSED

This is awesome marc, the problem is where can you run this crontab file? I can set to run over my computer which stay on 24/7, but than should be migrated to some pkp server later.

This is the process what i'm doing now:

1. Update the master branch to the new ojs version
2. Create a new release over github with the new version
3. Update the lastest release pointing to the new version
4. After that the dockerHub already detects the new tag and rebuild:
   

So, we can create an script to run and make this automatically for now, but i think the best is to join this project inside pkp/ojs and created a new dockerHub pointing directly to pkp/ojs image file, this can be done over #4.

So far i'll upgrade to the new version manually o close this issue.

Thanks.

from ojs.

@marcbria , just to confirm, this is the release tag? I noticed that the name pattern has changed.

from ojs.

Yes, this is the right tag... although I'm unsure why the "ojs-" prefix was removed.
I will ask Alec next week.

Thanks for the job!

BTW... did you noticed we need to move to PHP7?

To run the latest release of OJS 3.x, your web server will need:
PHP 7.0 or later with MySQL or PostgreSQL support

I was not aware of this and it could explain the errors we got with former 3.1.1-4 release.

If it's ok for you, I will defend in the PKP technical committee the proposal of including you in the end of the development workflow... with minimal info, but to keep you informed about new releases and important changes (as this php5 to php7 upgrade).

What do you think?

from ojs.

About the script proposal:

The problem is where can you run this crontab file? I can set to run over my computer which stay on 24/7, but than should be migrated to some pkp server later.

Only as a temporary solution, a cron in you laptop could be great. I mean... it's close to perfection if we dockerize the new release in "the next working day", but if you prefer setting this in a server, I can offer mines or ask PKP to set the cronjob in theirs.

But maybe we don't need scripting if we improve the communication workflows and you are advice of new releases and major architecture changes 2 weeks before every release?

from ojs.

@marcbria , about the PHP7 i was going to ask you, to upgrade to latest version of Alpine i needed to upgrade to PHP7 but i was unsure if PKP/OJS has the available support. So you confirm that i need to upgrade to PHP7?

When upgrading to PHP7, we should migrate to official PHP7 Container and that should change a lot, as we need to starting using multi-layer container, for separating compose and npm process, what you think?

About the commitee feel free to include me, i'm most willing to help in the project growth.

Thanks.

from ojs.

About the script proposal:

The problem is where can you run this crontab file? I can set to run over my computer which stay on 24/7, but than should be migrated to some pkp server later.

Only as a temporary solution, a cron in you laptop could be great. I mean... it's close to perfection if we dockerize the new release in "the next working day", but if you prefer setting this in a server, I can offer mines or ask PKP to set the cronjob in theirs.

But maybe we don't need scripting if we improve the communication workflows and you are advice of new releases and major architecture changes 2 weeks before every release?

Awesome, advising 2 weeks before is nice.

About the script i'm going to make this today as a temporary solution. The 3.1.2-0 version should be released as the script runs.

Thanks.

from ojs.

about the PHP7 i was going to ask you, to upgrade to latest version of Alpine i needed to upgrade to PHP7 but i was unsure if PKP/OJS has the available support. So you confirm that i need to upgrade to PHP7?

I confirm we need to upgrade to php7 and I offer myself to test the new release during next week. ;-)
IMPORTANT: Keep in mind that you also need to change the database driver from "mysql" to "mysqli" in the config.inc.php.

When upgrading to PHP7, we should migrate to official PHP7 Container and that should change a lot, as we need to starting using multi-layer container, for separating compose and npm process, what you think?

I'm not a docker expert so I'm unsure about this.

Some questions rise to me (sorry in advance if answer is obvious):

• Why not keeping alpine and install php7 instead of php5?
• If we need (or like) to move to official php7, do you know if the image will be much more heavy?
• Why do we need multi-layer? I mean, official php images are not multilayered, aren't them?
• If we need (or like) to move to multi-layer, do you feel like they are extended enough right now? (for instance, will it work with PWD?)

My suggestion here will be conservative and keep working with alpine to keep changes to the minimum till we find time to review it all in deep... but if you feel the opposite, I respect your expertise and opinion.

from ojs.

• Why not keeping alpine and install php7 instead of php5?
  There is not difference really, but i as saw offical images tend to use the offical php image as well.

• If we need (or like) to move to official php7, do you know if the image will be much more heavy?
  Migrating to PHP7 by the official image or by Alpine directly will be a more heavy test progress, at least at the beginning.

• Why do we need multi-layer? I mean, official php images are not multilayered, aren't them?
  Multi-layer is good for separation of responsability, we'll have a container for compose taks, another one with npm taks, as the last one will be the hosting tasks. So i don't need to install npm to build stuff and than later remove it and clean the residual files.

• If we need (or like) to move to multi-layer, do you feel like they are extended enough right now? (for instance, will it work with PWD?)

The process of building a container using a multi-layer perspective doesn't change the final container, actually it changes nothing as the user always will use lucas.diedrich/ojs:latest container. Don't worry about this. Multi-layer its just a term to build one image using separation of responsability.

About the PHP7 upgrade, i'm going to release 3.1.2 version, an than i can start the process of migrating to PHP7. Is that ok?

Thanks for all the help @marcbria .

from ojs.

@marcbria, check out this commit made by the automatic script, it created the tag like 3_1_2-0, i`m thinking its better maintain the 3.1.2-0 tag as i was using, going to fix that now. The new release will be ready tomorrow.

Thanks,

from ojs.

Sorry for the silence. Today we had a feminist general strike and I support it so I didn't go to work.

I understood your arguments for the official php, as well as the multi-layer and you convince me.

It's great if you start moving to php7 in 3.1.2. Once it's done and tested I will PR you a 3.1.1-4 version with php7 to discover if the issues we had were related with php version or not.

About the tags, I'm also ok with adding a -0 to the end, but I think we need to talk with PKP to be more consistent with the version numbering. It will make authomatisms easier.

PKP didn't announce nothing so we are still in the "unofficial" zone so nobody is expecting 3.1.2-0 docker version as soon as PKP releases it.

I mean, we are not in a hurry with this, but as soon as you finish the dockerfile I will test it.

Thanks a lot for your work Lucas.

PD: BTW, did you know about a this. Any chance to see you in Barcelona this November?

from ojs.

Hi @lucasdiedrich

No hurry with this. Just asking to plan my weekly agenda... any estimation about a the Dockerfile for ojs 3.1.2 with php7?

Thanks for your work,
m.

from ojs.

Hey @marcbria, going to start the process today, i'm just finishing some work that i have to do first, sorry for letting you without of communication.

About the PKP conference should be really nice going there, but as i live in Brazil the passage cost can be very expensive, i'll be monitoring ticket prices and i let you informed ;).

Thanks.

from ojs.

@marcbria, quick update, i have already created the image base using one for code compiling (installation of deps) and another one which will run (apache), i'm using PHP 7.3 + Apache 2.

Unfortunetly i'm hitting the erro bellow:

[Tue Mar 12 20:54:26.398598 2019] [php7:warn] [pid 17] [client 172.17.0.1:42570] PHP Warning:  Declaration of InstallHandler::validate($request) should be compatible with PKPHandler::validate($requiredContexts = NULL, $request = NULL) in /var/www/html/lib/pkp/pages/install/InstallHandler.inc.php on line 118
[Tue Mar 12 20:54:26.427645 2019] [php7:error] [pid 17] [client 172.17.0.1:42570] PHP Fatal error:  Uncaught Error: Call to undefined function mb_split() in /var/www/html/lib/pkp/lib/vendor/smarty/smarty/libs/plugins/shared.mb_str_replace.php:47\nStack trace:\n#0 /var/www/html/lib/pkp/lib/vendor/smarty/smarty/libs/plugins/modifier.replace.php(34): smarty_mb_str_replace('_', '-', 'en_US')\n#1 /var/www/html/cache/t_compile/13376d7934b5f251160733e5e3c8b2ff6a1e1f24^652202841b9a358b5663534995b87eb1fcc7545d_0.core.commonheader.tpl.php(29): smarty_modifier_replace('en_US', '_', '-')\n#2 /var/www/html/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_5c881b90808913_23753477(Object(Smarty_Internal_Template))\n#3 /var/www/html/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode(Object(Smarty_Internal_Template))\n#4 /var/www/html/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(216): Smarty_Template_Compiled->render(Object(Smarty_Internal_Template))\n#5 /var/www/ht in /var/www/html/lib/pkp/lib/vendor/smarty/smarty/libs/plugins/shared.mb_str_replace.php on line 47

Going to look more tomorrow, an image is already beeing made at dockerhub, you can use it as lucasdiedrich/ojs:php7-test

Thanks.

from ojs.

Nevermind, it was some php7 dependencies missing, we should review that later on. New build in process.

from ojs.

@marcbria , was you able to test the test-php7 version?

from ojs.

sorry... I didn't noticed it was ready to test. Sorry.
I will do tomorrow morning.

Thanks a lot Lucas!
Cheers,
m.

from ojs.

I couldn't resist the temptation and I made a fast test with a formerly created stack.
Unfortunately it didn't work and I get a WSOD with the following log:

Creating brumalnew_db ...                                         
Creating brumalnew_db ... done                                    
Creating brumalnew_ojs ...                                             
Creating brumalnew_ojs ... done                                                       
Attaching to brumalnew_db, brumalnew_ojs                                                                                           
db_1   | 2019-03-14 14:29:15 140000731850624 [Note] mysqld (mysqld 10.2.15-MariaDB-10.2.15+maria~jessie) starting as process 1 ...
db_1   | 2019-03-14 14:29:15 140000731850624 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
db_1   | 2019-03-14 14:29:15 140000731850624 [Note] InnoDB: Uses event mutexes        
db_1   | 2019-03-14 14:29:15 140000731850624 [Note] InnoDB: Compressed tables use zlib 1.2.8
db_1   | 2019-03-14 14:29:15 140000731850624 [Note] InnoDB: Using Linux native AIO    
db_1   | 2019-03-14 14:29:15 140000731850624 [Note] InnoDB: Number of pools: 1
db_1   | 2019-03-14 14:29:15 140000731850624 [Note] InnoDB: Using SSE2 crc32 instructions
db_1   | 2019-03-14 14:29:15 140000731850624 [Note] InnoDB: Initializing buffer pool, total size = 256M, instances = 1, chunk size = 128M
db_1   | 2019-03-14 14:29:16 140000731850624 [Note] InnoDB: Completed initialization of buffer pool
db_1   | 2019-03-14 14:29:16 139999996614400 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can bec
hanged. See the man page of setpriority().
db_1   | 2019-03-14 14:29:16 140000731850624 [Note] InnoDB: Highest supported file format is Barracuda.
db_1   | 2019-03-14 14:29:16 140000731850624 [Note] InnoDB: Starting crash recovery from checkpoint LSN=11942956
ojs_1  | 2019-03-14 15:29:16,163 CRIT Supervisor is running as root.  Privileges were not dropped because no user is specified in the config file.  If you intend to run as root, you can set user=root in the config file to avoid this message.
ojs_1  | 2019-03-14 15:29:16,168 INFO supervisord started with pid 1
db_1   | 2019-03-14 14:29:16 140000731850624 [Note] InnoDB: 128 out of 128 rollback segments are active.
db_1   | 2019-03-14 14:29:16 140000731850624 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
db_1   | 2019-03-14 14:29:16 140000731850624 [Note] InnoDB: Creating shared tablespace for temporary tables
db_1   | 2019-03-14 14:29:16 140000731850624 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
db_1   | 2019-03-14 14:29:16 140000731850624 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
db_1   | 2019-03-14 14:29:16 140000731850624 [Note] InnoDB: 5.7.22 started; log sequence number 11942965
db_1   | 2019-03-14 14:29:16 139999416674048 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
db_1   | 2019-03-14 14:29:16 140000731850624 [Note] Plugin 'FEEDBACK' is disabled.
db_1   | 2019-03-14 14:29:16 140000731850624 [Note] Recovering after a crash using tc.log
db_1   | 2019-03-14 14:29:16 140000731850624 [Note] Starting crash recovery...
db_1   | 2019-03-14 14:29:16 140000731850624 [Note] Crash recovery finished.
db_1   | 2019-03-14 14:29:16 140000731850624 [Note] Server socket created on IP: '::'.
db_1   | 2019-03-14 14:29:16 140000731850624 [Warning] 'proxies_priv' entry '@% root@08355b620f85' ignored in --skip-name-resolve mode.
db_1   | 2019-03-14 14:29:16 140000731850624 [Note] Reading of all Master_info entries succeded
db_1   | 2019-03-14 14:29:16 140000731850624 [Note] Added new Master_info '' to hash table
db_1   | 2019-03-14 14:29:16 140000731850624 [Note] mysqld: ready for connections.
db_1   | Version: '10.2.15-MariaDB-10.2.15+maria~jessie'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution
db_1   | 2019-03-14 14:29:16 139999416674048 [Note] InnoDB: Buffer pool(s) load completed at 190314 14:29:16
ojs_1  | 2019-03-14 15:29:17,171 INFO spawned: 'apache' with pid 9
ojs_1  | 2019-03-14 15:29:17,174 INFO spawned: 'crond' with pid 10
ojs_1  | 2019-03-14 15:29:17,177 INFO spawned: 'checkstart' with pid 11
ojs_1  | 2019-03-14 15:29:17,225 INFO exited: checkstart (exit status 0; not expected)
ojs_1  | 2019-03-14 15:29:18,227 INFO success: apache entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
ojs_1  | 2019-03-14 15:29:18,227 INFO success: crond entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
ojs_1  | 2019-03-14 15:29:18,231 INFO spawned: 'checkstart' with pid 25
ojs_1  | 2019-03-14 15:29:18,283 INFO exited: checkstart (exit status 0; not expected)
ojs_1  | 2019-03-14 15:29:20,286 INFO spawned: 'checkstart' with pid 34
ojs_1  | 2019-03-14 15:29:20,345 INFO exited: checkstart (exit status 0; not expected)
ojs_1  | 2019-03-14 15:29:23,352 INFO spawned: 'checkstart' with pid 43
ojs_1  | 2019-03-14 15:29:23,406 INFO exited: checkstart (exit status 0; not expected)
ojs_1  | 2019-03-14 15:29:24,407 INFO gave up: checkstart entered FATAL state, too many start retries too quickly

Then I remove the database, I set ojs "installed" and "restful_urls" variables to Off and I could install, but when the installation finishes, I was redirected to a wrong url (/index/index).

I suspect your Dockerfile is working but my mod_rewrite rules are interfering.
I will test deeper tomorrow.

Thanks a lot Lucas,
m.

from ojs.

I missed the most important part :-) php logs report the following error:

[Thu Mar 14 15:45:53.637133 2019] [php7:error] [pid 20] [client 158.109.238.110:47698] PHP Fatal error: Uncaught Error: Call to undefined function session_set_save_handler() in /var/www/html/lib/pkp/classes/session/SessionManager.inc.php:47\nStack trace:\n#0 /var/www/html/lib/pkp/classes/session/SessionManager.inc.php(129): SessionManager->__construct(Object(SessionDAO), Object(Request))\n#1 /var/www/html/lib/pkp/classes/security/Validation.inc.php(371): SessionManager::getManager()\n#2 /var/www/html/lib/pkp/classes/core/PKPPageRouter.inc.php(66): Validation::isLoggedIn()\n#3 /var/www/html/lib/pkp/classes/core/Dispatcher.inc.php(117): PKPPageRouter->isCacheable(Object(Request))\n#4 /var/www/html/lib/pkp/classes/core/PKPApplication.inc.php(252): Dispatcher->dispatch(Object(Request))\n#5 /var/www/html/index.php(68): PKPApplication->execute()\n#6 {main}\n thrown in /var/www/html/lib/pkp/classes/session/SessionManager.inc.php on line 47

As said... it was tested poorly over an existing site, trying to upgrade.
Let me take a deeper and a more systematic look tomorrow with a clean install, and so on.

from ojs.

from ojs.

Hello,

the current Dockerfile provided in git is not compatible with ojs 3.1.2, it needs modifications (for using php7 instead of php5),

I notice also that the docker-compose.yml provided in git is not usable, because of an error of indentation, yml parser will fail, and there is also syntax problem with the environment variables,

thanks

from ojs.

Hi @Potomac54,

OJS 3.1.2 recommendation is php7, so Lucas is moving from php5 to 7.
If you found errors, I'm pretty sure Lucas will appreciate a PR.

Otherwise, open a new issue and write down your suggestions.

Cheers,
m.

from ojs.

Hi @marcbria,

I thought that Lucas has already built a docker image of OJS 3.1.2, because the Dockerfile in git has a reference to 3.1.2 version of OJS :

https://github.com/lucasdiedrich/ojs/blob/master/Dockerfile

as the current Dockerfile is not usable (it still uses php5) then I suggest to revert this commit, in order to set the version to 3.1.1-4 :

7f2ce9d

the purpose is to have usable Dockerfile for those who discover Lucas's project, they expect to have working files "out of the box" (Dockerfile, docker-compose.yml), currently it's not working and this can lead misunderstandings

from ojs.

Hey @Potomac54 , how are you? What you mean by not usable?

As far as i know, the master branch using the 3.1.2 version compile without error, also the docker-compose.yml file, now we are migrating the 3.1.2 to use php7 version, which is the php-7-test branch.

The 3.1.2 are test builds not stable yet, in order to help we need the informations about whats wrong, please show some logs or prints if possible.

If you wan't, you can use the 3.1.1-4 tag .

Thanks

from ojs.

Hello Lucas,

when using the current Dockerfile (in master branch) it compiles with no errors (docker build), but when running the image it will not work, php error messages are displayed when I go to the install page of OJS, because OJS 3.1.2 needs php 7 (it is not usable with php5),

https://github.com/lucasdiedrich/ojs/blob/master/Dockerfile

the commit 7f2c9d comes too soon in the master branch (because the migration of Dockerfile to php7 is not finished yet), I think you should revert this commit for the master branch,

master branch is supposed to give usable and stable files, this is not the case when user clones the master branch,

for docker-compose.yml in the master branch : my yml parser found errors (bad indentation at line 32, and syntax problem for environment variables) :

ERROR: yaml.parser.ParserError: while parsing a block mapping
in "./docker-compose.yml", line 3, column 3
expected , but found ''
in "./docker-compose.yml", line 32, column 5

ERROR: Invalid interpolation format for "container_name" option in service "db": "${COMPOSE_PROJECT_NAME:ojs}_db"

replacing "${COMPOSE_PROJECT_NAME:ojs}_db" by "${COMPOSE_PROJECT_NAME}_db" solves this kind of errors

from ojs.

Hi @lucasdiedrich ,

I thinks @Potomac54 is right.

If I checked it well, right now:

• latest ------> 3.1.1-4
• master ----> 3.1.1-2
• php5-test -> 3.1.2-0

But something happens with images because a simple docker deploy (without docker-compose) makes them fail. I mean, you can see the install page but is not able to go to the next page.

I tested them and I open new issues for each error to keep things sorted.

To follow talking about 3.1.1-4 branch (latest): #14
To talk about the 3.1.2-0 branch (php7-test): #15

Anyway, if it worked before last commit, what about reverting master branch as Potomac54 suggests till we have all 3.1.2 up and running? @Potomac54 do you mind to report which is the last version that is working to you?

@Potomac54 what I don't understand is why you get errors with the "brace expansion".
The syntax is right and it's the recommended way to define default variables.

What is your docker and docker-compose versions?

from ojs.

Hello Macrbria,

I use ubuntu 18.04 , I installed docker 6 months ago, it's the PC I use at my work, so I will tell you tomorrow the exact version,

perhaps the syntax in docker-compose.yml file is too recent for my docker version

from ojs.

Don't need to. I just realize that you are also right with this. :-)

It's my docker that was old and accepted an deprecated syntax.
"Brace expansion" is still accepted but the default value need a "-" before.
Apart from this, environment variables were wrongly set.

A example of how it need to look like:

environment: SERVERNAME: ${PROJECT_DOMAIN:-pkp.ojs.localhost} OJS_CLI_INSTALL: 1 OJS_DB_HOST: 'db'

Now my docker-compose passes the config check.
Tomorrow will make a PR to lucas, to avoid him losing time with syntax issues.

from ojs.

here is the version of docker I use :
Docker version 18.06.1-ce, build e68fc7a

and for docker-compose :
docker-compose version 1.22.0, build f46880fe

from ojs.

@marcbria , i just need some guidance over here, to much information over here, should i revert the master branch as requested by @Potomac @Potomac54, than fix the master with both #14 #15. Than re-upload the base images to github, is that right?

Thanks.

from ojs.

@marcbria , don't mind with the PR to fix the docker-compose file, already did it at 783cb5b

from ojs.

@Potomac @Potomac54 @marcbria, can you please test the lastest master branch and container image?

Thanks

from ojs.

Closing this issue to make the issue tracker cleaner as we're handling the new optimizations issue by issue.

from ojs.