[HOTFIX] FIX QUICKSTART

[singhpk234]

About the change

A couple of changes have went in, which has broken quick start experience

[1] This refactor missed jdbc : #1522 as it changed the common assets which are used outside of eclipse-link module.

I see pr for fixing this : #1614, I am happy if the author of the PR wants to take the 2nd part of change also in his pr and close this one, marking them as co-author for now, Thanks a lot for the contribution.

[2] The PR for Require explicit user-consent to enable HadoopFileIO went it which missed handling the quick start for all the persistences (eclipse-link / jdbc) and hence both of them can't be used.

I putting this PR out for reference, and would request if this could get merged as a hotfix, as presently none of the persistence is usable on main. Happy to close this PR as well if the @pjanuario wants to take the 2nd part of change also in.

Co-author @pjanuario

[pjanuario]

Awesome, thanks for picking this up. Honestly I am just starting to play with the tool and deep diving into it. I was also having troubles in launching an instance with jdbc and I just created a ticket for the first thing I know it was missing and the other I was still playing around to understand what was going on.
I am happy to close my pr favour of this one, no worries.

[eric-maynard]

Do any other docker-compose files need this fix? For example getting-started/eclipselink/docker-compose.yml

[dimas-b]

I wonder why this format change is required even in this PR 🤔

[RussellSpitzer]

I'm not sure this is required ... but i'm also not sure why the old version worked. Wouldn't the previous syntax have essentially been

LIST
[ "JAVA_DEBUG=true", "JAVA_DEBUG_PORT=*:5005", ...]

While this syntax is
OBJECT
{ JAVA_DEBUG => true, JAVA_DEBUG_PORT => *:5005 }

? YAML is always confusing to me

[snazy]

- is a list element in yaml. However, I looked at a couple docker-compose files in other projects and all have that - . It's not just yaml - it's yaml+docker-compose-syntax.

[snazy]

Anyway - whatever works and not break stuff if fine for me.

[singhpk234]

Do any other docker-compose files need this fix? For example getting-started/eclipselink/docker-compose.yml

yes, we do, added that !

I wonder why this format change is required even in this PR 🤔

I tried the following syntax, with the new variables and aparently it didn't work for me, didn't debug it further and hence for consistency moved everything back to the format that worked :

  - POLARIS_FEATURES_ALLOW_INSECURE_STORAGE_TYPES=true
  - POLARIS_FEATURES_SUPPORTED_CATALOG_STORAGE_TYPES=[\"FILE\",\"S3\",\"GCS\",\"AZURE\"]
  - POLARIS_READINESS_IGNORE_SEVERE_ISSUES=true

? YAML is always confusing to me

same here, I am working on hit and trial basis here :), this worked and hence i moved, i can definetly take a deeper look !

[eric-maynard]

LGTM, but we should fix everywhere else that needs this

[dimas-b]

Please rebase to get the latest CI changes.

[dimas-b]

I wonder why this format change is required even in this PR 🤔

[RussellSpitzer]

For another pr: Maybe this should only be FILE and we have a built in error message for users trying to use any other storage type to come back and redo their config. Not a huge deal.

Also we probably should not allow "ALLOW_INSECURE_STORAGE_TYPES" if an insecure storage type is not in supported storage types right? Also "ignore-severe-issues" probably shouldn't be allowed to be true unless a sever item has been selected.

Just thoughts for future cleanups though

[singhpk234]

Ack, I allowlisted all as this same script also used with cloud providers,.

Also we probably should not allow "ALLOW_INSECURE_STORAGE_TYPES" if an insecure storage type is not in supported storage types right? Also "ignore-severe-issues" probably shouldn't be allowed to be true unless a sever item has been selected.

Sure thing ! let me take a deeper look in this as fast followup

[flyrain]

LGTM, but we should fix everywhere else that needs this

Here is another issue broken by #1532, #1649. I agreed we need to fix them all. But not necessarily within this PR.

[singhpk234]

Thank so much, everyone for the quick review (@flyrain @eric-maynard @dimas-b @RussellSpitzer @snazy) !

Thank you @pjanuario for your contribution (marked you as co-author) !