ztp: Add ztp-deploy-wave annotation in source CR #862
Conversation
|
Skipping CI for Draft Pull Request. |
openshift-ci
bot
added
the
do-not-merge/work-in-progress
openshift-ci
bot
removed
the
do-not-merge/work-in-progress
Missxiaoguo
force-pushed
the
add_wave_in_source_crs
branch
from
a232758
to
34ed40d
Compare
| @@ -3,6 +3,8 @@ kind: Subscription | |||
| metadata: | |||
| name: cluster-logging | |||
| namespace: openshift-logging | |||
| annotations: | |||
| ran.openshift.io/ztp-deploy-wave: "1" | |||
There was a problem hiding this comment.
Need to confirm that a subscription will eventually get reconciled if the ns/operatorgroup has not. This use to be a problem need to confirm it has been resolved
|
See the comment I made in 836. I think we want to seperate config from s/w installation, i.e. the subscription related cr's have their own policy |
Missxiaoguo
force-pushed
the
add_wave_in_source_crs
branch
from
34ed40d
to
1e9156d
Compare
| @@ -9,6 +9,16 @@ test-policygen: | |||
| checkExtraManifests: | |||
| $(MAKE) -C ./extra-manifests-builder check | |||
|
|
|||
| checkSourceCRsAnnotation: | |||
| for sourcefile in ./source-crs/*.yaml;do \ | |||
| if [[ "$${sourcefile}" != *"MachineConfig"* ]];then \ | |||
There was a problem hiding this comment.
Why not check MachineConfig files?
We have symlinks in source-crs for backwards compatibility, so it's possible users might still include them within as policy.
What happens if there's no annotation on a CR in a PGT?
There was a problem hiding this comment.
Based on the discussion this morning, no need waves for MCs we want to deprecate the use of MCs after installation via policies. We need to consider how to deprecate.
To the question that "What happens if there's no annotation on a CR in a PGT"
One policy should only have sources with same waves, otherwise, it's an error. This includes a CR doesn't have wave but others have.
If policy has no wave which means its sourceCRs do not have wave, this policy will not be managed by lifecycle operator.
Add 'ran.openshift.io/ztp-deploy-wave' annotation in source CR to indicate its deploy order. It will be used to set policy's 'ran.openshift.io/ztp-deploy-wave' annotation. Signed-off-by: Angie Wang <angwang@redhat.com>
Missxiaoguo
force-pushed
the
add_wave_in_source_crs
branch
from
1e9156d
to
166de42
Compare
updated |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: imiller0, Missxiaoguo 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:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
Add 'ran.openshift.io/ztp-deploy-wave' annotation in source CR
to indicate its deploy order. It will be used to set policy's
'ran.openshift.io/ztp-deploy-wave' annotation.
A check added in Makefile to make sure our provided sourceCRs have this wave annotation.
Resources have same wave means they can be applied in one policy.
Resources have different waves means they need to be applied in order and in different policies.
The default resource waves are set according to PR836 which are based on common, group-du and site. We can adjust the default waves if some resources in one group(common/group-du/site) need to be applied in order.
Wave 1(common):
Catalogsources
DisconnectedICSP
Disableoperatorhub
ReduceMonitoringFootprint
Wave 2(common):
OperatorNamespaces
OperatorGroups
OperatorSubscriptions
Wave 10(group-du):
ClusterLogForwarder
ClusterLogging
consoleOperatorDisable
ptpConfigSlave
ptpConfigMaster
ptpConfigSlaveCvl
ptpOperatorConfigForEvent
sriovOperatorConfig
DisableSnoNetworkDiag
StorageLV
Wave 100(site specifics):
Amqinstance
performanceProfile
SriovNetwork
SriovNetworkNodePolicy
TunedPerformancePatch
Jira: https://issues.redhat.com/browse/CNF-3635
Signed-off-by: Angie Wang angwang@redhat.com
/cc @imiller0 @serngawy @browsell