[FOLIO-1121] upgrade backend modules daily of folio-perf Created: 14/Mar/18  Updated: 15/Jan/19

Status: Open
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: New Feature Priority: P3
Reporter: Jakub Skoczen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: ci, core, sprint34, sprint35, sprint36, sprint37
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
is blocked by FOLIO-1245 create automated performance testing ... Closed
is blocked by MODINVSTOR-60 Create JMeter scripts for performance... Closed
Sprint:
Development Team: Core: Platform

 Description   

Module upgrade capability is required for this. The most important module here is mod-inventory.

Wayne Schneider shale99 Marc Johnson



 Comments   
Comment by shale99 [ 14/Mar/18 ]

this should be supported , rmb should be in sync with the versions sent by okapi

Comment by Marc Johnson [ 15/Mar/18 ]

I wasn't in the conversation, and I'm not that familiar with the upgrade process, so I may be missing details about this

I imagine that the primary module concerned here is mod-inventory-storage?

From my understanding of RAML Module Builder declarative database configuration which I believe we will need the fromModuleVersion adding to all of the existing configuration, is that correct shale99?

As the module version where this will be added in will be mod-invnentory-storage-8.0.1-SNAPSHOT.build what should the value of that property be? What parts of a module version does the RAML Module Builder strip away during comparison?

Comment by shale99 [ 15/Mar/18 ]

it doesnt strip anthing , for example,
if the current installed version is:
mod-invnentory-storage-8.0.1-SNAPSHOT.5
and the to version is this:
mod-invnentory-storage-8.0.1-SNAPSHOT.10

if the fromModuleVersion in the schema.json is mod-invnentory-storage-8.0.1-SNAPSHOT.7 , it will know that it needs to run the declaration associated with that fromModuleVersion

it will compare
mod-invnentory-storage-8.0.9
to
mod-invnentory-storage-8.0.11
in the same manner

Comment by Marc Johnson [ 15/Mar/18 ]

I think I'm confused. I'll try to reflect my understanding to see if it is at all sensible.

The upgrade process knows that mod-inventory-storage-8.0.1-SNAPSHOT.7 is between mod-inventory-storage-8.0.1-SNAPSHOT-5 and mod-inventory-storage-8.0.1-SNAPSHOT-10, is that correct?

Does it also know that mod-inventory-storage-8.0.1-SNAPSHOT.7 is between mod-inventory-storage-8.0.0 and mod-inventory-storage-8.1.0?

What kind of version would you envisage the versions in the fromModuleVersion property look like? Could / should they include the SNAPSHOT or builder number parts?

Comment by shale99 [ 15/Mar/18 ]

The upgrade process knows that mod-inventory-storage-8.0.1-SNAPSHOT.7 is between mod-inventory-storage-8.0.1-SNAPSHOT-5 and mod-inventory-storage-8.0.1-SNAPSHOT-10, is that correct?

correct

Does it also know that mod-inventory-storage-8.0.1-SNAPSHOT.7 is between mod-inventory-storage-8.0.0 and mod-inventory-storage-8.1.0?

yes

What kind of version would you envisage the versions in the fromModuleVersion property look like? Could / should they include the SNAPSHOT or builder number parts?

i would hope no snapshot, other than that, i could see it being a major / minor / and potentially sp

Comment by Marc Johnson [ 15/Mar/18 ]

shale99 Cool, thanks.

I think I only have one more question yet.

If as part of the work that defines mod-inventory-storage-8.0.1-SNAPSHOT.81 introduces the FromModuleVersion for the various elements as mod-inventory-storage-8.0.1 will anything upgrading to that version pick up that change?

For example, upgrading from mod-inventory-storage-8.0.0-SNAPSHOT.79 or mod-inventory-storage-8.0.0 should include it. How would upgrading from mod-inventory-storage-8.0.1-SNAPSHOT.81 to mod-inventory-storage-8.0.1-SNAPSHOT.82 behave?

My guess is that we need to be strict about only making database configuration changes in a single build of a version?

Comment by Marc Johnson [ 15/Mar/18 ]

shale99 Cool, thanks.

I think I only have one more question.

If as part of the work that defines mod-inventory-storage-8.0.1-SNAPSHOT.81 introduces the FromModuleVersion for the various elements as mod-inventory-storage-8.0.1 will anything upgrading to that version pick up that change?

For example, upgrading from mod-inventory-storage-8.0.0-SNAPSHOT.79 or mod-inventory-storage-8.0.0 should include it. How would upgrading from mod-inventory-storage-8.0.1-SNAPSHOT.81 to mod-inventory-storage-8.0.1-SNAPSHOT.82 behave?

My guess is that we need to be strict about only making database configuration changes in a single build of a version?

Comment by shale99 [ 21/Mar/18 ]

the FromModuleVersion
should be the same as the version you are actually adding it in
otherwise it will get messy. the above creates a FromModuleVersion that is x versions ahead of the actualy version it was introduced in

Comment by Marc Johnson [ 22/Mar/18 ]

shale99 I'm confused, which example are you referring to above that creates a fromModuleVersion that is ahead of the actual version it was introduced in?

Looking at your responses, I think the guidance is:

1. FromModuleVersion should be a non-snapshot version (even when the module version and the version in the pom contains a -SNAPSHOT postfix?

For example, a change introduced where the module version is mod-inventory-storage-8.1.0-SNAPSHOT (the pom version being 8.1.0-SNAPSHOT) should have a FromModuleVersion of mod-inventory-storage-8.1.0?

2. Database changes should only be introduced once per version number (which is inline with each merge to master changing the version)? As otherwise they could be missed during upgrades between snapshot builds.

For example, once a branch is merged to master for 8.1.0-SNAPSHOT in the pom, is merged to master, no subsequent merges to master with 8.1.0-SNAPSHOT in the pom should include database changes?

Does that reflect your previous comments accurately?

Generated at Thu Feb 08 23:10:59 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.