https://www.gooddata.com/ logo
Join Slack
Powered by
Is there any way to make gooddata-cn-ce use an ext...
# gooddata-cn
v
Is there any way to make gooddata-cn-ce use an external idp, other than dex? e.g. Cognito? For development, we have an auth flow where it might be convenient to use the same auth as production
r
Yes, it is possible. As the CE will probably have a different hostname, just add properly formatter redirect_url to the existing (production) user pool client. Everything else related to configuring GD Organization is the same for CE as for production k8s deployment https://www.gooddata.com/developers/cloud-native/doc/2.3/manage-organization/set-up-authentication/aws-cognito/#configure-cognit[…]p-in-organization
❤️ 1
v
ah gotcha... let me wrap my head around that for a minute
but I think I see
and with GoodData CE... is there a limitation on workspaces?
we are not trying to circumvent licensing.. but trying to make dev environment more like prod
r
no, there's a limit on organization count (1)
v
ok
r
I understand
v
but on the k8s CN installation... I could create > 1 org ?
in case... I wanted to give an org per developer
for non-prod
r
no, it's not possible. In that case you'd need one CE per developer.
v
I meant k8s CN installation
ok... one CE per developer is fine...
r
I see. In CN (k8s), you may create one org per developer. But it's overkill unless you need a full isolation
v
sure... just feeling out what's possible... trying to do the simplest thing
but if CE can do multiple workspaces...that gets us there I think
r
I'd prefer one (or a few) shared dev envs (organizations) where all developers can cooperate. Each can have several workspaces.
But sure it's your decission 😉
v
for our configuration... that would not work... but yeah...I see it's possible
for production, there is a single root workspace... so all metric changes get done there
so you could isolate developers with workspaces... but... I think it would deviate from prod config
and probably make things more complicated
we'll see... there is a lot of knowledge to transfer... lots of stuff figured out
r
sure, the product is becoming pretty complex. If you use WS hierarchy, you can simulate the setup with multiple hierarchies, each developer could have his own. But it's just an idea, IDK how your setup looks like.
v
I'll have to think about it
r
but it would be inconvenient for declarative layout APIs
hmm
v
a user signs up, an org gets created, and then it creates a workspace for that account
and that workspace, inherits from the root
no metrics or anything get defined in the child workspaces
they are just for tenant separation
r
so these child WS are basically almost empty.
v
correct
GoodData has given us plenty to work with
we aren't stuck (yet)
I see at least one if not multiple paths forward
and it's not like there are 50 developers... it's just me an another person
but we still have to keep it sane in case anyone else has to work on it
or we forget how to work on it, and have to remember LOL
r
🙂
Basically there are 2 options. Both have pros and cons. Option A: single (shared) dev Org. Multiple WS hierarchies (one per developer). Option B: multiple Orgs (one per developer). Each org has a single WS hierarchy. A pros: • shared auth setup, shared datasource management • you can use it even in CE (b/c it's single organization) A cons: • difficult to manage a single hierarchy via declarative API (b/c these APIs always manage the whole organization, not just a part of it) • Doesn't exactly match production setup (you have multiple hierarchies) B pros: • strict isolation • exact match on production setup • /layout/ APIs work just fine B cons: • you'd need to deploy as many CE containers as many developers you have (not a big deal, if there are just two) • each org has fully separate management (users, DS, auth,...)
v
sure... the CE containers get run in a local docker-desktop k8 instance
so one CE per dev
great information, thanks for explaining that
helps a lot
r
what's "docker-desktop k8 instance" ?
v
Docker Desktop can run k8s
and that's the flavor we use
for local dev
r
and there you run CE within k8s inside docker-desktop?
v
so we have a k8s configuration that is similar to prod... but kustomized for local
yes we run the CE image in a k8 deployment
just for local development
we'd like to keep the ability to develop with all local components if possible
r
what are the benefits of running gooddata-cn-ce in k8s, if you run it on local docker-desktop? https? or something else?
b/c k8s brings a lot of extra overhead.
v
our system is just as complex as yours
there are a ton of other moving parts... and it's easier to develop against a configuration that is as similar to prod as possible
it allows us to deploy an environment to the developer's local desktop, that's similar to prod...
that's the theory anyway
r
I see. So developer runs a lot of other stuff in local k8s anyway, not just GD CE. Then it makes sense.
v
exactly
trying to keep the complexity down... but seems like there is no way to escape it
Open in Slack
PreviousNext
Powered by