-
Notifications
You must be signed in to change notification settings - Fork 109
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
go/oasis-node/cmd/config: Add the migrate subcommand #5237
Conversation
2c035fc
to
cc4368c
Compare
Codecov Report
@@ Coverage Diff @@
## master #5237 +/- ##
==========================================
- Coverage 67.23% 67.07% -0.17%
==========================================
Files 512 514 +2
Lines 54293 54685 +392
==========================================
+ Hits 36502 36678 +176
- Misses 13371 13555 +184
- Partials 4420 4452 +32
... and 62 files with indirect coverage changes Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
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 not put this under debug
.
Also can you add a cfg
changelog entry that describes how to use this command?
cc4368c
to
873ba13
Compare
Done :) Going to try this out on various config files now and add code to migrate |
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.
Can you also add some quick unit tests for these migrations? E.g. using some dummy configs derived from real ones.
f4dcf82
to
41a1b64
Compare
logger.Warn("note that grpc.* options are from now on only available on the command-line") | ||
} | ||
if _, ok = oldCfg["metrics"]; ok { | ||
logger.Warn("note that metrics.* options are from now on only available on the command-line") |
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.
Oh, didn't notice that before, why is this the case, doesn't it make sense to have them in the config file?
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 guess we could move them into the config in a separate PR...
52ffc9e
to
9a9785c
Compare
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 think that most of the code could be simplified with a map old.config.value => new.config.value
and a function which creates all maps on the path, copies values from one config to the other and prints a comment, but not sure.
logger.Error("output file name missing, use the --out flag to specify it") | ||
os.Exit(1) | ||
} | ||
if cfgInFileName == cfgOutFileName { |
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.
This check probably won't work for oasis-node config migrate --in a.yaml --out ./folder/../a.yaml
.
Files could also be folders, e.g. oasis-node config migrate --out folder
(not sure if we need so thorough validation).
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.
Yeah, this is by design, it's just a safeguard against fatfingering :)
d42cc40
to
17cd76c
Compare
Thank you for your comments! I also tried to come up with a way to represent and apply the changes in a nicer, more organized way, but the actual changes are too chaotic to do that, so unfortunately this mess of if/else statements is what works best :D This command will only be useful in the next release. Afterwards, we can remove it or replace its structure with something nicer if necessary. |
newCfgStruct := config.DefaultConfig() | ||
err = yaml.Unmarshal(newCfgRaw, &newCfgStruct) | ||
if err != nil { | ||
logger.Error("failed to parse config file after migration (this might be normal if you're using environment variable substitutions in your original config file)", "err", err) |
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.
This error message is a bit confusing for me, as I expect the problem is in the original file and not in the converted one. I hope the users won't have the same problem.
Options:
- Add few extra lines, one printing that we are doing a migration, one that migration was completed, file saved, another that we are validating the migrated file.
- Or split migration/validation, e.g. create a new command and print the command for validation at the end. Maybe even add a warning that the file is not validated. New command could be useful latter to verify already migrated config files.
- Keep as it is.
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.
Config validation is done by default now when then node starts up and loads the config file, so I don't think a separate command is needed for that.
I will add a few more info logs to let the user know what's happening.
17cd76c
to
2622d56
Compare
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.
Looks good.
One last thing. I would maybe change that the mode is always present in the config file, so that you know the node's type as soon as you see the config file, without need to know the default value.
2622d56
to
19cffd5
Compare
A new
migrate
subcommand is added to the node'sconfig
command. This subcommand can be used to automatically migrate
the old YAML config file into the new format introduced in
commit 2a132b3.
The subcommand logs the various changes it makes and warns the
user if a config option is no longer supported, etc.
At the end, any unknown sections of the input config file are
printed to the terminal to give the user a chance to review
them and make manual changes if appropriate.