Simplify synopsysctl options

[yashbhutwala]

Why is this needed:

There is many places in synopsysctl where we expose parameters that a customer should not worry about changing. Currently, there are 43 flags for synopsysctl create blackduck, 38 flags for synopsysctl create opssight and many more for others. The goal of this is to minimize inconsistencies and simplify the usage of synopsysctl for the end user.

synopsysctl has become more of a templating cli, essentially converting all yaml fields in the spec to command line parameters. Ideally a good operator should just have sane defaults, and then we have different templates that a user can choose.

Related issues:

365

426

444

What would you like to be added:

synopsysctl deploy

• [ ] remove --metrics-image from synopsysctl deploy (this should just default to a stable image that a customer should not change)
• [ ] remove --no-of-threads from synopsysctl deploy (not sure if this changes with namespace scope, but a customer should not need to change this I think) controller level option that's useful for some customers
• [ ] remove --operator-time-bomb-in-seconds from synopsysctl deploy(#444)
• [ ] remove --log-level from from synopsysctl deploy (this one is the log level of the container, and I think this should just be set to debug by default, and a customer should not need to change this)
• [ ] remove --pod-wait-timeout-in-seconds from synopsysctl deploy (this one maybe we can keep, but I'm not sure if anyone is actually using it as much) controller level option
• [ ] move --postgres-restart-in-minutes and --postgres-termination-grace-period to blackduck level (not sure if we need this as operator level) controller level option
• [ ] change --verbose-level, -v to -l because -v usually corresponds to getting a version widely in other software
• [ ] have a version command similar to kubectl version or oc version instead of putting in help. Maybe it should print out what version of synopsysctl, as well as what version of operator, and what version of the kubernetes version it is using.

synopsysctl create alert

currently create blackduck has no configuration for setting specific images, however alert and opssight do. We should make it consistent, so either remove them from alert and opssight, which I think would simplify the flags, or add them back to blackduck.

• [ ] remove --alert-image from synopsysctl create alert image names can be removed once registry configuration option is enabled (currently useful for airgapped customers)
• [ ] remove --cfssl-image from synopsysctl create alert image names can be removed once registry configuration option is enabled (currently useful for airgapped customers)
• [ ] remove --alert-memory from synopsysctl create alert
• [ ] remove --cfssl-memory from synopsysctl create alert

synopsysctl create opssight

image names can be removed once registry configuration option is enabled (currently useful for airgapped customers)

• [ ] remove --image-getter-image from synopsysctl create opssight

• [ ] remove --image-processor-image from synopsysctl create opssight

• [ ] remove --metrics-image from synopsysctl create opssight

• [ ] remove --opssight-core-image from synopsysctl create opssight

• [ ] remove --pod-processor-image from synopsysctl create opssight

• [ ] remove --scanner-image from synopsysctl create opssight

• [ ] remove --log-level from synopsysctl create opssight (just always set to debug)

• [ ] remove --default-cpu from synopsysctl create opssight (or at least rename it to cpu-size)

• [ ] remove --default-memory from synopsysctl create opssight (or at least rename it to memory-size)

• [ ] remove --image-getter-service-account from synopsysctl create opssight (not sure when a customer would use this?)

• [ ] rename --opssight-core-expose to --expose-model

synopsysctl create blackduck

• [ ] redescribe --db-prototype in synopsysctl create blackduck (not very clear)
• [ ] change everything to string to be consistent to the user: #365

Cuelang seems like a promising solution for configuration management that incorporates lot of Google's internal Borg learnings. Thread from Brian Grant: https://twitter.com/bgrant0607/status/1123620689930358786

Also, sig-architecture meeting on desired vs actual: https://www.youtube.com/watch?v=6HfntQM757M

[rrati]

Need to make sure to consider air-gapped users or people with restricted access to repositories. These users would likely have to pull images from a public repo and place in a local private repo. This is the reason for many of the -image options.

Also need to consider a deprecation path for any options that are removed/changed.

log-level and verbosity are generally the same thing. Should investigate why there are both.

[yashbhutwala]

@rrati I agree about establishing a process for deprecation for any user-facing change.

For logs, there are different log flags:

1. --verbose-level at global flag level for logs of synopsysctl
2. --log-level at synopsysctl deploy level for logs inside the synopsys-operator container
3. --log-level at synopsysctl create opssight level for logs inside the opssight containers

I think 1 is fine to keep, but should change the shorthand of it, since -v can be interpreted as version.

2 and 3 are inconsistent in that there is no such setting for blackduck and alert. I think, by default, they should be debug, so if there's anything wrong, either a customer can look at them, or send them to us. @msenmurugan does mention that they could get large due to amount of debugging those services would do in debug mode. But if we set them to info by default, then if a customer runs into a problem, and wants to change the log level, it would restart the container anyways, so that defeats the purpose.