Task #102
closed
AMQ in production: upgrade OS
100%
Description
The AMQ in production is hosted on:
message-broker.d4science.research-infrastructures.eu
with: ubuntu 9.04.
The OS should be upgraded.
Updated by Pasquale Pagano about 10 years ago
- Category set to System Application
- Target version set to System Configuration
Updated by Luca Frosini about 10 years ago
- Assignee changed from Tommaso Piccioli to Andrea Dell'Amico
Updated by Andrea Dell'Amico over 9 years ago
- Infrastructure Development added
Also the dev VM is old and not maintained. Should we start with that?
Updated by Roberto Cirillo over 9 years ago
- Start date changed from Apr 24, 2015 to Mar 14, 2016
I think is better to wait, for the moment. We can upgrade the OS in dev at the end of the next week and after the upgrade in prod of 3.10.1 release. In this week the development environment is used by external users for some tests with statistical-manager service and the broker is involved in these tests.
For production it's need a minimal downtime, so I think we'll perform this upgrade in 3.11 (of course, after the upgrade in dev environment)
Updated by Andrea Dell'Amico over 9 years ago
Ok, you'll give me the green flag when ready.
Updated by Pasquale Pagano over 9 years ago
Can we avoid a downtime? Can we create a new VM, configure it, test it and when ready simply change the configuration in the IS and shutdown and destroy the previous used service?
Updated by Roberto Cirillo over 9 years ago
I think, it is not possible without a disservice.
Besides to the time between the shutdown and the startup of the new broker, besides to the time that needs to upgrade the broker service endpoint in the IS, it's need a much more relevant time for registering the producers and the consumers to the new broker. Therefore if we change the Service Endpoint resource, I think it's need to restart all the producers service and the consumer services registered to the broker. If this is the case, It's need to restart all the IS-Collector in production environment. I guess it's better to evaluate the possibility to avoid to change the ServiceEndpoint resource and rename the new message-broker VM as the old one. Of course, this test should be done in dev environment. What do you think about this?
Updated by Pasquale Pagano over 9 years ago
Roberto Cirillo wrote:
I think, it is not possible without a disservice.
I have to admit that I am confused even more now.Besides to the time between the shutdown and the startup of the new broker,
If a service does not recognize that a service changed its endpoint and must be restarted, then this service has to be dismissed because it is not suitable to run in the infrastructure.besides to the time that needs to upgrade the broker service endpoint in the IS,
why you to have to update the broker endpoint?it's need a much more relevant time for registering the producers and the consumers to the new broker. Therefore if we change the Service Endpoint resource, I think it's need to restart all the producers service and the consumer services registered to the broker. If this is the case, It's need to restart all the IS-Collector in production environment. I guess it's better to evaluate the possibility to avoid to change the ServiceEndpoint resource and rename the new message-broker VM as the old one. Of course, this test should be done in dev environment. What do you think about this?
Yes, please do the test in the dev environment.
All the above issues will have to disappear because it is completely unreasonable to arrive at the restart of the IS to change an external service.
BTW, the IS does not use the AMQ anymore (it was a dependency introduced by the old accounting) starting from version 3.10 I believe. Soon or later they should restarted.
Updated by Andrea Dell'Amico over 8 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
activemq will die, I'm closing this activity
