New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[vnet] vnet_config
resource
#41399
[vnet] vnet_config
resource
#41399
Conversation
fc8694a
to
4392e49
Compare
@@ -180,7 +180,7 @@ type fakeChecker struct { | |||
|
|||
func (f fakeChecker) CheckAccessToRule(_ services.RuleContext, _ string, resource string, verb string) error { | |||
if resource == types.KindCrownJewel { | |||
for slices.Contains(f.allowedVerbs, verb) { | |||
if slices.Contains(f.allowedVerbs, verb) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How did you end up finding this? Linter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I copied the test and noticed it while making edits, in practice it makes no difference
lib/services/kubewaitingcontainer.go
Outdated
@@ -41,57 +39,21 @@ type KubeWaitingContainer interface { | |||
|
|||
// MarshalKubeWaitingContainer marshals a KubernetesWaitingContainer resource to JSON. | |||
func MarshalKubeWaitingContainer(in *kubewaitingcontainerpb.KubernetesWaitingContainer, opts ...MarshalOption) ([]byte, error) { | |||
if in == nil { | |||
return nil, trace.BadParameter("message is nil") | |||
} | |||
if err := kubewaitingcontainer.ValidateKubeWaitingContainer(in); err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this also does a nil check
friendly ping @tigrato and @GavinFrazar |
lib/auth/vnetconfig/v1/service.go
Outdated
// Opting out of forward compatibility, this service must implement all service methods. | ||
vnet.UnsafeVnetConfigServiceServer | ||
|
||
storage *local.VnetConfigService |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We generally have some kind of interface to decouple the RPC service from the storage layer. Any reason not to follow that pattern as well here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is one area where I'm not really sure what we want to do going forward
we could have an interface here but I don't really see why, there is only one storage layer implementation that we'll use, is it to break the (api layer) -> (storage layer) dependency?
some other types use that same interface and implement it with both the storage layer and an api client. Just to take the most recent example, the CrownJewel service uses this interface in the gRPC api layer to abstract the storage layer, and also makes this gRPC client wrapper implement that same interface
Backend services.CrownJewels |
teleport/lib/auth/authclient/clt.go
Line 639 in 127184f
return c.APIClient.CrownJewelServiceClient() |
I do see why it's useful to have authclient.Client.<SomeService>Client
return an interface rather than a concrete type, so that you can mock authclient.Client
and have it return a mocked <SomeService>Client
. What I don't see is why you should need the storage layer to implement that same interface, but maybe it has something to do with the cache needing an interface too and it's just easier to have a single common interface? I just haven't dug that deep yet. Would be nice to have some guidance on this in RFD153 I just haven't figured it out
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The interest I see here is to be able to mock the underlying storage and test error handling.
Usually we don't do it 😞
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
alright, switch to interface and added tests for storage-layer errors
lib/services/resource.go
Outdated
resource = proto.Clone(resource).(T) | ||
//nolint:staticcheck // SA1019. Id is deprecated, but still needed. | ||
resource.GetMetadata().Id = 0 | ||
resource.GetMetadata().Revision = "" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use maybeResetProtoResourceID
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wrote a maybeResetProtoResourceIDv2
that works with the new types, in #41562
aa7e4aa
to
e618b23
Compare
lib/auth/vnetconfig/v1/service.go
Outdated
// Opting out of forward compatibility, this service must implement all service methods. | ||
vnet.UnsafeVnetConfigServiceServer | ||
|
||
storage *local.VnetConfigService |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The interest I see here is to be able to mock the underlying storage and test error handling.
Usually we don't do it 😞
e618b23
to
3ffbe7e
Compare
5055d14
to
53ab4a0
Compare
a2c4355
to
ddc93ce
Compare
@tigrato this is ready for another look |
Co-authored-by: Tiago Silva <[email protected]>
eb9d66d
to
66aa928
Compare
This PR adds a storage layer, gRPC service, and
tctl
support forvnet_config
resources https://github.com/gravitational/teleport/blob/master/rfd/0163-vnet.mdTODO: support resource bootstrap and add to the cache, tracked in #39330