Single instance of Looker supporting Dev/QA/UAT

[Audy]

Hi All,

We have been struggling with setting up Dev/QA/UAT environments on a single instance of Looker.

Our core issue is around LookML - Git integration where it is too open to all users (access to multiple branches and operations) so setting up controls in terms of QA/UAT users only accessing specific read-only branch is something we do not have a solution for.

Secondly, we are using manifest.lkml to enable variables for gcp project, data connection, bigquery dataset but are struggling to find a way to embed that into git promotion where in we need to modify variable values to reflect QA or UAT values.

Any thoughts are really appreciated guys!

[David-Google · Accepted solution]

Hey there Audy,

Great use case and question! With regards to the issues surrounding the LookML<>Git integration, there should be controls on the Looker side that can help Admins distribute the correct level of access to all kinds of users. If you take a look at our permissions list doc, you can see that we have 3 "levels" of permissions for developers. The lowest level of permissions is `see_lookml` which enables folks to view the LookML behind the scenes, but they won't have the ability to toggle on development mode and adjust any code. The next level up would be `develop` which enables users to change the LookML code locally in their dev branch, with the final tier of access being `deploy` which enables developers to push their changes to production. Additionally, if you can use multiple account HTTPS git connections on your git repositories, that can help control access and permissions on the repository side as well. Because users are providing their own git user account information on a per-user basis, we can control which accounts have access to varying permissions on the repository from outside of Looker as well.

Regarding the manifest.lkml file you mentioned, would it be feasible to use parameterized connections in the Admin -> Connections panel? At a high level, user attributes can be used in database connections and I'm thinking it may be easier to assign dev/QA/prod attribute values than to update an ephemeral LookML file under the hood. Worst case scenario--if the manifest file is a hard requirement for this use case--it may be possible to use a tool like PyLookML to programmatically update the values within your manifest file to QA/UAT values as well.

Let me know if that ends up working out for you!

Best,

David

[Audy]

Thank You David.

I have applied permissions as suggested and looks like should enable limiting user access to what they can do with lookml across Dev/QA/UAT, will be testing with end users and see if anymore questions come up.

While mapping the roles and groups came upon an issue where GCP IAM based AD groups are not showing up by default in Looker and i also do not see LDAP section in the Looker Admin Authentication menu (e.g. i can see SAML). I have created another post for this issue.

We will be exploring pylookml and the user attribute option, atleast we have a path forward, I assume for the user attribute option i would need to use oauth connection to bigquery as currently  connection is using looker service account.

[David-Google]

Hey again Audy!

Just went and posted a reply to your other LDAP-related post, so hopefully that helps with that issue. In reference to your question about utilizing user attributes within a BQ connection, nope; no oauth required! Check out this screenshot:

Simply go to your Admin -> Connections menu, click the little user silhouette button next to the thing you want to parameterize (e.g. dataset, billing project ID, etc.), and then choose a user attribute from the dropdown list. Since these can be managed on the Looker-side, there isn't a need for oauth to be configured to get these user-specific values, although you may need to configure a couple of new user attributes in the Admin panel to support this use case.

Let me know if that clarifies things!

Best,
David

[Audy]

Thanks again David.

We were trying to use user attributes in a manner that we can use them to switch connections across Dev/QA/UAT on a single Looker instance. Looks like this needs multiple userid for an individual user, still looking into it, will get back once i have more clarity.