Make process number configurable in KeystoneAPI

[Deydra71]

Adds new section httpdCustomization with the option processNumber to configure the number of processes used by KeystoneAPI. The maximum number is not set, though this may be defined in the future

Jira: OSPRH-10363

[vakwetu]

not sure about setting a max here. @d34dh0r53 @dmendiza @xek - is there a reasonable setting here or should we just leave it blank?

[Deydra71]

I deleted the maximum limit for now for testing.

[d34dh0r53]

I also don't think a maximum is needed, it's easy enough to add should this become a problem.

[stuggi]

This is probably something we want to be able to do across multiple service operators api deployments, but I am not sure if adding it as a top parameter for the deployment is good. if there will be more parameters we need to be able to customize related to httpd its probably better to have them in a sub struct. And this needs to be the same for all operators. @dprince @olliewalsh @abays thoughts?

maybe we should have a generic crd for httpd which allows us to extend for future customization.

[vakwetu]

@d34dh0r53 ^^ just for awareness of the above. @d34dh0r53 is working on changes needed for federation.

[olliewalsh]

This is probably something we want to be able to do across multiple service operators api deployments, but I am not sure if adding it as a top parameter for the deployment is good. if there will be more parameters we need to be able to customize related to httpd its probably better to have them in a sub struct. And this needs to be the same for all operators. @dprince @olliewalsh @abays thoughts?

maybe we should have a generic crd for httpd which allows us to extend for future customization.

+1 for a sub struct. Also could potentially switch from apache/wsgi to $something_else in future

[vakwetu]

I'm not opposed to a substruct of some sort. That said, there are types of apache config which are much more extensive - see #479 Does the approach there change at all?

[stuggi]

This is probably something we want to be able to do across multiple service operators api deployments, but I am not sure if adding it as a top parameter for the deployment is good. if there will be more parameters we need to be able to customize related to httpd its probably better to have them in a sub struct. And this needs to be the same for all operators. @dprince @olliewalsh @abays thoughts?
maybe we should have a generic crd for httpd which allows us to extend for future customization.

+1 for a sub struct. Also could potentially switch from apache/wsgi to $something_else in future

I was thinking about adding some subsection for httpdTunings or httpdCustomization. if there are more settings, we could just add them there, instead of having multiple top level ones.

spec:
  httpdCustomization:
    processNumber:

don't think it affects #479 as it is a separate feature which are not a generic httpd settings.

[Deydra71]

@stuggi Please take a look again on the updated version, ty!

[stuggi]

looks good to me, @olliewalsh @dprince @abays for you too?

[stuggi]

as discussed on slack, this needs to be tested for updating the controller/CRD on an already deployed env

[olliewalsh]

looks good to me, if updating works

[stuggi]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Deydra71, stuggi, vakwetu, xek

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [stuggi]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Deydra71]

/cherry-pick 18.0-fr1

[openshift-cherrypick-robot]

@Deydra71: new pull request created: #504

In response to this:

/cherry-pick 18.0-fr1

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.