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

Enabling Secrets Sync for HVD #26841

Merged
merged 17 commits into from
May 9, 2024
Merged

Conversation

Monkeychip
Copy link
Contributor

@Monkeychip Monkeychip commented May 6, 2024

  • enterprise test pass

The main focus of this PR is to allow HVD managed clusters to access Secrets Sync. This requires that the UI allow HVD users to activate Secrets Sync and see Secrets Sync from within Client Counts and Sidebar nav. In order to activate from an hvd cluster, the backend now accepts "admin" as a namespace header when POST'ing to the secrets-sync/activate endpoint. The backend still expects namespace: null for non-hvd clusters.

The UI cannot tell if the HVD cluster actually has Secrets Sync on their license so we display an error depending on whatever the backend returns.

Additionally, this PR:

  • renames the getter on the flag service from managedNamespaceRoot to hvdManagedNamespaceRoot
  • separates out the client counts nav bar into it's own component for easier reading/testing.
  • uses the flag service to check if a user has permissions to post to the activate endpoint and hides activation actions depending on their permissions.
  • Adds another badge text option of "plus" for hvd clusters.
  • reduces the description on the upsell to one message instead of custom messages for premium vs enterprise vs plus.
  • calls the feature-flags endpoint for a concurrency task on the flag service instead of inside the application route.

Walk through video of user with activate permissions (root user) on an hvd cluster

secrets_sync_hvd.mov

Walk through video of user who does not have activate permissions (default policy) on an hvd cluster

permissions.mov

Monkeychip and others added 5 commits April 29, 2024 16:05
…26649)

* update badge text and allow hvd on secrets sync views

* update logic in Secrets Sync overview and cta for hvd.

* spacing

* rearrange based on pr feedback

* fix return on badgeText and cluster nav test

* fix landing cta tests

* update test to reflect new changes

* moved call to feature-flags from application route to the service to match patterns

* add managed test coverage on overview component test and remove premium feature so cta message appplies to both managed and non-managed clusters

* missed service name and unskip admin test

* clean up

* fix tests

* flags test fix
* renames

* lowercase HVD to match

* missed some

* test failure
…26713)

* feat: split client counts navbar into separate component

* acceptance/clients/counts/overview-test: remove tests now covered by int tests

* clients counts route: rename isSecretsSyncActivated to showSecretsSync

* sync clients page: show unactivated state unless sync client history or feature is activated

* client counts navbar: show sync tab only if client history or is /able to be/ activated

* clients overview page: only show sync charts if activated

* fix: rename isManaged to isHvd

* acceptance/counts/overview-test: add HVD tests

* acceptance/counts/overview-test: clean up unused cruft

* aceptance/clients/counts/overview-test: ensure we dont get false negatives

* chore: move Clients::Error to Clients::Counts::Error

* chore: calculate showSecretSync in page component instead of route

* chore: add copyright headers

* acceptance/clients/counts/overview-test: stub activated flags to fix test
* acceptance/clients/counts/overview-test: use imported test selectors

* general-selectors: add missing emptyStateSubtitle property

* acceptance/clients/counts/sync: nest tests in top level module for easier test runs
Monkeychip added 2 commits May 6, 2024 16:19
* add permissions check to flags service and consume in overview template

* add back missing refresh

* fix test failures

* add test coverage

* clean up

* address flaky test

* grr
@github-actions github-actions bot added the hashicorp-contributed-pr If the PR is HashiCorp (i.e. not-community) contributed label May 7, 2024
Copy link

github-actions bot commented May 7, 2024

CI Results:
All Go tests succeeded! ✅

@Monkeychip Monkeychip changed the title WIP: Sidebranch for enabling Secrets Sync HVD Enabling Secrets Sync for HVD May 8, 2024
@Monkeychip Monkeychip marked this pull request as ready for review May 8, 2024 15:54
@Monkeychip Monkeychip requested review from a team as code owners May 8, 2024 15:54
Copy link

github-actions bot commented May 8, 2024

Build Results:
All builds succeeded! ✅

Copy link
Contributor

@hashishaw hashishaw left a comment

Choose a reason for hiding this comment

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

So much great cleanup work! Some things to consider but nothing blocking

if (this.version.isCommunity) return 'Enterprise';
if (!this.version.hasSecretsSync) return 'Premium';
return undefined;
if (isHvdManaged) return 'Plus';
Copy link
Contributor

Choose a reason for hiding this comment

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

To make sure I understand correctly -- HVD vault clusters will show the "Plus" badge next to this nav item, whether or not their cluster is plus tier?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Correct. The UI will cannot tell if the hvd cluster is plus or not, so we're basically upselling it to plus.

this.flagsService.setFeatureFlags(flags);
}
beforeModel() {
return this.flagsService.fetchFeatureFlags();
Copy link
Contributor

Choose a reason for hiding this comment

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

much cleaner 👏

});

fetchFeatureFlags() {
return this.getFeatureFlags.perform();
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 want to add any kind of caching, so that we don't refetch the flags if they've already been retrieved?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Another conservative approach on my end. The previous behavior did not have a caching check and because we use this response for things outside Secrets Sync I didn't want to modify the behavior. 😬

method: 'GET',
});

if (result.status === 200) {
Copy link
Contributor

Choose a reason for hiding this comment

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

we're swallowing any errors that might happen from the API, since those will return with a non-200 status. Is that intentional?

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 carried over the previous method exactly as it was in fear of changing the behavior from how it was before.

{{/if}}
{{#unless @isActivated}}
{{#if (or @licenseHasSecretsSync @isHvdManaged)}}
{{#unless this.hideOptIn}}
Copy link
Contributor

Choose a reason for hiding this comment

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

These if statements 😵 I wonder if we can move this logic to a backing class?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Let me add this as a todo and revisit when Noelle returns. There's been a lot of back and forth on how to work through this logic (a persona service, etc). Additionally, there's a solid chance that an api change will clean some of this logic up.

@@ -71,10 +75,12 @@ export default class SyncSecretsDestinationsPageComponent extends Component<Args
@task
@waitFor
*onFeatureConfirm() {
// must return null instead of root for non managed cluster.
const namespace = this.args.isHvdManaged ? 'admin' : null;
Copy link
Contributor

Choose a reason for hiding this comment

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

The behavior is still that it can only be enabled in root or admin, right? Not other child namespaces? Might be good to add that to the comment

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yep, you're correct. And I'll amend the comment to include, good idea.

await click('[data-test-show-calendar]');
await click('[data-test-previous-year]');
await click(`[data-test-calendar-month=${ARRAY_OF_MONTHS[LICENSE_START.getMonth()]}]`);
await click(CLIENT_COUNT.calendarWidget.customEndMonth);
Copy link
Contributor

Choose a reason for hiding this comment

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

👏

@Monkeychip Monkeychip merged commit 077c70f into main May 9, 2024
31 checks passed
@Monkeychip Monkeychip deleted the ui/VAULT-25468/enable-secrets-sync-hvd branch May 9, 2024 21:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hashicorp-contributed-pr If the PR is HashiCorp (i.e. not-community) contributed ui
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants