-
Notifications
You must be signed in to change notification settings - Fork 104
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
Maintain daemon mode information for each daemon instance #466
Conversation
need rebase 🥺 |
8a5c4cf
to
98466c9
Compare
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #466 +/- ##
==========================================
+ Coverage 37.05% 37.31% +0.26%
==========================================
Files 60 59 -1
Lines 6904 6960 +56
==========================================
+ Hits 2558 2597 +39
- Misses 4046 4052 +6
- Partials 300 311 +11
|
ID string | ||
ProcessID int | ||
APISocket string | ||
LogDir string | ||
LogLevel string | ||
LogToStdout bool | ||
DaemonMode config.DaemonMode |
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.
Do we need to handle the compatibility if the newer nydus-snapshotter is loading old records in DB without DamonMode
?
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, we need to migrate the database, that's on the todo list.
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.
Currently it works, but may get broken in future easily. So the safe way is to convert records in databases. Rafs
will face the same situation in coming PRs, so let's delay support of data migration.
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.
Um. I tend to tolerate the DB compatibility within this PR rather than make it a future work.
For the compatibility, I suppose it wouldn't be very complicated. Nydus-sanpshotter already has an experience on how to migrate different record formats in function tryTranslateRecords()
. We can simply assign a DaemonMode by comparing daemon Mountpoint
and HostRootMount
and rewrite the daemon's record of state
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 patch to migrate the database.
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
Introduce daemon mode `dedicated` as an alias for `multiple`. Signed-off-by: Jiang Liu <[email protected]>
Currently the daemon mode is global and is recorded in manager, which limits extensibility. So record daemon mode in every daemon instance, so we can extend it later. Signed-off-by: Jiang Liu <[email protected]>
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.
Otherwise LGTM
93b807e
to
5c35107
Compare
Migrate boltdb from old version to add `DaemonMode` field to daemon object. Signed-off-by: Jiang Liu <[email protected]>
Why do we need to introduce the alias? |
We are planning to deprecated |
Feel like |
Currently daemon mode is a global configuration, all daemon instances must be with the same daemon mode, which limits some possible usage scenarios. So add
DaemonMode
to daemon object, so daemons may have different daemon modes.Aslo add an alias for daemon mode "multiple" as "dedicated".