[FOLIO-812] construct a vagrant image based on the metadata available from the central registry Created: 29/Aug/17  Updated: 12/Nov/18  Resolved: 22/Nov/17

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

Type: Task Priority: P2
Reporter: Jakub Skoczen Assignee: Wayne Schneider
Resolution: Done Votes: 0
Labels: ci, sprint22, sprint23, sprint24, sprint25, sprint26, sprint27
Remaining Estimate: Not Specified
Time Spent: 3 days, 3 hours, 15 minutes
Original estimate: Not Specified

Issue links:
Blocks
blocks FOLIO-947 deploy registry-driven installation a... Closed
is blocked by FOLIO-799 Post UI module descriptors to mod des... Closed
is blocked by OKAPI-466 Posting module list to install endpoi... Closed
Relates
relates to FOLIO-852 rewrite okapi-stripes Open
relates to FOLIO-948 use okapi deployment persistence for ... Open
relates to OKAPI-399 Install/upgrade without simulate Closed
Sprint:

 Description   

1. use the Okapi's pull mechanism to sync all MDs from central registry
2. use the Okapi's install to list dependencies for selected (ui) modules, the selected modules are listed in the yarn platform (Okapi can filter for snapshots or releases)
3. use the list to construct deployment descriptors with the right module ID, request Okapi to physically deploy using the DD
4. enable the modules for one or more tenants



 Comments   
Comment by Jakub Skoczen [ 06/Sep/17 ]

1. Okapi can list modules that need to be deployed with /install?simulate=true
2. Modules can be deployed (e.g using ansible)
3. Modules can be enable in Okapi in one go with /install

Comment by Wayne Schneider [ 07/Nov/17 ]

Work is nearly done, blocked by OKAPI-461 Closed .

Comment by Jakub Skoczen [ 08/Nov/17 ]

The new distribution will be rolled out nightly as 'folio-snapshots' on a new AWS cluster.

Comment by Wayne Schneider [ 08/Nov/17 ]

A new Vagrant box – folio/snapshot – has been created with this build. It will be built nightly along with folio/testing and folio/testing-backend.

I will hold off on making an announcement until we have the AWS build ready and I've updated the documentation.

Comment by Wayne Schneider [ 08/Nov/17 ]

...especially since the box doesn't work as expected – apparently okapi environment variables aren't persisted.

Comment by Adam Dickmeiss [ 09/Nov/17 ]

Correct.. Will make them persistent in OKAPI-423 Closed . As I probably mentioned during our calls, I am surprised that Okapi is stopped and started again in our environments. The service is essentially "down" in in this case - and downtime is not desired in production. It also begs the question of environment for re-deployment.. One can choose the environment as of the state in the initial deployment or use the current environment (which makes a potentially different deployment). Since the node could be different anyway, we'll use the current environment always (which is persisted when OKAPI-423 Closed is complete).

Comment by Wayne Schneider [ 09/Nov/17 ]

Well, the use case for us right now is a single-host VM system for development, where it is reasonable to expect the user will want to stop and start the VM, not production, where Okapi should never really go down. We have worked around the issue for deployment (and since last night, environment variables, too ), so for our purposes OKAPI-423 Closed is not a blocker. I agree that the use case for clustered Okapi deployment has more complex needs. Perhaps we should talk about this in more detail in person in January.

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