[FOLIO-1720] Testing environment unavailable due to incompatibility between mod-gobi and mod-orders Created: 20/Jan/19  Updated: 03/Jun/20  Resolved: 28/Jan/19

Status: Closed
Project: FOLIO
Components: Continuous Integration
Affects versions: None
Fix versions: None

Type: Bug Priority: P2
Reporter: Marc Johnson Assignee: Marc Johnson
Resolution: Done Votes: 0
Labels: devops
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified
Environment:

folio-testing


Issue links:
Relates
relates to MODGOBI-44 Use new Orders endpoint Closed
relates to MODORDERS-124 MODORDERS-124 Redefined existing orde... Closed
Sprint:

 Description   

Overview

The shared testing environment is unavailable due to incompatible backend dependences between the latest versions of mod-gobi and mod-orders.

Steps to Reproduce

Execute folio-testing build

Expected Results

Successful build of environment

Actual Results

Activating mod-gobi for the diku tenant fails with the following error:

Incompatible version for module mod-gobi-1.2.0-SNAPSHOT.49 interface orders. Need 2.0. Have 3.0

Additional Information

mod-orders was upgraded to provide the orders 3.0 interface.

Mod-gobi requires orders 2.0.

It might be that MODGOBI-44 Closed is required to resolve this.

The stripes-testing job has been disabled until this is resolved (to avoid redundant alerts every 20 minutes).

Interested parties

I'm including relevant people I can find from the change, the two teams and the core platform team

Siarhei Hrabko Viachaslau Khandramai Piotr Kalashuk Craig McNally Jakub Skoczen Wayne Schneider John Malconian Dennis Bridges Ann-Marie Breaux Former user Pavel Korolenok



 Comments   
Comment by Piotr Kalashuk [ 21/Jan/19 ]

The mod-orders was downgraded to revert back to the orders 2.0 interface.

The mod-orders will be upgraded to provide the orders 3.0 interface once mod-gobi PR have corresponding interface change.

Comment by Aliaksei Chumakou [ 21/Jan/19 ]

Marc Johnson Basically, folio-testing build is green already https://jenkins-aws.indexdata.com/job/Automation/job/folio-testing-backend01/660/
Maybe it makes sense to return stripes-testing job

Comment by Marc Johnson [ 21/Jan/19 ]

Aliaksei Chumakou The stripes-testing job has been reactivated and is running now

Comment by Marc Johnson [ 21/Jan/19 ]

Piotr Kalashuk Thank you for reacting to this so quickly.

To confirm, was the API change rolled back entirely or only the interface version (and hence clients would fail at runtime despite the check passing)?

Comment by Piotr Kalashuk [ 21/Jan/19 ]

Only interface version was rolled-back to 2.0. There are 2 known clients which use orders endpoints: ui-orders (usage of new endpoints is already added) and mod-gobi (no changes yet done, requests will be failing).

Comment by Marc Johnson [ 21/Jan/19 ]

Piotr Kalashuk Thanks for the clarification.

Given UI Orders had already changed to the new API, does that mean that it's interface dependency was updated to orders 3.0?

Comment by Marc Johnson [ 21/Jan/19 ]

It would appear that UI orders relies on orders 2.0 still.

And from some very limited testing, makes requests like

http://folio-snapshot-543.aws.indexdata.com:9130/orders?limit=30&query=(id="*" or po_number="*" or vendor="*" or assigned_to="*")

This appears to me to be the old orders API? Have I missed something?

Comment by Piotr Kalashuk [ 21/Jan/19 ]

UI Orders still references to orders 2.0.
We will update interface version separately and merge 3 PRs the same time once all required changes done:

  • mod-order PR #72
  • mod-gobi PR #36 - the PR requires additional changes but thunderjet team has no write permissions to this repository
  • ui-orders PR #174
Comment by Marc Johnson [ 21/Jan/19 ]

Piotr Kalashuk Thank you for clarifying that.

Is this changed planned today, or does it rely on mod-gobi and that cannot be changed to the US holiday?

If this change is not going to go in today. It might be possible that folio-snapshot fails tomorrow.

UI Orders references orders 2.0, the latest version of mod-orders provides the new API however declares support for orders 2.0 (due to the version rollback yesterday).

This means that this version will be pulled in by the Okapi install endpoint however will not be compatible with the UI orders at runtime (due to UI orders using /orders and mod-orders providing /orders/composite-orders).

Does that make sense and seem plausible?

Comment by Aliaksei Chumakou [ 21/Jan/19 ]

Marc Johnson You're looking to folio-snapshot env, which hasn't the latest ui-orders deployed. You can look at folio-testing, where ui-orders calls new endpoints http://folio-testing.aws.indexdata.com/orders
At the same time please keep in mind that we found issue with getting collection of orders within new api, but it's fixed already https://github.com/folio-org/mod-orders/pull/73

Comment by Piotr Kalashuk [ 21/Jan/19 ]

Just to summarize:

  • UI Orders has been already updated to use new endpoints (the changes were merged today PR #173) and still relies on orders 2.0. As Aliaksei mentioned above the change is already in place on folio testing environment and UI orders already consumes new endpoints: http://folio-testing-backend01.aws.indexdata.com:9130/orders/composite-orders?limit=30&query=(id="" or po_number="" or vendor="" or assigned_to="")
  • mod-gobi can be updated only tomorrow
  • For now mod-orders will still provide 2.0 interface version. We wait for latest snapshot version of mod-orders to be deployed to resolve the issue mentioned by Aliaksei
Comment by Marc Johnson [ 21/Jan/19 ]

Piotr Kalashuk Aliaksei Chumakou I think I am very confused. Apologies if my understanding is incorrect or outdated.

Would a reasonable summary of the current situation be:

  • mod-orders provides the new API, whilst stating provision of the previous version
  • UI-orders uses the new API, whilst stating dependency on the previous version
  • mod-gobi uses the old API (and states that dependency)

When the mod-gobi changes are completed. The 3 modules will have the interface provision and dependency updates in sync to satisfy the builds of both folio-testing and folio-snapshot.

As versions of mod-orders and UI-orders have been published with out of step interface definitions (e.g. what they provide/use differs from the stated version) we need to be aware that this might result in odd behaviour if folio-registry is used to build older environments (e.g. the last version of mod-orders stating provising of orders 2.0 will actually provide the API of orders 3.0).

If that is sensible, I'm going to stop interrupting people, apologies

Comment by Piotr Kalashuk [ 21/Jan/19 ]

Hi Marc Johnson. Sorry for delay. Yes, summary above is correct.
Please let us know if the applied temporary workaround is actually bad idea and we have to roll-back functional changes as well so 2.0 version will have state of last week.

Comment by John Malconian [ 21/Jan/19 ]

mod-gobi PR #36 - the PR requires additional changes but thunderjet team has no write permissions to this repository

Thunderjet now has write access to this repo

Comment by Piotr Kalashuk [ 21/Jan/19 ]

Thank you very much John Malconian!

Required mod-gobi changes have been done. All 2 PR's have been merged to master.

Comment by Marc Johnson [ 21/Jan/19 ]

Piotr Kalashuk

Please let us know if the applied temporary workaround is actually bad idea and we have to roll-back functional changes as well so 2.0 version will have state of last week.

At this stage I don't think it is worth rolling back to 2.0 fully. I only wanted to make it explicit that there might be an impact of the approach taken for some builds.

Comment by Marc Johnson [ 21/Jan/19 ]

Piotr Kalashuk

Required mod-gobi changes have been done. All 2 PR's have been merged to master.

Does that mean that the interface provision and dependencies have also all moved to orders 3.0?

Comment by Piotr Kalashuk [ 21/Jan/19 ]

At the moment all 3 PR's are already merged to master (mod-orders, mod-gobi and ui-orders). Now latest snapshot version of the mod-orders provides 3.0 interface and both mod-gobi and ui-orders require orders 3.0.

Sorry for inconvenience

Comment by Marc Johnson [ 21/Jan/19 ]

Piotr Kalashuk Thanks for picking this issue up so quickly.

Comment by Piotr Kalashuk [ 22/Jan/19 ]

Hi All

According to latest build of folio-testing-backend job, the issue is resolved now.

Thank you all very much for assistance!

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