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 feature flag for enable_release_channels #1910

Merged
merged 3 commits into from
Dec 4, 2024

Conversation

sfc-gh-melnacouzi
Copy link
Contributor

@sfc-gh-melnacouzi sfc-gh-melnacouzi commented Dec 2, 2024

Pre-review checklist

  • I've confirmed that instructions included in README.md are still correct after my changes in the codebase.
  • I've added or updated automated unit tests to verify correctness of my new code.
  • I've added or updated integration tests to verify correctness of my new code.
  • I've confirmed that my changes are working by executing CLI's commands manually on MacOS.
  • I've confirmed that my changes are working by executing CLI's commands manually on Windows.
  • I've confirmed that my changes are up-to-date with the target branch.
  • I've described my changes in the release notes.
  • I've described my changes in the section below.

Changes description

  • Add feature flag (in config.toml) for enable_release_channels
  • Feature flag has to be explicitly enabled or disabled for it to take effect. Otherwise, we will rely on the default in the backend.
  • For the feature flag to be respected, release channels need to be enabled in the account. That's why we check the parameter first before attempting to update the flag on the application package.
  • Use the flag when creating/updating application package

@sfc-gh-melnacouzi sfc-gh-melnacouzi requested review from a team as code owners December 2, 2024 15:01


def get_ui_parameter(
conn: SnowflakeConnection, parameter: UIParameter, default: Any
) -> str:
conn: SnowflakeConnection, parameter: UIParameter, default: T
Copy link
Contributor

Choose a reason for hiding this comment

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

this is an odd signature. If we find a value, then it's for sure a string. If we fall back to the default, it could be something else. Shouldn't the default be something like Optional[str] instead?

Copy link
Contributor Author

@sfc-gh-melnacouzi sfc-gh-melnacouzi Dec 2, 2024

Choose a reason for hiding this comment

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

I tried it - it doesn't help much because type checker will complain about None not having .lower() function. This one works nicely for typechecking.
i.e. since the return type is str | T, the type checker is able to smartly reason about it based on the passed in default.

@@ -155,5 +155,5 @@ def _should_invoke_processors(self):

def _is_enabled(self, processor: ProcessorMapping) -> bool:
if processor.name.lower() == NA_SETUP_PROCESSOR:
return FeatureFlag.ENABLE_NATIVE_APP_PYTHON_SETUP.is_enabled()
return FeatureFlag.ENABLE_NATIVE_APP_PYTHON_SETUP.get_flag_value() is True
Copy link
Contributor

Choose a reason for hiding this comment

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

couldn't we alias is_enabled to this so that we can use either kind of feature flag without worrying about the difference?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

How do you suggest doing this?

  • is_enabled: True if set to true, False if set to False, None otherwise?
  • is_disabled: True if set to false, False if set to True, None otherwise?

OR:

  • is_enabled: True if set to true, False otherwise (including None).
  • is_disabled: False if set to false, False otherwise (including None).
    Optional: - is_set: True if explicitly set.

WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

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

I was thinking: is_enabled(default: False), so by default, the 2nd option you listed, but the first one can be retrofitted.

"ENABLE_NATIVE_APP_PYTHON_SETUP", False
)
ENABLE_RELEASE_CHANNELS = OptionalBooleanFlag("ENABLE_RELEASE_CHANNELS", None)
Copy link
Contributor

Choose a reason for hiding this comment

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

heads up: you and Guy will have conflicts here


if feature_flag_from_config is not None and not feature_enabled_in_account:
self._workspace_ctx.console.warning(
f"Cannot use feature flag {FeatureFlag.ENABLE_RELEASE_CHANNELS.name} because release channels are not enabled in the current account."
Copy link
Contributor

Choose a reason for hiding this comment

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

this is a warning, but the wording suggests an error. I'd prefer to word it so that the user knows the feature flag will be essentially ignored.

sfc-gh-astus
sfc-gh-astus previously approved these changes Dec 2, 2024
@sfc-gh-melnacouzi sfc-gh-melnacouzi force-pushed the melnacouzi-add-release-channel-feature-flag branch from f7a47f8 to fce7d76 Compare December 3, 2024 16:32
src/snowflake/cli/_plugins/connection/util.py Show resolved Hide resolved
@@ -286,8 +286,12 @@ def get_config_value(*path, key: str, default: Optional[Any] = Empty) -> Any:
raise


def get_config_bool_value(*path, key: str, default: Optional[Any] = Empty) -> bool:
value = get_config_value(*path, key=key, default=default)
def get_config_bool_value(*path, key: str, default: Any = Empty) -> bool | None:
Copy link
Contributor

Choose a reason for hiding this comment

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

that signature doesn't make sense to me, looks like we can return Optional[Any] with the current logic. That wasn't the case before because we tried to cast any value to a bool.

Do we really need Any anyway? Optional[bool] is probably a lot more intuitive.

@sfc-gh-melnacouzi sfc-gh-melnacouzi force-pushed the melnacouzi-add-release-channel-feature-flag branch from b9c8c05 to c393435 Compare December 3, 2024 16:53
@sfc-gh-melnacouzi sfc-gh-melnacouzi enabled auto-merge (squash) December 3, 2024 17:02
@sfc-gh-melnacouzi sfc-gh-melnacouzi merged commit c00c2e2 into main Dec 4, 2024
20 checks passed
@sfc-gh-melnacouzi sfc-gh-melnacouzi deleted the melnacouzi-add-release-channel-feature-flag branch December 4, 2024 13:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants