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

Epic: Migrate critical packages to kpt 1.0 #1834

Closed
9 tasks done
phanimarupaka opened this issue Apr 28, 2021 · 5 comments · Fixed by #2096
Closed
9 tasks done

Epic: Migrate critical packages to kpt 1.0 #1834

phanimarupaka opened this issue Apr 28, 2021 · 5 comments · Fixed by #2096
Assignees
Labels
customer deep engagement enhancement New feature or request epic p1 size/XXL 16 day triaged Issue has been triaged by adding an `area/` label

Comments

@phanimarupaka
Copy link
Contributor

phanimarupaka commented Apr 28, 2021

  • POC on Blueprints Controller, Landing Zone packages migration
  • Design proposal for e2e path to migrate existing kpt packages to make them compatible with kpt 1.0
  • Implement helper function(gcr.io/kpt-fn/fix) to help with automated portion of migration.
  • Document end to end migration steps (https://kpt.dev/installation/migration)

Related issues:

@phanimarupaka phanimarupaka added the enhancement New feature or request label Apr 28, 2021
@phanimarupaka phanimarupaka added this to the v1.0 m3 milestone Apr 28, 2021
@phanimarupaka phanimarupaka self-assigned this Apr 28, 2021
@phanimarupaka phanimarupaka added customer deep engagement p1 size/XXL 16 day triaged Issue has been triaged by adding an `area/` label labels Apr 28, 2021
@phanimarupaka phanimarupaka added this to To do in kpt kanban board via automation Apr 28, 2021
@phanimarupaka phanimarupaka changed the title Epic: Migrate critical packages to V1 Epic: Migrate critical packages to kpt 1.0 May 9, 2021
@phanimarupaka phanimarupaka moved this from To do to In Review in kpt kanban board May 9, 2021
@mikebz mikebz added the epic label May 11, 2021
@phanimarupaka phanimarupaka removed this from In Review in kpt kanban board May 12, 2021
@phanimarupaka phanimarupaka added this to To do in kpt kanban board via automation May 13, 2021
@phanimarupaka phanimarupaka moved this from To do to In Review in kpt kanban board May 13, 2021
@phanimarupaka phanimarupaka moved this from In Review to In progress in kpt kanban board May 18, 2021
@phanimarupaka phanimarupaka moved this from In progress to In Review in kpt kanban board May 20, 2021
@phanimarupaka phanimarupaka linked a pull request May 25, 2021 that will close this issue
@mikebz mikebz removed the size/XXL 16 day label May 25, 2021
@phanimarupaka phanimarupaka added the size/XXL 16 day label May 26, 2021
@phanimarupaka
Copy link
Contributor Author

cc @mikebz @frankfarzan

@phanimarupaka phanimarupaka moved this from In Review to To do in kpt kanban board May 31, 2021
@phanimarupaka
Copy link
Contributor Author

@yhrn Can we have a timeline for getting your sign-off on this epic ? Are there any major action items for us to help you with smooth migration ?

The support will continue even after you sign-off.

@yhrn
Copy link

yhrn commented Jun 16, 2021

@phanimarupaka I was added to this ticket without any heads up or additional context so I don't know what the expectations are. Am I signing off for all of Spotify or mainly as a Kpt user with some involved use cases? If it is the former then I need to pull some more people in. Also what would signing off mean? That I believe that migration will eventually be feasible given the direction of v1, that it already is feasible, that we have already migrated, something else?

I haven't had time to look into v1 that much other than reading docs and trying out various functions in the function catalog using v0. One obvious blocker is #1889. Another thing I need to understand is the details of v1 imperative vs declarative fn run. We currently have cases where we use some kind of mixed mode - kpt fn source input-dir -> kpt fn run --fn-path with fn configs annotated with the image, exec binary or Starlark source -> kpt fn sink output-dir and I'm not sure how that translates.

@phanimarupaka
Copy link
Contributor Author

@yhrn Apologies for not providing more context in the issue description.

@phanimarupaka I was added to this ticket without any heads up or additional context so I don't know what the expectations are.

Am I signing off for all of Spotify or mainly as a Kpt user with some involved use cases? If it is the former then I need to pull some more people in.

Just for your team, or set of existing pre-v1 kpt packages you own. The aim here is to have a metric to measure some success with migrating existing pre-v1 kpt packages without major blockers.

Also what would signing off mean? That I believe that migration will eventually be feasible given the direction of v1, that it already is feasible, that we have already migrated, something else?

Signing off doesn't mean you have completely migrated your packages and are production ready. It just means, you have done a decent POC using kpt v1, decided that it is feasible to migrate your packages and will be done eventually with no major blockers.

I haven't had time to look into v1 that much other than reading docs and trying out various functions in the function catalog using v0. One obvious blocker is #1889.

I added it to the list of blockers. Thanks.

Another thing I need to understand is the details of v1 imperative vs declarative fn run. We currently have cases where we use some kind of mixed mode - kpt fn source input-dir -> kpt fn run --fn-path with fn configs annotated with the image, exec binary or Starlark source -> kpt fn sink output-dir and I'm not sure how that translates.

You can go through this section for information https://kpt.dev/installation/migration?id=fn

@phanimarupaka
Copy link
Contributor Author

Since the customers have different timelines for migrating their packages based on their priorities, it is not feasible to have it as the exit criteria for this epic. The work for migration from kpt team has been implemented and documented. There could be few issues/bugs filed by users as they migrate their packages but we can track it as individual issues and add them to appropriate milestones as opposed to tying them to this epic. So adjusting the exit criteria and closing this epic as the planned work is done and released.

cc @mikebz @frankfarzan

kpt kanban board automation moved this from In Review to Done Jun 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
customer deep engagement enhancement New feature or request epic p1 size/XXL 16 day triaged Issue has been triaged by adding an `area/` label
Projects
Development

Successfully merging a pull request may close this issue.

3 participants