-
Notifications
You must be signed in to change notification settings - Fork 55
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
feat: Implement GSP-700 Config Features and DefaultPairs via Connection String #699
Conversation
Codecov Report
@@ Coverage Diff @@
## master #699 +/- ##
==========================================
- Coverage 12.35% 12.14% -0.21%
==========================================
Files 22 22
Lines 1441 1490 +49
==========================================
+ Hits 178 181 +3
- Misses 1256 1302 +46
Partials 7 7
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
Please start GSP first before implement this feature, we could reject huge changes without already approved GSP. |
tests/connstr_test.go
Outdated
}, | ||
nil, | ||
}, | ||
//{ |
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 this test?
tests/generated.go
Outdated
@@ -591,8 +681,36 @@ func parsePairStorageNew(opts []Pair) (pairStorageNew, error) { | |||
} | |||
result.HasWorkDir = true | |||
result.WorkDir = v.Value.(string) | |||
// Default pairs | |||
case "default_content_type": | |||
defaultPairs = true |
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.
Maybe we can simplify the logic via respect to the order of pairs?
We don't need to take default_storage_pairs
first any more, instead we always take the order.
- If user input
WithDefaultStoragePairs
andWithDefaultStorageClass
, we will takeWithDefaultStoragePairs
first. - If user input
WithDefaultStorageClass
andWithDefaultStoragePairs
, we will takeWithDefaultStorageClass
.
After this change, we don't need to maintain defaultPairs
or enableFeatures
, we can set HasStorageFeatures
directly.
NOTICE: this change requires an update of GSP.
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.
Does this mean that we do not consider the case where there is no intersection,like:
oss.WithDefaultStorageClass("Standard")
// ...
oss.WithDefaultStoragePairs(oss.DefaultStoragePairs{Write: []types.Pair{ps.WithContentType("application/text")}})
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 can use them concurrently, they will not affect each other.
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.
Maybe we need to keep these two variables defaultPairs
and enableFeatures
as when there is more than one default pairs(DefaultStorageClass
and DefaultContentType
, or EnableVirtualDir
and EnableVirtualLink
), we can't set HasDefault*Pairs
or Has*Features
to true every time, otherwise we would ignore some default values?
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.
DefaultStorageClass
and DefaultContentType
will always be appened into DefaultStorageParis
, I think setting HasDefaultStorageParis
is the same with defaultPairs
.
@@ -103,7 +103,7 @@ func setStorageSystemMetadata(s *StorageMeta, sm StorageSystemMetadata) { | |||
} | |||
|
|||
{{- range $_, $v := .Pairs }} | |||
{{- if not $v.Global }} | |||
{{- if and (not $v.Global) (not (hasPrefix $v.Name "enable_")) }} |
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 removed WithEnableXxx()
for features as we can use <type>.WithStorageFeatures(<type>.StorageFeatures{Xxx: true, })
during initialize. I'm not sure whether it's necessary.
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 it's OK to allow users to enable a feature via WithEableXxx()
.
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.
OK, I'll roll back this change.
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.
For bool types, maybe we can generate WithEnableXxxx()
directly? With the internal value set to true
.
tests/generated.go
Outdated
continue | ||
} | ||
enableFeatures = true | ||
result.HasStorageFeatures = true | ||
result.StorageFeatures.LoosePair = v.Value.(bool) |
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 found the last one will be picked if there are multiple enable_loose_pair
.
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.
How about generating HasEnableLoose
to prevent it?
Maybe treat enable_loose
as a normal pair can prevent those strange edge cases?
if v != "" { | ||
opt = append(opt, v, "true") | ||
} else { | ||
// && , ignore | ||
continue | ||
} |
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.
It's hard-coded here.
How about not generate pairs for enable_xxx
features and register parsing functions for StorageFeatures
and ServiceFeatures
? Then we can collection pairs without values for StorageFeatures
or ServiceFeatures
parsing?
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.
Current implementation LGTM, we will refactor this part later, so don't be worried.
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.
Got it.
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 have some questions and let's discuss in https://matrix.to/#/#beyondstorage@gsp-700:matrix.org
{{- end }} | ||
{{- end }} | ||
{{- if $needPair }} | ||
"github.com/beyondstorage/go-storage/v4/pairs" |
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.
How about always import pairs? Like:
import "github.com/beyondstorage/go-storage/v4/pairs"
var _ pairs.XXXX
@@ -103,7 +103,7 @@ func setStorageSystemMetadata(s *StorageMeta, sm StorageSystemMetadata) { | |||
} | |||
|
|||
{{- range $_, $v := .Pairs }} | |||
{{- if not $v.Global }} | |||
{{- if and (not $v.Global) (not (hasPrefix $v.Name "enable_")) }} |
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.
For bool types, maybe we can generate WithEnableXxxx()
directly? With the internal value set to true
.
The PR is too big, I updated steps in #704, let's split it into PRs. |
Maybe we can close this PR for now? |
ref: #680
ref: #704