-
Notifications
You must be signed in to change notification settings - Fork 243
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
Guide for migrating from v2 to v3 #6095
Guide for migrating from v2 to v3 #6095
Conversation
✅ Deploy Preview for odo-docusaurus-preview ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a few comments.
I think it is worth documenting the following changes (with more concrete examples):
- how we leverage port-forwarding instead of URLs to access the running application. A concrete example of how to access the application using both v2 and v3 could be helpful, I think.
- what needs to be changed for debugging to work with v3: if I'm not mistaken, if v2, you needed to run
odo push --debug
and thenodo debug port-forward
. In v3, a Debug endpoint needs to be explicitly declared in the Devfile.
I agree that this needs to be mentioned, but don't think it should be done with an example for v2 and v3. I have added a section titled "What happened to Ingress/Route?" to clarify this.
I have similarly added a section titled "Changes to the way component debugging works" for this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added more comments.
LGTM overall, but while reviewing and testing the migration, I was also thinking about the following "breaking" changes that might be worth documenting here:
-
how
odo dev
handles command and args in the container definition in the Devfile (Add support forcommand
/args
fields incontainer
components #5768). I am not sure how v2 users used this, but this is a potential breaking change, I think: in v2, the container command was always overridden with Supervisord; but v3 now respects what has been specified in the Devfile as command/args. However, v3 requires a non-terminating command in the Devfile, so the container can remain running. If nothing is defined,odo dev
defaults totail -f /dev/null
. -
the fact that Ephemeral now defaults to
False
(Change ephemeral default to false #5795), and what this means for users -
the changes in the odo config file related to temporal values (#5822). This point might not be that critical to document here, because the
odo
commands will display warnings like⚠ Please change the preference value for Timeout, PushTimeout, RegistryCacheTime, the value does not comply with the minimum value of 1s; e.g. of acceptable formats: 4s, 5m, 1h
. But I was wondering if we shouldn't mention it here too.
I think this doesn't affect the users in terms of migration. In v2, we used supervisord. In v3, we override their command with the
Ack. I'll add.
I'd prefer not to mention it here because, I think, it's not going to affect a lot of users (telemetry data could confirm, I'm simply assuming based on issues we have seen around |
Signed-off-by: Dharmit Shah <shahdharmit@gmail.com>
Signed-off-by: Dharmit Shah <shahdharmit@gmail.com>
Signed-off-by: Dharmit Shah <shahdharmit@gmail.com>
Just to clarify: in v3, we don't override the command but use whatever is defined as command/args in the Devfile container component. As a workaround to have a running container, we force the use of My concern was more about people using v2 and who currently have command/args explicitly defined in their Devfiles. Just wanted this doc to warn them to make sure that such definition should result in a non-terminating container.
Thanks.
Makes sense. Thanks Dharmit! |
This should be under "Advanced Usage" as it messed up the side bar order a bit (or if not in advanced usage, can be at the very end instead / low priority?) |
--- | ||
|
||
### Migrate existing odo component from v2 to v3 | ||
If you have created an odo component using odo v2, this section will help you move it to use odo v3. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you have created an odo component using odo v2, this section will help you move it to use odo v3. | |
If you have created an odo component using odo v2, this section will help you move it to use odo v3. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
add newline :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, this may be better as you are just rewording the title?
If you have created an odo component using odo v2, this section will help you move it to use odo v3. | |
Before migrating to odo v3 you must delete your application and re-run it: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand what exactly you are suggesting here. Replacing the current statement with Before migrating to odo v3 you must delete your application and re-run it:
is not making sense to me.
|
||
### Migrate existing odo component from v2 to v3 | ||
If you have created an odo component using odo v2, this section will help you move it to use odo v3. | ||
1. `cd` into the component directory, and delete the component from the Kubernetes cluster: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1. `cd` into the component directory, and delete the component from the Kubernetes cluster: | |
Step 1. `cd` into the component directory, and delete the component from the Kubernetes cluster: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Step 1, step 2, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You also don't necessarily need to cd
into the directory ;)
Perhaps just say: "Delete the component from the Kubernetes cluster:"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You also don't necessarily need to cd into the directory ;)
I'd prefer having it because if the user wants to odo dev
the same component using v3, they need to be in the component directory. So although it's technically possible to delete the component from outside the component directory, I'd rather they cd
into it. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Step 1, step 2, etc.
Done. But PTAL and suggest. Please mark resolved if looks good.
Signed-off-by: Dharmit Shah <shahdharmit@gmail.com>
@cdrage thanks for the exhaustive review! I have not committed your suggestions through the GH interface because that would trigger a Netlify deploy preview for each such commit. I have manually made the changes or made a counterpoint. Hopefully, I didn't miss anything in your review. @rm3l Added the info about Ephemeral storage. PTAL and thanks for your patience. :) |
Signed-off-by: Dharmit Shah <shahdharmit@gmail.com>
Kudos, SonarCloud Quality Gate passed! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the changes!
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rm3l 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 |
@dharmit: The following test failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
Looking into why the test below was not passing on Windows, but this is unrelated to the changes in this PR. /override windows-integration-test/Windows-test
|
@rm3l: Overrode contexts on behalf of rm3l: windows-integration-test/Windows-test In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/lgtm |
Signed-off-by: Dharmit Shah shahdharmit@gmail.com
What type of PR is this:
/kind documentation
What does this PR do / why we need it:
$subject
Which issue(s) this PR fixes:
Fixes #6069
PR acceptance criteria:
Unit test
Integration test
Documentation
How to test changes / Special notes to the reviewer: