Closed leochr closed 2 years ago
@mcurran-us please attach the dynamic linter scan results. Thanks.
The items marked with an * are new items detected by the dynamic linter. The rest of the items have already been identified by the static linter. dynamic_lint_results.txt
@mcurran-us What's the yaml used for the WLO Custom Resources (CRs) for this? There are certain items that the IBM Certification requires, since we manage customer's application, we enable some configurations by default, but there are options in the CR to configure them (i.e. resource limits/requests, probes, affinity, autoscaling, etc)
@idlewis fyi, some dev items are still in progress, like adding .spec.license.*
and .status.versions.reconciled
, adding NetworkPolicy
@leochr It uses the yamls that are defined in the operators config/samples directory.
Here is a sample WebSphereLibertyApplication with some additional configuration that'll address some linter issues. @idlewis please deploy it on your cluster to verify that it works fine
Edit: April 11, 2022: config updates are listed in the comment below
Edit: April 20, 2022: update livenessProbe initial delay to 70 seconds to satisfy linter condition, add architectue affinity
apiVersion: liberty.websphere.ibm.com/v1
kind: WebSphereLibertyApplication
metadata:
name: wlo-app
spec:
license:
accept: true
applicationImage: registry.connect.redhat.com/ibm/open-liberty-samples:springPetClinic
expose: true
replicas: 3
probes:
liveness:
httpGet:
path: /
port: 9443
scheme: HTTPS
initialDelaySeconds: 70
readiness:
httpGet:
path: /
port: 9443
scheme: HTTPS
initialDelaySeconds: 60
resources:
limits:
cpu: '1'
memory: 1Gi
requests:
cpu: 500m
memory: 400Mi
statefulSet: {}
serviceability:
size: 1Gi
affinity:
architecture:
- amd64
Sample CRs for day-2 operations:
apiVersion: liberty.websphere.ibm.com/v1
kind: WebSphereLibertyDump
metadata:
name: websphereliberty-dump-sample
spec:
podName: wlo-app-0
include:
- thread
- heap
apiVersion: liberty.websphere.ibm.com/v1
kind: WebSphereLibertyTrace
metadata:
name: websphereliberty-trace-sample
spec:
podName: wlo-app-1
traceSpecification: "*=info:com.ibm.ws.webcontainer*=all"
maxFileSize: 20
maxFiles: 5
Note that dump and trace are enabled on different pods intentionally. They could be enabled on the same pod, but dump shouldn't be requested while the trace is on, because that generates too much information and could crash the application pod.
@leochr Are these changes to the sample yamls going to be incorporated into the operator code base?
@mcurran-us In the operator, we try to keep configuration to a minimum, since customers would deploy their apps and we don't know what the appropriate values would be for their apps. Some of the configurations would be added to the sample CRs in the operator, but not everything (i.e. we wouldn't have the serviceability or statefulset enabled, since that'll require storage configured on the cluster).
There is one error from the dynamic scan that I'm not sure about:
*[ERROR] scanned-pod-chobqif-dyn-0-websphereliberty-app-sample-6f94698c58-ptkg5.yaml: keys for pod security context not defined: spec.securityContext.runAsNonRoot OR spec.containers[0].securityContext.runAsNonRoot, spec.containers[0].securityContext.privileged, spec.containers[0].securityContext.readOnlyRootFilesystem, spec.containers[0].securityContext.allowPrivilegeEscalation (PodSecurityContextDefined) --> see references https://github.ibm.com/IBMPrivateCloud/content-verification/blob/master/docs/rules/PodSecurityContextDefined.md
@leochr @halim-lee Should this be fixed by any recent changes?
@idlewis runAsNonRoot
, privileged
and allowPrivilegeEscalation
should be fixed by https://github.com/WASdev/websphere-liberty-operator/pull/61
readOnlyRootFilesystem
is not currently set. @halim-lee will have an update to RCO and then to WLO to specify that. readOnlyRootFilesystem
is a bit more restrictive than the other fields, so we shouldn't set it to true by default. It'll be set to false. If that doesn't satisfy linter, then we'll need to add an override.
Static linter results as of 4/6. Level of operator code is today, commit 90e4764. Images are from 1.0.0-20220405-1800. They are now running bundle validation as part of the linter results. However, I cannot run that locally. Therefore, there may be more errors that appear when this runs as part of the travis build. The items marked with an *** are new items detected by the dynamic linter. The rest of the items have already been identified by the static linter. dynamic-lint.txt
Updated the CR above to use for linter:
fyi @mcurran-us @idlewis
Dynamic linter results for websphere-liberty-operator commit [849c9e1], image tag 1.0.0-20220410-1600. The items marked with an *** are new items detected by the dynamic linter. The rest of the items have already been identified by the static linter. Both the static and dynamic linters are now running in the travis build for the CASE. dynamic-lint-results-4-12-22.txt
Leo #82 adds probes into the sample as per your snippet above, I've confirmed that it does fix some (but not all) of the dynamic linter errors
Dynamic linter results for websphere-liberty-operator commit [https://github.com/WASdev/websphere-liberty-operator/commit/30b9d6495f73afb76e9fa48c07cb7ca33858ddd0], image tag 1.0.0-20220418-1800 dynamic-lint-results-4-19-22.txt
@mcurran-us
False-positive (requires permanent linter override):
***[ERROR] scanned-persistentvolumeclaim-dulfcbe-dyn-0-websphereliberty-app-sample-serviceability.yaml: The accessModes parameter for PVCs and PVs should be set to ReadWriteOnce by default (NoReadWriteMany) --> see references https://github.ibm.com/IBMPrivateCloud/content-verification/blob/master/docs/rules/NoReadWriteMany.md
Justification: The optional Day-2 operations provided by the operator require a volume that needs to be mounted and accessed by multiple pods, hence ReadWriteMany is required. The users have the option to specify their own PersistentVolumeClaim (PVC) where they can specify another access mode if it fits their application needs.CV Test's CR need to be updated to resolve these:
***[ERROR] scanned-statefulset-dulfcbe-dyn-0-websphereliberty-app-sample.yaml: (failureThreshold * periodSeconds) + initialSecondsDelay for livenessProbe (60) less than values for readinessProbe (90) for container spec.template.spec.containers[0] (ContainerLivenessLongerThanReadiness) --> see references https://github.ibm.com/IBMPrivateCloud/content-verification/blob/master/docs/rules/ContainerLivenessLongerThanReadiness.md
Action (Mary): The sample application liveness.initialDelaySeconds should be updated to at least 60 to satisfy the constraint.
***[ERROR] scanned-statefulset-dulfcbe-dyn-0-websphereliberty-app-sample.yaml: expected value "IBM WebSphere Hybrid Edition" at spec.template.metadata.annotations.cloudpakName to contain "Cloud Pak" (LicensingAnnotationsDefined) --> see references https://github.ibm.com/IBMPrivateCloud/content-verification/blob/master/docs/rules/LicensingAnnotationsDefined.md
Action (Mary): It seems that the sample CV test app is setting spec.productEntitlementSource
to IBM WebSphere Hybrid Edition
. We can set it to IBM Cloud Pak for Applications
to make linter happy. Otherwise, this will need to be a permanent override, since WSHE is not a Cloud Pak and can't have that in its name.
The rest of the errors require changes to operator or sample app CR. We are investigating. In the mean time, they could be temporarily overridden. Thanks.
***[ERROR] inventory/websphereLibertyOperatorSetup/resources.yaml: Operator bundle image "icr.io/cpopen/websphere-liberty-operator-bundle@sha256:d7db2bc7829c213425064eb1db94da74646d8c614fe47f13304a94644bfbf9c6" found at "websphereLibertyOperatorSetup.resources.resourceDefs.containerImages[1]" has validation error: Error: : expected spec.customresourcedefinitions.owned[0].specDescriptors[64].value to be a boolean array with a single value false (OLMOperatorBundleCSVDefinesCRDWithLicenseParameter) --> see references https://github.ibm.com/IBMPrivateCloud/content-verification/blob/master/docs/rules/OLMOperatorBundleCSVDefinesCRDWithLicenseParameter.md
Action (Leo): Update the operator metadata to satisfy this check/condition
***[ERROR] scanned-pod-dulfcbe-dyn-0-websphereliberty-app-sample-0.yaml: container "app" mounts local ephemeral storage of type secret, but ephemeral storage limits and requests are not declared (EphemeralStorageLimitsAndRequestsDeclared) --> see references https://github.ibm.com/IBMPrivateCloud/content-verification/blob/master/docs/rules/EphemeralStorageLimitsAndRequestsDeclared.md
Action (@BradleyMayo): The ephemeral storage can be specified via spec.resources
field in the CR. Determine an appropriate value for the sample app (the CR is specified here)
***[ERROR] scanned-statefulset-dulfcbe-dyn-0-websphereliberty-app-sample.yaml: missing one or more fields at some spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms[i].matchExpressions[j].(key|operator|values). All three fields must be defined and non-empty for architecture-based node affinity. 'key' field must be one of ["kubernetes.io/arch"] (PodHasArchBasedNodeAffinity) --> see references https://github.ibm.com/IBMPrivateCloud/content-verification/blob/master/docs/rules/PodHasArchBasedNodeAffinity.md
@mcurran-us do you know on which platform the CV tests are run on? The sample app that we currently use only has amd64 image, we can add that as the arch.
@leochr The CV tests run on amd64.
@mcurran-us thanks, we can set spec.affinity.architecture
in the CV test CR to satisfy the PodHasArchBasedNodeAffinity
linter requirement. Updated the sample CR above to include the snippet.
@mcurran-us please share the latest dynamic linter scan results (from the GM candidate). Thanks
@leochr You can see the latest dynamic linter results here: https://certification.cloudpaklab.ibm.com/#/certifications/certView/fc36702e-cca8-41c8-9987-8754a96717b0/lint/results
Thank you @mcurran-us
@BradleyMayo could you please take a look at the latest dynamic scan results to see if there are any new items (including warning/review)? Thank you
There are no errors currently and none of the items are new. They were all on the last scan
Review the results from dynamic linter scan.