This issue is to roll out the feature on production,
that is currently behind the ai_impact_only_on_duo_enterprise feature flag.
Owners
Most appropriate Slack channel to reach out to: #g_plan_optimize
Best individual to reach out to: @
Expectations
What are we expecting to happen?
What can go wrong and how would we detect it?
Rollout Steps
Note: Please make sure to run the chatops commands in the Slack channel that gets impacted by the command.
Release the feature
After the feature has been deemed stable,
the clean up
should be done as soon as possible to permanently enable the feature and reduce complexity in the
codebase.
Create a merge request to remove the ai_impact_only_on_duo_enterprise feature flag. Ask for review/approval/merge as usual. The MR should include the following changes:
Remove all references to the feature flag from the codebase.
Remove the YAML definitions for the feature from the repository.
Ensure that the cleanup MR has been included in the release package.
If the merge request was deployed before the monthly release was tagged,
the feature can be officially announced in a release blog post: /chatops run release check https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163036 17.4
Close the feature issue to indicate the feature will be released in the current milestone.
Clean up the feature flag from all environments by running these chatops command in #production channel: /chatops run feature delete ai_impact_only_on_duo_enterprise --dev --pre --staging --staging-ref --production
Close this rollout issue.
Rollback Steps
This feature can be disabled on production by running the following Chatops command:
/chatops run feature set ai_impact_only_on_duo_enterprise false
Disable the feature flag on non-production environments:
/chatops run feature set ai_impact_only_on_duo_enterprise false --dev --pre --staging --staging-ref
Delete feature flag from all environments:
/chatops run feature delete ai_impact_only_on_duo_enterprise --dev --pre --staging --staging-ref --production
Create an additional feature flag to rollout only for self-managed
For self-managed we start to ignore ai_impact_only_on_duo_pro FF on %17.5 by considering it as enabled. This way when the release happens duo-enterprise will be required when user upgrades and we can still control the rollout on SaaS
Use a hard-cut off date, and add that logic in code.
@pshutsin I mean hardcode that when self-managed is considered enabled.
I think we can enable it by default in 17.5 and still have control over it on .com
Yes, the problem is if we default enable without the self-managed check in the code customers can turn it off and keep using the feature as it was still on trial period. I am ok with only default enabling it if this is not a problem.
@felipe_artur Hmm I thought we have some kind of JWT to protect against that. I think it's worth to add code creation team to the conversation maybe they can share their thoughts.
@pshutsin That was my first thought too, after this discussion it was clarified that AI impact analytics should not rely on Cloud Connector JWT for access control.
@felipe_artur so the data will be present with "Duo Pro" but the analytics is only available with "Duo Enterprise" and in theory someone shameless can modify the code to use AI Impact with Pro only, is it correct?
In this case I think default_enabled: true is not much different from hardcoding except that it leaves less debt in the code. Both approaches can be hacked if the one will.
shameless can modify the code to use AI Impact with Pro only, is it correct?
Yes
In this case I think default_enabled: true is not much different from hardcoding except that it leaves less debt in the code.
Yes, not much difference. It is easier to bypass the feature flag stragegy because we even document how to do so . I am also ok to default enabling it, we just need to ensure it is turned off on .com until the cut-off date.
@felipe_artur This issue looks like it may slip this current milestone. Can you leave a or to signify if you are on track to deliver this issue?
Please also consider updating the issue's Health Status or Milestone to reflect its current state,
and communicate with your Product Manager as appropriate.
Hi @blabuschagne I think it makes more sense for groupoptimize to enable the feature flag, as they'll know how to validate and test it better. We're happy to help co-ordinate the FF on the Staging-side and on the testing instances though.
@blabuschagne I'm not sure who exactly is toggling the feature flags on Production - @cersoz would you happen to know? If not, is there usually a process for co-ordinating a set of feature flags like the one for free access cut-off?
We hadn't discussed the toggling of the feature flags on 2024-10-17 specifically. I had assumed that each team would toggle their own. @vburton would have only been responsible for the feature flags in Staging to facilitate testing (which has completed).
@gitlab-org/duo-feature-access-testing
I'm tagging in here our PMs and EMs for our testing teams to see if each team toggling their own on flags on 2024-10-17 surfaces any major concerns.
I believe that Trials has planned (per the day-of rollout plan) to toggle their own.
I was just wondering if this was going to be coordinated by an individual to ensure synchronised timing, but if that's not a concern then I'll just enable the feature flag at some point on the 17th.
Hi everyone, I am back from PTO today. Thank you @cersoz and @mtimoustafa for the help in following up on this.
To help clear up some confusion, the access cut-off feature flags listed here (with the exception of AI Impact Dashboard) were for testing purposes only and do not need to be enabled in production in order for cut-off to take effect. Based on my understanding, the cut-off should be automatic based on the cut_off_date defined in access_data.yml in GitLab (for SaaS) and cloud_connector.yml in CustomersDot (for self-managed). @nmilojevic1 could you please help confirm and clarify anything else I may be missing for the teams here?
I believe the only exception to this was the AI Impact Dashboard, as that feature does not have a Cloud Connector service, and this flag needed to be created for this feature specifically to control its access cut-off. I agree, this feature flag will be best managed by groupoptimize. @blabuschagne can you please help confirm that was the intent?
@felipe_artur This issue looks like it may slip this current milestone. Can you leave a or to signify if you are on track to deliver this issue?
Please also consider updating the issue's Health Status or Milestone to reflect its current state,
and communicate with your Product Manager as appropriate.