Initialize OpenFGA with a predefined StoreID

[ashok-an]

Why?

Like seeding DB engines with predefined DBs, there is a need to start a openFGA with predefined storeIDs (any valid ULID)

What is expected?

Run OpenFGA container with a seeding StoreID, a store should get created with the given ULID and appropriate log message displayed for verification

[jon-whit]

@ashok-an could you provide some examples of shell commands demonstrating what the OpenFGA startup process would look like with this?

What would an ideal cli interface look like to achieve this?

[ashok-an]

@ashok-an could you provide some examples of shell commands demonstrating what the OpenFGA startup process would look like with this?

What would an ideal cli interface look like to achieve this?

For simplicity, how it looks today is:

❯ fga store create --name "store-A"
{
  "store": {
    "created_at":"2023-11-08T04:12:09.966412585Z",
    "id":"01HEPJ2TBDBZEAMEWSGMP95SZ9",
    "name":"store-A",
    "updated_at":"2023-11-08T04:12:09.966412585Z"
  }
}

❯ fga store create --name "store-A"
{
  "store": {
    "created_at":"2023-11-08T04:12:14.882152171Z",
    "id":"01HEPJ2Z52WP8RK2G5CDNJ4MW5",
    "name":"store-A",
    "updated_at":"2023-11-08T04:12:14.882152171Z"
  }
}

What I mean/look for is:

❯ fga store create --name "store-A"
{
  "store": {
    "created_at":"2023-11-08T04:12:09.966412585Z",
    "id":"01HEPJ2TBDBZEAMEWSGMP95SZ9",
    "name":"store-A",
    "updated_at":"2023-11-08T04:12:09.966412585Z"
  }
}

❯ fga store create --name "store-A"
{
  "store": {
    "created_at":"2023-11-08T04:12:14.882152171Z", // original creation timestamp
    "id":"01HEPJ2Z52WP8RK2G5CDNJ4MW5", // original ID - 01HEPJ2TBDBZEAMEWSGMP95SZ9
    "name":"store-A",
    "updated_at":"2023-11-08T04:12:14.882152171Z"
  }
}

[jon-whit]

@ashok-an I think you may have accidentally copy/pasted the same thing twice. The two examples (before/after) are identical.

What I may infer from what you're trying to do, just based on the description you have, is that it sounds like you want an idempotent CreateStore method that operates on a Store name (e.g. only a single store of a given name can exist in OpenFGA). Is that what you mean?

[ashok-an]

Yes! -- Ashok

…

On Wed, Nov 8, 2023 at 10:34 PM Jonathan Whitaker ***@***.***> wrote: @ashok-an <https://github.com/ashok-an> I think you may have accidentally copy/pasted the same thing twice. The two examples (before/after) are identical. What I may infer from what you're trying to do, just based on the description you have, is that it sounds like you want an idempotent CreateStore method that operates on a Store name (e.g. only a single store of a given name can exist in OpenFGA). Is that what you mean? — Reply to this email directly, view it on GitHub <#1132 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH5YCT6L5CYFB2QA3H5MIL3YDO3QRAVCNFSM6AAAAAA7AULGJ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBSGMYDGMJYHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[github-actions]

It appears this issue has been stale for at least 14 days 🗓️. If no action is taken the maintainer team may consider closing the issue. Please reach out if you need feedback or follow up actions from the maintainer team.

[fsedano]

@jon-whit @ashok-an I updated an existing issue for this same use case:

#989

Thanks,

[github-actions]

It appears this issue has been stale for at least 14 days 🗓️. If no action is taken the maintainer team may consider closing the issue. Please reach out if you need feedback or follow up actions from the maintainer team.

[PatrickMunsey]

I just posted an issue in the cli repo openfga/cli#331 (comment) prior to coming accross this issue here.

Allowing store-id to be specified would be really benifitial in simplifying deployment configuration. The goal would be to have the entire openfga deployment and configuraiton being able to be achieved repeatably with pre defined values. Requiring randomly generated store-id that changes during each deployment to be used for cli connections is cumbersome as opposed to something like a db connection string.

Some examples of how the usage could look:
fga store import --file test-store.yaml --store-id 01HYHGP755KA1BQMBR568RVKKV
or
fga store create --name test-store --model test-model.fga --store-id 01HYHGP755KA1BQMBR568RVKKV

I foresee being able to specify model-id in a similar fation would go a long way as well.

[danielloader]

Yeah this would be quite useful, the alternative I've taken to is just using pg_dump and moving around a database instead and frankly it's not ideal.

For local dev/CI purposes being able to define the model id and the store id feel almost like a requirement for a docker compose stack.

[abdok96]

This is very essential when using docker compose and setting up some init scripts.
There should be a way to determine the store id so that it can be passed as env variable to other services.

[lvieirajr]

+1 to being able to set static model and store ids

[c-thiel]

+1 for this.

If we cannot set the store-id on store creation, then the store-id becomes dynamic state that needs to be stored.
This is super inconvenient for stateless docker or K8s setups.

Imagine a "migration" container that runs before the app and is supposed to set an auth model (schema) to openfga.

The first time it runs, it currently creates the store and gets a random ULID in return. It then has to pass this on to the application, for example via an emptyDir, which is already not nice.

The second time this container runs, it must determine which migration to apply next. As the container is stateless, it does not even know which stores exist. It has to paginate through all stores until the store name matches. If we could specify the store-id on creation, this wouldn't be required as the store-id becomes easy to manage static information.

[flex-seongbok]

How about making store name unique and search store by name?
I think what we need is reproducable and expectable environment.