[xwiki-devs] [Brainstorming] Upgrading myxwiki.org
Hi devs, As you know our goal is to use myxwiki.org as a real life test platform to validate releases of XWiki. Current Situation ================== However this is currently not working very well for 2 reasons: 1) We’re always lagging behind on the version installed on myxwiki.org. Right now it’s 7.1.2 and our last released version is 7.3M2. Thus if we notice a problem on myxwiki.org, it’ll be fixed only in much later versions and myxwiki.org is not playing its role of helping validate releases before we release final versions. 2) We don’t really monitor the performance of myxwiki.org. 3) We don’t really analyse issues that can happen on it because we don’t check the logs. Thus I think we need to find a better process for benefitting from myxwiki.org. Question ========= Are we still interested in benefitting from myxwiki.org for testing our releases? If not, then stop reading at this point :) If we are, then I’m making some proposals below. Proposal ========= For 1): I’d like to propose to add a step in our ReleasePlan template as the last step: - Check the myxwiki.org upgrade roster and ping the next person to update myxwiki.org So the idea would be to not make the RM do the upgrade since he/she already has a lot to do to release XWiki but to make him/her responsible for pinging someone to do it. Then we would take turn to upgrade it (in a similar fashion as we do for releasing XWiki). Note that I believe this would also make us work on making it simpler to perform XWiki upgrades and this would benefit our users. We would eat our own dog food basically :) For 2): Here are ideas of what we could monitor and receive alerts when they go beyond a given threshold: - the average response times users get on it, - when a specific requests takes more than N seconds (this would also allow us to find wiki pages written by our users and which take too much CPU thus making the farm slower than it should be), - its uptime - the memory used For 3): I think we could set up some elastic search/kibana solution as we had set up at some point (this makes it nice to browse and search for logs) and then send automatic mails to the devs list or IRC when exception happen. This would have the nice benefit of making us work on fixing the code and not generating exceptions when we have only warnings that don’t impact the stability of the platform. WDYT? If we agree, then we’ll need to discuss how to setup 2 and 3. Thanks -Vincent
+1 On Sat, Nov 7, 2015 at 5:11 PM, [email protected] <[email protected]> wrote:
Hi devs,
As you know our goal is to use myxwiki.org as a real life test platform to validate releases of XWiki.
Current Situation ==================
However this is currently not working very well for 2 reasons:
1) We’re always lagging behind on the version installed on myxwiki.org. Right now it’s 7.1.2 and our last released version is 7.3M2. Thus if we notice a problem on myxwiki.org, it’ll be fixed only in much later versions and myxwiki.org is not playing its role of helping validate releases before we release final versions.
2) We don’t really monitor the performance of myxwiki.org.
3) We don’t really analyse issues that can happen on it because we don’t check the logs.
Thus I think we need to find a better process for benefitting from myxwiki.org.
Question =========
Are we still interested in benefitting from myxwiki.org for testing our releases?
If not, then stop reading at this point :) If we are, then I’m making some proposals below.
Proposal =========
For 1):
I’d like to propose to add a step in our ReleasePlan template as the last step: - Check the myxwiki.org upgrade roster and ping the next person to update myxwiki.org
So the idea would be to not make the RM do the upgrade since he/she already has a lot to do to release XWiki but to make him/her responsible for pinging someone to do it. Then we would take turn to upgrade it (in a similar fashion as we do for releasing XWiki).
Note that I believe this would also make us work on making it simpler to perform XWiki upgrades and this would benefit our users. We would eat our own dog food basically :)
For 2):
Here are ideas of what we could monitor and receive alerts when they go beyond a given threshold: - the average response times users get on it, - when a specific requests takes more than N seconds (this would also allow us to find wiki pages written by our users and which take too much CPU thus making the farm slower than it should be), - its uptime - the memory used
For 3):
I think we could set up some elastic search/kibana solution as we had set up at some point (this makes it nice to browse and search for logs) and then send automatic mails to the devs list or IRC when exception happen. This would have the nice benefit of making us work on fixing the code and not generating exceptions when we have only warnings that don’t impact the stability of the platform.
WDYT?
If we agree, then we’ll need to discuss how to setup 2 and 3.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
+1, definitely. Thanks, Eduard On Sun, Nov 8, 2015 at 1:49 PM, Thomas Mortagne <[email protected]> wrote:
+1
On Sat, Nov 7, 2015 at 5:11 PM, [email protected] <[email protected]> wrote:
Hi devs,
As you know our goal is to use myxwiki.org as a real life test platform to validate releases of XWiki.
Current Situation ==================
However this is currently not working very well for 2 reasons:
1) We’re always lagging behind on the version installed on myxwiki.org. Right now it’s 7.1.2 and our last released version is 7.3M2. Thus if we notice a problem on myxwiki.org, it’ll be fixed only in much later versions and myxwiki.org is not playing its role of helping validate releases before we release final versions.
2) We don’t really monitor the performance of myxwiki.org.
3) We don’t really analyse issues that can happen on it because we don’t check the logs.
Thus I think we need to find a better process for benefitting from myxwiki.org.
Question =========
Are we still interested in benefitting from myxwiki.org for testing our releases?
If not, then stop reading at this point :) If we are, then I’m making some proposals below.
Proposal =========
For 1):
I’d like to propose to add a step in our ReleasePlan template as the last step: - Check the myxwiki.org upgrade roster and ping the next person to update myxwiki.org
So the idea would be to not make the RM do the upgrade since he/she already has a lot to do to release XWiki but to make him/her responsible for pinging someone to do it. Then we would take turn to upgrade it (in a similar fashion as we do for releasing XWiki).
Note that I believe this would also make us work on making it simpler to perform XWiki upgrades and this would benefit our users. We would eat our own dog food basically :)
For 2):
Here are ideas of what we could monitor and receive alerts when they go beyond a given threshold: - the average response times users get on it, - when a specific requests takes more than N seconds (this would also allow us to find wiki pages written by our users and which take too much CPU thus making the farm slower than it should be), - its uptime - the memory used
For 3):
I think we could set up some elastic search/kibana solution as we had set up at some point (this makes it nice to browse and search for logs) and then send automatic mails to the devs list or IRC when exception happen. This would have the nice benefit of making us work on fixing the code and not generating exceptions when we have only warnings that don’t impact the stability of the platform.
WDYT?
If we agree, then we’ll need to discuss how to setup 2 and 3.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 for final versions Thanks, Caty On Mon, Nov 9, 2015 at 5:14 PM, Eduard Moraru <[email protected]> wrote:
+1, definitely.
Thanks, Eduard
On Sun, Nov 8, 2015 at 1:49 PM, Thomas Mortagne <[email protected]
wrote:
+1
On Sat, Nov 7, 2015 at 5:11 PM, [email protected] <[email protected]> wrote:
Hi devs,
As you know our goal is to use myxwiki.org as a real life test platform to validate releases of XWiki.
Current Situation ==================
However this is currently not working very well for 2 reasons:
1) We’re always lagging behind on the version installed on myxwiki.org . Right now it’s 7.1.2 and our last released version is 7.3M2. Thus if we notice a problem on myxwiki.org, it’ll be fixed only in much later versions and myxwiki.org is not playing its role of helping validate releases before we release final versions.
2) We don’t really monitor the performance of myxwiki.org.
3) We don’t really analyse issues that can happen on it because we don’t check the logs.
Thus I think we need to find a better process for benefitting from myxwiki.org.
Question =========
Are we still interested in benefitting from myxwiki.org for testing our releases?
If not, then stop reading at this point :) If we are, then I’m making some proposals below.
Proposal =========
For 1):
I’d like to propose to add a step in our ReleasePlan template as the last step: - Check the myxwiki.org upgrade roster and ping the next person to update myxwiki.org
So the idea would be to not make the RM do the upgrade since he/she already has a lot to do to release XWiki but to make him/her responsible for pinging someone to do it. Then we would take turn to upgrade it (in a similar fashion as we do for releasing XWiki).
Note that I believe this would also make us work on making it simpler to perform XWiki upgrades and this would benefit our users. We would eat our own dog food basically :)
For 2):
Here are ideas of what we could monitor and receive alerts when they go beyond a given threshold: - the average response times users get on it, - when a specific requests takes more than N seconds (this would also allow us to find wiki pages written by our users and which take too much CPU thus making the farm slower than it should be), - its uptime - the memory used
For 3):
I think we could set up some elastic search/kibana solution as we had set up at some point (this makes it nice to browse and search for logs) and then send automatic mails to the devs list or IRC when exception happen. This would have the nice benefit of making us work on fixing the code and not generating exceptions when we have only warnings that don’t impact the stability of the platform.
WDYT?
If we agree, then we’ll need to discuss how to setup 2 and 3.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 Thanks, Marius On Sat, Nov 7, 2015 at 6:11 PM, [email protected] <[email protected]> wrote:
Hi devs,
As you know our goal is to use myxwiki.org as a real life test platform to validate releases of XWiki.
Current Situation ==================
However this is currently not working very well for 2 reasons:
1) We’re always lagging behind on the version installed on myxwiki.org. Right now it’s 7.1.2 and our last released version is 7.3M2. Thus if we notice a problem on myxwiki.org, it’ll be fixed only in much later versions and myxwiki.org is not playing its role of helping validate releases before we release final versions.
2) We don’t really monitor the performance of myxwiki.org.
3) We don’t really analyse issues that can happen on it because we don’t check the logs.
Thus I think we need to find a better process for benefitting from myxwiki.org.
Question =========
Are we still interested in benefitting from myxwiki.org for testing our releases?
If not, then stop reading at this point :) If we are, then I’m making some proposals below.
Proposal =========
For 1):
I’d like to propose to add a step in our ReleasePlan template as the last step: - Check the myxwiki.org upgrade roster and ping the next person to update myxwiki.org
So the idea would be to not make the RM do the upgrade since he/she already has a lot to do to release XWiki but to make him/her responsible for pinging someone to do it. Then we would take turn to upgrade it (in a similar fashion as we do for releasing XWiki).
Note that I believe this would also make us work on making it simpler to perform XWiki upgrades and this would benefit our users. We would eat our own dog food basically :)
For 2):
Here are ideas of what we could monitor and receive alerts when they go beyond a given threshold: - the average response times users get on it, - when a specific requests takes more than N seconds (this would also allow us to find wiki pages written by our users and which take too much CPU thus making the farm slower than it should be), - its uptime - the memory used
For 3):
I think we could set up some elastic search/kibana solution as we had set up at some point (this makes it nice to browse and search for logs) and then send automatic mails to the devs list or IRC when exception happen. This would have the nice benefit of making us work on fixing the code and not generating exceptions when we have only warnings that don’t impact the stability of the platform.
WDYT?
If we agree, then we’ll need to discuss how to setup 2 and 3.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (5)
-
Ecaterina Moraru (Valica) -
Eduard Moraru -
Marius Dumitru Florea -
Thomas Mortagne -
vincent＠massol.net