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

Implement phase/plan validation changes in Treasuremap manifests #176

Closed
eak13 opened this issue Jun 16, 2021 · 7 comments
Closed

Implement phase/plan validation changes in Treasuremap manifests #176

eak13 opened this issue Jun 16, 2021 · 7 comments
Assignees
Labels
enhancement New feature or request priority/critical Items critical to be implemented, usually by the next release
Milestone

Comments

@eak13
Copy link

eak13 commented Jun 16, 2021

airshipit/airshipctl#563 has moved document validation into the airshipctl phases & plans. We need to do the manifest work in Treasuremap to leverage the validation changes made in Airshipctl.

@eak13 eak13 added enhancement New feature or request triage priority/critical Items critical to be implemented, usually by the next release labels Jun 16, 2021
@eak13 eak13 added this to the v2.1 milestone Jun 17, 2021
@sirajyasin
Copy link
Contributor

@ak3216 , is this impacted with a pinned version of airshipctl in treasuremap ? I had the same issue with uplift and trying to fix it.

@sirajyasin
Copy link
Contributor

My observation for this issue:
@ak3216
Treasuremap phase/plan/executors is inherited from airshipctl with specific patches. So plan list gives all plans of treasuremap's test-site as well as airshipctl's test-site.
Because of this validate docs is failing trying to validate all plans listed.

Plan list (from treasuremap [test-site] config):
PhasePlan/deploy-aiship-core-gating
PhasePlan/deploy-gating
PhasePlan/iso

Approach:

  1. Should we stop inheriting phase/executors/plan from airshipctl ?
  2. Should we have patch to delete unwanted plans
    https://review.opendev.org/c/airship/treasuremap/+/795703/16/manifests/type/airship-core/phases/patches/delete-deploy-gating.yaml

@eak13
Copy link
Author

eak13 commented Jun 17, 2021

@sirajyasin this was reported from downstream and I'm not sure what version is currently being pulled as they're trying to stay up to date with current code, so I'm not sure there's a pinned version right now, though ultimately, they will pin to v2.1.

As far as approach, if we did #2, then we'd need patches for each type to remove the unwanted phases/plans, correct? That is, we would still inherit from airshipctl, but then just modify the list to remove the unwanted ones.

@jezogwza jezogwza removed the triage label Jun 23, 2021
airshipbot pushed a commit that referenced this issue Jun 23, 2021
* Use patch to re-define the plan definition with required
  sequence of phases applicable to the specific type/site instead of
  defining a new plan.
* The idea of this change is to have one unique plan for deployment
'deploy-gating' with its own definition per type/site.

RelatesTo: #176
Change-Id: I162883dd2e86b709fbb483b985130e8748d8e557
@michaelfix
Copy link

Related PS merged 23 June 2021: https://review.opendev.org/c/airship/treasuremap/+/796930

@sirajyasin , @ak3216 , can this issue be closed, or more PSs planned?

@sirajyasin
Copy link
Contributor

@mf4716 , one part of the issue is to fix the plan list to restrict it to site/type specific by overriding the same plan 'deploy-gating', instead of defining new plans for each site/type. The change for this is now merged.

However the new format of phase/plan based validation will be addressed as part of the uplift PS [0]
[0] https://review.opendev.org/c/airship/treasuremap/+/795703

@sirajyasin
Copy link
Contributor

All sites in treasuremap are passing validate docs after the uplift PS is merged. This issue can be marked closed.

@eak13
Copy link
Author

eak13 commented Jun 28, 2021

Closing per above patchset merge

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request priority/critical Items critical to be implemented, usually by the next release
Projects
None yet
Development

No branches or pull requests

4 participants