-
Notifications
You must be signed in to change notification settings - Fork 5
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
Support for kpack service bindings #5
Comments
@dmikusa - We are looking for similar feature, so is there any plan to get this in near future ? |
Please check out paketo-buildpacks/rfcs#302. I think this is going to be the path forward for most users with respect to dependency mapping. Please let me know though. To move this one forward, i think I'd need to get some examples of what we need the tool to generate. I don't have kpack deployed, so I can't easily make them. If you give me some templates, it's pretty easy to make the tool generate them. |
If my understanding is right ,currently pack users should use the --volume flag to mount a binding directory into the build or app containers. Users of the kpack platform should store key value pairs in a Kubernetes Secret and provide that secret and associated metadata to an Image as described in the kpack documentation(opens in a new tab). Is binding tool going to supports creation of secrets in future ? |
@dmikusa - Can above format be possible from the bt tool ? |
Yes, the tool could definitely generate secrets. What is your thought on how to tell the CLI you want it to generate the secrets file? I could add a flag to Also, what is your thought on running the command multiple times? I suspect that we'd need to read the secrets file, locate the particular dependency mapping and then update it (if modified) or add new mappings to the list of mappings. Does that sound reasonable? |
Yes, Something like bt dm --k8s-secrets should work. I think we can just add new mappings to the list when command is run multiple times. |
@dmikusa Just checking if the above capability is added to the tool? |
Sorry @doddisam I went to look at this again, and I'm not sure I follow in terms of what the value of the secret should be. In the example you provided, it's pointing to artifactory, which isn't really consistent with what the tool does now. It's purpose is to fetch from remote URLs and to generate a local folder structure that could be used as place from which to fetch the dependencies. Given that, the value would probably be I would also refer you back to #5 (comment) because if you're just trying to point your buildpacks to an artifactory cache that you have already set up, you can do that with the dependency mirror RFC, which has been implemented for all of the Java-based buildpacks. See https://paketo.io/docs/howto/configuration/#dependency-mirrors for docs on using that. |
@dmikusa will dependency mirrors work for dotnet build pack also ? |
I believe that it should. It looks like packit implemented the RFC a few months back, see paketo-buildpacks/packit#563. So long as that set of buildpack has updated packit to at least https://github.com/paketo-buildpacks/packit/releases/tag/v2.13.0. I don't think there should be anything else that's needed. |
It would be great if the tool could support creating the service bindings for kpack.
Would it also be a volume mount to the builder?
Sofar I don't know how one would add the bindings of this sort via kpack.
Or could it look something like this, where "..." is the URI to the file (might also be an https URL)?
The text was updated successfully, but these errors were encountered: