Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Backup/recovery commands fail when default configuration for backup attached to cluster-config.yml #2930

Closed
8 of 18 tasks
cicharka opened this issue Jan 26, 2022 · 1 comment
Assignees
Labels

Comments

@cicharka
Copy link
Contributor

cicharka commented Jan 26, 2022

Describe the bug
Documentation for backup/recovery states that it is possible to attach default backup/recovery configuration from defaults/configuration/backup.yml/defaults/configuration/recovery.yml to cluster-config.yml, but in both cases running epicli backup/epicli recovery fails due to the error:

11:07:59 INFO cli.engine.schema.SchemaValidator - Starting step
11:07:59 ERROR cli.engine.schema.SchemaValidator - Failed validating: epiphany-cluster
11:07:59 ERROR cli.engine.schema.SchemaValidator - '#/specification' does not match '^[^#]*#?$'

Failed validating 'pattern' in metaschema['allOf'][0]['properties']['$id']:
    {'$comment': 'Non-empty fragments not allowed.',
     '$ref': '#/$defs/uriReferenceString',
     'pattern': '^[^#]*#?$'}

On schema['$id']:
    '#/specification'
11:07:59 INFO cli.engine.schema.SchemaValidator - Step finished in: 0.06s
11:07:59 ERROR epicli - Schema validation error, see the error above.

It is important to note that backup and recovery commands work fine when there's a newly created backup.yml or recovery.yml file which contain only default backup/recovery configuration.

How to reproduce
Steps to reproduce the behavior for backup:

  1. create new cluster -> epicli init -> epicli apply
  2. Copy default backup configuration from defaults/configuration/backup.yml and attach it to existing cluster-config.yml (can be a copy of that file as well -> important part here is to have your previous configuration statements and the backup section in one file)
  3. try to run epicli backup ... command

Steps to reproduce the behavior for recovery:

  1. Use existing cluster that has already backup done
  2. Attach default recovery configuration to existing config file (similar to backup steps)
  3. try to run epicli recovery ... command

Expected behavior
Attaching recovery/backup configuration to existing configuration file will not make epicli backup/recovery commands fail -> operations will succeed

  • If it is not possible to fix that issue, remove obsolete notes from documentations

Environment

  • Cloud provider: All
  • OS: Any

epicli version: [epicli --version]
v2.0dev

Additional context
Verify if it is needed to test it in previous releases.


DoD checklist

  • Changelog
    • updated
    • not needed
  • COMPONENTS.md
    • updated
    • not needed
  • Schema
    • updated
    • not needed
  • Backport tasks
    • created
    • not needed
  • Documentation
    • added
    • updated
    • not needed
  • Feature has automated tests
  • Automated tests passed (QA pipelines)
    • apply
    • upgrade
    • backup/restore
  • Idempotency tested
  • All conversations in PR resolved
@cicharka cicharka self-assigned this Feb 9, 2022
cicharka added a commit to cicharka/epiphany that referenced this issue Feb 9, 2022
Bug hitachienergy#2942 rsync command fails trying to copy artifacts
* With new version of ansible we can use private_key option for
  synchronize module, therefore there's no need to use rsh

Bug hitachienergy#2930 Backup/recovery commands fail when default configuration for
backup attached to cluster-config.yml
* extend run_for_individual_documents method so it can choose relevant
  schema for validated document
cicharka added a commit to cicharka/epiphany that referenced this issue Feb 14, 2022
Bug hitachienergy#2942 rsync command fails trying to copy artifacts
* With new version of ansible we can use private_key option for
  synchronize module, therefore there's no need to use rsh

Bug hitachienergy#2930 Backup/recovery commands fail when default configuration for
backup attached to cluster-config.yml
* extend run_for_individual_documents method so it can choose relevant
  schema for validated document
cicharka added a commit to cicharka/epiphany that referenced this issue Feb 23, 2022
Bug hitachienergy#2942 rsync command fails trying to copy artifacts
* With new version of ansible we can use private_key option for
  synchronize module, therefore there's no need to use rsh

Bug hitachienergy#2930 Backup/recovery commands fail when default configuration for
backup attached to cluster-config.yml
* extend run_for_individual_documents method so it can choose relevant
  schema for validated document
@cicharka
Copy link
Contributor Author

After conversations with @przemyslavic and @seriva there is agreement:

  • documentation will instruct user to create new backup.yml/recovery.yml file in order to use epicli backup/recovery commands
  • nevertheless it will be possible to attach these configs to any yml file as there is additional validation to fetch desired kind of docs: select_all(loaded_docs, lambda x: x.kind in ['configuration/backup', 'configuration/recovery'])

cicharka added a commit that referenced this issue Feb 24, 2022
* Fix for #2942 - with new version of ansible we can use private_key option for
  synchronize module, therefore there's no need to use rsh

* Fix for #2930

* Remove legacy code

* Additional check to verify if backup/recovery present in input docs
@seriva seriva closed this as completed Mar 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants