-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Improve UpdateChecker #18101
Improve UpdateChecker #18101
Conversation
@@ -31,17 +31,17 @@ | |||
public class FuseOptions { | |||
private static final Logger LOG = LoggerFactory.getLogger(FuseOptions.class); | |||
public static final PropertyKey FUSE_UPDATE_CHECK_ENABLED = | |||
PropertyKey.Builder.booleanBuilder("fuse.update.check.enabled") | |||
PropertyKey.Builder.booleanBuilder("alluxio.fuse.update.check.enabled") |
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.
@dbw9580 is this purposely named as fuse.update.check.enabled
rather than alluxio.fuse.update.check.enabled
?
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.
The rationale for not defining it in PropertyKey.java
and not starting with alluxio.
is that this is purely a command line option, and it should not be made accessible in alluxio-site.properties
, etc. I named it without the alluxio prefix and put it here so that the usage should be limited to fuse CLI facilities, hopefully.
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, i see. so it is not a real property key but only a CLI option.
In this case, we shall not free-ride PropertyKey
for this purpose.
I will leave your code unchanged in this PR, but let's find a different way to incorporate a CLI option
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.
The CLI can be removed and not allow user to disable it from this approach.
do we consider using
dev/scripts/src/alluxio.org/build/profiles.yml: mvnArgs: "-Dupdate.check.enabled=false"
docs/_data/generated/en/master-configuration.yml:alluxio.master.update.check.enabled:
docs/_data/generated/master-configuration.csv:alluxio.master.update.check.enabled,"true"
dora/core/common/src/main/java-templates/alluxio/ProjectConstants.java: public static final String UPDATE_CHECK_ENABLED = "${update.check.enabled}";
dora/core/common/src/main/java/alluxio/conf/PropertyKey.java: "alluxio.master.update.check.enabled";
dora/integration/fuse/src/main/java/alluxio/fuse/options/FuseOptions.java: PropertyKey.Builder.booleanBuilder("fuse.update.check.enabled")
pom.xml: <update.check.enabled>true</update.check.enabled>
the update check maven arguments way for this fuse update check disable during internal development and testing?
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 am also worried about hardcoding this. there needs to be a way to differentiate whether or not the update checks should run by default. the current mechanism is to set -Dupdate.check.enabled=false
when building the code for specific purposes; see https://github.com/Alluxio/alluxio/blob/672562bc96b3bb575ad66e3d8e765ca2794b089e/dev/scripts/src/alluxio.org/build/profiles.yml#L127C1-L127C1
i recommend reusing the same mechanism and set .setDefaultValue(Boolean.parseBoolean(ProjectConstants.UPDATE_CHECK_ENABLED))
for this property
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.
followed what @Xenorith suggested
.buildUnregistered(); | ||
|
||
/** | ||
* The UFS root that Fuse mounts. | ||
* In standalone Fuse SDK, this is different from {@link PropertyKey#DORA_CLIENT_UFS_ROOT}. | ||
* */ | ||
public static final PropertyKey FUSE_UFS_ROOT = | ||
PropertyKey.Builder.stringBuilder("fuse.ufs.root") | ||
PropertyKey.Builder.stringBuilder("alluxio.fuse.ufs.root") |
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.
@dbw9580 will this rename create issue?
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.
Renaming this should not cause breakage in functionality, but I purposely did not follow the naming convention to indicate that this a property should be limited to the fuse component, and should not be used elsewhere.
@Xenorith Add rico as the gate keeper before merging this PR |
Discussed with @Xenorith that we will add a ProcessType: FUSE to the checker |
mFuseInfo.add(LOCAL_KERNEL_DATA_CACHE); | ||
} | ||
mFuseInfo.add(String.format("UnderlyingFileSystem:%s", getUnderlyingFileSystem(fuseOptions))); | ||
mFuseInfo.add(TYPE_FUSE); |
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.
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.
previously the update checker on master has a "scale" of 1 update check per cluster deployment. what's the approximate scale for the fuse update checker? we would need to be more careful if the scale suddenly is 100-1000 times larger.
@@ -119,7 +114,6 @@ public static String getUserAgentString(String id, List<String> additionalInfo) | |||
List<String> info = new ArrayList<>(); | |||
info.add(id); | |||
addUserAgentEnvironments(info); | |||
addUserAgentFeatures(info); |
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.
is this removal on purpose? i do not see these user agent features readded for the master side update check
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, this is intentional. original addUserAgentFeatures
method is only covering master features and none of them is relevant after 300. Now, if we need any feature related info, make it in their respective UpdateChecker
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.
these changes look good to me, but i think it will be a good idea to update the endpoint's version to reflect the set of new changes. https://github.com/Alluxio/alluxio/blob/main/dora/core/common/src/main/java/alluxio/check/UpdateCheck.java#L83 is using a path with /v0
and i would recommend to change it to /v1
. but i will also have to make the corresponding changes on the receiving side for this to properly work, so please hold off on merging until it is ready
@LuQQiu can i get a (fully populated) example of a http request to compare the server side with? |
@Xenorith @Zijian-Zhu
User agent string contains ID, agent environments, processType similar to original user agent
UnderFileSystemType: "alluxio" or "local" or ufs type (e.g. "s3", "hdfs"
|
2fec0ec
to
b597c61
Compare
the update for receiving side is done. Please update the endpoint from path |
guessing the integration test failure is real:
@LuQQiu do you know what could be wrong? |
alluxio-bot, merge this please |
### What changes are proposed in this pull request? Improve UpdateChecker ### Why are the changes needed? 1. remove irrelevant master features 2. turn on fuse update check pr-link: Alluxio#18101 change-id: cid-8f6801fedda5f7710d111939e50cfd5f4372b7e5
What changes are proposed in this pull request?
Improve UpdateChecker
Why are the changes needed?