Skip to main content
Solved

Bootstrap CLI - Space support + Custom group support

S
Seasoned

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.

Best answer by Peter Arwanitis

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=)

View original
    Did this topic help you find an answer to your question?

    J
    Seasoned Practitioner
    Forum|alt.badge.img

    @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
    Forum|alt.badge.img

    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):

    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
    Forum|alt.badge.img

    -- 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:

    1. `src:001:weather`
      • for managing your RAW and cleansed weather data in CDF RAW, CDF Time Series and CDF Events (as an example)
    2. `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.

    1. only use provided RAWDb `src:001:weather:db` and Dataset `src:001:weather:ds` to manage your raw-tables, time-series and events
    2. 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
    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 Arwanitis
    1 person likes this
    • Peter Arwanitis
      Peter Arwanitis
    Peter Arwanitis
    Practitioner
    Forum|alt.badge.img

    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
    1 person likes this
    • J
      Jason Dressel

    Reply


    Terms & ConditionsCookie Settings

    Cookie Policy

    We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

     
    Cookie Settings