<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Unity Catalog - Cluster Access Mode - Change Management in Administration &amp; Architecture</title>
    <link>https://community.databricks.com/t5/administration-architecture/unity-catalog-cluster-access-mode-change-management/m-p/3941#M13</link>
    <description>&lt;P&gt;Hi all,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I am curious to know how you handled change management when rolling out changes to cluster access modes (single user, shared) applicable to UC, especially when there is a centralized platform team offering Infrastructure Deployment services via DevOps for around 20+ projects building their use cases in Databricks Lakehouse.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I am trying to decouple the changes to cluster access modes, and roll-out those even before the UC upgrade starts, so the projects can deploy their Databricks jobs/workflows in "Single User" access mode already in Non-UC enabled workspaces (like they do currently on high concurrency, table acl enabled clusters with external hive metastore). Even though I notice "Single User" access mode in Non-UC workspaces, it seems I cannot use it against the cluster policy of existing table acl enabled clusters with external hive metastore.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;If this is not possible, then the option I think of is having a flag in the CI/CD code that signifies which environment (DEV/QAS/PRD) is UC enabled, and accordingly deploy jobs/workflows accordingly with appropriate cluster access modes.&lt;/P&gt;</description>
    <pubDate>Thu, 20 Mar 2025 16:23:26 GMT</pubDate>
    <dc:creator>NOOR_BASHASHAIK</dc:creator>
    <dc:date>2025-03-20T16:23:26Z</dc:date>
    <item>
      <title>Unity Catalog - Cluster Access Mode - Change Management</title>
      <link>https://community.databricks.com/t5/administration-architecture/unity-catalog-cluster-access-mode-change-management/m-p/3941#M13</link>
      <description>&lt;P&gt;Hi all,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I am curious to know how you handled change management when rolling out changes to cluster access modes (single user, shared) applicable to UC, especially when there is a centralized platform team offering Infrastructure Deployment services via DevOps for around 20+ projects building their use cases in Databricks Lakehouse.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I am trying to decouple the changes to cluster access modes, and roll-out those even before the UC upgrade starts, so the projects can deploy their Databricks jobs/workflows in "Single User" access mode already in Non-UC enabled workspaces (like they do currently on high concurrency, table acl enabled clusters with external hive metastore). Even though I notice "Single User" access mode in Non-UC workspaces, it seems I cannot use it against the cluster policy of existing table acl enabled clusters with external hive metastore.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;If this is not possible, then the option I think of is having a flag in the CI/CD code that signifies which environment (DEV/QAS/PRD) is UC enabled, and accordingly deploy jobs/workflows accordingly with appropriate cluster access modes.&lt;/P&gt;</description>
      <pubDate>Thu, 20 Mar 2025 16:23:26 GMT</pubDate>
      <guid>https://community.databricks.com/t5/administration-architecture/unity-catalog-cluster-access-mode-change-management/m-p/3941#M13</guid>
      <dc:creator>NOOR_BASHASHAIK</dc:creator>
      <dc:date>2025-03-20T16:23:26Z</dc:date>
    </item>
  </channel>
</rss>

