2023-07-06 13:35:26 +01:00
|
|
|
// Copyright (C) 2023 Storj Labs, Inc.
|
|
|
|
// See LICENSE for copying information.
|
|
|
|
|
|
|
|
package overlay
|
|
|
|
|
|
|
|
import (
|
2023-08-23 15:02:58 +01:00
|
|
|
"fmt"
|
2023-07-06 13:35:26 +01:00
|
|
|
"testing"
|
|
|
|
|
2023-08-16 09:36:05 +01:00
|
|
|
"github.com/stretchr/testify/assert"
|
2023-07-06 13:35:26 +01:00
|
|
|
"github.com/stretchr/testify/require"
|
|
|
|
|
|
|
|
"storj.io/common/storj"
|
|
|
|
"storj.io/common/storj/location"
|
|
|
|
"storj.io/storj/satellite/nodeselection"
|
|
|
|
)
|
|
|
|
|
|
|
|
func TestPlacementFromString(t *testing.T) {
|
|
|
|
signer, err := storj.NodeIDFromString("12whfK1EDvHJtajBiAUeajQLYcWqxcQmdYQU5zX5cCf6bAxfgu4")
|
|
|
|
require.NoError(t, err)
|
|
|
|
|
2023-07-10 16:01:48 +01:00
|
|
|
t.Run("invalid country-code", func(t *testing.T) {
|
satellite/overlay: fix placement selection config parsing
When we do `satellite run api --placement '...'`, the placement rules are not parsed well.
The problem is based on `viper.AllSettings()`, and the main logic is sg. like this (from a new unit test):
```
r := ConfigurablePlacementRule{}
err := r.Set(p)
require.NoError(t, err)
serialized := r.String()
r2 := ConfigurablePlacementRule{}
err = r2.Set(serialized)
require.NoError(t, err)
require.Equal(t, p, r2.String())
```
All settings evaluates the placement rules in `ConfigurablePlacementRules` and stores the string representation.
The problem is that we don't have proper `String()` implementation (it prints out the structs instead of the original definition.
There are two main solutions for this problem:
1. We can fix the `String()`. When we parse a placement rule, the `String()` method should print out the original definition
2. We can switch to use pure string as configuration parameter, and parse the rules only when required.
I feel that 1 is error prone, we can do it (and in this patch I added a lot of `String()` implementations, but it's hard to be sure that our `String()` logic is inline with the parsing logic.
Therefore I decided to make the configuration value of the placements a string (or a wrapper around string).
That's the main reason why this patch seems to be big, as I updated all the usages.
But the main part is in beginning of the `placement.go` (configuration parsing is not a pflag.Value implementation any more, but a separated step).
And `filter.go`, (a few more String implementation for filters.
https://github.com/storj/storj/issues/6248
Change-Id: I47c762d3514342b76a2e85683b1c891502a0756a
2023-09-06 10:40:22 +01:00
|
|
|
p := NewPlacementDefinitions()
|
2023-07-10 16:01:48 +01:00
|
|
|
err := p.AddPlacementFromString(`1:country("ZZZZ")`)
|
|
|
|
require.Error(t, err)
|
|
|
|
})
|
|
|
|
|
2023-08-16 09:36:05 +01:00
|
|
|
t.Run("country tests", func(t *testing.T) {
|
|
|
|
countryTest := func(placementDef string, shouldBeIncluded []location.CountryCode, shouldBeExcluded []location.CountryCode) {
|
satellite/overlay: fix placement selection config parsing
When we do `satellite run api --placement '...'`, the placement rules are not parsed well.
The problem is based on `viper.AllSettings()`, and the main logic is sg. like this (from a new unit test):
```
r := ConfigurablePlacementRule{}
err := r.Set(p)
require.NoError(t, err)
serialized := r.String()
r2 := ConfigurablePlacementRule{}
err = r2.Set(serialized)
require.NoError(t, err)
require.Equal(t, p, r2.String())
```
All settings evaluates the placement rules in `ConfigurablePlacementRules` and stores the string representation.
The problem is that we don't have proper `String()` implementation (it prints out the structs instead of the original definition.
There are two main solutions for this problem:
1. We can fix the `String()`. When we parse a placement rule, the `String()` method should print out the original definition
2. We can switch to use pure string as configuration parameter, and parse the rules only when required.
I feel that 1 is error prone, we can do it (and in this patch I added a lot of `String()` implementations, but it's hard to be sure that our `String()` logic is inline with the parsing logic.
Therefore I decided to make the configuration value of the placements a string (or a wrapper around string).
That's the main reason why this patch seems to be big, as I updated all the usages.
But the main part is in beginning of the `placement.go` (configuration parsing is not a pflag.Value implementation any more, but a separated step).
And `filter.go`, (a few more String implementation for filters.
https://github.com/storj/storj/issues/6248
Change-Id: I47c762d3514342b76a2e85683b1c891502a0756a
2023-09-06 10:40:22 +01:00
|
|
|
p := NewPlacementDefinitions()
|
2023-08-16 09:36:05 +01:00
|
|
|
err := p.AddPlacementFromString("11:" + placementDef)
|
|
|
|
require.NoError(t, err)
|
|
|
|
filters := p.placements[storj.PlacementConstraint(11)]
|
|
|
|
require.NotNil(t, filters)
|
|
|
|
for _, code := range shouldBeExcluded {
|
2023-08-28 08:42:08 +01:00
|
|
|
require.False(t, filters.Match(&nodeselection.SelectedNode{
|
2023-08-16 09:36:05 +01:00
|
|
|
CountryCode: code,
|
|
|
|
}), "%s shouldn't be included in placement %s", code, placementDef)
|
|
|
|
}
|
|
|
|
for _, code := range shouldBeIncluded {
|
2023-08-28 08:42:08 +01:00
|
|
|
require.True(t, filters.Match(&nodeselection.SelectedNode{
|
2023-08-16 09:36:05 +01:00
|
|
|
CountryCode: code,
|
|
|
|
}), "%s is not included in placement %s", code, placementDef)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
countryTest(`country("GB")`, []location.CountryCode{location.UnitedKingdom}, []location.CountryCode{location.Germany, location.UnitedStates})
|
|
|
|
countryTest(`country("EU")`, []location.CountryCode{location.Germany, location.Hungary}, []location.CountryCode{location.UnitedStates, location.Norway, location.Iceland})
|
|
|
|
countryTest(`country("EEA")`, []location.CountryCode{location.Germany, location.Hungary, location.Norway, location.Iceland}, []location.CountryCode{location.UnitedStates})
|
|
|
|
countryTest(`country("ALL","!EU")`, []location.CountryCode{location.Norway, location.India}, []location.CountryCode{location.Germany, location.Hungary})
|
|
|
|
countryTest(`country("ALL", "!RU", "!BY")`, []location.CountryCode{location.Norway, location.India, location.UnitedStates}, []location.CountryCode{location.Russia, location.Belarus})
|
|
|
|
|
2023-07-06 13:35:26 +01:00
|
|
|
})
|
|
|
|
|
|
|
|
t.Run("tag rule", func(t *testing.T) {
|
2023-09-14 17:42:59 +01:00
|
|
|
tagged := func(key string, value string) nodeselection.NodeTags {
|
satellite/overlay: fix placement selection config parsing
When we do `satellite run api --placement '...'`, the placement rules are not parsed well.
The problem is based on `viper.AllSettings()`, and the main logic is sg. like this (from a new unit test):
```
r := ConfigurablePlacementRule{}
err := r.Set(p)
require.NoError(t, err)
serialized := r.String()
r2 := ConfigurablePlacementRule{}
err = r2.Set(serialized)
require.NoError(t, err)
require.Equal(t, p, r2.String())
```
All settings evaluates the placement rules in `ConfigurablePlacementRules` and stores the string representation.
The problem is that we don't have proper `String()` implementation (it prints out the structs instead of the original definition.
There are two main solutions for this problem:
1. We can fix the `String()`. When we parse a placement rule, the `String()` method should print out the original definition
2. We can switch to use pure string as configuration parameter, and parse the rules only when required.
I feel that 1 is error prone, we can do it (and in this patch I added a lot of `String()` implementations, but it's hard to be sure that our `String()` logic is inline with the parsing logic.
Therefore I decided to make the configuration value of the placements a string (or a wrapper around string).
That's the main reason why this patch seems to be big, as I updated all the usages.
But the main part is in beginning of the `placement.go` (configuration parsing is not a pflag.Value implementation any more, but a separated step).
And `filter.go`, (a few more String implementation for filters.
https://github.com/storj/storj/issues/6248
Change-Id: I47c762d3514342b76a2e85683b1c891502a0756a
2023-09-06 10:40:22 +01:00
|
|
|
return nodeselection.NodeTags{{
|
|
|
|
Signer: signer,
|
|
|
|
Name: key,
|
|
|
|
Value: []byte(value),
|
|
|
|
},
|
2023-09-14 17:42:59 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
satellite/overlay: fix placement selection config parsing
When we do `satellite run api --placement '...'`, the placement rules are not parsed well.
The problem is based on `viper.AllSettings()`, and the main logic is sg. like this (from a new unit test):
```
r := ConfigurablePlacementRule{}
err := r.Set(p)
require.NoError(t, err)
serialized := r.String()
r2 := ConfigurablePlacementRule{}
err = r2.Set(serialized)
require.NoError(t, err)
require.Equal(t, p, r2.String())
```
All settings evaluates the placement rules in `ConfigurablePlacementRules` and stores the string representation.
The problem is that we don't have proper `String()` implementation (it prints out the structs instead of the original definition.
There are two main solutions for this problem:
1. We can fix the `String()`. When we parse a placement rule, the `String()` method should print out the original definition
2. We can switch to use pure string as configuration parameter, and parse the rules only when required.
I feel that 1 is error prone, we can do it (and in this patch I added a lot of `String()` implementations, but it's hard to be sure that our `String()` logic is inline with the parsing logic.
Therefore I decided to make the configuration value of the placements a string (or a wrapper around string).
That's the main reason why this patch seems to be big, as I updated all the usages.
But the main part is in beginning of the `placement.go` (configuration parsing is not a pflag.Value implementation any more, but a separated step).
And `filter.go`, (a few more String implementation for filters.
https://github.com/storj/storj/issues/6248
Change-Id: I47c762d3514342b76a2e85683b1c891502a0756a
2023-09-06 10:40:22 +01:00
|
|
|
p := NewPlacementDefinitions()
|
|
|
|
err := p.AddPlacementFromString(`11:tag("12whfK1EDvHJtajBiAUeajQLYcWqxcQmdYQU5zX5cCf6bAxfgu4","foo","bar")`)
|
|
|
|
require.NoError(t, err)
|
|
|
|
filters := p.placements[storj.PlacementConstraint(11)]
|
|
|
|
require.NotNil(t, filters)
|
|
|
|
require.True(t, filters.Match(&nodeselection.SelectedNode{
|
|
|
|
Tags: tagged("foo", "bar"),
|
|
|
|
}))
|
|
|
|
|
2023-09-14 17:42:59 +01:00
|
|
|
testCases := []struct {
|
|
|
|
name string
|
|
|
|
placement string
|
|
|
|
includedNodes []*nodeselection.SelectedNode
|
|
|
|
excludedNodes []*nodeselection.SelectedNode
|
|
|
|
}{
|
|
|
|
{
|
|
|
|
name: "simple tag",
|
|
|
|
placement: `11:tag("12whfK1EDvHJtajBiAUeajQLYcWqxcQmdYQU5zX5cCf6bAxfgu4","foo","bar")`,
|
|
|
|
includedNodes: []*nodeselection.SelectedNode{
|
|
|
|
{
|
|
|
|
Tags: tagged("foo", "bar"),
|
|
|
|
},
|
|
|
|
},
|
|
|
|
excludedNodes: []*nodeselection.SelectedNode{
|
|
|
|
{
|
|
|
|
CountryCode: location.Germany,
|
|
|
|
},
|
2023-07-06 13:35:26 +01:00
|
|
|
},
|
|
|
|
},
|
2023-09-14 17:42:59 +01:00
|
|
|
{
|
|
|
|
name: "tag not empty",
|
|
|
|
placement: `11:tag("12whfK1EDvHJtajBiAUeajQLYcWqxcQmdYQU5zX5cCf6bAxfgu4","foo",notEmpty())`,
|
|
|
|
includedNodes: []*nodeselection.SelectedNode{
|
|
|
|
{
|
|
|
|
Tags: tagged("foo", "barx"),
|
|
|
|
},
|
|
|
|
{
|
|
|
|
Tags: tagged("foo", "bar"),
|
|
|
|
},
|
|
|
|
},
|
|
|
|
excludedNodes: []*nodeselection.SelectedNode{
|
|
|
|
{
|
|
|
|
Tags: tagged("foo", ""),
|
|
|
|
},
|
|
|
|
{
|
|
|
|
CountryCode: location.Germany,
|
|
|
|
},
|
|
|
|
},
|
|
|
|
},
|
|
|
|
{
|
|
|
|
name: "tag empty",
|
|
|
|
placement: `11:tag("12whfK1EDvHJtajBiAUeajQLYcWqxcQmdYQU5zX5cCf6bAxfgu4","foo",empty())`,
|
|
|
|
includedNodes: []*nodeselection.SelectedNode{
|
|
|
|
{
|
|
|
|
Tags: tagged("foo", ""),
|
|
|
|
},
|
|
|
|
},
|
|
|
|
excludedNodes: []*nodeselection.SelectedNode{
|
|
|
|
{
|
|
|
|
Tags: tagged("foo", "bar"),
|
|
|
|
},
|
|
|
|
{
|
|
|
|
CountryCode: location.Germany,
|
|
|
|
},
|
|
|
|
},
|
|
|
|
},
|
|
|
|
}
|
|
|
|
for _, tc := range testCases {
|
|
|
|
t.Run(tc.name, func(t *testing.T) {
|
satellite/overlay: fix placement selection config parsing
When we do `satellite run api --placement '...'`, the placement rules are not parsed well.
The problem is based on `viper.AllSettings()`, and the main logic is sg. like this (from a new unit test):
```
r := ConfigurablePlacementRule{}
err := r.Set(p)
require.NoError(t, err)
serialized := r.String()
r2 := ConfigurablePlacementRule{}
err = r2.Set(serialized)
require.NoError(t, err)
require.Equal(t, p, r2.String())
```
All settings evaluates the placement rules in `ConfigurablePlacementRules` and stores the string representation.
The problem is that we don't have proper `String()` implementation (it prints out the structs instead of the original definition.
There are two main solutions for this problem:
1. We can fix the `String()`. When we parse a placement rule, the `String()` method should print out the original definition
2. We can switch to use pure string as configuration parameter, and parse the rules only when required.
I feel that 1 is error prone, we can do it (and in this patch I added a lot of `String()` implementations, but it's hard to be sure that our `String()` logic is inline with the parsing logic.
Therefore I decided to make the configuration value of the placements a string (or a wrapper around string).
That's the main reason why this patch seems to be big, as I updated all the usages.
But the main part is in beginning of the `placement.go` (configuration parsing is not a pflag.Value implementation any more, but a separated step).
And `filter.go`, (a few more String implementation for filters.
https://github.com/storj/storj/issues/6248
Change-Id: I47c762d3514342b76a2e85683b1c891502a0756a
2023-09-06 10:40:22 +01:00
|
|
|
p := NewPlacementDefinitions()
|
2023-09-14 17:42:59 +01:00
|
|
|
err := p.AddPlacementFromString(tc.placement)
|
|
|
|
require.NoError(t, err)
|
|
|
|
filters := p.placements[storj.PlacementConstraint(11)]
|
|
|
|
require.NotNil(t, filters)
|
|
|
|
for _, i := range tc.includedNodes {
|
|
|
|
require.True(t, filters.Match(i), "%v should be included", i)
|
|
|
|
}
|
|
|
|
for _, e := range tc.excludedNodes {
|
|
|
|
require.False(t, filters.Match(e), "%v should be excluded", e)
|
|
|
|
}
|
|
|
|
})
|
|
|
|
}
|
2023-07-06 13:35:26 +01:00
|
|
|
})
|
|
|
|
|
2023-08-16 09:36:05 +01:00
|
|
|
t.Run("placement reuse", func(t *testing.T) {
|
satellite/overlay: fix placement selection config parsing
When we do `satellite run api --placement '...'`, the placement rules are not parsed well.
The problem is based on `viper.AllSettings()`, and the main logic is sg. like this (from a new unit test):
```
r := ConfigurablePlacementRule{}
err := r.Set(p)
require.NoError(t, err)
serialized := r.String()
r2 := ConfigurablePlacementRule{}
err = r2.Set(serialized)
require.NoError(t, err)
require.Equal(t, p, r2.String())
```
All settings evaluates the placement rules in `ConfigurablePlacementRules` and stores the string representation.
The problem is that we don't have proper `String()` implementation (it prints out the structs instead of the original definition.
There are two main solutions for this problem:
1. We can fix the `String()`. When we parse a placement rule, the `String()` method should print out the original definition
2. We can switch to use pure string as configuration parameter, and parse the rules only when required.
I feel that 1 is error prone, we can do it (and in this patch I added a lot of `String()` implementations, but it's hard to be sure that our `String()` logic is inline with the parsing logic.
Therefore I decided to make the configuration value of the placements a string (or a wrapper around string).
That's the main reason why this patch seems to be big, as I updated all the usages.
But the main part is in beginning of the `placement.go` (configuration parsing is not a pflag.Value implementation any more, but a separated step).
And `filter.go`, (a few more String implementation for filters.
https://github.com/storj/storj/issues/6248
Change-Id: I47c762d3514342b76a2e85683b1c891502a0756a
2023-09-06 10:40:22 +01:00
|
|
|
p := NewPlacementDefinitions()
|
2023-08-16 09:36:05 +01:00
|
|
|
err := p.AddPlacementFromString(`1:tag("12whfK1EDvHJtajBiAUeajQLYcWqxcQmdYQU5zX5cCf6bAxfgu4","foo","bar");2:exclude(placement(1))`)
|
2023-07-06 13:35:26 +01:00
|
|
|
require.NoError(t, err)
|
2023-08-16 09:36:05 +01:00
|
|
|
|
2023-08-28 08:42:08 +01:00
|
|
|
require.True(t, p.placements[storj.PlacementConstraint(1)].Match(&nodeselection.SelectedNode{
|
2023-07-06 13:35:26 +01:00
|
|
|
Tags: nodeselection.NodeTags{
|
|
|
|
{
|
|
|
|
Signer: signer,
|
|
|
|
Name: "foo",
|
|
|
|
Value: []byte("bar"),
|
|
|
|
},
|
|
|
|
},
|
|
|
|
}))
|
2023-08-16 09:36:05 +01:00
|
|
|
|
|
|
|
placement2 := p.placements[storj.PlacementConstraint(2)]
|
2023-08-28 08:42:08 +01:00
|
|
|
require.False(t, placement2.Match(&nodeselection.SelectedNode{
|
2023-07-06 13:35:26 +01:00
|
|
|
Tags: nodeselection.NodeTags{
|
|
|
|
{
|
|
|
|
Signer: signer,
|
|
|
|
Name: "foo",
|
|
|
|
Value: []byte("bar"),
|
|
|
|
},
|
|
|
|
},
|
|
|
|
}))
|
2023-08-28 08:42:08 +01:00
|
|
|
require.True(t, placement2.Match(&nodeselection.SelectedNode{
|
2023-08-16 09:36:05 +01:00
|
|
|
CountryCode: location.Germany,
|
|
|
|
}))
|
|
|
|
|
|
|
|
})
|
|
|
|
|
|
|
|
t.Run("all rules", func(t *testing.T) {
|
|
|
|
for _, syntax := range []string{
|
|
|
|
`11:all(country("GB"),tag("12whfK1EDvHJtajBiAUeajQLYcWqxcQmdYQU5zX5cCf6bAxfgu4","foo","bar"))`,
|
|
|
|
`11:country("GB") && tag("12whfK1EDvHJtajBiAUeajQLYcWqxcQmdYQU5zX5cCf6bAxfgu4","foo","bar")`,
|
|
|
|
} {
|
satellite/overlay: fix placement selection config parsing
When we do `satellite run api --placement '...'`, the placement rules are not parsed well.
The problem is based on `viper.AllSettings()`, and the main logic is sg. like this (from a new unit test):
```
r := ConfigurablePlacementRule{}
err := r.Set(p)
require.NoError(t, err)
serialized := r.String()
r2 := ConfigurablePlacementRule{}
err = r2.Set(serialized)
require.NoError(t, err)
require.Equal(t, p, r2.String())
```
All settings evaluates the placement rules in `ConfigurablePlacementRules` and stores the string representation.
The problem is that we don't have proper `String()` implementation (it prints out the structs instead of the original definition.
There are two main solutions for this problem:
1. We can fix the `String()`. When we parse a placement rule, the `String()` method should print out the original definition
2. We can switch to use pure string as configuration parameter, and parse the rules only when required.
I feel that 1 is error prone, we can do it (and in this patch I added a lot of `String()` implementations, but it's hard to be sure that our `String()` logic is inline with the parsing logic.
Therefore I decided to make the configuration value of the placements a string (or a wrapper around string).
That's the main reason why this patch seems to be big, as I updated all the usages.
But the main part is in beginning of the `placement.go` (configuration parsing is not a pflag.Value implementation any more, but a separated step).
And `filter.go`, (a few more String implementation for filters.
https://github.com/storj/storj/issues/6248
Change-Id: I47c762d3514342b76a2e85683b1c891502a0756a
2023-09-06 10:40:22 +01:00
|
|
|
p := NewPlacementDefinitions()
|
2023-08-16 09:36:05 +01:00
|
|
|
err := p.AddPlacementFromString(syntax)
|
|
|
|
require.NoError(t, err)
|
|
|
|
filters := p.placements[storj.PlacementConstraint(11)]
|
|
|
|
require.NotNil(t, filters)
|
2023-08-28 08:42:08 +01:00
|
|
|
require.True(t, filters.Match(&nodeselection.SelectedNode{
|
2023-08-16 09:36:05 +01:00
|
|
|
CountryCode: location.UnitedKingdom,
|
|
|
|
Tags: nodeselection.NodeTags{
|
|
|
|
{
|
|
|
|
Signer: signer,
|
|
|
|
Name: "foo",
|
|
|
|
Value: []byte("bar"),
|
|
|
|
},
|
|
|
|
},
|
|
|
|
}))
|
2023-08-28 08:42:08 +01:00
|
|
|
require.False(t, filters.Match(&nodeselection.SelectedNode{
|
2023-08-16 09:36:05 +01:00
|
|
|
CountryCode: location.UnitedKingdom,
|
|
|
|
}))
|
2023-08-28 08:42:08 +01:00
|
|
|
require.False(t, filters.Match(&nodeselection.SelectedNode{
|
2023-08-16 09:36:05 +01:00
|
|
|
CountryCode: location.Germany,
|
|
|
|
Tags: nodeselection.NodeTags{
|
|
|
|
{
|
|
|
|
Signer: signer,
|
|
|
|
Name: "foo",
|
|
|
|
Value: []byte("bar"),
|
|
|
|
},
|
|
|
|
},
|
|
|
|
}))
|
|
|
|
}
|
|
|
|
t.Run("invalid", func(t *testing.T) {
|
satellite/overlay: fix placement selection config parsing
When we do `satellite run api --placement '...'`, the placement rules are not parsed well.
The problem is based on `viper.AllSettings()`, and the main logic is sg. like this (from a new unit test):
```
r := ConfigurablePlacementRule{}
err := r.Set(p)
require.NoError(t, err)
serialized := r.String()
r2 := ConfigurablePlacementRule{}
err = r2.Set(serialized)
require.NoError(t, err)
require.Equal(t, p, r2.String())
```
All settings evaluates the placement rules in `ConfigurablePlacementRules` and stores the string representation.
The problem is that we don't have proper `String()` implementation (it prints out the structs instead of the original definition.
There are two main solutions for this problem:
1. We can fix the `String()`. When we parse a placement rule, the `String()` method should print out the original definition
2. We can switch to use pure string as configuration parameter, and parse the rules only when required.
I feel that 1 is error prone, we can do it (and in this patch I added a lot of `String()` implementations, but it's hard to be sure that our `String()` logic is inline with the parsing logic.
Therefore I decided to make the configuration value of the placements a string (or a wrapper around string).
That's the main reason why this patch seems to be big, as I updated all the usages.
But the main part is in beginning of the `placement.go` (configuration parsing is not a pflag.Value implementation any more, but a separated step).
And `filter.go`, (a few more String implementation for filters.
https://github.com/storj/storj/issues/6248
Change-Id: I47c762d3514342b76a2e85683b1c891502a0756a
2023-09-06 10:40:22 +01:00
|
|
|
p := NewPlacementDefinitions()
|
2023-08-16 09:36:05 +01:00
|
|
|
err := p.AddPlacementFromString("10:1 && 2")
|
|
|
|
require.Error(t, err)
|
|
|
|
})
|
2023-07-06 13:35:26 +01:00
|
|
|
})
|
|
|
|
|
|
|
|
t.Run("multi rule", func(t *testing.T) {
|
satellite/overlay: fix placement selection config parsing
When we do `satellite run api --placement '...'`, the placement rules are not parsed well.
The problem is based on `viper.AllSettings()`, and the main logic is sg. like this (from a new unit test):
```
r := ConfigurablePlacementRule{}
err := r.Set(p)
require.NoError(t, err)
serialized := r.String()
r2 := ConfigurablePlacementRule{}
err = r2.Set(serialized)
require.NoError(t, err)
require.Equal(t, p, r2.String())
```
All settings evaluates the placement rules in `ConfigurablePlacementRules` and stores the string representation.
The problem is that we don't have proper `String()` implementation (it prints out the structs instead of the original definition.
There are two main solutions for this problem:
1. We can fix the `String()`. When we parse a placement rule, the `String()` method should print out the original definition
2. We can switch to use pure string as configuration parameter, and parse the rules only when required.
I feel that 1 is error prone, we can do it (and in this patch I added a lot of `String()` implementations, but it's hard to be sure that our `String()` logic is inline with the parsing logic.
Therefore I decided to make the configuration value of the placements a string (or a wrapper around string).
That's the main reason why this patch seems to be big, as I updated all the usages.
But the main part is in beginning of the `placement.go` (configuration parsing is not a pflag.Value implementation any more, but a separated step).
And `filter.go`, (a few more String implementation for filters.
https://github.com/storj/storj/issues/6248
Change-Id: I47c762d3514342b76a2e85683b1c891502a0756a
2023-09-06 10:40:22 +01:00
|
|
|
p := NewPlacementDefinitions()
|
2023-07-06 13:35:26 +01:00
|
|
|
err := p.AddPlacementFromString(`11:country("GB");12:country("DE")`)
|
|
|
|
require.NoError(t, err)
|
|
|
|
|
|
|
|
filters := p.placements[storj.PlacementConstraint(11)]
|
|
|
|
require.NotNil(t, filters)
|
2023-08-28 08:42:08 +01:00
|
|
|
require.True(t, filters.Match(&nodeselection.SelectedNode{
|
2023-07-06 13:35:26 +01:00
|
|
|
CountryCode: location.UnitedKingdom,
|
|
|
|
}))
|
2023-08-28 08:42:08 +01:00
|
|
|
require.False(t, filters.Match(&nodeselection.SelectedNode{
|
2023-07-06 13:35:26 +01:00
|
|
|
CountryCode: location.Germany,
|
|
|
|
}))
|
satellite/overlay: fix placement selection config parsing
When we do `satellite run api --placement '...'`, the placement rules are not parsed well.
The problem is based on `viper.AllSettings()`, and the main logic is sg. like this (from a new unit test):
```
r := ConfigurablePlacementRule{}
err := r.Set(p)
require.NoError(t, err)
serialized := r.String()
r2 := ConfigurablePlacementRule{}
err = r2.Set(serialized)
require.NoError(t, err)
require.Equal(t, p, r2.String())
```
All settings evaluates the placement rules in `ConfigurablePlacementRules` and stores the string representation.
The problem is that we don't have proper `String()` implementation (it prints out the structs instead of the original definition.
There are two main solutions for this problem:
1. We can fix the `String()`. When we parse a placement rule, the `String()` method should print out the original definition
2. We can switch to use pure string as configuration parameter, and parse the rules only when required.
I feel that 1 is error prone, we can do it (and in this patch I added a lot of `String()` implementations, but it's hard to be sure that our `String()` logic is inline with the parsing logic.
Therefore I decided to make the configuration value of the placements a string (or a wrapper around string).
That's the main reason why this patch seems to be big, as I updated all the usages.
But the main part is in beginning of the `placement.go` (configuration parsing is not a pflag.Value implementation any more, but a separated step).
And `filter.go`, (a few more String implementation for filters.
https://github.com/storj/storj/issues/6248
Change-Id: I47c762d3514342b76a2e85683b1c891502a0756a
2023-09-06 10:40:22 +01:00
|
|
|
require.Equal(t, `country("GB")`, fmt.Sprintf("%s", filters))
|
2023-07-06 13:35:26 +01:00
|
|
|
|
|
|
|
filters = p.placements[storj.PlacementConstraint(12)]
|
|
|
|
require.NotNil(t, filters)
|
2023-08-28 08:42:08 +01:00
|
|
|
require.False(t, filters.Match(&nodeselection.SelectedNode{
|
2023-07-06 13:35:26 +01:00
|
|
|
CountryCode: location.UnitedKingdom,
|
|
|
|
}))
|
2023-08-28 08:42:08 +01:00
|
|
|
require.True(t, filters.Match(&nodeselection.SelectedNode{
|
2023-07-06 13:35:26 +01:00
|
|
|
CountryCode: location.Germany,
|
|
|
|
}))
|
|
|
|
|
2023-08-01 12:50:22 +01:00
|
|
|
})
|
2023-08-23 15:02:58 +01:00
|
|
|
|
2023-08-23 14:47:49 +01:00
|
|
|
t.Run("annotation usage", func(t *testing.T) {
|
|
|
|
t.Run("normal", func(t *testing.T) {
|
|
|
|
t.Parallel()
|
satellite/overlay: fix placement selection config parsing
When we do `satellite run api --placement '...'`, the placement rules are not parsed well.
The problem is based on `viper.AllSettings()`, and the main logic is sg. like this (from a new unit test):
```
r := ConfigurablePlacementRule{}
err := r.Set(p)
require.NoError(t, err)
serialized := r.String()
r2 := ConfigurablePlacementRule{}
err = r2.Set(serialized)
require.NoError(t, err)
require.Equal(t, p, r2.String())
```
All settings evaluates the placement rules in `ConfigurablePlacementRules` and stores the string representation.
The problem is that we don't have proper `String()` implementation (it prints out the structs instead of the original definition.
There are two main solutions for this problem:
1. We can fix the `String()`. When we parse a placement rule, the `String()` method should print out the original definition
2. We can switch to use pure string as configuration parameter, and parse the rules only when required.
I feel that 1 is error prone, we can do it (and in this patch I added a lot of `String()` implementations, but it's hard to be sure that our `String()` logic is inline with the parsing logic.
Therefore I decided to make the configuration value of the placements a string (or a wrapper around string).
That's the main reason why this patch seems to be big, as I updated all the usages.
But the main part is in beginning of the `placement.go` (configuration parsing is not a pflag.Value implementation any more, but a separated step).
And `filter.go`, (a few more String implementation for filters.
https://github.com/storj/storj/issues/6248
Change-Id: I47c762d3514342b76a2e85683b1c891502a0756a
2023-09-06 10:40:22 +01:00
|
|
|
p := NewPlacementDefinitions()
|
2023-08-23 14:47:49 +01:00
|
|
|
err := p.AddPlacementFromString(`11:annotated(country("GB"),annotation("autoExcludeSubnet","off"))`)
|
|
|
|
require.NoError(t, err)
|
|
|
|
filters := p.placements[storj.PlacementConstraint(11)]
|
2023-08-28 08:42:08 +01:00
|
|
|
require.True(t, filters.Match(&nodeselection.SelectedNode{
|
2023-08-23 14:47:49 +01:00
|
|
|
CountryCode: location.UnitedKingdom,
|
|
|
|
}))
|
2023-08-01 12:50:22 +01:00
|
|
|
|
2023-08-23 14:47:49 +01:00
|
|
|
require.Equal(t, nodeselection.GetAnnotation(filters, "autoExcludeSubnet"), "off")
|
|
|
|
})
|
|
|
|
t.Run("with &&", func(t *testing.T) {
|
|
|
|
t.Parallel()
|
satellite/overlay: fix placement selection config parsing
When we do `satellite run api --placement '...'`, the placement rules are not parsed well.
The problem is based on `viper.AllSettings()`, and the main logic is sg. like this (from a new unit test):
```
r := ConfigurablePlacementRule{}
err := r.Set(p)
require.NoError(t, err)
serialized := r.String()
r2 := ConfigurablePlacementRule{}
err = r2.Set(serialized)
require.NoError(t, err)
require.Equal(t, p, r2.String())
```
All settings evaluates the placement rules in `ConfigurablePlacementRules` and stores the string representation.
The problem is that we don't have proper `String()` implementation (it prints out the structs instead of the original definition.
There are two main solutions for this problem:
1. We can fix the `String()`. When we parse a placement rule, the `String()` method should print out the original definition
2. We can switch to use pure string as configuration parameter, and parse the rules only when required.
I feel that 1 is error prone, we can do it (and in this patch I added a lot of `String()` implementations, but it's hard to be sure that our `String()` logic is inline with the parsing logic.
Therefore I decided to make the configuration value of the placements a string (or a wrapper around string).
That's the main reason why this patch seems to be big, as I updated all the usages.
But the main part is in beginning of the `placement.go` (configuration parsing is not a pflag.Value implementation any more, but a separated step).
And `filter.go`, (a few more String implementation for filters.
https://github.com/storj/storj/issues/6248
Change-Id: I47c762d3514342b76a2e85683b1c891502a0756a
2023-09-06 10:40:22 +01:00
|
|
|
p := NewPlacementDefinitions()
|
2023-08-23 14:47:49 +01:00
|
|
|
err := p.AddPlacementFromString(`11:country("GB") && annotation("foo","bar") && annotation("bar","foo")`)
|
|
|
|
require.NoError(t, err)
|
|
|
|
|
|
|
|
filters := p.placements[storj.PlacementConstraint(11)]
|
2023-08-28 08:42:08 +01:00
|
|
|
require.True(t, filters.Match(&nodeselection.SelectedNode{
|
2023-08-23 14:47:49 +01:00
|
|
|
CountryCode: location.UnitedKingdom,
|
|
|
|
}))
|
|
|
|
require.Equal(t, "bar", nodeselection.GetAnnotation(filters, "foo"))
|
|
|
|
require.Equal(t, "foo", nodeselection.GetAnnotation(filters, "bar"))
|
|
|
|
require.Equal(t, "", nodeselection.GetAnnotation(filters, "kossuth"))
|
|
|
|
})
|
|
|
|
t.Run("chained", func(t *testing.T) {
|
|
|
|
t.Parallel()
|
satellite/overlay: fix placement selection config parsing
When we do `satellite run api --placement '...'`, the placement rules are not parsed well.
The problem is based on `viper.AllSettings()`, and the main logic is sg. like this (from a new unit test):
```
r := ConfigurablePlacementRule{}
err := r.Set(p)
require.NoError(t, err)
serialized := r.String()
r2 := ConfigurablePlacementRule{}
err = r2.Set(serialized)
require.NoError(t, err)
require.Equal(t, p, r2.String())
```
All settings evaluates the placement rules in `ConfigurablePlacementRules` and stores the string representation.
The problem is that we don't have proper `String()` implementation (it prints out the structs instead of the original definition.
There are two main solutions for this problem:
1. We can fix the `String()`. When we parse a placement rule, the `String()` method should print out the original definition
2. We can switch to use pure string as configuration parameter, and parse the rules only when required.
I feel that 1 is error prone, we can do it (and in this patch I added a lot of `String()` implementations, but it's hard to be sure that our `String()` logic is inline with the parsing logic.
Therefore I decided to make the configuration value of the placements a string (or a wrapper around string).
That's the main reason why this patch seems to be big, as I updated all the usages.
But the main part is in beginning of the `placement.go` (configuration parsing is not a pflag.Value implementation any more, but a separated step).
And `filter.go`, (a few more String implementation for filters.
https://github.com/storj/storj/issues/6248
Change-Id: I47c762d3514342b76a2e85683b1c891502a0756a
2023-09-06 10:40:22 +01:00
|
|
|
p := NewPlacementDefinitions()
|
2023-08-23 14:47:49 +01:00
|
|
|
err := p.AddPlacementFromString(`11:annotated(annotated(country("GB"),annotation("foo","bar")),annotation("bar","foo"))`)
|
|
|
|
require.NoError(t, err)
|
|
|
|
filters := p.placements[storj.PlacementConstraint(11)]
|
2023-08-28 08:42:08 +01:00
|
|
|
require.True(t, filters.Match(&nodeselection.SelectedNode{
|
2023-08-23 14:47:49 +01:00
|
|
|
CountryCode: location.UnitedKingdom,
|
|
|
|
}))
|
|
|
|
|
|
|
|
require.Equal(t, "bar", nodeselection.GetAnnotation(filters, "foo"))
|
|
|
|
require.Equal(t, "foo", nodeselection.GetAnnotation(filters, "bar"))
|
|
|
|
require.Equal(t, "", nodeselection.GetAnnotation(filters, "kossuth"))
|
|
|
|
})
|
2023-08-23 15:02:58 +01:00
|
|
|
t.Run("location", func(t *testing.T) {
|
satellite/overlay: fix placement selection config parsing
When we do `satellite run api --placement '...'`, the placement rules are not parsed well.
The problem is based on `viper.AllSettings()`, and the main logic is sg. like this (from a new unit test):
```
r := ConfigurablePlacementRule{}
err := r.Set(p)
require.NoError(t, err)
serialized := r.String()
r2 := ConfigurablePlacementRule{}
err = r2.Set(serialized)
require.NoError(t, err)
require.Equal(t, p, r2.String())
```
All settings evaluates the placement rules in `ConfigurablePlacementRules` and stores the string representation.
The problem is that we don't have proper `String()` implementation (it prints out the structs instead of the original definition.
There are two main solutions for this problem:
1. We can fix the `String()`. When we parse a placement rule, the `String()` method should print out the original definition
2. We can switch to use pure string as configuration parameter, and parse the rules only when required.
I feel that 1 is error prone, we can do it (and in this patch I added a lot of `String()` implementations, but it's hard to be sure that our `String()` logic is inline with the parsing logic.
Therefore I decided to make the configuration value of the placements a string (or a wrapper around string).
That's the main reason why this patch seems to be big, as I updated all the usages.
But the main part is in beginning of the `placement.go` (configuration parsing is not a pflag.Value implementation any more, but a separated step).
And `filter.go`, (a few more String implementation for filters.
https://github.com/storj/storj/issues/6248
Change-Id: I47c762d3514342b76a2e85683b1c891502a0756a
2023-09-06 10:40:22 +01:00
|
|
|
p := NewPlacementDefinitions()
|
2023-08-23 15:02:58 +01:00
|
|
|
s := fmt.Sprintf(`11:annotated(annotated(country("GB"),annotation("%s","test-location")),annotation("%s","%s"))`, nodeselection.Location, nodeselection.AutoExcludeSubnet, nodeselection.AutoExcludeSubnetOFF)
|
|
|
|
require.NoError(t, p.AddPlacementFromString(s))
|
|
|
|
filters := p.placements[storj.PlacementConstraint(11)]
|
2023-08-28 08:42:08 +01:00
|
|
|
require.True(t, filters.Match(&nodeselection.SelectedNode{
|
2023-08-23 15:02:58 +01:00
|
|
|
CountryCode: location.UnitedKingdom,
|
|
|
|
}))
|
2023-08-01 12:50:22 +01:00
|
|
|
|
2023-08-23 15:02:58 +01:00
|
|
|
require.Equal(t, nodeselection.AutoExcludeSubnetOFF, nodeselection.GetAnnotation(filters, nodeselection.AutoExcludeSubnet))
|
|
|
|
require.Equal(t, "test-location", nodeselection.GetAnnotation(filters, nodeselection.Location))
|
|
|
|
})
|
2023-07-06 13:35:26 +01:00
|
|
|
})
|
2023-08-23 15:02:58 +01:00
|
|
|
|
2023-08-14 12:30:27 +01:00
|
|
|
t.Run("exclude", func(t *testing.T) {
|
satellite/overlay: fix placement selection config parsing
When we do `satellite run api --placement '...'`, the placement rules are not parsed well.
The problem is based on `viper.AllSettings()`, and the main logic is sg. like this (from a new unit test):
```
r := ConfigurablePlacementRule{}
err := r.Set(p)
require.NoError(t, err)
serialized := r.String()
r2 := ConfigurablePlacementRule{}
err = r2.Set(serialized)
require.NoError(t, err)
require.Equal(t, p, r2.String())
```
All settings evaluates the placement rules in `ConfigurablePlacementRules` and stores the string representation.
The problem is that we don't have proper `String()` implementation (it prints out the structs instead of the original definition.
There are two main solutions for this problem:
1. We can fix the `String()`. When we parse a placement rule, the `String()` method should print out the original definition
2. We can switch to use pure string as configuration parameter, and parse the rules only when required.
I feel that 1 is error prone, we can do it (and in this patch I added a lot of `String()` implementations, but it's hard to be sure that our `String()` logic is inline with the parsing logic.
Therefore I decided to make the configuration value of the placements a string (or a wrapper around string).
That's the main reason why this patch seems to be big, as I updated all the usages.
But the main part is in beginning of the `placement.go` (configuration parsing is not a pflag.Value implementation any more, but a separated step).
And `filter.go`, (a few more String implementation for filters.
https://github.com/storj/storj/issues/6248
Change-Id: I47c762d3514342b76a2e85683b1c891502a0756a
2023-09-06 10:40:22 +01:00
|
|
|
p := NewPlacementDefinitions()
|
2023-08-14 12:30:27 +01:00
|
|
|
err := p.AddPlacementFromString(`11:exclude(country("GB"))`)
|
|
|
|
require.NoError(t, err)
|
|
|
|
filters := p.placements[storj.PlacementConstraint(11)]
|
2023-08-28 08:42:08 +01:00
|
|
|
require.False(t, filters.Match(&nodeselection.SelectedNode{
|
2023-08-14 12:30:27 +01:00
|
|
|
CountryCode: location.UnitedKingdom,
|
|
|
|
}))
|
2023-08-28 08:42:08 +01:00
|
|
|
require.True(t, filters.Match(&nodeselection.SelectedNode{
|
2023-08-14 12:30:27 +01:00
|
|
|
CountryCode: location.Germany,
|
|
|
|
}))
|
|
|
|
})
|
2023-07-06 13:35:26 +01:00
|
|
|
|
2023-07-31 08:42:45 +01:00
|
|
|
t.Run("legacy geofencing rules", func(t *testing.T) {
|
satellite/overlay: fix placement selection config parsing
When we do `satellite run api --placement '...'`, the placement rules are not parsed well.
The problem is based on `viper.AllSettings()`, and the main logic is sg. like this (from a new unit test):
```
r := ConfigurablePlacementRule{}
err := r.Set(p)
require.NoError(t, err)
serialized := r.String()
r2 := ConfigurablePlacementRule{}
err = r2.Set(serialized)
require.NoError(t, err)
require.Equal(t, p, r2.String())
```
All settings evaluates the placement rules in `ConfigurablePlacementRules` and stores the string representation.
The problem is that we don't have proper `String()` implementation (it prints out the structs instead of the original definition.
There are two main solutions for this problem:
1. We can fix the `String()`. When we parse a placement rule, the `String()` method should print out the original definition
2. We can switch to use pure string as configuration parameter, and parse the rules only when required.
I feel that 1 is error prone, we can do it (and in this patch I added a lot of `String()` implementations, but it's hard to be sure that our `String()` logic is inline with the parsing logic.
Therefore I decided to make the configuration value of the placements a string (or a wrapper around string).
That's the main reason why this patch seems to be big, as I updated all the usages.
But the main part is in beginning of the `placement.go` (configuration parsing is not a pflag.Value implementation any more, but a separated step).
And `filter.go`, (a few more String implementation for filters.
https://github.com/storj/storj/issues/6248
Change-Id: I47c762d3514342b76a2e85683b1c891502a0756a
2023-09-06 10:40:22 +01:00
|
|
|
p := NewPlacementDefinitions()
|
2023-07-31 08:42:45 +01:00
|
|
|
p.AddLegacyStaticRules()
|
|
|
|
|
|
|
|
t.Run("nr", func(t *testing.T) {
|
|
|
|
nr := p.placements[storj.NR]
|
2023-08-28 08:42:08 +01:00
|
|
|
require.True(t, nr.Match(&nodeselection.SelectedNode{
|
2023-07-31 08:42:45 +01:00
|
|
|
CountryCode: location.UnitedKingdom,
|
|
|
|
}))
|
2023-08-28 08:42:08 +01:00
|
|
|
require.False(t, nr.Match(&nodeselection.SelectedNode{
|
2023-07-31 08:42:45 +01:00
|
|
|
CountryCode: location.Russia,
|
|
|
|
}))
|
2023-08-28 08:42:08 +01:00
|
|
|
require.False(t, nr.Match(&nodeselection.SelectedNode{
|
2023-07-31 08:42:45 +01:00
|
|
|
CountryCode: 0,
|
|
|
|
}))
|
|
|
|
})
|
|
|
|
t.Run("us", func(t *testing.T) {
|
|
|
|
us := p.placements[storj.US]
|
2023-08-28 08:42:08 +01:00
|
|
|
require.True(t, us.Match(&nodeselection.SelectedNode{
|
2023-07-31 08:42:45 +01:00
|
|
|
CountryCode: location.UnitedStates,
|
|
|
|
}))
|
2023-08-28 08:42:08 +01:00
|
|
|
require.False(t, us.Match(&nodeselection.SelectedNode{
|
2023-07-31 08:42:45 +01:00
|
|
|
CountryCode: location.Germany,
|
|
|
|
}))
|
2023-08-28 08:42:08 +01:00
|
|
|
require.False(t, us.Match(&nodeselection.SelectedNode{
|
2023-07-31 08:42:45 +01:00
|
|
|
CountryCode: 0,
|
|
|
|
}))
|
|
|
|
})
|
|
|
|
|
|
|
|
})
|
|
|
|
|
2023-08-16 09:36:05 +01:00
|
|
|
t.Run("full example", func(t *testing.T) {
|
|
|
|
// this is a realistic configuration, compatible with legacy rules + using one node tag for specific placement
|
|
|
|
|
satellite/overlay: fix placement selection config parsing
When we do `satellite run api --placement '...'`, the placement rules are not parsed well.
The problem is based on `viper.AllSettings()`, and the main logic is sg. like this (from a new unit test):
```
r := ConfigurablePlacementRule{}
err := r.Set(p)
require.NoError(t, err)
serialized := r.String()
r2 := ConfigurablePlacementRule{}
err = r2.Set(serialized)
require.NoError(t, err)
require.Equal(t, p, r2.String())
```
All settings evaluates the placement rules in `ConfigurablePlacementRules` and stores the string representation.
The problem is that we don't have proper `String()` implementation (it prints out the structs instead of the original definition.
There are two main solutions for this problem:
1. We can fix the `String()`. When we parse a placement rule, the `String()` method should print out the original definition
2. We can switch to use pure string as configuration parameter, and parse the rules only when required.
I feel that 1 is error prone, we can do it (and in this patch I added a lot of `String()` implementations, but it's hard to be sure that our `String()` logic is inline with the parsing logic.
Therefore I decided to make the configuration value of the placements a string (or a wrapper around string).
That's the main reason why this patch seems to be big, as I updated all the usages.
But the main part is in beginning of the `placement.go` (configuration parsing is not a pflag.Value implementation any more, but a separated step).
And `filter.go`, (a few more String implementation for filters.
https://github.com/storj/storj/issues/6248
Change-Id: I47c762d3514342b76a2e85683b1c891502a0756a
2023-09-06 10:40:22 +01:00
|
|
|
rules1 := NewPlacementDefinitions()
|
2023-08-16 09:36:05 +01:00
|
|
|
err := rules1.AddPlacementFromString(`
|
2023-09-14 17:42:59 +01:00
|
|
|
10:tag("12whfK1EDvHJtajBiAUeajQLYcWqxcQmdYQU5zX5cCf6bAxfgu4","selected",notEmpty());
|
|
|
|
11:placement(10) && annotation("autoExcludeSubnet","off") && annotation("location","do-not-use");
|
|
|
|
12:placement(10) && annotation("autoExcludeSubnet","off") && country("US") && annotation("location","us-select-1");
|
|
|
|
0:exclude(placement(10)) && annotation("location","global");
|
|
|
|
1:country("EU") && exclude(placement(10)) && annotation("location","eu-1");
|
|
|
|
2:country("EEA") && exclude(placement(10)) && annotation("location","eea-1");
|
|
|
|
3:country("US") && exclude(placement(10)) && annotation("location","us-1");
|
|
|
|
4:country("DE") && exclude(placement(10)) && annotation("location","de-1");
|
|
|
|
6:country("*","!BY", "!RU", "!NONE") && exclude(placement(10)) && annotation("location","custom-1");`)
|
2023-08-16 09:36:05 +01:00
|
|
|
require.NoError(t, err)
|
|
|
|
|
|
|
|
// for countries, it should be the same as above
|
satellite/overlay: fix placement selection config parsing
When we do `satellite run api --placement '...'`, the placement rules are not parsed well.
The problem is based on `viper.AllSettings()`, and the main logic is sg. like this (from a new unit test):
```
r := ConfigurablePlacementRule{}
err := r.Set(p)
require.NoError(t, err)
serialized := r.String()
r2 := ConfigurablePlacementRule{}
err = r2.Set(serialized)
require.NoError(t, err)
require.Equal(t, p, r2.String())
```
All settings evaluates the placement rules in `ConfigurablePlacementRules` and stores the string representation.
The problem is that we don't have proper `String()` implementation (it prints out the structs instead of the original definition.
There are two main solutions for this problem:
1. We can fix the `String()`. When we parse a placement rule, the `String()` method should print out the original definition
2. We can switch to use pure string as configuration parameter, and parse the rules only when required.
I feel that 1 is error prone, we can do it (and in this patch I added a lot of `String()` implementations, but it's hard to be sure that our `String()` logic is inline with the parsing logic.
Therefore I decided to make the configuration value of the placements a string (or a wrapper around string).
That's the main reason why this patch seems to be big, as I updated all the usages.
But the main part is in beginning of the `placement.go` (configuration parsing is not a pflag.Value implementation any more, but a separated step).
And `filter.go`, (a few more String implementation for filters.
https://github.com/storj/storj/issues/6248
Change-Id: I47c762d3514342b76a2e85683b1c891502a0756a
2023-09-06 10:40:22 +01:00
|
|
|
rules2 := NewPlacementDefinitions()
|
2023-08-16 09:36:05 +01:00
|
|
|
rules2.AddLegacyStaticRules()
|
|
|
|
|
|
|
|
testCountries := []location.CountryCode{
|
|
|
|
location.Russia,
|
|
|
|
location.India,
|
|
|
|
location.Belarus,
|
|
|
|
location.UnitedStates,
|
|
|
|
location.Canada,
|
|
|
|
location.Brazil,
|
|
|
|
location.Ghana,
|
|
|
|
}
|
|
|
|
testCountries = append(testCountries, nodeselection.EeaCountriesWithoutEu...)
|
|
|
|
testCountries = append(testCountries, nodeselection.EuCountries...)
|
|
|
|
|
|
|
|
// check if old geofencing rules are working as before (and string based config is the same as the code base)
|
|
|
|
for _, placement := range []storj.PlacementConstraint{storj.EU, storj.EEA, storj.DE, storj.US, storj.NR} {
|
|
|
|
filter1 := rules1.CreateFilters(placement)
|
|
|
|
filter2 := rules2.CreateFilters(placement)
|
|
|
|
for _, country := range testCountries {
|
2023-08-28 08:42:08 +01:00
|
|
|
result1 := filter1.Match(&nodeselection.SelectedNode{
|
2023-08-16 09:36:05 +01:00
|
|
|
CountryCode: country,
|
|
|
|
})
|
2023-08-28 08:42:08 +01:00
|
|
|
result2 := filter2.Match(&nodeselection.SelectedNode{
|
2023-08-16 09:36:05 +01:00
|
|
|
CountryCode: country,
|
|
|
|
})
|
2023-09-06 12:15:26 +01:00
|
|
|
assert.Equal(t, result1, result2, "default legacy rules do not match string based configuration for placement %d and country %s", placement, country)
|
2023-08-16 09:36:05 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// make sure that new rules exclude location.None from NR
|
2023-08-28 08:42:08 +01:00
|
|
|
assert.False(t, rules1.CreateFilters(storj.NR).Match(&nodeselection.SelectedNode{}))
|
|
|
|
assert.False(t, rules2.CreateFilters(storj.NR).Match(&nodeselection.SelectedNode{}))
|
2023-08-16 09:36:05 +01:00
|
|
|
|
|
|
|
// make sure tagged nodes (even from EU) matches only the special placement
|
|
|
|
node := &nodeselection.SelectedNode{
|
|
|
|
CountryCode: location.Germany,
|
|
|
|
Tags: nodeselection.NodeTags{
|
|
|
|
{
|
|
|
|
Signer: signer,
|
|
|
|
Name: "selected",
|
|
|
|
Value: []byte("true"),
|
|
|
|
},
|
|
|
|
},
|
|
|
|
}
|
|
|
|
|
|
|
|
for _, placement := range []storj.PlacementConstraint{storj.EveryCountry, storj.EU, storj.EEA, storj.DE, storj.US, storj.NR} {
|
2023-08-28 08:42:08 +01:00
|
|
|
assert.False(t, rules1.CreateFilters(placement).Match(node))
|
2023-08-16 09:36:05 +01:00
|
|
|
}
|
2023-08-28 08:42:08 +01:00
|
|
|
assert.False(t, rules1.CreateFilters(6).Match(node))
|
2023-08-16 09:36:05 +01:00
|
|
|
|
2023-09-14 17:42:59 +01:00
|
|
|
// any value is accepted
|
|
|
|
assert.True(t, rules1.CreateFilters(11).Match(&nodeselection.SelectedNode{
|
|
|
|
Tags: nodeselection.NodeTags{
|
|
|
|
{
|
|
|
|
Signer: signer,
|
|
|
|
Name: "selected",
|
|
|
|
Value: []byte("true,something"),
|
|
|
|
},
|
|
|
|
},
|
|
|
|
}))
|
|
|
|
|
|
|
|
// but not empty
|
|
|
|
assert.False(t, rules1.CreateFilters(11).Match(&nodeselection.SelectedNode{
|
|
|
|
Tags: nodeselection.NodeTags{
|
|
|
|
{
|
|
|
|
Signer: signer,
|
|
|
|
Name: "selected",
|
|
|
|
Value: []byte(""),
|
|
|
|
},
|
|
|
|
},
|
|
|
|
}))
|
|
|
|
|
2023-08-21 15:16:44 +01:00
|
|
|
// check if annotation present on 11,12, but not on other
|
|
|
|
for i := 0; i < 20; i++ {
|
|
|
|
subnetDisabled := nodeselection.GetAnnotation(rules1.CreateFilters(storj.PlacementConstraint(i)), nodeselection.AutoExcludeSubnet) == nodeselection.AutoExcludeSubnetOFF
|
|
|
|
if i == 11 || i == 12 {
|
|
|
|
require.True(t, subnetDisabled, "Placement filter should be disabled for %d", i)
|
|
|
|
} else {
|
|
|
|
require.False(t, subnetDisabled, "Placement filter should be enabled for %d", i)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-08-16 09:36:05 +01:00
|
|
|
})
|
satellite/overlay: fix placement selection config parsing
When we do `satellite run api --placement '...'`, the placement rules are not parsed well.
The problem is based on `viper.AllSettings()`, and the main logic is sg. like this (from a new unit test):
```
r := ConfigurablePlacementRule{}
err := r.Set(p)
require.NoError(t, err)
serialized := r.String()
r2 := ConfigurablePlacementRule{}
err = r2.Set(serialized)
require.NoError(t, err)
require.Equal(t, p, r2.String())
```
All settings evaluates the placement rules in `ConfigurablePlacementRules` and stores the string representation.
The problem is that we don't have proper `String()` implementation (it prints out the structs instead of the original definition.
There are two main solutions for this problem:
1. We can fix the `String()`. When we parse a placement rule, the `String()` method should print out the original definition
2. We can switch to use pure string as configuration parameter, and parse the rules only when required.
I feel that 1 is error prone, we can do it (and in this patch I added a lot of `String()` implementations, but it's hard to be sure that our `String()` logic is inline with the parsing logic.
Therefore I decided to make the configuration value of the placements a string (or a wrapper around string).
That's the main reason why this patch seems to be big, as I updated all the usages.
But the main part is in beginning of the `placement.go` (configuration parsing is not a pflag.Value implementation any more, but a separated step).
And `filter.go`, (a few more String implementation for filters.
https://github.com/storj/storj/issues/6248
Change-Id: I47c762d3514342b76a2e85683b1c891502a0756a
2023-09-06 10:40:22 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
func TestStringSerialization(t *testing.T) {
|
|
|
|
placements := []string{
|
|
|
|
`"10:country("GB")`,
|
|
|
|
}
|
|
|
|
for _, p := range placements {
|
|
|
|
// this flow is very similar to the logic of our flag parsing,
|
|
|
|
// where viper first parses the value, but later write it out to a string when viper.AllSettings() is called
|
|
|
|
// the string representation should be parseable, and have the same information.
|
|
|
|
|
|
|
|
r := ConfigurablePlacementRule{}
|
|
|
|
err := r.Set(p)
|
|
|
|
require.NoError(t, err)
|
|
|
|
serialized := r.String()
|
|
|
|
|
|
|
|
r2 := ConfigurablePlacementRule{}
|
|
|
|
err = r2.Set(serialized)
|
|
|
|
require.NoError(t, err)
|
|
|
|
|
|
|
|
require.Equal(t, p, r2.String())
|
2023-08-16 09:36:05 +01:00
|
|
|
|
satellite/overlay: fix placement selection config parsing
When we do `satellite run api --placement '...'`, the placement rules are not parsed well.
The problem is based on `viper.AllSettings()`, and the main logic is sg. like this (from a new unit test):
```
r := ConfigurablePlacementRule{}
err := r.Set(p)
require.NoError(t, err)
serialized := r.String()
r2 := ConfigurablePlacementRule{}
err = r2.Set(serialized)
require.NoError(t, err)
require.Equal(t, p, r2.String())
```
All settings evaluates the placement rules in `ConfigurablePlacementRules` and stores the string representation.
The problem is that we don't have proper `String()` implementation (it prints out the structs instead of the original definition.
There are two main solutions for this problem:
1. We can fix the `String()`. When we parse a placement rule, the `String()` method should print out the original definition
2. We can switch to use pure string as configuration parameter, and parse the rules only when required.
I feel that 1 is error prone, we can do it (and in this patch I added a lot of `String()` implementations, but it's hard to be sure that our `String()` logic is inline with the parsing logic.
Therefore I decided to make the configuration value of the placements a string (or a wrapper around string).
That's the main reason why this patch seems to be big, as I updated all the usages.
But the main part is in beginning of the `placement.go` (configuration parsing is not a pflag.Value implementation any more, but a separated step).
And `filter.go`, (a few more String implementation for filters.
https://github.com/storj/storj/issues/6248
Change-Id: I47c762d3514342b76a2e85683b1c891502a0756a
2023-09-06 10:40:22 +01:00
|
|
|
}
|
2023-07-06 13:35:26 +01:00
|
|
|
}
|