-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Conversation
…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
* 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
CI Results: |
Build Results: |
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.
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'; |
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.
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?
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.
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(); |
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.
much cleaner 👏
}); | ||
|
||
fetchFeatureFlags() { | ||
return this.getFeatureFlags.perform(); |
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.
Do we want to add any kind of caching, so that we don't refetch the flags if they've already been retrieved?
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.
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) { |
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're swallowing any errors that might happen from the API, since those will return with a non-200 status. Is that intentional?
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 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}} |
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.
These if statements 😵 I wonder if we can move this logic to a backing class?
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.
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; |
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 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
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.
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); |
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 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 expectsnamespace: 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:
managedNamespaceRoot
tohvdManagedNamespaceRoot
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