I like the profile concept, however I'd rename "Secured" to "Default", because we don't want to imply that "Performance" is not secure.

One more thing:

• .spec.container.jvmOptionsAppend name sounds a bit clunky. I'm liking more the idea of naming it .spec.container.extraJvmOptions. Thoughts?

@tristantarrant Something else came to my mind while 😴, would it make sense for connector authentication to take a list of credentials instead of a single one? E.g. if you want to add multiple users for data access. Each could either be defined with credentials... Or would such situation be handled by a single Keystore authentication entry, where the keystore can store usernames and passwords for multiple users?

Do we have/need something to manage application roles?

The question popped in a chat with @tristantarrant about the need to keep management and connector authentication separate...

Tristan Are we keeping application and management user separation in new image?
No.
Tristan: It was pretty pointless, especially in the context of allowing users to create caches remotely on demand.

So, we'll further coalesce the authentication part, probably under spec.authentication.

Do we have/need something to manage application roles?

We probably do. @tristantarrant What should we do here? What is the bare minimum you'd need? @rigazilla We could see what's done in Kubernetes with security in this area of role definitions...

There must be two ways

• simple, which uses property files created with serverng's user-tool. This can support Basic/Plain, digest and scram Auth methods. This is identical to the old server
• token, which delegates user/password/roles to keycloak. The infinispan operator must interact with the keycloak one to provision keycloak "client id/secret" pairs for the server and the clients. This means hot rod /rest clients can use bearer tokens. We need to talk to the keycloak team about this
  In truth, both methods can be active at the same time, but let's not overcomplicate things for now

@galderz V2 specification looks good to me. I wasn't sure at first about datagrid and cache elements in context of services but seeing it written down I'm convinced. Eg.: storage element would more fit container as container groups hw resources but that depends on the angle of view. Current way the API is sending clear message that there are two modes to Infinispan with completely different set of capabilities and it's quite clear what can be configured for one but not for the other which wouldn't be as clear with storage being under container.

What's not so clear just by looking at yaml API is that you can either use cache or datagrid element (or you can use both?). Yaml won't naturally stop you from doing that. That'll require either good documentation or something like:

spec:
  service:
    type: cache
    cacheProp1: xxx
    cacheProp2: yyy


spec:
  service:
    type: datagrid
    datagridProp1: xxx
    datagridProp2: yyy

.spec.container.jvmOptionsAppend name sounds a bit clunky. I'm liking more the idea of naming it .spec.container.extraJvmOptions. Thoughts?

+1, Maybe extraJvmOpts?

spec.management.prometheus could be removed completely by making using the profile as a way to signal whether prometheus is enabled or not. As example, with Secured and Performance prometheus would be enabled, but with Development it'd be disabled. Thoughts?

What if user would like to play with the stats in Development mode so he can set up and prepare his monitoring solution? Maybe the best would be to enable Prometheus in any case and drop that option completely. Prometheus agent isn't anything that would give you any advantage if you turn it off.

@rigazilla

More words on how/why the setup is partitioned under: cache, datagrid, container would be good IMO.

Cache is the most simple way to use DG, as a cache. We simplified the config in OpenShift images already for 7.3. The existing options there come from the work we did there. Check that out.

Data Grid is everything else: x-site, plug remote stores, local PV data persistence...etc.

Container is per pod configuration: how much CPU to give each pod, how much memory, any extra JVM settings to pass.

@Crumby

storage element would more fit container as container groups hw resources but that depends on the angle of view.

Good point, I'll amend that for next revision.

@Crumby

Current way the API is sending clear message that there are two modes to Infinispan with completely different set of capabilities and it's quite clear what can be configured for one but not for the other which wouldn't be as clear with storage being under container.

Replied too early. Good point about this, I'll try to think it differently.

What's not so clear just by looking at yaml API is that you can either use cache or datagrid element (or you can use both?). Yaml won't naturally stop you from doing that. That'll require either good documentation or something like:

Good point. Your suggestion makes sense, I'll address that for next rev.

+1, Maybe extraJvmOpts?

+1

What if user would like to play with the stats in Development mode so he can set up and prepare his monitoring solution? Maybe the best would be to enable Prometheus in any case and drop that option completely. Prometheus agent isn't anything that would give you any advantage if you turn it off.

+1

@galderz Have you thought about adding some option for exposing the rest/hotrod out? Or users will be required to create the route always manually? Asking because I noticed that opc's cluster config contains option defaultRoute: false and if you set it to true then it exposes the OpenShift's internal registry. I found out myself using this option quite often as it's way quicker and simpler then creating the route manually.

@tristantarrant Something else came to my mind while 😴, would it make sense for connector authentication to take a list of credentials instead of a single one? E.g. if you want to add multiple users for data access. Each could either be defined with credentials... Or would such situation be handled by a single Keystore authentication entry, where the keystore can store usernames and passwords for multiple users?

FYI, this will be sorted in v3, where you'll be able to define multiple user/pass credentials.

Closing PR, v3 can be found in #108.