Skip to content
This repository has been archived by the owner on Mar 3, 2023. It is now read-only.

upgrade yarn scheduler driver memory to ByteAmount #1728

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

mycFelix
Copy link
Contributor

@mycFelix mycFelix commented Feb 20, 2017

As #1727 mentioned and #1707 refactored, this PR upgraded driverMemory to use ByteAmount.

The key changes are following:

  • add getByteAmountValueMB() in Config class
  • change driverMemory from int to ByteAmount
  • refactor YarnKey class
  • remove unused variables in HeronMasterDriver

cc: @billonahill @ashvina

@@ -87,6 +87,17 @@ public static ByteAmount getByteAmount(Object o) {
}
}

public static ByteAmount getByteAmountMB(Object o) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of adding a utility method for each unit, I think adding a unit to the existing method would be better. For e.g. getByteAmount(Object o) will become getByteAmount(Object o, ByteAmountUnit unit). This is same as the usage pattern of java.util.concurrent.Delayed.getDelay(TimeUnit unit). What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point~

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@billonahill - It seems we don't have ByteAmountUnit class currently. Do you think it is a good idea if we add a new class in c.t.h.common.basics in this PR?

Copy link
Contributor

@objmagic objmagic Feb 22, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mycFelix Bill is on vacation so he may not have spare time to reply you. We can definitely add ByteAmountUnit (and as a enum class to keep things simple). Another approach is to make 2048 into 2048 * 1024. We sacrifice some clarity here but can avoid extending current APIs. Thoughts? @ashvina

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mycFelix actually, now I think @ashvina's suggestion is better. It would be nice to add a enum class ByteAmountUnit in the same style of SystemConfigKey to expose MB and GB in a typed manner.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@objmagic - Understood. Thank you for your suggestion.

public static int heronDriverMemoryMb(Config cfg) {
return cfg.getIntegerValue(YarnKey.YARN_SCHEDULER_DRIVER_MEMORY_MB.value(),
YarnKey.YARN_SCHEDULER_DRIVER_MEMORY_MB.getDefaultInt());
public static ByteAmount heronDriverMemoryMb(Config cfg) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove mb from method name since ByteAmount is generic?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree

return cfg.getIntegerValue(YarnKey.YARN_SCHEDULER_DRIVER_MEMORY_MB.value(),
YarnKey.YARN_SCHEDULER_DRIVER_MEMORY_MB.getDefaultInt());
public static ByteAmount heronDriverMemoryMb(Config cfg) {
return cfg.getByteAmountValueMB(YarnKey.YARN_SCHEDULER_DRIVER_MEMORY_MB.value(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above, remove MB from method name?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will do

@mycFelix
Copy link
Contributor Author

@ashvina @objmagic I've addressed all comments. Would you please take a look again?

@objmagic
Copy link
Contributor

@mycFelix Looks good to me. I think putting ByteAmountUnit inside of ByteAmount might be better, but it's totally up to you. We can merge it if @ashvina gives a ship-it.

@mycFelix
Copy link
Contributor Author

mycFelix commented Feb 22, 2017

@objmagic - Thanks for reviewing. I'm agree with you. At first, I think putting ByteAmountUnit inside of ByteAmount is a better approach and using enum to instead static MB and GB inside of ByteAmount seems nice too. But It might trigger a large refactor in ByteAmount. So, I decided to put ByteAmountUnit outside of ByteAmount temporarily.

Copy link
Contributor

@billonahill billonahill left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should introduce ByteAmountUnit. The point of ByteAmount is that config users will know how to create a ByteAmount (because they know the units), and put it in the config for others to leverage. Those others should not need to know what the unit in the config is, hence the ByteAmount class exists. It is a representation of bytes that consumers can get in whatever unit they need to, without knowledge of how the units at play when the config value was added. Creating ByteAmountUnit just allows the ability for the lazy to read a long and convert it to a ByteAmount if they happen to know the correct unit. This is undesirable and is exactly what we're trying to prevent with the ByteAmount class. It implies that the config consumer knows the unit that the config producer used when adding the config, which should not be the case (this pattern is super bug-prone). Instead, the agent that puts the size into the config should know the units, and create a ByteAmount up front.

@@ -161,7 +162,7 @@ Configuration getHMDriverConf() {
.set(HeronDriverConfiguration.HTTP_PORT, 0)
.set(HeronDriverConfiguration.VERBOSE, false)
.set(YarnDriverConfiguration.QUEUE, queue)
.set(DriverConfiguration.DRIVER_MEMORY, driverMemory)
.set(DriverConfiguration.DRIVER_MEMORY, driverMemory.asMegabytes())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused here. Shouldn't DRIVER_MEMORY accept value of type int, according to reef?

Copy link
Contributor Author

@mycFelix mycFelix Feb 23, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be honest, it make me confused too. I didn't notice that...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@objmagic - cast it to int

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you can just cast here...?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mycFelix I now think I am not the right person to review this PR. You can think about Bill's review and wait for @ashvina's comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@objmagic - Sure~

@mycFelix
Copy link
Contributor Author

mycFelix commented Mar 7, 2017

Considering @billonahill 's comment, creating ByteAmountUnit enum class might not be a proper way.

@ashvina @billonahill - How about we make 2048 into 2048 * 1024 here?

}
}

public static ByteAmount getByteAmount(Object o, ByteAmountUnit unit) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be useful to add javadocs for these overloaded methods.

@objmagic
Copy link
Contributor

is there any update on this? seems we have very few things left to do for this PR? @mycFelix @billonahill

@huijunw huijunw added the Yarn label Jul 23, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants