Buildpack Visibility

[Gocool272]

Thanks for submitting an issue to cloud_controller_ng. We are always trying to improve! To help us, please fill out the following template.

Issue

I have a basic question with respect to the Build-pack Visibility across our Environments We would like to understand if there is an option to hide / unhide build-packs in specific environments for any obvious purposes What I am trying to say is,

When i create a buildpack using the cf create-buildpack , i want to hide this buildpack with respect to specific Org and Space.

So when a specific user logs into CF with his account , he should not be able to see the buildpacks that we wish to hide

Context

I should be able to hide / unhide buildpacks according to the users at Org level or space level

Steps to Reproduce

cf api cf login cf buildpacks

Expected result

We as a CF admin should be able to hide / unhide buildpacks at Org or Space levels depending on the users

Current result

Unable to hide / unhide buildpacks that are shown from the cf buildpacks command All Orgs and Spaces display the same result as that of the cf buildpacks command

Possible Fix

Can enable the CC-DB show up the created build pack to display results like the cf service-access. BPs should be able to be hid / unhid

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/168428782

The labels on this github issue will be updated when the story is started.

[Gocool272]

Any update on this yet?

[cwlbraa]

There are no plans that I'm aware of to scope created buildpacks to spaces or orgs. I think if we were to build this, you're likely right that it'd look a bit like cf service-access.

This is an interesting feature request, but we'd like to know more about what you're trying to do. Why do you want to hide/unhide buildpacks? What problem does that solve for you?

[Gocool272]

@cwlbraa Alright, would like to give you a background around why we would like to see this feature up there We right now offer three different versions of any buildpack to the customers essentially the : Old, default and the beta

1) The challenge that we are facing is the application developers adaption to the beta / default buildpacks which they are reluctant about

2) We still have the builpack refresh and all that in place after enough soaking across all the environments, the customer migration from "Old" to "Default" or "Beta" is still a challenge

So , we would like to get away with the old builpack and that is when this availability comes into picture

We would still have the specific version of buildpack in the "cf buildpacks" , but we would hide it from the customers, so they do not use it This way, this particular version of buildpack could be used only for some show stopping circumstances and not give the customers a chance to use their own Custom Buildpack

We are basically trying to hide a specific version of buildpack from customers which still would be a part of the "cf buildpacks" command, in nutshell

[cwlbraa]

Interesting! I think one rough edge here is how hidden buildpacks should interact with buildpack detection. Would you prefer if they weren't used in detection? Or if they were used, but just not shown in the list? Keep in mind that pushing without a buildpack specified would fail if the push really needed a hidden one and it wasn't used in detection.

[Gocool272]

@cwlbraa : I'd prefer having it this way , if they were used, but just not shown in the list, so that the end users are not tempted to develop newer applications using an older version of buildpack whilst having a newer version of the same buildpack