Foros de discusión

Liferay source code patching

Vincent CARNINO, modificado hace 9 años.

Liferay source code patching

Junior Member Mensajes: 47 Fecha de incorporación: 11/09/14 Mensajes recientes
Hi, i need some precisions on the way to handle patching with the staging process on.

Is it possible to use different Liferay source code for staging and for live server. What i want is to test potential patches first on the staging server and then (if everything is ok) to apply these patches to the live server but i'm afraid that there could be conflicts.

Do i have to update liferay source code on both (live and staging) servers at once ?

Thanks in advance for your answers.

PS: I'm also wandering, if my staging server is off for a moment but my live server is on, is this a problem ? Will i be able to restart my staging server without conflicts ?

PS2: Different topic, but i was wondering if i have to use liferay GitHub repository as a base and then apply every patch myself or if it would be better to use Liferay CST repository in order to use there cumulative patch ?
thumbnail
David H Nebinger, modificado hace 9 años.

RE: Liferay source code patching

Liferay Legend Mensajes: 14914 Fecha de incorporación: 2/09/06 Mensajes recientes
Vincent CARNINO:
Is it possible to use different Liferay source code for staging and for live server. What i want is to test potential patches first on the staging server and then (if everything is ok) to apply these patches to the live server but i'm afraid that there could be conflicts.


Testing a patch is different than a remote staging setup. A remote staging setup, both systems should be considered as production Liferay systems, it's just that one of those is used for creating and approving content.

If you need or want to test a patch, you should be doing that in a separate test server.

Do i have to update liferay source code on both (live and staging) servers at once ?


Both production remote staging instances should be at the same version of Liferay.

PS: I'm also wandering, if my staging server is off for a moment but my live server is on, is this a problem ? Will i be able to restart my staging server without conflicts ?


Your staging instance is where you create content, but publish to the other remote. If the staging instance is offline, you just won't be able to create or publish content while it is offline.

PS2: Different topic, but i was wondering if i have to use liferay GitHub repository as a base and then apply every patch myself or if it would be better to use Liferay CST repository in order to use there cumulative patch ?


If you are concerned about patching and updates you should consider Liferay EE. You get regular patch releases from them and you don't have to worry about figuring out which patches are good and which patches are not ready yet. You also don't have to worry about pulling patches from github and applying them manually.

If you're trying to use CE in a production, internet facing server and want to maintain by tracking and applying patches yourself, well then you're in for a world of hurt. Liferay doesn't make it easy to do this, but it is possible. You end up having to keep a working version of the source that you can apply the patch(es) to, then do a build and deploy. This you'd really want a separate test instance because you won't want to take either of your production instances out as a result of a bad patch.

Note that github patches are cumulative and apply against the master (currently 7.0) branch. Pulling patches out of github to apply to, say, a 6.1 code base would be extremely painful (whereas a 6.1 EE instance you get updates to 6.1 and don't have to back-patch yourself).
Vincent CARNINO, modificado hace 9 años.

RE: Liferay source code patching

Junior Member Mensajes: 47 Fecha de incorporación: 11/09/14 Mensajes recientes
Thanks alot, David, for your accurate answers (as always).

About Liferay EE, if i could afford it, i would. But the cost of it won't fit in my budget ...
I was asking about patches because i though it was unavoidable but maybe it's not that necessary.
My current project concerns an entreprise intranet, and all i need is some basic fonctionalities.
In your opinion, since Liferay 6.2 CE is stable won't it be sufficient to "patch" with CST cumulative patches (only for security) ? Do you think that it's ok to use Liferay 6.2 CE for production ?

Again thanks for your previous answers and thank you in advance for your future answers.
thumbnail
David H Nebinger, modificado hace 9 años.

RE: Liferay source code patching

Liferay Legend Mensajes: 14914 Fecha de incorporación: 2/09/06 Mensajes recientes
Vincent CARNINO:
My current project concerns an entreprise intranet, and all i need is some basic fonctionalities.
In your opinion, since Liferay 6.2 CE is stable won't it be sufficient to "patch" with CST cumulative patches (only for security) ? Do you think that it's ok to use Liferay 6.2 CE for production ?


CE should be fine for an intranent. Typically if you are internet-facing, those situations demand EE just because of the regular patching that is available for them. Alternatively you might want or need EE to get some of the EE functionality, but only you know if that's required or not.

Out of curiosity, if you haven't checked on pricing you might talk with them about it just to be sure. Honestly I don't know how EE is priced, but I do believe that non-profits get breaks on pricing, but it never hurts to share with them what you're doing and what you need just to see if they can find something to fit what you're building.

Anyway, if you pick a later CE, most of the time you shouldn't have to worry about patching unless, of course, there's some sort of specific bug that's impacting you. For example, 6.2 CE GA 2 has been out for many months now (I don't know how many), but it's proven to be stable enough for most CE implementations. I would pay attention if they come out with a GA3 (or whatever) as that tends to include a bunch of patches (somewhat tested and ready) so it's typically a good idea to add those.

But as far as applying patches on an individual basis, that can be a full-time job all on it's own. Instead I'd try to go with the latest GA, upgrade if a new GA becomes available, and otherwise only go to the patches if, in fact, you hit a bug that you cannot work around on your own.
Vincent CARNINO, modificado hace 9 años.

RE: Liferay source code patching

Junior Member Mensajes: 47 Fecha de incorporación: 11/09/14 Mensajes recientes
Thanks a lot David, clear as always.

For the EE version, i'm gonna think about it but the fact that i won't have to patch very often even with CE version confort me.

If you don't mind, i want to ask you some questions which are not related to a unique subject but which are about setup and installation for sure.

  • In your backup process, you say that regularly, it's needed to update the staging server database with the live server database but what about the data ? isn't it a problem to update the database without also updating the data ? The staging server and the live one shouldn't have the same data (on remote staging of course since with local staging data are shared) ?
    On the same topic, you mentioned that copying the database and the data, while the server is still on, may bring some conflicts. Is it really risky and should i put the database in "read only" mode during the copy ? How about the data ? Should i go for a file system with snapshot ?

  • I've planed to use remote staging especially to be able to modified some plugin without affecting live server. But i actually don't dispose of 2 physical server but only one with 2 virtual dedicated server. I think even though that it is useful because of the plugin thing but do you think is it really that useful (this implies two sets of data) ? I'm always able to test a plugin on my own computer, is it not enaugh and would it be better to go for a local staging environment in my case ?

  • If i go for a remote staging environment how many disk space should i dedicate to each server ? How about the RAM (i was thinking 2Go for the staging server and the rest for the live one) ? What is the average size of the database ?


I know this is a lot of questions ! Some of them might be difficult to answer because it is related to my goals but i can't stop thinking about it untill i'm sure that i'm going in the right direction.
I would be very thankful if you could give me some answers but, rather or not, i thank you again for your previous answers.
thumbnail
David H Nebinger, modificado hace 9 años.

RE: Liferay source code patching

Liferay Legend Mensajes: 14914 Fecha de incorporación: 2/09/06 Mensajes recientes
Vincent CARNINO:
  • In your backup process, you say that regularly, it's needed to update the staging server database with the live server database but what about the data ? isn't it a problem to update the database without also updating the data ? The staging server and the live one shouldn't have the same data (on remote staging of course since with local staging data are shared) ?


Sorry about the confusion. I always consider the two to be so integrated that sometimes I just talk about the database... Whenever you do something with the database (back it up, migrate to another environ, etc.) you should also be doing the same with the data directory. They are pretty tightly coupled and should always go together.

On the same topic, you mentioned that copying the database and the data, while the server is still on, may bring some conflicts. Is it really risky and should i put the database in "read only" mode during the copy ? How about the data ? Should i go for a file system with snapshot ?


So the issue here is around copying the data while some user activity is in flight. For the database, Liferay's use of hibernate can mean that some data is still held in the cache; the only way to ensure all caches are flushed (and no new data is added before the DB copy/backup completes) is to shut down. Likewise for the data directory, if you start a tar process on the data directory while a user is uploading a new document or triggered an index update, well then your tar would capture part of the change. So just like the db, shutting down is the only way to ensure you get everything.

Now this sounds pretty dreadful, but fortunately it's an edge case. Most of the time we do this kind of thing off hours when no one is on, and even if folks are on the only susceptible data is the very latest changes so it may be just fine.

Obviously you should test to see what your risk potential is. You can test to see the impacts of grabbing a data directory backup during an instant when a doc upload is completing, you can capture a DB backup while users are in the system, then restore to another system and test to determine how it comes back up and what the impact is.

  • I've planed to use remote staging especially to be able to modified some plugin without affecting live server. But i actually don't dispose of 2 physical server but only one with 2 virtual dedicated server. I think even though that it is useful because of the plugin thing but do you think is it really that useful (this implies two sets of data) ? I'm always able to test a plugin on my own computer, is it not enaugh and would it be better to go for a local staging environment in my case ?


Remote staging is not for testing plugins. Remote staging is for testing content only. When using remote staging, it is important to treat both environments as production environments. They should both be updated and patched at the same time, the plugins should be updated at the same time, ...

Basically you don't want to risk anything disrupting your staging setup as it affects your ability to publish content.

For your plugins, you should have a separate test server (outside of your remote staging configuration) to test functionality.

  • If i go for a remote staging environment how many disk space should i dedicate to each server ? How about the RAM (i was thinking 2Go for the staging server and the rest for the live one) ? What is the average size of the database ?


There's no hard and fast rule about sizing as it always depends on the sizing in your environment. I might have a million docs whereas you only have a thousand, so my disk needs are significantly different than yours. I might have only a thousand users but you have millions with lots of web content, so your database requirements are significantly different than mine.

Memory is calculated a little differently, it will be based on how much to run liferay and should grow based upon expected concurrent user load. If you have a handful of content creators and approvers in the staging system, memory requirements will be lower than the live instance and 2g is probably more than enough to get everything running like a top.

I know this is a lot of questions ! Some of them might be difficult to answer because it is related to my goals but i can't stop thinking about it untill i'm sure that i'm going in the right direction. I would be very thankful if you could give me some answers but, rather or not, i thank you again for your previous answers.


Eh, they may seem tough, but there's certainly enough detail and they are well thought out so answering these kinds of questions ends up being pretty easy. Glad to help!
Vincent CARNINO, modificado hace 9 años.

RE: Liferay source code patching

Junior Member Mensajes: 47 Fecha de incorporación: 11/09/14 Mensajes recientes
Thanks for those answers, i'm kind of relieved now since i'm quite sure that i'm gonna take good decisions.
Based on that, i'm goint to change my configuration, hopefully for the best.

For the disk space problem (data+databse), the intranet is going to be used by around a hundred of users (at least at the beginning).
For the memory, as you said, only a handful of content creators so 2Go for the staging server should be enough and the rest for the live server.

For the remote staging, i've read the following in the Liferay guide:

With Remote Live staging, your staging and live environments are hosted on separate servers. This allows you to deploy new versions of portlets and content to your staging environment without worrying about interfering with your live environment


So could you, please, confirm to me that it is a mistake ?

Thanks again for your time and of course your answers. I appriciate a lot.
thumbnail
David H Nebinger, modificado hace 9 años.

RE: Liferay source code patching

Liferay Legend Mensajes: 14914 Fecha de incorporación: 2/09/06 Mensajes recientes
Vincent CARNINO:
For the remote staging, i've read the following in the Liferay guide:

With Remote Live staging, your staging and live environments are hosted on separate servers. This allows you to deploy new versions of portlets and content to your staging environment without worrying about interfering with your live environment


So could you, please, confirm to me that it is a mistake ?

Thanks again for your time and of course your answers. I appriciate a lot.


Well, I don't think it's a mistake as much as it is just a clarification based upon your perspective.

Yes, they should be separate servers, but it's not defining physical vs virtual servers as that is a characteristic of your environment. Since you're virtual, then the line would be "separate virtual servers", but if you have no virtualization then it would be "separate physical servers".
Vincent CARNINO, modificado hace 9 años.

RE: Liferay source code patching

Junior Member Mensajes: 47 Fecha de incorporación: 11/09/14 Mensajes recientes
Sorry, i wasn't clear about that question. I was talking about the fact that it is possible to deploy a different portlet on the staging server than the one on the live server.


They should both be updated and patched at the same time, the plugins should be updated at the same time, ...

Basically you don't want to risk anything disrupting your staging setup as it affects your ability to publish content.

For your plugins, you should have a separate test server (outside of your remote staging configuration) to test functionality.


Maybe i'm wrong but i've the impression that the guide says something which is in conflict with what you said. As a precautionary measure, i will go for your advice (if i do understand well ...)

Thanks for your answer David.
thumbnail
David H Nebinger, modificado hace 9 años.

RE: Liferay source code patching

Liferay Legend Mensajes: 14914 Fecha de incorporación: 2/09/06 Mensajes recientes
So the doco is right on most cases, I guess, but it's the odd ones that will throw you, and when you get thrown and you have to figure out how to fix everything back up, well that's when it will seem like trying to do testing and staging on the same server might not have been the best plan.

Typically you have the most problems in this kind of situation when you're trying to move lars around a mixed environment because things from one environ (i.e roles and the like) can make it into the that cannot get imported into other environs.

Staging is not so susceptible to this kind of thing since staging is really just for content, but you should still consider both of the systems as production systems. Save your testing for another environment, one where if things go bad your production environment won't be affected.
Vincent CARNINO, modificado hace 9 años.

RE: Liferay source code patching

Junior Member Mensajes: 47 Fecha de incorporación: 11/09/14 Mensajes recientes
Ok thanks a lot David, i'm going to take your advice and consider the staging environment as one and only "production server".
I'll test plugins on my personal computer and then i'll try to apply it to both (live and staging) servers at once.

Thanks again.