Seasoned ⭐️⭐️⭐️

Solved

Bootstrap CLI - Space support + Custom group support

5 replies
116 views

Hi Team,

Does bootstrap-cli supports space creation? If yes, can I get sample config format for space creation.

Also , we noticed that using bootstrap-cli, w can create groups related to rawDbs or datasets based on specified namespace and nodes. Is there a way we can create custom groups or granular groups which can be linked to spaces and not related to datasets or raw DBS?

Thanks,

Snehal.

Peter ArwanitisAnswer

Practitioner ⭐️⭐️⭐️

Hi @Snehal-Jagtap

glad to here that v3.0.0-beta.1 is working for you :)

Please follow the releases, to catch up with new ones.

> Will there be any cost impact if the bootstrap-cli creates some Datasets, RAWDbs or Spaces and if some of those are unused.?

The answer is no, there is no impact.

> Also, are there any plans to include groups for granular level access in bootstrap-cli, like access on specific instances or timeseries objects, etc.

No, because this is -- kind of -- already supported:

for each access-control requirement => you have to establish an `idp-cdf-mapping` which means, linking one of your AAD Groups to one (or more) of the CDF Groups available based on your bootstrap-cli configuration
creating the right amount of namespaces/nodes allows you to express your project semantics (terminology)

The “template approach” of bootstrap-cli is creating all scopes for you, but -- as pointed out in last post -- with only two templates of capabilities: OWNER and READ

so you get more capabilities as you might need, but due to the tailored AAD > CDF Group only the mapped users/service-apps get access to data
like before: ignore the additional capabilities, they don’t break your data-lineage (governance), as this is controlled on the scope level (datasets)

The design decision of having a “configuration-driven templated access-control” provides you some overhead, but for the benefit of a transparent and understandable access-control and data-lineage (governance).

I fully understand your approach and thinking to *individually minimize* access-control, which you can do w/o bootstrap-cli in a manual configuration. But I’m confident that the templated concept of bootstrap-cli helps you to solve your access-control requirements!

(=PA=)

J

Jason Dressel

Expert ⭐️⭐️⭐️⭐️

@Peter Arwanitis fyi. I had a call with @Snehal-Jagtap this morning. She’s looking for an example using spaces and has a few other asks. I mentioned that you could assist faster than I can 😀.

Peter Arwanitis

Practitioner ⭐️⭐️⭐️

Hi @Snehal-Jagtap,

-- 1. part about ‘spaces’ support available with bootstrap-cli ---

You can get full ”spaces” support (equal to “datasets”) from a bootstrap-cli pre-release (release candidate):

https://github.com/cognitedata/inso-bootstrap-cli/releases/tag/v3.0.0-beta.1

As noted in release notes it is already ok to use it in production environment, and I expect no configuration changes for the official v3 release :)

In case you used bootstrap-cli before with v2, please read through the linked migration guide and the provided config-example for v3.

Please let me know if you run into problem, which I can help you to fix.

Bets regards

Peter

(=PA=)

Peter Arwanitis

Practitioner ⭐️⭐️⭐️

-- 2. part about ‘custom groups or granular groups’ ---

I’m not sure that I fully understood your idea?

Using “bootstrap-cli” provides you a fully templated-setup, following the namespaces and node-names.

By design it avoids customization (which typically harms transparency).

Instead you are encouraged to configure “namespaces & nodes”, let’s say:

`src:001:weather`
- for managing your RAW and cleansed weather data in CDF RAW, CDF Time Series and CDF Events (as an example)
`uc:004:forecast`
- for managing you source and domain data-models

Using “templates” means you get more than you asked for, simply ignore everything which you don’t need.

only use provided RAWDb `src:001:weather:db` and Dataset `src:001:weather:ds` to manage your raw-tables, time-series and events
only use provided Space `src-001-weather-spc` to manage your data-models and data-model-instances

With this approach, a lot of Datasets, RAWDbs or Spaces are created by bootstrap-cli according to your configuration, but not necessarily used.

This “waste” is fine and designed by intent.

FYI: Same templating happens for access-control, where you can choose between a READ or OWNER role to connect (`idp-cdf-mapping`) to your AAD => for each of your namespaces & nodes.

I hope I was able to respond to your concern / question?

(=PA=)

S

Snehal-JagtapAuthor

Seasoned ⭐️⭐️⭐️

Thanks for the details Peter👍. We tried using the new release which is working fine.

Will there be any cost impact if the bootstrap-cli creates some Datasets, RAWDbs or Spaces and if some of those are unused.?? @Peter Arwanitis @Jason Dressel. Also, are there any plans to include groups for granular level access in bootstrap-cli, like access on specific instances or timeseries objects, etc.

Peter ArwanitisAnswer

Practitioner ⭐️⭐️⭐️

Hi @Snehal-Jagtap

glad to here that v3.0.0-beta.1 is working for you :)

Please follow the releases, to catch up with new ones.

> Will there be any cost impact if the bootstrap-cli creates some Datasets, RAWDbs or Spaces and if some of those are unused.?

The answer is no, there is no impact.

> Also, are there any plans to include groups for granular level access in bootstrap-cli, like access on specific instances or timeseries objects, etc.

No, because this is -- kind of -- already supported:

for each access-control requirement => you have to establish an `idp-cdf-mapping` which means, linking one of your AAD Groups to one (or more) of the CDF Groups available based on your bootstrap-cli configuration
creating the right amount of namespaces/nodes allows you to express your project semantics (terminology)

The “template approach” of bootstrap-cli is creating all scopes for you, but -- as pointed out in last post -- with only two templates of capabilities: OWNER and READ

so you get more capabilities as you might need, but due to the tailored AAD > CDF Group only the mapped users/service-apps get access to data
like before: ignore the additional capabilities, they don’t break your data-lineage (governance), as this is controlled on the scope level (datasets)

The design decision of having a “configuration-driven templated access-control” provides you some overhead, but for the benefit of a transparent and understandable access-control and data-lineage (governance).

I fully understand your approach and thinking to *individually minimize* access-control, which you can do w/o bootstrap-cli in a manual configuration. But I’m confident that the templated concept of bootstrap-cli helps you to solve your access-control requirements!

(=PA=)

Sign up

Welcome to Cognite Hub