Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
fix: allow to customize config values on create new page #228
fix: allow to customize config values on create new page #228
Changes from all commits
7e10c2a
1c0e5ce
ca9d37f
1dcfc94
b5b7491
ed95663
b07bba2
23e9a07
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 would suggest to preserve previous behavior when this form creates and starts VM.
When opened it should show default values set in CRC Extension settings and let user to changes them and use as part of 'crc start' command without saving them in settings as default.
There could be a switch 'Save as default settings' if we want and saveConfig method should be called in create function before calling createCrcVm().
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 agree about showing the default values. The initial plan i had was this one but this is not currently supported by Desktop as far as i recall and I don't think a user is going to delete/create the VM several time so we should be good with what we have now as an initial release. This can be done in a follow-up PR. Even because it can be useful for other extensions and it is an improvement we should do on the Desktop side.
Regarding saving the values as default vs using them when starting the VM - i think there is a bit of confusion about how crc fit inside the Podman Desktop mechanisms.
In the
create new
page we usually create the instance of something (for podman - a podman machine, for kind - a kind cluster) but we are not actually starting them (unless you set the optionstart now
). In CRC i tried to do the same but crc does not have the concept of a new instance. Everything is set up during the setup phase and then you have to start it.So in the "creation" process what we do is just registering the kubernetes connection to Desktop with its custom lifecycle (start/stop/delete).
Now if you want to start the VM you can click on the start button from the resources page, but in that case you don't have any way to set the memory/cpu/disk, and i don't think that showing a quickpick is really user friendly. So it is easier to set them globally during the "create" process so that when the user start the VM, the properties are already saved.
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.
Yes +1, I don't think the settings for the "OpenShift Local" environments should be handle in a different way than what we are doing for podman machine. (For podman machine, we have "default values", but the user has no way to configure those in the preferences.)
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.
Sounds good to me then with nit. There should be markup paragraph before pull-secret file location configuration field explaining that if you have file with it you can configure it here, but it is optional. If you do not fill up file location for pull-secret file you are going to be requested to login using Red Hat SSO to pull pull-secret and store it in platform specific secure storage.
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.
@dgolovin done. Description updated. You can see it in the image on the first post above