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

Documentation for ResourceGroup inventory and migration #1269

Closed
wants to merge 1 commit into from

Conversation

seans3
Copy link
Contributor

@seans3 seans3 commented Dec 9, 2020

  • Adds documentation in the live command to migrate to the next generation ResourceGroup inventory object.
  • Adds documentation for the kpt live migrate command
  • Adds documentation for the kpt live install-resource-group command
  • Updates the documentation for the kpt live init command to add new information about initialization for the ResourceGroup inventory object.

@seans3 seans3 requested review from mortent and frankfarzan December 9, 2020 04:28
@seans3 seans3 added area/live documentation Improvements or additions to documentation labels Dec 9, 2020
@seans3 seans3 requested a review from Liujingfang1 December 9, 2020 04:29
@Liujingfang1
Copy link
Contributor

/lgtm

Copy link
Contributor

@frankfarzan frankfarzan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First round just focusing on high level positioning of this feature.

@@ -20,4 +20,129 @@ description: >

Live contains the next-generation versions of apply related commands for
deploying local configuration packages to a cluster.

### How to Upgrade to the Next Generation Inventory Object
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that once the next branch graduates, the new way using ResourceGroup will be the default (not opt-in). So in terms of positioning this, we want to just present the ResourceGroup first and then dedicate a section on 'migrating from legacy'.

I think this is currently assuming the change is being introduced to master.

Copy link
Contributor Author

@seans3 seans3 Dec 14, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mortent Please comment

I believe there are basically four phases to this ResourceGroup rollout. My belief might not align with your expectations. I do not believe we will have ResourceGroup as the default for a couple months (Phase Two)--is that your expectation?

  1. (Phase Zero) This is the current phase. The ResourceGroup functionality is hidden behind an environment variable (RESOURCE_GROUP_INVENTORY). We have not announced this functionality, and we do not expect any customers to use it. Once the environment variable is exported, new packages will use the ResourceGroup inventory object, but previously initialized packages must be manually migrated. The legacy kpt live still works using the ConfigMap inventory object.

  2. (Phase One): This is the next phase that these docs are targeting. It is the same as phase zero, but we announce the new functionality for customers to experiment with (opt in). I'm guessing this can be rolled out the first week in the new year.

  3. (Phase Two): We remove the environment variable gate, and the ResourceGroup functionality for new/uninitialized packages is the default. Legacy ConfigMap inventory continues to work, but there is a warning (which can be turned off) which urges customers to upgrade to the new inventory object. Migration is still manual. We will probably move to this phase a few releases after Phase One, once we are confident of the ResourceGroup functionality. I'm guessing this phase would be possible a few releases after Phase One (maybe end of February/early March).

  4. (Phase Three): We automatically migrate packages using the legacy inventory group to the ResourceGroup inventory object. I'm guessing this would be several months after Phase Two rolls out.

So unless the next branch is not going to graduate for a few months, I do not think we are on the same page.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think by the time we integrate ConfigSync with kpt, the ResourceGroup inventory should be the default inventory object used by kpt. Before ResourceGroup is the default one, giving a period for users to know the upcoming change is reasonable. We can document it clearly that after some (or 1-2) releases, the default inventory type will change.

#### What is an Inventory Object

An inventory object is the automatically generated object which keeps track
of the set of objects applied together. The current inventory object type
Copy link
Contributor

@frankfarzan frankfarzan Dec 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Goes back to comment above, these docs need to be future looking, so when they're released, the 'current way' will be using ResourceGroup and the 'old way' will be using ConfigMap.

**ResourceGroup** CRD is:

```
export RESOURCE_GROUP_INVENTORY=1
Copy link
Contributor

@frankfarzan frankfarzan Dec 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given we forked a next branch, do we still want to support both mechanisms in the same version of kpt CLI? Instead we can say that version N-1 uses ConfigMap and version N uses ResourceGroup. version N provides migration tools.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Until we force customers off the legacy ConfigMap inventory object by automatically migrating them, we must allow them to run kpt live on these packages which the legacy mechanism. I do not believe we will be at that point (Phase Four) for at least six months, and probably longer.

site/content/en/reference/live/_index.md Outdated Show resolved Hide resolved
site/content/en/reference/live/_index.md Outdated Show resolved Hide resolved
of the set of objects applied together. The current inventory object type
is a ConfigMap, and it is usually defined in a package file called
**inventory-template.yaml**. This file is created from an invocation of
`kpt live init`. A typical use of the inventory object is to prune (delete)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you need to delete objects omitted locally? Can you provide an example, use case or more depth on what an inventory object tracks and why? Part of this confusion may come from this being the landing page for live commands, including more context about the purpose of that set of commands may help clarify here.

site/content/en/reference/live/_index.md Outdated Show resolved Hide resolved
Packages which are newly downloaded and uninitialized should follow the
following steps:

1. `export RESOURCE_GROUP_INVENTORY=1`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This RESOURCE_GROUP_INVENTORY has been referenced multiple times but not documented yet on this page. Can you include info about what this is here or link to ./init/_index.md?


#### What is a Next Generation Inventory Object

The next generation inventory object is a **ResourceGroup** custom resource
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as ConfigMap for ResourceGroup. Where do I go to find out more about this object/type, can we make that path easier?

site/content/en/reference/live/init/_index.md Outdated Show resolved Hide resolved
object (**ResourceGroup** custom resource). See commands `migrate` and
`install-resource-group` for more information.

The inventory object is required by other live commands
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is an inconsistency here. Some commands are formatted like migrate above but here they are not formatted like apply, preview, destroy etc. Can we make this consistent?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you give a bit more information about the inconsistency--thanks.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How commands are highlighted. apply, preview and destroy are not emphasized but others like migrate (above) are.

kpt live install-resource-group
```

#### Upgrade Scenario 1: New (Uninitialized) Packages
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand what this is upgrading. In scenario 2 certain files are migrated, but here it seems like this is getting started with the new ResourceGroup object with a new project for example.

@seans3 seans3 force-pushed the inventory-rg-docs branch 8 times, most recently from 191ea83 to 3827a44 Compare December 14, 2020 06:14
@mikebz
Copy link
Contributor

mikebz commented Feb 10, 2021

curious about the state of this. Seems like this hasn't been touched since December. Is this still relevant?

@mikebz
Copy link
Contributor

mikebz commented Mar 30, 2021

bump 👋

@seans3
Copy link
Contributor Author

seans3 commented Mar 30, 2021

This was superseded by: #1357

Closing

@seans3 seans3 closed this Mar 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/live documentation Improvements or additions to documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants