-
Notifications
You must be signed in to change notification settings - Fork 67
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
"CF-ServicePlanVisibilityAlreadyExists" with new "service-access" approach #197
Comments
Can you provide the output of |
$ cf service-access
Getting service access as coffee-squirrel...
broker: app-autoscaler
service plan access orgs
app-autoscaler standard all
broker: identity-service-broker
service plan access orgs
p-identity sso-devl all
p-identity uaa none
broker: nfsbroker
service plan access orgs
nfs-legacy Existing limited sandbox-org,system
nfs Existing limited sandbox-org,system
broker: redis-odb
service plan access orgs
p.redis cache-large all
p.redis cache-medium all
p.redis cache-small all
broker: smbbroker
service plan access orgs
smb Existing all |
@coffee-squirrel Wasn't able to exactly reproduce this but added some additional debug logging if you can try with https://github.com/pivotalservices/cf-mgmt/releases/tag/v1.0.32 and provide output if still having issues. |
@calebwashburn Sure, here's build 4:
There are 3 Orgs:
|
@coffee-squirrel I believe I have this ran into a corner - https://github.com/pivotalservices/cf-mgmt/releases/tag/v1.0.33 |
@calebwashburn Looks like I've noticed, however, it's giving
|
@coffee-squirrel It will only give access to protected orgs that match orgs that exist. It processes this list of patterns to find orgs that match and always grants limited service-access to those orgs due to brokers, etc that get deployed into orgs that you aren't managing with cf-mgmt. Interesting that for some reason your sandbox-org was a duplicate somehow which either is due to it being listed and being a protected-org or there is another bug somewhere that I need to chase down. Can you share a few more details about your deployment?
Thanks |
@calebwashburn : Okay, I had assumed
# Organizations
orgs:
- sandbox-org
- delivery
# Allow deleting Organizations
enable-delete-orgs: true
# Always ignore these Organizations
protected_orgs:
- system
- p-spring-cloud-services
- splunk-nozzle-org
- redis-test-ORG*
- appdynamics-org
- org-*
$ cf orgs
Getting orgs as coffee-squirrel...
name
delivery
sandbox-org
system |
Closing this issue as assume it's fixed now. |
When trying out the new
cf-mgmt service-access
(#160; v1.0.31) we ran into the error below at the first occurrence of an Org already having access to a particular service plan.Our process was to:
cf-mgmt export-service-access-config
to update the config (removedservice-access: {}
, generatedservice-access
, etc.)enable-service-access: true
(as we hadn't used it prior)cf-mgmt service-access
Here's a stripped-down extract from this foundation's
cf-mgmt.yml
:API version is 2.135.0 (PAS 2.6.4).
The text was updated successfully, but these errors were encountered: