-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/more flexibility for managed object names #480
base: main
Are you sure you want to change the base?
Feature/more flexibility for managed object names #480
Conversation
… managed object naming used in imports and exports
There is no v2 branch - a branch would need to be created from v2.3.1-0 to allow this to correctly target the correct codebase. |
@phalestrivir @hfranklin I really like the idea of what this PR is accomplishing and I wonder if it would align with what you guys are doing (making ForgeOps look like AIC). Please provide feedback on approach and if we should think about this in a larger scope or the approach in this PR is sufficient. |
I think this approach makes sense and is probably sufficient for this use case. I'm not familiar enough with Forgeops deployments to offer much feedback on this, but if it's possible to name the managed object for organizations whatever you want, then something we may want to do in the future is having an option that lets you specify the name of the managed object used for organizations, that way we aren't limited to "managed/organization", "managed/alpha_organization", etc. However, I would think this use case where you name it something different than one of these names is probably pretty rare, so I don't think it would be worthwhile to support something like this yet, I think supporting just the realm variants is good enough. |
I'm looking to adapt this pair of PRs onto the v3 codebase (and update our config to be able to use v3 too). I'm happy to modify this to be a string prefix option if needed, to provide more flexibility. Something like: Just let me know. Will continue as is for now. |
I have applied this same approach to a v3 branch of frodo cli & lib. Just let me know if you think it's worth me porting this code change to a new PR to target main. |
Our use case for frodo is not executing correctly due to the logic in place to decide what the managed object name should be.
In a cloud deployment, the managed objects (user, application and organization) get the realm prefix, but in other types that is omitted, e.g.
managed/alpha_user
managed/organization
We are working on replicating the alpha & bravo realm in a local deployment, so having some flexibility on this is needed.
Do you think this can be retrofitted into the 2.X codebase and released? Currently we are relying on a fork for our needs.
If this is accepted, once we can migrate to 3.X I am happy to apply this to v3 too.
Also added cli option in this PR: frodo-cli#464
Thanks!