HDDS-4562. Old bucket needs to be accessible after the cluster was upgraded to the Quota version. #1677

captainzmc · 2020-12-09T02:38:03Z

What changes were proposed in this pull request?

long quotaInBytes are new fields in the bucketArgs, this field will go to 0 by default in the old bucket when the old cluster is upgraded. At this point, the data writes are rejected.

This is similar to creating a bucket without specifying quotaInBytes, where quotaInBytes is set to -1 by default via getQuotaValue. We can use 0 as a special term.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-4562

How was this patch tested?

ut added

adoroszlai

Thanks @captainzmc for fixing this. The old bucket is now writeable, reproduced the problem and verified the fix using upgrade compose environment.

bharatviswa504

Hi @captainzmc
Few questions:

Can we make use of proto default value to -1 for quotaInBytes value in proto.
So on old buckets, we cannot set quota, as we don't have any info of bytesUsed/namespace count, or if it can be set how this will be handled?
And how upgrades are handled for quota feature overall, like for older volumes and buckets under it?

bharatviswa504 · 2020-12-11T20:01:53Z

Not related to this PR, can you also provide info on how the clear space quota works and it's usage.

Because I see when bucket clear space quota comes, we reset to -1, but what will happen to volume quota (Will it reclaim bucket quota? or any information on clear space quota usage and how it works also can you share some info.

adoroszlai · 2020-12-12T11:08:51Z

@captainzmc see #1691 for acceptance test with two lines that are currently disabled to verify this fix. If you could review that PR, then uncommenting them in this PR would improve test coverage.

captainzmc · 2020-12-13T03:53:59Z

Hi @captainzmc
Few questions:

Can we make use of proto default value to -1 for quotaInBytes value in proto.

So on old buckets, we cannot set quota, as we don't have any info of bytesUsed/namespace count, or if it can be set how this will be handled?

And how upgrades are handled for quota feature overall, like for older volumes and buckets under it?

Thanks for @bharatviswa504’s advices.

Currently, Unsigned field can't have negative default value in proto. If we set [default = -1], an error will be compiled.
For now, we use getQuotaValue(long quota) to handle the default case in RpcClient..
After adding usedByets, the original keys of the old bucket cannot be counted, so we can only count the newly written keys. Therefore, we temporarily did not recommend old buckets to enable Quota (because their usedByets were inaccurate).
For old buckets we do not recommend that quota be enabled, but in order not to affect the write, I handle the default at checkBucketQuotaInBytes in this PR.

captainzmc · 2020-12-13T03:57:46Z

Not related to this PR, can you also provide info on how the clear space quota works and it's usage.

Because I see when bucket clear space quota comes, we reset to -1, but what will happen to volume quota (Will it reclaim bucket quota? or any information on clear space quota usage and how it works also can you share some info.

Yes, I have submitted the use of the latest quota in Doc. Can be seen here:
https://ci-hadoop.apache.org/view/Hadoop%20Ozone/job/ozone-doc-master/lastSuccessfulBuild/artifact/hadoop-hdds/docs/public/feature/quota.html
Bucket quota can be set separately without enabling Volume quota. So if volume's quota is cleared, his bucket will not be affected. However, if the volume quota is set to another value, it cannot be less than the quota size for all buckets.

captainzmc · 2020-12-13T04:09:02Z

@captainzmc see #1691 for acceptance test with two lines that are currently disabled to verify this fix. If you could review that PR, then uncommenting them in this PR would improve test coverage.

Thanks for @adoroszlai 's suggestion, I will deal with the acceptance test here.

bharatviswa504 · 2020-12-14T23:09:53Z

https://ci-hadoop.apache.org/view/Hadoop%20Ozone/job/ozone-doc-master/lastSuccessfulBuild/artifact/hadoop->hdds/docs/public/feature/quota.html

When clear volume quota(Assuming volume quota was set before), it is just like setting the quota on the volume to -1, >when clear volume quota is called?

When volume quota is set, bucket clear quota, it is like just setting the quota for that bucket to -1, and it will allow new >buckets can be created if volume quota is still available(As previous bucket quota cleared quota)

When volume quota is not set and bucket quota is set, it is just reset quota of the bucket to -1. when clear bucket quota operation is performed

Is my understanding correct here?

Example:
V1 - 100 MB
V1/B1 - 50MB
V1/B2- 50MB

Now clear quota on V1/B2 we set quota of V1/B2 to -1, and now a new bucket can be still created in this volume?

New Bucket created with quota 50MB. (V1/B3)

So, in this volume there are 3 buckets, only 2 are considered in to count, as clearQuota is run(on V1/B2), and we are not considering this bucket in quota calculations, so this bucket will not be counted under quota, but for volume we have crossed the quota of that volume. (As user has run clear quota on V1/B2)

So, here clear quota means resetting the quota to -1? Or what is the real purpose of this clearQuota usage on clusters, in what scenarios this will be useful on the cluster?

For old buckets, we do not recommend that quota be enabled, but in order not to affect the write, I handle the default at >checkBucketQuotaInBytes in this PR.

But I don't see any guards in the cluster to not allow quota operations for older buckets/volumes.

And also do you think, we need to document this in our docs?

bharatviswa504 · 2020-12-14T23:19:33Z

hadoop-ozone/client/src/main/java/org/apache/hadoop/ozone/client/rpc/RpcClient.java

Why do we need to do this during set Operation?

This check simply ensures that when we use RpcClient set Quota, the value of quota must be legal (not less than -1). But the getQuotaValue conversion step inside is redundant, I‘ll delete this conversion.

bharatviswa504 · 2020-12-14T23:59:07Z

Currently, Unsigned field can't have negative default value in proto. If we set [default = -1], an error will be compiled.
For now, we use getQuotaValue(long quota) to handle the default case in RpcClient..

Might be use int64, but protobuf document said it is inefficient for negative numbers, not sure it is good idea. Just thought of bringing this up here?

int64	Uses variable-length encoding. Inefficient for encoding negative numbers – if your field is likely to have negative values, use sint64 instead.	int64	long	int/long[3]	*int64

I think it will also help if we plan to support quota on older buckets.

The default will be -2, all older buckets will have -2, new buckets created after this feature will have -1. So, if some one sets quota on older buckets in this way, we can figure it out, just an idea saying here.

captainzmc · 2020-12-15T02:58:29Z

Might be use int64, but protobuf document said it is inefficient for negative numbers, not sure it is good idea. Just thought of bringing this up here?

I'll change the type to sint64, which is both negative by default and more efficient than int64.

captainzmc · 2020-12-15T03:21:09Z

Example:
V1 - 100 MB
V1/B1 - 50MB
V1/B2- 50MB

Now clear quota on V1/B2 we set quota of V1/B2 to -1, and now a new bucket can be still created in this volume?

New Bucket created with quota 50MB. (V1/B3)

So, in this volume there are 3 buckets, only 2 are considered in to count, as clearQuota is run(on V1/B2), and we are not considering this bucket in quota calculations, so this bucket will not be counted under quota, but for volume we have crossed the quota of that volume. (As user has run clear quota on V1/B2)

So, here clear quota means resetting the quota to -1? Or what is the real purpose of this clearQuota usage on clusters, in what scenarios this will be useful on the cluster?

Thanks to @bharatviswa504‘s advice, you found a very important point.
Before HDDS-4308, we had usedBytes in volume, so before writing the key, we checked both bucket quota and volume quota. Setting bucket quota to -1 alone at this point does not matter, since we are able to ensure that usedBytes do not exceed volume quota.
But we can't do that now because volume doesn't have usedBytes. I created a new JIRA HDDS-4588 to fix this problem. If volume's quota is enabled then bucket's quota cannot be cleared. We need to prompt the user to clear volume quota first.

But I don't see any guards in the cluster to not allow quota operations for older buckets/volumes.

And also do you think, we need to document this in our docs?

I’ll refine the docs to make it clear that older volumes/buckets are not recommended to use quota.

captainzmc · 2020-12-15T12:49:34Z

When the acceptance test upgrade, namespace will also have the problem that old volumes cannot create buckets. This also fixed in this PR. R: @amaliujia @linyiqun

captainzmc · 2020-12-15T12:52:08Z

Updated PR and fixed review issues.

linyiqun

@captainzmc , current PR change looks good to me. But I catch some places we can improve in follow-up JIRA.

linyiqun · 2020-12-15T14:27:52Z

hadoop-hdds/docs/content/feature/Quota.md

+
 d. Volume quota is not currently supported separately, and volume quota takes effect only if bucket quota is set. Because ozone only check the usedBytes of the bucket when we write the key.

+e. If the cluster is upgraded from old version less than 1.1.0, use of quota on older volumes and buckets is not recommended. Since the old key is not counted to the bucket's usedBytes, the quota setting is inaccurate at this point.


We can make this check in OM side and throw exception once user try to set quota on older version volumes/buckets.

Currently, we have not agreed on whether bucket can be enabled for the old quota. At present, we only put forward the suggestion in the document very briefly. If the requirement is clear, we can issue Jira and solve it.

Make sense to me.

linyiqun · 2020-12-15T14:29:36Z

hadoop-hdds/docs/content/feature/Quota.md

 So far, we know that Ozone allows users to create volumes, buckets, and keys. A Volume usually contains several buckets, and each Bucket also contains a certain number of keys. Obviously, it should allow the user to define quotas (for example, how many buckets can be created under a Volume or how much space can be used by a Bucket), which is a common requirement for storage systems.

 ## Currently supported
 1. Storage Space level quota


The namespace quota introduction can also be added. We could file a new JIRA for tacking this.

I can add namespace quota to this documentation: https://issues.apache.org/jira/browse/HDDS-4594. Before adding to documentation, I will first finish namespace support on bucket: https://issues.apache.org/jira/browse/HDDS-4277

bharatviswa504 · 2020-12-15T16:41:47Z

Example:
V1 - 100 MB
V1/B1 - 50MB
V1/B2- 50MB
Now clear quota on V1/B2 we set quota of V1/B2 to -1, and now a new bucket can be still created in this volume?
New Bucket created with quota 50MB. (V1/B3)
So, in this volume there are 3 buckets, only 2 are considered in to count, as clearQuota is run(on V1/B2), and we are not considering this bucket in quota calculations, so this bucket will not be counted under quota, but for volume we have crossed the quota of that volume. (As user has run clear quota on V1/B2)
So, here clear quota means resetting the quota to -1? Or what is the real purpose of this clearQuota usage on clusters, in what scenarios this will be useful on the cluster?

Thanks to @bharatviswa504‘s advice, you found a very important point.
Before HDDS-4308, we had usedBytes in volume, so before writing the key, we checked both bucket quota and volume quota. Setting bucket quota to -1 alone at this point does not matter, since we are able to ensure that usedBytes do not exceed volume quota.
But we can't do that now because volume doesn't have usedBytes. I created a new JIRA HDDS-4588 to fix this problem. If volume's quota is enabled then bucket's quota cannot be cleared. We need to prompt the user to clear volume quota first.

But I don't see any guards in the cluster to not allow quota operations for older buckets/volumes.
And also do you think, we need to document this in our docs?

I’ll refine the docs to make it clear that older volumes/buckets are not recommended to use quota.

So, now if the volume quota is not set, the bucket Clearspace quota is just disabling quota on the buckets.

And also just setting quota at volume level will not be counted, until bucket level quotas are set.

For my understanding so volume quota is set, and bucket quota is set, clearing volume quota is just set to -1, so that now quota is tracked at bucket level. And now when bucket quota is cleared, when volume quota is set, we disallow the operation.
This will be the behavior of clear space quota, let me know if i am missing something.

But we can't do that now because volume doesn't have usedBytes. I created a new JIRA [HDDS-4588
(https://issues.apache.org/jira/browse/HDDS-4588) to fix this problem. If volume's quota is enabled then bucket's quota >cannot be cleared. We need to prompt the user to clear volume quota first.

Now the example mentioned scenarios will not happen. Thanks for opening this Jira and tracking this issue.

bharatviswa504 · 2020-12-15T16:42:40Z

The default will be -2, all older buckets will have -2, new buckets created after this feature will have -1. So, if some one sets >quota on older buckets in this way, we can figure it out, just an idea saying here.

If we want to disallow the quota support for older buckets, one idea to do at code level.

bharatviswa504

Overall LGTM.
Few comments, and one question regarding handling old buckets/volumes.

bharatviswa504 · 2020-12-15T17:50:08Z

hadoop-hdds/docs/content/feature/Quota.md

+
 a. By default, the quota for volume and bucket is not enabled.
+
 b. When volume quota is enabled, the total size of bucket quota cannot exceed volume.


Minor:
When volume quota is enabled, the total quota of the buckets, cannot exceed the volume quota.

bharatviswa504 · 2020-12-15T17:51:24Z

hadoop-hdds/docs/content/feature/Quota.md

+
 d. Volume quota is not currently supported separately, and volume quota takes effect only if bucket quota is set. Because ozone only check the usedBytes of the bucket when we write the key.

+e. If the cluster is upgraded from old version less than 1.1.0, use of quota on older volumes and buckets is not recommended. Since the old key is not counted to the bucket's usedBytes, the quota setting is inaccurate at this point.


Can we also add documentation about the clear space quota and the behavior?

Yes. To prevent conflicts, I have updated the usage and behavior of clear space quota in this PR.

amaliujia · 2020-12-15T19:36:15Z

@captainzmc

Can we use 0 to indicate that a quota is not set? Will this better handle the cluster upgrade issue that some buckets by default has 0 quota?

If a case is really set "0" quota to a bucket thus lock the bucket from creating, then users can choose to use a negative value.

amaliujia · 2020-12-15T19:40:01Z

O, actually from the code seems that setting default value as -1 is solved in proto. If so please ignore my previous comment (which assumed that proto cannot set -1 as default value for quota)

ChenSammi · 2020-12-16T06:54:57Z

The default will be -2, all older buckets will have -2, new buckets created after this feature will have -1. So, if some one sets >quota on older buckets in this way, we can figure it out, just an idea saying here.

If we want to disallow the quota support for older buckets, one idea to do at code level.

User using old Ozone version may still has the desire to use the new Quota feature. It's better not shut the door completely.
@adoroszlai , I'm not sure if it's feasible that we provide a option of calculating the bytesInUsed for each bucket during 1.0.0 -> 1.1. upgrade to user? So that user has the choice either tolerate the inaccurate bytesInUsed or a relative longer upgrade time to get accurate bytesInUsed of buckets.

captainzmc · 2020-12-16T11:10:20Z

So, now if the volume quota is not set, the bucket Clearspace quota is just disabling quota on the buckets.

And also just setting quota at volume level will not be counted, until bucket level quotas are set.

For my understanding so volume quota is set, and bucket quota is set, clearing volume quota is just set to -1, so that now quota is tracked at bucket level. And now when bucket quota is cleared, when volume quota is set, we disallow the operation.
This will be the behavior of clear space quota, let me know if i am missing something.

@bharatviswa504 Yes. And the problem of clear quota will be fixed in HDDS-4588.

captainzmc · 2020-12-16T11:34:46Z

The default will be -2, all older buckets will have -2, new buckets created after this feature will have -1. So, if some one sets >quota on older buckets in this way, we can figure it out, just an idea saying here.

If we want to disallow the quota support for older buckets, one idea to do at code level.

User using old Ozone version may still has the desire to use the new Quota feature. It's better not shut the door completely.
@adoroszlai , I'm not sure if it's feasible that we provide a option of calculating the bytesInUsed for each bucket during 1.0.0 -> 1.1. upgrade to user? So that user has the choice either tolerate the inaccurate bytesInUsed or a relative longer upgrade time to get accurate bytesInUsed of buckets.

Hi @ChenSammi, I think it's dangerous recalculating usedBytes in upgrade . If the amount of data is too large, it will greatly increase the time, and if the processing is not good, it will cause the upgrade to fail.
If we want use Quota in old buckets, we can add a command to recalculate bucket usedBytes to minimize the impact. User can decide for himself which buckets to recalculate.

bharatviswa504 · 2020-12-16T17:31:18Z

The default will be -2, all older buckets will have -2, new buckets created after this feature will have -1. So, if some one sets >quota on older buckets in this way, we can figure it out, just an idea saying here.

If we want to disallow the quota support for older buckets, one idea to do at code level.

User using old Ozone version may still has the desire to use the new Quota feature. It's better not shut the door completely.
@adoroszlai , I'm not sure if it's feasible that we provide a option of calculating the bytesInUsed for each bucket during 1.0.0 -> 1.1. upgrade to user? So that user has the choice either tolerate the inaccurate bytesInUsed or a relative longer upgrade time to get accurate bytesInUsed of buckets.

@ChenSammi Above idea is to detect older buckets/volumes in the Ozone cluster, from discussion as it is said not recommended, said we can fail the operation But, if we want to support, when they setQuota, we can know this is an old bucket, we can say a warning message to the user, older keys are not considered.

I am fine with whatever way we go, if we clearly document the behavior it will not be confusing to end-users.

bharatviswa504 · 2020-12-16T17:34:47Z

The default will be -2, all older buckets will have -2, new buckets created after this feature will have -1. So, if some one sets >quota on older buckets in this way, we can figure it out, just an idea saying here.

If we want to disallow the quota support for older buckets, one idea to do at code level.

User using old Ozone version may still has the desire to use the new Quota feature. It's better not shut the door completely.
@adoroszlai , I'm not sure if it's feasible that we provide a option of calculating the bytesInUsed for each bucket during 1.0.0 -> 1.1. upgrade to user? So that user has the choice either tolerate the inaccurate bytesInUsed or a relative longer upgrade time to get accurate bytesInUsed of buckets.

Hi @ChenSammi, I think it's dangerous recalculating usedBytes in upgrade . If the amount of data is too large, it will greatly increase the time, and if the processing is not good, it will cause the upgrade to fail.
If we want use Quota in old buckets, we can add a command to recalculate bucket usedBytes to minimize the impact. User can decide for himself which buckets to recalculate.

Yes during upgrade might not be a feasible idea, it will take a long time for an upgrade if there are many buckets/keys in the cluster.

If we want to use Quota in old buckets, we can add a command to recalculate bucket usedBytes to minimize the impact. User can decide for himself which buckets to recalculate.

Even this will be a costly operation, during that operation we should acquire bucket read lock and do the calculation, so all writes will be stalled in the system. (As during this operation, we should not allow new writes to get accurate bytesused).

captainzmc · 2020-12-17T04:45:46Z

Updated PR, set default to -2. No matter whether or not we support old volume/bucket setting quota, we need to distinguish which volumes and buckets are old. So Here I take @bharatviswa504's advice.

linyiqun · 2020-12-17T15:34:46Z

...e-manager/src/main/java/org/apache/hadoop/ozone/om/request/bucket/OMBucketCreateRequest.java

Why we change above condition check? Above check is to confirmed that the quota is enabled, not a validation check. If we want to make sure quota value is a positive value, I prefer to additionally add omVolumeArgs.getQuotaInNamespace() > 0 check.

if (omVolumeArgs.getQuotaInNamespace() != OzoneConsts.QUOTA_RESET && omVolumeArgs.getQuotaInNamespace() > 0) { }

@linyiqun Here with omVolumeArgs.getQuotaInNamespace () > 0 is enough? Because when it > 0 is certainly is not equal to -1.

@captainzmc , here my point is that we should firstly check if the quota was enabled by using one variable flag(here I understand is OzoneConsts.QUOTA_RESET). Then we check the quota value if it's valid. Is there a switch config for the quota now? If the quota is not enabled, we don't need to do the quota check anymore.

For the current value OzoneConsts.QUOTA_RESET is -1, omVolumeArgs.getQuotaInNamespace () > 0 makes the sense. But once OzoneConsts.QUOTA_RESET to a positive value, this check won't work. So omVolumeArgs.getQuotaInNamespace() != OzoneConsts.QUOTA_RESET would still be a better check.

Thanks for @linyiqun's feedback.
Current there are two case -1 or -2 (old volume/bucket) not check quota, actually we have guarantee on the client, user cann’t set negative quota, Therefore, except for clear quota and old quota, there is no negative case.

In addition to using omVolumeArgs.getQuotaInNamespace ()! = OzoneConsts.QUOTA_RESET also need add omvolumeargs.getQuotainNamespace ()! = 2. The judgment condition will increase too much and the code will not be clear enough, we can use omVolumeArgs. getQuotaInNamespace () > 0, this will make the code much cleaner.

Okay, go ahead for this.

bharatviswa504 · 2020-12-18T07:03:15Z

hadoop-ozone/interface-client/src/main/proto/OmClientProtocol.proto

    optional uint64 usedBytes = 14;
-    optional uint64 quotaInBytes = 15;
-    optional uint64 quotaInNamespace = 16;
+    optional int64 quotaInBytes = 15 [default = -2];


#1677 (comment)
Any reason for moving back to int64?

Using sint64, I found that the default value changed to -9223372036854775808. This could be a compatibility issue. So I switched to int64, this is correct.

Interesting, thanks for info.

bharatviswa504

+1 LGTM.

bharatviswa504 · 2020-12-20T07:16:31Z

hadoop-ozone/interface-client/src/main/proto/OmClientProtocol.proto

    optional uint64 usedBytes = 14;
-    optional uint64 quotaInBytes = 15;
-    optional uint64 quotaInNamespace = 16;
+    optional int64 quotaInBytes = 15 [default = -2];


Interesting, thanks for info.

bharatviswa504 · 2020-12-22T19:50:57Z

If no more comments, I will commit this by tomorrow.

bharatviswa504 · 2020-12-23T15:38:28Z

Thank you @captainzmc for the contribution and everyone for the review.

if any one has more comments, we can open a new Jira to fix them.

…graded to the Quota version. (apache#1677) Cherry picked from master to fix acceptance test failure in upgrade test. Merging again from this point would have introduced 52 new conflicts.

(#1822) * HDDS-4587. Merge remote-tracking branch 'upstream/master' into HDDS-3698. * HDDS-4587. Addressing CI failure. * HDDS-4562. Old bucket needs to be accessible after the cluster was upgraded to the Quota version. (#1677) Cherry picked from master to fix acceptance test failure in upgrade test. Merging again from this point would have introduced 52 new conflicts. * HDDS-4770. Upgrade Ratis Thirdparty to 0.6.0 (#1868) Cherry picked from master because 0.6.0-SNAPSHOT is no longer in the repos Co-authored-by: micah zhao <[email protected]> Co-authored-by: Doroszlai, Attila <[email protected]>

captainzmc requested a review from ChenSammi December 9, 2020 03:20

adoroszlai reviewed Dec 11, 2020

View reviewed changes

bharatviswa504 reviewed Dec 11, 2020

View reviewed changes

captainzmc force-pushed the HDDS-4562 branch 2 times, most recently from 7833495 to 265bf1d Compare December 14, 2020 13:06

bharatviswa504 reviewed Dec 14, 2020

View reviewed changes

captainzmc force-pushed the HDDS-4562 branch 4 times, most recently from a38bd49 to 576e3d3 Compare December 15, 2020 07:20

fix bucket quotaInBytes.

bc0ec8b

captainzmc force-pushed the HDDS-4562 branch from 576e3d3 to bc0ec8b Compare December 15, 2020 08:09

linyiqun reviewed Dec 15, 2020

View reviewed changes

bharatviswa504 reviewed Dec 15, 2020

View reviewed changes

captainzmc force-pushed the HDDS-4562 branch from b5c8b92 to 7dce9f7 Compare December 17, 2020 02:37

captainzmc force-pushed the HDDS-4562 branch from 7dce9f7 to c2704f7 Compare December 17, 2020 11:21

linyiqun reviewed Dec 17, 2020

View reviewed changes

captainzmc force-pushed the HDDS-4562 branch from d7ef4e8 to 828f2e3 Compare December 18, 2020 02:17

captainzmc mentioned this pull request Dec 18, 2020

HDDS-4588. If volume's quota is enabled then bucket's quota cannot be cleared #1723

Merged

fix review issues and change default to -2.

554c9a8

captainzmc force-pushed the HDDS-4562 branch from 828f2e3 to 554c9a8 Compare December 18, 2020 06:05

bharatviswa504 reviewed Dec 18, 2020

View reviewed changes

captainzmc mentioned this pull request Dec 18, 2020

HDDS-4277. Support Bucket Namespace Quota Updates #1706

Merged

bharatviswa504 approved these changes Dec 20, 2020

View reviewed changes

bharatviswa504 merged commit 0687cc5 into apache:master Dec 23, 2020


		d. Volume quota is not currently supported separately, and volume quota takes effect only if bucket quota is set. Because ozone only check the usedBytes of the bucket when we write the key.

		e. If the cluster is upgraded from old version less than 1.1.0, use of quota on older volumes and buckets is not recommended. Since the old key is not counted to the bucket's usedBytes, the quota setting is inaccurate at this point.


		a. By default, the quota for volume and bucket is not enabled.

		b. When volume quota is enabled, the total size of bucket quota cannot exceed volume.

HDDS-4562. Old bucket needs to be accessible after the cluster was upgraded to the Quota version. #1677

HDDS-4562. Old bucket needs to be accessible after the cluster was upgraded to the Quota version. #1677

Uh oh!

Conversation

captainzmc commented Dec 9, 2020

What changes were proposed in this pull request?

What is the link to the Apache JIRA

How was this patch tested?

Uh oh!

adoroszlai left a comment

Choose a reason for hiding this comment

Uh oh!

bharatviswa504 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bharatviswa504 commented Dec 11, 2020

Uh oh!

adoroszlai commented Dec 12, 2020

Uh oh!

captainzmc commented Dec 13, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

captainzmc commented Dec 13, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

captainzmc commented Dec 13, 2020

Uh oh!

bharatviswa504 commented Dec 14, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bharatviswa504 commented Dec 14, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

captainzmc commented Dec 15, 2020

Uh oh!

captainzmc commented Dec 15, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

captainzmc commented Dec 15, 2020

Uh oh!

captainzmc commented Dec 15, 2020

Uh oh!

linyiqun left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bharatviswa504 commented Dec 15, 2020

Uh oh!

bharatviswa504 commented Dec 15, 2020

Uh oh!

bharatviswa504 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

amaliujia commented Dec 15, 2020

Uh oh!

amaliujia commented Dec 15, 2020

Uh oh!

ChenSammi commented Dec 16, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bharatviswa504 left a comment •

edited

Loading

captainzmc commented Dec 13, 2020 •

edited

Loading

captainzmc commented Dec 13, 2020 •

edited

Loading

bharatviswa504 commented Dec 14, 2020 •

edited

Loading

bharatviswa504 commented Dec 14, 2020 •

edited

Loading

captainzmc commented Dec 15, 2020 •

edited

Loading

ChenSammi commented Dec 16, 2020 •

edited

Loading

captainzmc commented Dec 16, 2020 •

edited

Loading

captainzmc commented Dec 16, 2020 •

edited

Loading

bharatviswa504 commented Dec 16, 2020 •

edited

Loading

bharatviswa504 commented Dec 16, 2020 •

edited

Loading

linyiqun Dec 17, 2020 •

edited

Loading

linyiqun Dec 18, 2020 •

edited

Loading

captainzmc Dec 18, 2020 •

edited

Loading

captainzmc Dec 18, 2020 •

edited

Loading

bharatviswa504 commented Dec 23, 2020 •

edited

Loading