Skip to content
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

Add cluster autoupdate resources with enabled cache #45617

Closed
wants to merge 17 commits into from

Conversation

vapopov
Copy link
Contributor

@vapopov vapopov commented Aug 20, 2024

In this PR implemented new resources for autoupdate configuration and version store with enabled cache on proxy side to be able serve these resources without making requests to auth service.
Also added commands for tctl edit/get/create

Related: #39805
changelog: Added resources for autoupdate (config and version)

@vapopov vapopov requested a review from sclevine August 20, 2024 04:53
@vapopov vapopov force-pushed the vapopov/add-autoupdate-resources branch from bd8e1d3 to db12db8 Compare August 21, 2024 17:42
@vapopov vapopov force-pushed the vapopov/add-autoupdate-resources branch from 4e2cd91 to 0e45c8f Compare August 22, 2024 07:03
api/proto/teleport/autoupdate/v1/autoupdate.proto Outdated Show resolved Hide resolved
api/client/webclient/webclient.go Outdated Show resolved Hide resolved
@vapopov vapopov force-pushed the vapopov/add-autoupdate-resources branch from e24daff to 70b7c54 Compare August 22, 2024 18:36
@vapopov vapopov marked this pull request as ready for review August 22, 2024 19:06
Copy link

The PR changelog entry failed validation: Changelog entry not found in the PR body. Please add a "no-changelog" label to the PR, or changelog lines starting with changelog: followed by the changelog entries for the PR.

@github-actions github-actions bot added size/lg tctl tctl - Teleport admin tool labels Aug 22, 2024
Copy link
Member

@sclevine sclevine left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, may want to double-check with @rosstimothy about whether the cache is configured suitably for serving the /find endpoint

@vapopov vapopov force-pushed the vapopov/add-autoupdate-resources branch from 6675c32 to 0184ab6 Compare August 22, 2024 20:15
Fix interval first duration
@vapopov vapopov force-pushed the vapopov/add-autoupdate-resources branch from 0184ab6 to 3b03379 Compare August 22, 2024 21:48
Copy link
Contributor

@rosstimothy rosstimothy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a lot going on in this PR - many layers of boilerplate all being implemented at once. I'd suggest trying to scope this to just adding the resource, the RPC service and persisting it in the backend and retrieving it from the cache. The tctl commands and webapi changes could probably both be in their own distinct and more focused PRs.

lib/auth/authclient/clt.go Outdated Show resolved Hide resolved
Comment on lines 2872 to 2888
// GetAutoupdateConfig gets autoupdate configuration.
func (c *Client) GetAutoupdateConfig(ctx context.Context) (*autoupdate.AutoupdateConfig, error) {
resp, err := c.AutoupdateServiceClient().GetAutoupdateConfig(ctx, &autoupdate.GetAutoupdateConfigRequest{})
if err != nil {
return nil, trace.Wrap(err)
}
return resp, nil
}

// GetAutoupdateVersion gets autoupdate version.
func (c *Client) GetAutoupdateVersion(ctx context.Context) (*autoupdate.AutoupdateVersion, error) {
resp, err := c.AutoupdateServiceClient().GetAutoupdateVersion(ctx, &autoupdate.GetAutoupdateVersionRequest{})
if err != nil {
return nil, trace.Wrap(err)
}
return resp, nil
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider consolidating the API here. If we offer AutoupdateServiceClient then let's have everyone use that instead of creating these helpers.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

after adding get methods for fetching config and version in find endpoint

interface ReadRemoteProxyAccessPoint {
	GetAutoupdateConfig(ctx context.Context) (*autoupdate.AutoupdateConfig, error)
	GetAutoupdateVersion(ctx context.Context) (*autoupdate.AutoupdateVersion, error)
}

cache.Cache and client.ClientI should implement these methods, otherwise if I replace this one to client get method I need to add some wrapper for https://github.com/gravitational/teleport/pull/45617/files#diff-3e237f973a30f7092dc18a706ecd95d8a7e1d99c5c50626b8bb0e7ac6cb7efd1R1899-R1920

api/types/autoupdate/config.go Show resolved Hide resolved
api/types/autoupdate/version.go Show resolved Hide resolved
lib/services/autoupdates.go Outdated Show resolved Hide resolved
lib/web/apiserver.go Outdated Show resolved Hide resolved
Comment on lines 46 to 48
// AutoupdateCommand implements the `tctl autoupdate` command for managing
// autoupdate process for tools and agents.
type AutoupdateCommand struct {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this resource be supported via tctl create and tctl get? Any reason to prefer managing auto update resources via tctl autoupdate instead?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The autoupdate subcommand was proposed by RJ here: https://github.com/gravitational/teleport/pull/39805/files#diff-8d3c0408dd826f27e9f13cd15f09f4d7e89202862f0b13ce131a2e3072c2a40dR249

Seems reasonable for both the subcommand and tctl create/tctl get to work?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that might be better from UX, when everything in one place and you able to configure autoupdates without having knowledge about resources responsible for this configuration.
I will additionally add these resources also to tctl create/get resource command

tool/tctl/common/autoupdate_command.go Outdated Show resolved Hide resolved
lib/services/local/autoupdate.go Outdated Show resolved Hide resolved
@public-teleport-github-review-bot

@vapopov - this PR will require admin approval to merge due to its size. Consider breaking it up into a series smaller changes.

lib/auth/grpcserver.go Outdated Show resolved Hide resolved
lib/web/apiserver.go Outdated Show resolved Hide resolved
Add tests for resources command
@vapopov vapopov force-pushed the vapopov/add-autoupdate-resources branch from 083fb77 to 4cceaac Compare August 27, 2024 21:16
@vapopov
Copy link
Contributor Author

vapopov commented Aug 30, 2024

@rosstimothy could you please take another look at the PR?

Copy link
Contributor

@rosstimothy rosstimothy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned before, I think it would be best if this PR was split up into several smaller, more focused PRs. I tend to recommend that for new resources folks try to split each layer of the boilerplate up into PRs in roughly the following order:

  1. resource and audit events proto and generated code
  2. backend storage service implementation
  3. RPC service implementation
  4. cache support
  5. tctl support
  6. audit event support

A good example to follow is the SPIFFEFederation resource that Noah recently added.

Comment on lines +38 to +40
Backend services.AutoupdateService
// Cache is the cache used to store autoupdate resources.
Cache services.AutoupdateServiceGetter
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion: consider using smaller, more well defined interfaces here for each of these containing only the methods expected to be called on each instead of relying on the services interface.

Comment on lines +45 to +46
// Opting out of forward compatibility, this service must implement all service methods.
autoupdate.UnsafeAutoupdateServiceServer
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any particular reason to go with this instead of the UnimplementedAutoupdateServiceServer?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is minimal requirement to be registered as service server, but we have to be sure that all methods implemented not to have nil pointer panic, will replace with UnimplementedAutoupdateServiceServer

Comment on lines +323 to +333
// KindAutoupdateConfig is the resource with autoupdate configuration.
KindAutoupdateConfig = "autoupdate_config"

// KindAutoupdateVersion is the resource with autoupdate versions.
KindAutoupdateVersion = "autoupdate_version"

// MetaNameAutoupdateConfig is the name of a configuration resource for autoupdate config.
MetaNameAutoupdateConfig = "autoupdate-config"

// MetaNameAutoupdateVersion is the name of a resource for autoupdate version.
MetaNameAutoupdateVersion = "autoupdate-version"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reading through the code I find the naming Autoupdate to look off - should we be using AutoUpdate instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We agreed with @sclevine to use Autoupdate instead camel case, both RFDs was modified to be consistent

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No strong opinion about this. The RFDs had a mixture of autoupdate_ / Autoupdate and auto_update_ / AutoUpdate prefixes, so we went with the former spelling everywhere to be consistent with the resource and command naming in the original Client Tools proposal: https://github.com/gravitational/teleport/pull/39805/files

@rosstimothy if you feel strongly that we should move the other way, or break consistency for identifiers in the codebase, no objections.

Comment on lines +35 to +36
autoupdateConfigPrefix = "autoupdate_config"
autoupdateVersionPrefix = "autoupdate_version"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same question about the naming of this resource. Is this entity an autoupdate or an auto update?

Suggested change
autoupdateConfigPrefix = "autoupdate_config"
autoupdateVersionPrefix = "autoupdate_version"
autoUpdateConfigPrefix = "auto_update_config"
autoUpdateVersionPrefix = "auto_update_version"

)

// Client is an AutoupdateService client that conforms to the following lib/services interfaces:
// - services.AutoupdateService
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should mention services in the api package since API does not an cannot depend on gravitational/teleport without creating an import cycle.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, will remove this one, we have other 4 clients declaring the same


// Client is an AutoupdateService client that conforms to the following lib/services interfaces:
// - services.AutoupdateService
type Client struct {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need a dedicated client? There isn't much going on here besides hiding gRPC requests. Consider following the same approach that Noah took with the SPIFFE resource:

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in codebase there are 3 ways how it is implemented, legacy one with interface in types, methods implementation and this one with wrapping grpc client to be interface compatible to service definition, this PR by iterations implemented all of them.

Last one was added because I was trying to eliminate methods declarations for client (as it was requested previously in this review)
1877695#diff-f5e514e352c12c01eab507e6d9bbdfa697791b35bf914d949b92245a8e950447R2873-R2889

and use only client wrapper:
1877695#diff-3bdff46f360deb2937ae725b5117a2462cf0bcaaff86400d08179c652a2ce2f3R2653

but its not possible right now because if we use cache wrapping, interfaces of the cache.Cache and authclient.ClientI must be compatible

interface ReadRemoteProxyAccessPoint {
	GetAutoupdateConfig(ctx context.Context) (*autoupdate.AutoupdateConfig, error)
	GetAutoupdateVersion(ctx context.Context) (*autoupdate.AutoupdateVersion, error)
}
type RemoteProxyAccessPoint interface {
	ReadRemoteProxyAccessPoint
	accessPoint
}

func NewRemoteProxyWrapper(base RemoteProxyAccessPoint, cache ReadRemoteProxyAccessPoint) RemoteProxyAccessPoint {...}

// newLocalCacheForRemoteProxy returns new instance of access point configured for a remote proxy.
func (process *TeleportProcess) newLocalCacheForRemoteProxy(clt authclient.ClientI, cacheName []string) (authclient.RemoteProxyAccessPoint, error) {
	// if caching is disabled, return access point
	if !process.Config.CachePolicy.Enabled {
		return clt, nil
	}

	cache, err := process.NewLocalCache(clt, cache.ForRemoteProxy, cacheName)
	if err != nil {
		return nil, trace.Wrap(err)
	}

	return authclient.NewRemoteProxyWrapper(clt, cache), nil
}

@vapopov
Copy link
Contributor Author

vapopov commented Sep 3, 2024

closed in prior to several PRs described in #45617 (review)

@vapopov vapopov closed this Sep 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport/branch/v16 size/lg tctl tctl - Teleport admin tool
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants