Claimed resources api by lhaendler · Pull Request #185 · kbind-dev/kbind

lhaendler · 2023-10-18T13:46:23Z

based on discussions from #155

Add human readable prompts for permission claims to cli plugin Add unit tests for permission claim prompts

Co-authored-by: Dr. Stefan Schimanski <stefan.schimanski@gmail.com>

sttts · 2023-10-23T14:29:10Z

+	// +required
+	// +kubebuilder:validation:Required
+	// +kubebuilder:validation:Enum=Accepted;Rejected
+	State AcceptablePermissionClaimState `json:"state"`


how is the flow? The cli (or some other means under the user identity) creates these acceptable claims and sets the accepted or rejected? What is the consequence of rejected (vs. not being listed)?

rejected claims are not reconciled. Saving them as rejected could allow the user to accept them later on via cli.

Signed-off-by: Dr. Stefan Schimanski <stefan.schimanski@gmail.com>

sttts · 2023-10-23T15:25:06Z

+
+type Matcher struct {
+	// +optional
+	Pattern string `json:"pattern,omitempty"`


what did we agree on is a pattern? A regex? A wildcard pattern?

// pattern is a wildcard pattern that is matched against the key. This means // it is either a literal string or start or ends in `*` but is not '*' // itself.

?

Also we should make this required for now, until we have another type and can make this a sum type.

Why not '*' itself?

Signed-off-by: Dr. Stefan Schimanski <stefan.schimanski@gmail.com>

mjudeikis

Thanks for this! APIS are hard :/
I think we could try modeling this more like client-go. Its not ideal, but is what people are used to. I mean like

Create(ctx context.Context, aPIBinding *v1alpha1.APIBinding, opts v1.CreateOptions) (*v1alpha1.APIBinding, error)
Try to isolate things into duplets - Action(Get,Update,Create,Delete) and ActionsOptions so stucts would be something like:

type PermissionClaim struct {
	GroupResource `json:","
	PermissionClaimActions `json:","
	...
}

type PermissionClaimActions{
  Get *PermissionClaimGetOptions `json:"get,omitempty"`
  Create *PermissionClaimCreateOptions `json:"create,omitempty"`

and thing like OnConflict *PermissionClaimOnConflictOptions json:"onConflict,omitempty"`` is explisit to Update/Create only and nested inside options, not on the parent struct.

mjudeikis · 2023-10-24T04:51:48Z

+	//
+	// +optional
+	// +kubebuilder:default:={}
+	Selector *ResourceSelector `json:"selector,omitempty"`


resourceSelector - mainly 2 reasons. selector is so overloaded these days. It can be pod selector, node selector. I would like us to be explicit. And bonus - match KCP.

it's actually objectSelector. We select objects, not resources. Resources are pods, namespaces, services, as in GVRs.

mjudeikis · 2023-10-24T04:52:36Z

+	//
+	// +kubebuilder:validation:Required
+	// +kubebuilder:validation:MinLength:=1
+	Version string `json:"version"`


Do we need this? Is there scenarios where we might want to claim v1 and not v1alpha1?

The version also determines what to sync. So yes, we have to know.

mjudeikis · 2023-10-24T04:54:54Z

+	AutoAdopt bool `json:"autoAdopt,omitempty"`
+
+	// autoDonate set to true means that a newly created object synced from the
+	// provider to the consumer cluster is immediately donated to the consumer
+	// by marking it as owned by the consumer on both sides.
+	//
+	// autoDonate is mutually exclusive with autoAdopt.
+	//
+	// +optional
+	AutoDonate bool `json:"autoDonate,omitempty"`


Can this become something like AdoptStratety and enum? So if more comes in the future we would not keep adding them like list of booleans?

ownerTransfer = Adopt|Donate|None ?

mjudeikis · 2023-10-24T04:57:58Z

+	// Note that update permissions do not imply create permissions.
+	//
+	// +optional
+	Update *PermissionClaimUpdateOptions `json:"update,omitempty"`


Just readability? Move close to Read, Create, Update and maybe we cloud do something like GroupResource json:","`` with PermissionsClaimsVerbOptions and I was thinking maybe worth matching RBAC syntax `GET, UPDATE, CREATE` ? I this case Read would change to Get? But not fully sold on last one myself.

it's not really about requests. Hence not "get".

mjudeikis · 2023-10-24T05:00:08Z

+	// If set to false, deleted provider-owned objects get deleted on the provider cluster as well.
+	//
+	// +kubebuilder:default:=true
+	RecreateWhenConsumerSideDeleted bool `json:"recreateWhenConsumerSideDeleted"`


These looks like they will be mutual exlusive too, maybe something similar to:

// Similarly to above, these are constants to support HTTP PATCH utilized by // both the client and server that didn't make sense for a whole package to be // dedicated to. type PatchType string const ( JSONPatchType PatchType = "application/json-patch+json" MergePatchType PatchType = "application/merge-patch+json" StrategicMergePatchType PatchType = "application/strategic-merge-patch+json" ApplyPatchType PatchType = "application/apply-patch+yaml" )

As I bet these will be more here, like ForceRecreate, DeleteAndRecreate, etc

you write above to move this into update or create. Neither is really a fit.

Maybe create.onDelete: Recreate|DeleteOnProviderSide.

I’m not sure if it was brought up in the previous discussions, but what about deletion scenarios? Currently an object removed from the consumer cluster is triggering deletion on the provider side. If you remove the object on the provider side, it will be re-created from the consumer copy. Meaning that in the Recreate state there is no way to remove the object from the cluster without stopping the konnector instance. Shouldn’t it be more general? Recreate|FollowDeletion|Orphan? allowing for both sides being equal in having right for resource eviction?

That's where the onConflict part of the field name comes from. The action is performed when the lifecycle of the object conflicts with the state on the cluster.

Meaning that in the Recreate state there is no way to remove the object from the cluster without stopping the konnector instance
For provider owned objects, that is true (short of undoing the binding). Claimed resources are objects that support objects of a bound api. For example, creating a MangoDB object should spawn a secret containing credentials to use the MangoDB instance. It is expected that the supporting objects are removed upon deletion of the 'main' resource.

The behavior in case of deletion looks like the following:

Recreate: false

provider owned object deleted: not recreated on the consumer side. Since the provide still manages the object, the provider will eventually delete it on the provider cluster.

consumer owned object: the object will be deleted on the provider cluster, since the consumer object controls the lifecycle

Recreate: true

provider owned object: the object is created again on the consumer cluster, once the provider deletes it on the provider cluster, it is deleted on the consumer cluster

consumer owned object: the object will be deleted on the provider cluster, since the consumer object controls the lifecycle

maybe onConflict.userDeletesProviderOwnedObject = Recreate | Orphan?

So an object created on the provider side and synchronized on the consumer side will behave the same way as the object created on the consumer side and synchronized on the provider side is idempotent when it comes to deletion? Basically the FollowDeletion or Follow scenario, is supported by the api?

An object that is created by the provider and synchronized to the consumer could be donated using ownerTransfer=Donate. In that case, if the consumer deletes it, it will be deleted on the provider cluster too. Since donation means that the consumer will own the object, the provider may have to claim update fields to continue writing to the object after creation in the consumer cluster

mjudeikis · 2023-10-24T05:01:58Z

+	// If not true, and a conflicting consumer object exists, it is not touched.
+	//
+	// +optional
+	ReplaceExisting bool `json:"replaceExisting,omitempty"`


Same as above. We could reuse these if done right.

what is "above"?

I mean, can we have more of these and be exclusive? Like:

CreateStrategy: DeleteAndCreate (some object in k8s world cant be updated) UpdateInplace

How about onConflict.userObjectExists = Replace | Keep?

mjudeikis · 2023-10-24T05:04:54Z

+	//
+	// +optional
+	// +kubebuilder:default:={}
+	OnConflict *PermissionClaimOnConflictOptions `json:"onConflict,omitempty"`


Somehow this does not look right. You will have conflict on Create/Update only. Now this still being optional but implied to get and Deletes too. Some logical shuffling might be needed. Like Clients logic: Delete(ctx context.Context, name string, opts v1.DeleteOptions) error where DeleteOptions are only for delete struct and we can reuse them inside.

Signed-off-by: Dr. Stefan Schimanski <stefan.schimanski@gmail.com>

mjudeikis · 2025-10-09T05:42:32Z

implemented in #304

lhaendler and others added 5 commits October 16, 2023 21:05

Add fields for claimed resources

88fecd6

Add readable prompts for permission claims (#1)

f0dee16

Add human readable prompts for permission claims to cli plugin Add unit tests for permission claim prompts

Update pkg/apis/kubebind/v1alpha1/apiservicebinding_types.go

5f5a8cc

Co-authored-by: Dr. Stefan Schimanski <stefan.schimanski@gmail.com>

Update pkg/apis/kubebind/v1alpha1/apiservicebinding_types.go

3b991fb

Co-authored-by: Dr. Stefan Schimanski <stefan.schimanski@gmail.com>

Remove redundant paragraph

977be31

sttts reviewed Oct 23, 2023

View reviewed changes

sttts added 2 commits October 23, 2023 16:44

apis: move permission claims to their own file

0e45d82

Signed-off-by: Dr. Stefan Schimanski <stefan.schimanski@gmail.com>

apis: qualify permission claim types

fbb4984

Signed-off-by: Dr. Stefan Schimanski <stefan.schimanski@gmail.com>

sttts reviewed Oct 23, 2023

View reviewed changes

sttts added 3 commits October 23, 2023 18:38

apis: an attempt on more precise permission claim docs

dc307ba

Signed-off-by: Dr. Stefan Schimanski <stefan.schimanski@gmail.com>

codegen

b67ec95

Signed-off-by: Dr. Stefan Schimanski <stefan.schimanski@gmail.com>

Update tests

31c7f3c

Signed-off-by: Dr. Stefan Schimanski <stefan.schimanski@gmail.com>

mjudeikis requested changes Oct 24, 2023

View reviewed changes

sttts and others added 2 commits October 24, 2023 09:58

Address comments

1ab45c3

Signed-off-by: Dr. Stefan Schimanski <stefan.schimanski@gmail.com>

Small fixes

81872fb

mirzakopic mentioned this pull request Jan 28, 2025

epic: support syncing associated resources in kube-bind platform-mesh/backlog#25

Closed

4 tasks

mjudeikis closed this Oct 9, 2025

Uh oh!

Conversation

lhaendler commented Oct 18, 2023 • 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!

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!

mjudeikis 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!

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!

sttts Oct 24, 2023 • 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!

Danil-Grigorev Nov 6, 2023 • 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!

Choose a reason for hiding this comment

Recreate: false

Recreate: true

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!

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!

mjudeikis commented Oct 9, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

lhaendler commented Oct 18, 2023 •

edited

Loading

sttts Oct 24, 2023 •

edited

Loading

Danil-Grigorev Nov 6, 2023 •

edited

Loading