Added bootstrap-gcp.conf, bootstrap-aws.conf, bootstrap-azure.conf and bootstrap-hashicorp-vault.conf files management

[juldrixx]

Q	A
Bug fix?	no
New feature?	yes
API breaks?	no
Deprecations?	no
Related tickets	Partial #360
License	Apache 2.0

What's in this PR?

Added the management of bootstrap-gcp.conf, bootstrap-aws.conf, bootstrap-azure.conf and bootstrap-hashicorp-vault.conf files.

Why?

NiFiKop already manages all the other configuration files, so it should manages them.

Checklist

• Implementation tested
• Error handling code meets the guideline
• Logging code meets the guideline
• User guide and development docs updated (if needed)
• Append changelog with changes

[mh013370]

I believe these would all need exposed in the nifi-cluster helm chart as we do with the logback configuration. Except in these cases, i don't think we need to provide an override in the chart :)

[mh013370]

We want to avoid maintaining templates in nifikop, right? We want to allow overrides or just default to what exists in the docker images. IMO, we can return on line 761 above.

if len(completeConfigMap) == 0 {
		return nil
} else {
		return completeConfigMap
}

Right?

[juldrixx]

I don't know. So i should remove the template file?

[mh013370]

Yeah so like you did with the logback configuration here:

https://github.com/konpyutaika/nifikop/pull/353/files#diff-5a73dc757d3f7b939a26147f59fc5df61991e53a968160047744a93828d1bbf9L363-L374

If we don't strictly need to maintain a template in nifikop, we shouldn't. That way we don't need to maintain it & keep it updated whenever it changes in NiFi.

[juldrixx]

And should I renamed to BoostrapXConf instead of BoostrapXProperties?

[mh013370]

And should I renamed to BoostrapXConf instead of BoostrapXProperties?

I feel like the properties ought to be named consistently, even though I think we've named them incorrectly. The actual files are .conf, but in the CRDs and helm charts we named them properties. What do you think?

[juldrixx]

And should I renamed to BoostrapXConf instead of BoostrapXProperties?

I feel like the properties ought to be named consistently, even though I think we've named them incorrectly. The actual files are .conf, but in the CRDs and helm charts we named them properties. What do you think?

In #363, I remplace some of BoostrapProperties to BoostrapConf, was it a good idea?

[juldrixx]

And I had an idea, instead of adding 4 new fields with the same configuration, could it be interesting to add 1 field that is an array where you provide the 3 fields + the filename? So that in the futur, if new files are added the user could override them without NiFiKop update. At least, until we need it and made an official field.

[mh013370]

And should I renamed to BoostrapXConf instead of BoostrapXProperties?

I feel like the properties ought to be named consistently, even though I think we've named them incorrectly. The actual files are .conf, but in the CRDs and helm charts we named them properties. What do you think?

In #363, I remplace some of BoostrapProperties to BoostrapConf, was it a good idea?

I think that is fine because you didn't change the CRDs, so there weren't any breaking changes. It was all internal to the helm chart and documentation. We should double check though. We should avoid introducing any CRD breaking changes IMO

[mh013370]

And I had an idea, instead of adding 4 new fields with the same configuration, could it be interesting to add 1 field that is an array where you provide the 3 fields + the filename? So that in the futur, if new files are added the user could override them without NiFiKop update. At least, until we need it and made an official field.

Not a bad idea - perhaps this could be part of the v2alpha1/NifiCluster spec? We could introduce ConfigurationOverrides that all get mapped into NiFi's conf/ directory. Yeah?

One potential downside is that with it being so open/flexible, it might not be clear what you can override with it. So with the explicit options, it's clear what things you can override in NiFi