Open-vsx deployment update issues.

While working through the deployment update this morning it was commented that we would need to make some changes to our ehcache deployment[1].

AFAIA we are not currently deploying ehcache, so how do we deploy an update to open-vsx that doesn't require providing/deploying any extra services?

/cc @amvanbaren /cc @mbarbero /cc @kineticSquid

[1]https://github.com/EclipseFdn/open-vsx.org/pull/1196#issuecomment-1222466297

added IT-severitynormal Infra team:infra wg:ECD TOOLS labels

assigned to @mward

@mward I'm also looking at other cache solutions. Azure[1] and AWS[2] provide Redis based products. Do you or members of your team have experience using Redis?

[1] https://azure.microsoft.com/en-us/services/cache
[2] https://aws.amazon.com/elasticache

I'm afraid not.

Just to be clear it's not that we can't/won't look into deploying some kind of cache layer(either directly or via Azure), but that is a separate issue from a 'basic' deployment.

Ok, makes sense. Let's do a basic deployment first.

Cool. Can you tell me what I should merge into the production branch that will pickup the desired updates, but stop short of adding the new caching feature/layer?

@amvanbaren , can you point me at what part of the staging branch I need to merge in order to complete a deployment here?

Should I just use the same image as for staging in #1483 (closed) ?

@mward I've opened PR #1197. You do have to configure the EHCACHE_CONFIG environment variable, so that it points to configuration/ehcache.xml. Once that works we can start testing and tuning the cache configuration on staging

@amvanbaren the goal here is to update the production instance of open vsx to move it forward from the last debacle.

Updating the staging instance or deploying new services(ehcahce) are separate issues.

Now if the production instance doesn't need to be updated that's fine and I can close this issue.

@mward Here you go: https://github.com/EclipseFdn/open-vsx.org/pull/1209 Before deploying, please make a database backup and have everything ready for a revert to keep downtime to a minimum.

I've merged that PR in, but it's failing to start the new containers with:

Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jCacheCacheManager' defined in class path resource [org/springframework/boot/autoconfigure/cache/JCacheCacheConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [javax.cache.CacheManager]: Factory method 'jCacheCacheManager' threw exception; nested exception is org.ehcache.StateTransitionException: Directory couldn't be created: /home/openvsx/server/ehcache

As such I'm going to rollback the deployment to it's previous state.

changed the description

@mward Have we tried deploying this in staging? What's the relationship between this and what's in #1483 (closed)?

I don't think this has been tried on staging, and certainly it wasn't what I expected in this case, hence the immediate rollback.

But I'm not a developer and I just play a RelEng on TV, so @amvanbaren is probably best able to answer your questions.

Yes, it was first deployed to staging where I did the performance testing. Then I opened a PR to deploy it to production.

@mward https://github.com/EclipseFdn/open-vsx.org/pull/1213 writes Ehcache files to the system temp directory.

I've merged that pull request and it appears to have successfully deployed. Let's give it a few hours before declaring victory.

As the site is still operational I'm going to close this as 'fixed'.

closed