Skip to content

Conversation

@helbashandy
Copy link
Contributor

Upgrade metacat more intelligently by waiting for metacat node capabilities status change.

Description

  • Upgrade metacat more intelligently by waiting for metacat node capabilities status change.
  • Read configured version and make sure it's 2.12.3 or above to apply the node capabilities upgrade monitoring method. If it's below 2.12.3, then it will apply a sleep for x time.
  • Wait incrementally if the upgrade didn't finish, and time out if the upgrade took too more than 5 minutes.
  • Read current metacat version from the node capabilities end point to properly log it.
  • Updated README in ess-dive-catalog

Description

Closes ess-dive/ess-dive-project#134

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

  • Integration tests
  • Other - add any additional tests here
    Checked the DB loading after the upgrade.

Test Configuration

  • Metacat Version: 2.12.3

@helbashandy helbashandy requested a review from vchendrix January 24, 2020 17:55
Copy link
Member

@vchendrix vchendrix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The overal structure of the changes is OK but it is not quite there. Review my comments and then set a time to discuss this with me.

@helbashandy helbashandy force-pushed the issue_134_update_upgrade branch from 08d808c to 6def483 Compare January 31, 2020 09:23
@helbashandy helbashandy requested a review from vchendrix January 31, 2020 09:26
Copy link
Member

@vchendrix vchendrix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added some comments to the docker-entrypoint.sh changes. I would like you to think about and address the following issues.

Graceful Shutdown
Basically I would like to see a graceful tomcat shutdown. Since our application may take longer to shutdown when there is more data, we want to give the application to honor executing requests before shutting down. You don't want to kill processes unless the shutdown is taking too long.

Timeout logic and startup
What do you think the best logic is for timeout? Do you..

  1. exit tomcat immediatly?
  2. try to startup anyway?

@helbashandy helbashandy force-pushed the issue_134_update_upgrade branch from 6def483 to c4617f0 Compare February 4, 2020 06:20
@helbashandy helbashandy requested a review from vchendrix February 4, 2020 10:03
helbashandy and others added 2 commits February 6, 2020 07:39
Issue ess-dive/ess-dive-project#134:

- Check upgrade status from metacat node capabilities
- Make sure port 8080 is avaialble before starting tomcat again
Closes ess-dive/ess-dive-project#134

The upgrade requires a restart and we can't
confidently shutdown tomcat before a restart.
The best course of action is to exit the container
after an upgrade which forces the container manager to
start up a new container with the upgaded application.

Logic for upgrade

+ Perform upgrade
+ Determine it completes successfully
+ shutdown tomcat
+ wait for application ports to be release
+ exit container
@vchendrix vchendrix force-pushed the issue_134_update_upgrade branch from f450beb to abdf3f0 Compare February 6, 2020 15:41
@vchendrix vchendrix merged commit cb4a482 into master Feb 6, 2020
@vchendrix vchendrix deleted the issue_134_update_upgrade branch February 6, 2020 16:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants