Hub 1.14.0 Scheduling via KNIME Desktop will only have TEAMS secrets available

This “new” feature was un-expected, when looking in Changelog (KNIME Analytics Platform 5.4.4). But was found in Changelog (KNIME Business Hub 1.14)

And it caused a great deal of pain today…
5.4.4 Snowflake Connector : Execute failed: Invalid state: Connection pool shut down. A potential cause is closing of a connection when a query is still running. - KNIME Business Hub - KNIME Community Forum

So, what is so new? : Team-scoped deployment execution

KNIME has introduced a new setting when Scheduling: Execution Scope

If set to “Team”, only the Team secrets are available during execution. And the “active” user for Kerberos authentication is now the Team name, and not the user name.
image

  • Team: Only Teams secrets + Team as Kerberos user
  • User: Teams + personal secrets + Creator as Kerberos user

The default settings for “NEW” scheduled jobs is “Team”.

This unfortunately conflicts with our internal recommendations to have “Snowflake OAuth” secrets stored in the Personal Secret store. And it messes up workflows that authenticate with Kerberos.

We now need to advice our users to use “User” when creating a new schedule via “Advanced settings”.
image
image

If you use KNIME Desktop,

  • There is no option to set Scope to “User” in the interface.
  • And the default will be set to “Team”
  • And, it’s NOT possible to change in the browser…
  • (And it’s still not possible to create a version first)

image

KNIME is moving more and more in the way of the “Modern UI” and “leaving” the “classic user interface”.

When using the “Modern UI”, there is no option to schedule in the interface, but a link to the HUB to do it.

Here you can:

  • Create a version
  • Schedule a workflow and set User as scope

BUT: Could we please have options that are “backward” compatible with previous behaviour? So scheduling via “Classic interface” in Desktop, will create a “User” context.

1 Like

Hi @tescnovonesis ,
Thank you for sharing your feedback. I’m summarizing the response my colleague provided to this in your separate Support ticket, so the response is publicly available:

We will introduce the ability to set the default scope at the Execution Context (EC) level. We’ve opened an internal case to track and address this.
This should also address the backwards compatibility aspect.