adm/ape: Adopt policy reader #1607

Open
dkirillov wants to merge 4 commits from dkirillov/frostfs-node:feature/adopt_policy_reader into master
Member

Embed https://git.frostfs.info/dkirillov/policy-reader
tool to 'frostfs-adm morph ape' command

Signed-off-by: Denis Kirillov d.kirillov@yadro.com

Embed https://git.frostfs.info/dkirillov/policy-reader tool to 'frostfs-adm morph ape' command Signed-off-by: Denis Kirillov <d.kirillov@yadro.com>
dkirillov force-pushed feature/adopt_policy_reader from 603c6b2fa7 to ef84808576 2025-01-20 06:33:45 +00:00 Compare
dkirillov changed title from WIP: [#XX] adm/ape: Adopt policy reader to WIP: [#1607] adm/ape: Adopt policy reader 2025-01-20 06:33:58 +00:00
dkirillov changed title from WIP: [#1607] adm/ape: Adopt policy reader to [#1607] adm/ape: Adopt policy reader 2025-01-20 06:34:14 +00:00
requested reviews from storage-core-committers, storage-core-developers 2025-01-20 06:34:15 +00:00
dkirillov force-pushed feature/adopt_policy_reader from ef84808576 to 4706a15743 2025-01-20 06:36:42 +00:00 Compare
dstepanov-yadro reviewed 2025-01-20 09:24:09 +00:00
@ -0,0 +18,4 @@
)
var listContainerCmd = &cobra.Command{
Use: "list-container",

What is the difference with list-rule-chains command?

What is the difference with `list-rule-chains` command?
Member

It seems this runs listing under chains subcommand
ape chains list-container (although it can be just ape chains list and flags can define targets) instead of ape list-rule-chains.

It seems this runs listing under `chains` subcommand `ape chains list-container` (although it can be just `ape chains list` and flags can define targets) instead of `ape list-rule-chains`.
Author
Member

This command is aimed to list all container related chains. Not only for container target but also for namespace target (in which container is location)

This command is aimed to list all container related chains. Not only for `container` target but also for `namespace` target (in which container is location)
@ -0,0 +52,4 @@
commonCmd.ExitOnErr(cmd, "can't parse chain-name: %w", err)
endpoint := viper.GetString(commonflags.EndpointFlag)
namespace := viper.GetString(namespaceFlag)

Other ape-related commands have root to empty string replacement:

Other ape-related commands have `root` to empty string replacement: https://git.frostfs.info/TrueCloudLab/frostfs-node/src/commit/c98357606b4e387f7a8063331438dccfb24d255e/cmd/frostfs-adm/internal/modules/morph/ape/ape_util.go#L27
@ -0,0 +13,4 @@
maxPrintable = 127
)
func PrintChains(cmd *cobra.Command, list []stackitem.Item, decodeChain, decodeID bool) error {

In which case is it expected that frostfs-adm user will not want to decode ID and chain?

In which case is it expected that `frostfs-adm` user will not want to decode ID and chain?
Author
Member

When data in policy contract isn't actually chain. For i kind we store aws policy json (that isn't compatible with ape chain format)

When data in policy contract isn't actually chain. For `i` kind we store aws policy json (that isn't compatible with ape chain format)
@ -0,0 +7,4 @@
)
var Cmd = &cobra.Command{
Use: "low-level",

What about raw?

What about `raw`?
Author
Member

I thought about it but for some reason I decided that you wouldn't like it

I thought about it but for some reason I decided that you wouldn't like it
aarifullin requested changes 2025-01-20 10:28:47 +00:00
Dismissed
aarifullin left a comment
Member

@dkirillov, look, I believe I can figure out your intentions, but you should take in account that we can't leave such aliases for subcommands.

Currently morph ape also defines such commands to manage/read chains

initAddRuleChainCmd()
initRemoveRuleChainCmd()
initListRuleChainsCmd()

This can't be accepted without refactoring. Is it possible to implement policy-reader features adding functionality to the current frostfs-adm morph ape subcommands?

@dkirillov, look, I believe I can figure out your intentions, but you should take in account that we can't leave such aliases for subcommands. Currently `morph ape` also defines such commands to manage/read chains ```go initAddRuleChainCmd() initRemoveRuleChainCmd() initListRuleChainsCmd() ``` This can't be accepted without refactoring. Is it possible to implement `policy-reader` features adding functionality to the current `frostfs-adm morph ape` subcommands?
@ -0,0 +20,4 @@
}
const (
policyHashFlag = "policy-hash"
Member

We don't need to pass it. See

We don't need to pass it. [See](https://git.frostfs.info/TrueCloudLab/frostfs-node/src/branch/master/cmd/frostfs-adm/internal/modules/morph/ape/ape_util.go#L64-L65)
Author
Member

These commands aimed to debug policy contract in any environment. In some environment this contract isn't registered in NNS

These commands aimed to debug `policy` contract in any environment. In some environment this contract isn't registered in NNS
Member

Okay. You haven't marked the flag as required but it's not processed when it's empty either.
Could we use searching within NNS as default behavior if its value is empty?

Okay. You haven't marked the flag as required but it's not processed when it's empty either. Could we use searching within NNS as default behavior if its value is empty?
aarifullin marked this conversation as resolved
@ -0,0 +31,4 @@
func initListChainNamesCmd() {
listChainNamesCmd.Flags().StringP(commonflags.EndpointFlag, commonflags.EndpointFlagShort, "", commonflags.EndpointFlagDesc)
listChainNamesCmd.Flags().String(kindFlag, "n", "Target kind (1-byte) to list (n(namespace)/c(container)/g(group)/u(user)/i(iam))")
Member

Consider reusing flag names from common package, please!

Consider reusing flag names from [common](https://git.frostfs.info/TrueCloudLab/frostfs-node/src/branch/master/cmd/internal/common/ape/flags.go#L7-L10) package, please!
Author
Member

Actually, I tried. But it leads to huge unwanted refactor in APE because target-type be parsed to this. This TargetType is widely used in RequestTarget and function like this.
But for i kind (

) we store aws json policy and this data MUST NOT be used in IsAllowed APE function because it isn't valid APE chain.
So I don't this that it's good idea change APE and provide user way for incorrect using APE library with i kind (target-type)

Actually, I tried. But it leads to huge unwanted refactor in APE because [target-type](https://git.frostfs.info/TrueCloudLab/frostfs-node/src/commit/c98357606b4e387f7a8063331438dccfb24d255e/cmd/internal/common/ape/flags.go#L9) be parsed to [this](https://git.frostfs.info/TrueCloudLab/policy-engine/src/commit/a3bc3099bd5bfefd702b44070d58982e477a56e9/pkg/engine/interface.go#L35-L42). This `TargetType` is widely used in `RequestTarget` and function like [this](https://git.frostfs.info/TrueCloudLab/policy-engine/src/commit/a3bc3099bd5bfefd702b44070d58982e477a56e9/pkg/engine/chain_router.go#L27). But for `i` kind (https://git.frostfs.info/TrueCloudLab/frostfs-contract/src/commit/201db45bd739fb729448ea8c806ae51ff01a5f2d/policy/policy_contract.go#L21) we store aws json policy and this data **MUST NOT** be used in `IsAllowed` APE function because it isn't valid APE chain. So I don't this that it's good idea change APE and provide user way for incorrect using APE library with `i` kind (target-type)
Member

Okay. Let me explain my point of view and, probably, we'll find a compromise.

These types are not bound to frostfs-node. It implied you can manage chains on the different protocol levels (ingress, s3 etc.), but it seems s3-gw doesn't use the interface yet (or it' not adapted ?)

  1. s3-gw manages IAM chains on S3 level
  2. IsAllowed will never list s3 chains, only ingress
  3. Overrides and chains added by ape-manager are created on ingress level. i won't affect its work

So, ideally, policy-engine could introduce i type that could be listed on S3 level using policy contract interface. So, it doesn't look like a huge refactoring

Anyway, I just asked to use flag names and description. Parsing to target hasn't been on point :))

Okay. Let me explain my point of view and, probably, we'll find a compromise. These [types](https://git.frostfs.info/TrueCloudLab/policy-engine/src/commit/a3bc3099bd5bfefd702b44070d58982e477a56e9/pkg/engine/interface.go#L35-L42) are not bound to `frostfs-node`. It implied you can manage chains on the different protocol levels (`ingress`, `s3` etc.), but it seems `s3-gw` doesn't use the interface yet (or it' not adapted **?**) 1. `s3-gw` manages IAM chains on `S3` [level](https://git.frostfs.info/TrueCloudLab/frostfs-s3-gw/src/branch/master/internal/frostfs/policy/morph_rule_chain_storage.go#L79) 2. `IsAllowed` will never list `s3` chains, only `ingress` 3. Overrides and chains added by `ape-manager` are created on `ingress` level. `i` won't affect its work So, ideally, `policy-engine` could introduce `i` type that could be listed on [S3](https://git.frostfs.info/TrueCloudLab/policy-engine/src/branch/master/pkg/chain/chain_names.go#L12) level using policy contract interface. So, it doesn't look like a huge refactoring Anyway, I just asked to use flag names and description. Parsing to target hasn't been on point :))
Author
Member

Anyway, I just asked to use flag names and description. Parsing to target hasn't been on point :))

#1607 (comment)

> Anyway, I just asked to use flag names and description. Parsing to target hasn't been on point :)) https://git.frostfs.info/TrueCloudLab/frostfs-node/pulls/1607#issuecomment-64812
aarifullin marked this conversation as resolved
Author
Member

Is it possible to implement policy-reader features adding functionality to the current frostfs-adm morph ape subcommands?

To the current subcommands? I believe it isn't possible (without a huge kludge).

> Is it possible to implement policy-reader features adding functionality to the current frostfs-adm morph ape subcommands? To the current subcommands? I believe it isn't possible (without a huge kludge).
dkirillov force-pushed feature/adopt_policy_reader from 4706a15743 to 98eeed2e74 2025-01-20 13:08:58 +00:00 Compare
fyrchik requested changes 2025-01-20 13:51:30 +00:00
@ -0,0 +12,4 @@
apeCmd "git.frostfs.info/TrueCloudLab/frostfs-node/cmd/internal/common/ape"
"git.frostfs.info/TrueCloudLab/frostfs-sdk-go/container"
cid "git.frostfs.info/TrueCloudLab/frostfs-sdk-go/container/id"
"git.frostfs.info/TrueCloudLab/frostfs-sdk-go/ns"
Owner

I would like to avoid using this package in this repo.
Ideally all node <-> neo-go communication is done via autogenerated code or helpers from the frostfs-contract.
We already have multiple commands using different mechanisms (actors vs common client from the frostfsid), let's not add yet another one.

Specifically, I would like to make this a thing #1035, so connection handling should be decoupled from the argument parsing.

I would like to avoid using this package in this repo. Ideally all node <-> neo-go communication is done via autogenerated code or helpers from the `frostfs-contract`. We already have multiple commands using different mechanisms (actors vs common client from the frostfsid), let's not add yet another one. Specifically, I would like to make this a thing #1035, so connection handling should be decoupled from the argument parsing.
fyrchik marked this conversation as resolved
@ -0,0 +19,4 @@
var listContainerCmd = &cobra.Command{
Use: "list-container",
Short: "List container related (namespace) policies",
Owner

I would use different naming: namespace somewhere in the command name and --container as an optional argument (aka filter).
Current implementation looks too specific.

I would use different naming: `namespace` somewhere in the command name and `--container` as an optional argument (aka filter). Current implementation looks too specific.
Author
Member

Current implementation looks too specific.

Indeed it is. This command is aimed to get all container related policies. In container target and in namespace target.

The similar command for user that get all user related (affected) policies (from namespace, group, user targets)

I'm not sure if using "--container as optional argument (aka filter)" is appropriate here

> Current implementation looks too specific. Indeed it is. This command is aimed to get all **container** related policies. In `container` target and in `namespace` target. The similar command for user that get all user related (affected) policies (from `namespace`, `group`, `user` targets) I'm not sure if using "`--container` as optional argument (aka filter)" is appropriate here
@ -0,0 +24,4 @@
Example: `chains list-container -r http://localhost:40332 list --container 7h7NcXcF6k6b1yidqEHc1jkyXUm1MfUDrrTuHAefhiDe
chains list-container -r http://localhost:40332 --policy-hash 81c1a41d09e08087a4b679418b12be5d3ab15742 list --container 7h7NcXcF6k6b1yidqEHc1jkyXUm1MfUDrrTuHAefhiDe --namespace test`,
PreRun: func(cmd *cobra.Command, _ []string) {
_ = viper.BindPFlag(containerFlag, cmd.Flags().Lookup(containerFlag))
Owner

We use BindPFlag to allow providing command values via configuration.
I doubt it is useful for any of these 4 flags.
(containerFlag is required, to this bind seems definitely useless).

We use `BindPFlag` to allow providing command values via configuration. I doubt it is useful for any of these 4 flags. (`containerFlag` is required, to this bind seems definitely useless).
@ -0,0 +72,4 @@
res, err = commonclient.ReadIteratorItems(inv, 100, policyHash, methodIteratorChainsByPrefix, big.NewInt(int64(policycontract.Container)), cnrID.String(), string(chainName))
commonCmd.ExitOnErr(cmd, "can't read iterator: %w", err)
cmd.Printf("container policies: %d\n", len(res))
Owner

Why do we have %s for namespace message, but no CID for this one?

Why do we have `%s` for namespace message, but no CID for this one?
fyrchik marked this conversation as resolved
@ -0,0 +77,4 @@
}
// ResolveContainerID determine container id by resolving NNS name.
func ResolveContainerID(endpoint, namespace, containerName string) (cid.ID, error) {
Owner

It is used only once and in this package, why is it public?

It is used only once and in this package, why is it public?
Owner

Why have you decided to move it to helper package instead of making it private?

Why have you decided to move it to `helper` package instead of making it private?
Author
Member

To make it similar to NNSResolveHash. Probably it can be helpful in some other places

To make it similar to `NNSResolveHash`. Probably it can be helpful in some other places
Owner

Probably can, probably not.
To me it complicates things now.

Probably can, probably not. To me it complicates things now.
fyrchik marked this conversation as resolved
@ -0,0 +128,4 @@
return ffsid.GetSubjectExtended(subj.PrimaryKey.GetScriptHash())
}
func parseChainName(service string) (apechain.Name, error) {
Owner

To my complete surprise, there is an old and undone issue: https://github.com/spf13/pflag/issues/236 which could be helpful here.

To my complete surprise, there is an old and undone issue: https://github.com/spf13/pflag/issues/236 which could be helpful here.
fyrchik marked this conversation as resolved
@ -0,0 +141,4 @@
return "", errUnknownServiceType
}
func printSubject(cmd *cobra.Command, subj *ffsidclient.SubjectExtended) {
Owner

It accepts SubjectExtended but doesn't print AdditionalKeys. It this intended?

It accepts `SubjectExtended` but doesn't print `AdditionalKeys`. It this intended?
Author
Member

Probably this was done (in policy-reader tool) before additional keys starts to be useful to see

Probably this was done (in `policy-reader` tool) before additional keys starts to be useful to see
fyrchik marked this conversation as resolved
@ -0,0 +25,4 @@
)
func init() {
Cmd.PersistentFlags().String(policyHashFlag, "policy.frostfs", "NNS name or script hash of policy contract")
Owner

Every other command may resolve contract hash from NNS.
frostfs-adm may resolve any domain too.
Why this argument exists?

Every other command may resolve contract hash from NNS. `frostfs-adm` may resolve any domain too. Why this argument exists?
Author
Member
https://git.frostfs.info/TrueCloudLab/frostfs-node/pulls/1607#issuecomment-64644
@ -0,0 +70,4 @@
return nil, fmt.Errorf("invalid type: %s", typ)
}
return big.NewInt(int64(typ[0])), nil
Owner

This is very error-prone: we connect some constants from contracts with CLI interface in the frostfs-adm.
If something changes, we won't notice.
Can we make this an implicit switch that uses some exported constants from the policy contract?

And, to be fair, full multi-byte names or even boolean flags look better IMO.

This is very error-prone: we connect some constants from contracts with CLI interface in the frostfs-adm. If something changes, we won't notice. Can we make this an implicit switch that uses some exported constants from the `policy` contract? And, to be fair, full multi-byte names or even boolean flags look better IMO.
Author
Member

I consider this command as low-level one, so I would like to be able to invoke ListTarget using any valid one-byte parameter (the same way as I can do this by neo-go contract testinvokefuntion)

I consider this command as low-level one, so I would like to be able to invoke [ListTarget](https://git.frostfs.info/TrueCloudLab/frostfs-contract/src/commit/201db45bd739fb729448ea8c806ae51ff01a5f2d/policy/policy_contract.go#L254) using any valid one-byte parameter (the same way as I can do this by `neo-go contract testinvokefuntion`)
Owner

But can we provide e.g. \x00?

But can we provide e.g. `\x00`?
Author
Member

Update parsing to be able provide just number

Update parsing to be able provide just number
@ -8,3 +8,3 @@
TargetNameFlagDesc = "Resource name in APE resource name format"
TargetTypeFlag = "target-type"
TargetTypeFlagDesc = "Resource type(container/namespace)"
TargetTypeFlagDesc = "Resource type(container/namespace/group/user)"
Owner

This should be in a separate commit.

This should be in a separate commit.
fyrchik marked this conversation as resolved
dkirillov force-pushed feature/adopt_policy_reader from 98eeed2e74 to 4022349fbe 2025-01-21 14:21:14 +00:00 Compare
aarifullin reviewed 2025-01-22 07:54:17 +00:00
@ -0,0 +9,4 @@
var Cmd = &cobra.Command{
Use: "raw",
Short: "FrostFS policy contract raw reader",
Long: "Helps reading policy information from contact in FrostFS network",
Member

raw is subcommand and Long won't be showed in the prompt. You can leave Short only

`raw` is subcommand and `Long` won't be showed in the prompt. You can leave `Short` only
aarifullin marked this conversation as resolved
aarifullin reviewed 2025-01-22 11:55:29 +00:00
@ -0,0 +81,4 @@
commonCmd.ExitOnErr(cmd, "can't get NNS contract state: %w", err)
policyHashStr, _ := cmd.Flags().GetString(policyHashFlag)
policyHash, err := helper.NNSResolveHash(inv, nnsCs.Hash, policyHashStr)
Member

Please, let this flag be optional (see this)

Please, let this flag be optional (see [this](https://git.frostfs.info/TrueCloudLab/frostfs-node/pulls/1607#issuecomment-64674))
Author
Member

This is already optional, If I understood you correctly. I have default policy.frostfs value for this flag

Cmd.PersistentFlags().String(policyHashFlag, "policy.frostfs", "NNS name or script hash of policy contract")

This is already optional, If I understood you correctly. I have default `policy.frostfs` value for this flag https://git.frostfs.info/dkirillov/frostfs-node/src/commit/4022349fbe06f374bd15cf9a29f043d5827c2f2a/cmd/frostfs-adm/internal/modules/morph/ape/raw/root.go#L23
Member

Ah, yeah. Correct!

Ah, yeah. Correct!
aarifullin marked this conversation as resolved
dkirillov force-pushed feature/adopt_policy_reader from 4022349fbe to a1154801d1 2025-01-23 08:34:38 +00:00 Compare
fyrchik changed title from [#1607] adm/ape: Adopt policy reader to adm/ape: Adopt policy reader 2025-01-29 09:52:26 +00:00
fyrchik reviewed 2025-01-29 11:37:25 +00:00
@ -0,0 +158,4 @@
for i, key := range subj.AdditionalKeys {
additionalKeys[i] = hex.EncodeToString(key.Bytes())
}
cmd.Printf("\tadditional keys: %v\n", additionalKeys)
Owner

We print all other arrays line-by-line, and here we use %v, why so?

We print all other arrays line-by-line, and here we use `%v`, why so?
Author
Member

Because we don't need extra formatting in this case

Because we don't need extra formatting in this case
Owner

I mean, why we don't need it?
Having keys line-by-line is easier to read and will correspond to the formatting of other array values.

I mean, why we don't need it? Having keys line-by-line is easier to read and will correspond to the formatting of other array values.
dkirillov force-pushed feature/adopt_policy_reader from a1154801d1 to a6f300ea17 2025-02-04 11:57:17 +00:00 Compare
dkirillov force-pushed feature/adopt_policy_reader from a6f300ea17 to ee4c32ad6e 2025-02-06 14:52:06 +00:00 Compare
aarifullin approved these changes 2025-02-07 08:28:10 +00:00
Dismissed
aarifullin left a comment
Member

We definitely should have this thing in our cli

We definitely should have this thing in our cli
fyrchik requested changes 2025-02-28 15:08:23 +00:00
@ -0,0 +87,4 @@
nnsCs, err := helper.GetContractByID(management.NewReader(inv), 1)
commonCmd.ExitOnErr(cmd, "can't get NNS contract state: %w", err)
policyHashStr, _ := cmd.Flags().GetString(policyHashFlag)
Owner

Could you explain, why this code works?
We get policyhash, which is hex-encoded contract hash we would like to use.
But instead of decoding it we use NNSResolveHash where policyHashStr is provided as a domain and resolved.
Secondly, regardless of how it works, if the user provides explicit policy hash, we should not care about NNS at all.

What am I missing here?

Could you explain, why this code works? We get policyhash, which is hex-encoded contract hash we would like to use. But instead of decoding it we use `NNSResolveHash` where `policyHashStr` is provided as a _domain_ and resolved. Secondly, regardless of how it works, if the user provides explicit policy hash, we should not care about NNS at all. What am I missing here?
Author
Member

Oh, It seems I've lost decoding during refactor. I'll fix it

Oh, It seems I've lost decoding during refactor. I'll fix it
Owner
  1. There are other places like this too, please check them.
  2. Now we skip err != nil for some reason. Why? We expect the hash, if it is invalid command should fail.
1. There are other places like this too, please check them. 2. Now we skip `err != nil` for some reason. Why? We expect the hash, if it is invalid command should fail.
Author
Member
  1. It's similar to the getting flags across frostfs-adm code e.g.

    s, _ := cmd.Flags().GetString(addrAdminFlag)

2. It's similar to the getting flags across frostfs-adm code e.g. https://git.frostfs.info/TrueCloudLab/frostfs-node/src/commit/0991077cb364c94e40f6838035acab4754b4d8af/cmd/frostfs-adm/internal/modules/morph/ape/ape.go#L202
Owner

We skip an error there because it cannot possibly happen (the flag is defined and all flags can be used as string).
The error you skip (in the if below this line) happens during parsing.

We skip an error there because it cannot possibly happen (the flag is defined and all flags can be used as string). The error you skip (in the `if` below this line) happens during parsing.
Author
Member

If parsing failed then we should try to resolve it in NNS, because it can have format like policy.frostfs

If parsing failed then we should try to resolve it in NNS, because it can have format like `policy.frostfs`
Owner

Then it should be a --policy-domain and not --policy-hash.
However, I think policy-hash is enough, if we want to use a custom domain, we might as well resolve it separately.

Then it should be a `--policy-domain` and not `--policy-hash`. However, I think `policy-hash` is enough, if we want to use a custom domain, we might as well resolve it separately.
dkirillov force-pushed feature/adopt_policy_reader from ee4c32ad6e to 05517ae305 2025-03-03 06:53:22 +00:00 Compare
dkirillov dismissed aarifullin's review 2025-03-03 06:53:22 +00:00
Reason:

New commits pushed, approval review dismissed automatically according to repository settings

dkirillov force-pushed feature/adopt_policy_reader from 05517ae305 to 10574f8ff0 2025-03-03 08:15:20 +00:00 Compare
fyrchik reviewed 2025-03-05 07:19:35 +00:00
@ -0,0 +187,4 @@
}
frostfsidHashStr, _ := cmd.Flags().GetString(frostfsidHashFlag)
frostfsidHash, err := util.Uint160DecodeStringLE(policyHashStr)
Owner

Is it really policyHashStr?

Is it really `policyHashStr`?
All checks were successful
DCO action / DCO (pull_request) Successful in 37s
Required
Details
Vulncheck / Vulncheck (pull_request) Successful in 59s
Required
Details
Build / Build Components (pull_request) Successful in 1m24s
Required
Details
Pre-commit hooks / Pre-commit (pull_request) Successful in 1m28s
Required
Details
Tests and linters / Run gofumpt (pull_request) Successful in 2m37s
Required
Details
Tests and linters / Tests (pull_request) Successful in 2m56s
Required
Details
Tests and linters / Lint (pull_request) Successful in 3m3s
Required
Details
Tests and linters / gopls check (pull_request) Successful in 3m50s
Required
Details
Tests and linters / Tests with -race (pull_request) Successful in 3m53s
Required
Details
Tests and linters / Staticcheck (pull_request) Successful in 6m11s
Required
Details
This pull request doesn't have enough approvals yet. 0 of 2 approvals granted.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u feature/adopt_policy_reader:dkirillov-feature/adopt_policy_reader
git checkout dkirillov-feature/adopt_policy_reader
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
4 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: TrueCloudLab/frostfs-node#1607
No description provided.