Skip to content
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 k8s service bindings #555

Closed
wants to merge 9 commits into from
Closed

Support k8s service bindings #555

wants to merge 9 commits into from

Conversation

tylerphelan
Copy link
Contributor

@tylerphelan tylerphelan commented Nov 20, 2020

Issue: #536

  • Add v1alpha2 for Builds and Images
  • Add conversion webhook for crds
  • Continue to support v1alpha1 bindings in controller
  • Small breaking change in v1alpha1 api code (lastSource)
  • Conversion strategy for v1alpha1 -> v1alpha2 is via annotation
  • Do not remove any v1alpha1 api code

Open questions:

  • Does this adequately support ProvisionedServices?
    - Is there a race condition between ProvisionedServices and Builds reconciling? (if a ProvisionedService is not Ready yet will the Build fail?)
    • This uses meta.UnsafeGuessKindToResource, is that alright?
    • Would love to hear thoughts.
  • Went with v1alpha2 but we could do v1beta1
  • Should we update the docs now? Or wait for the release so that master branch does not have inaccurate docs?
  • I added validation in the generator.go to check that service binding secrets include the required type and data.type based on the spec. Would love thoughts on that. Is it necessary?

Notes:

  • In order to integrate a ProvisionedService with kpack users will need to create rbac that allows the kpack-controller to get the resource via the spec
    • We should document this

- Add v1alpha2 for Builds and Images
- Add conversion webhook for crds
- Continue to support v1alpha1 bindings in controller
- Small breaking change in v1alpha1 api code (lastSource)
- Conversion strategy for v1alpha1 -> v1alpha2 is via annotation
- Do not remove any v1alpha1 api code

#536
@tylerphelan tylerphelan requested review from scothis and removed request for elenorebastian December 2, 2020 20:29
@scothis
Copy link
Contributor

scothis commented Dec 8, 2020

if a ProvisionedService is not Ready yet will the Build fail?

ProvisionedService has no notion of "Ready" either there is a Secret that can be read, or there isn't

Copy link
Contributor

@scothis scothis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps I missed it, but I didn't see where the "application projection" is occurring. The Service Binding for K8s Spec is not the CNB Binding Spec minus a ConfigMap. Check out https://github.com/k8s-service-bindings/spec#application-projection

RBAC can be defined generically, take a look at https://github.com/k8s-service-bindings/spec#for-service-binding-implementors

pkg/buildpod/generator.go Outdated Show resolved Hide resolved
Tyler Phelan and others added 2 commits December 8, 2020 14:20
Co-authored-by: Scott Andrews <sandrews@pivotal.io>
- Secret .stringData.type must be set and reflect .type as service.binding/{type}
- Add RBAC aggregationRule for kpack controller to access ProvisionedServices
- Default APIVersion to v1 for Secret service bindings
- validate services .kind is set

#536
@tylerphelan
Copy link
Contributor Author

Many thanks @scothis for looking at this! Made some changes from the feedback.

Perhaps I missed it, but I didn't see where the "application projection" is occurring

I was missing the type and data.type requirements previously but the apis/build/v1alpha2/build_pod.go should implement the mounting as I understand it.

config/controllerrole.yaml Outdated Show resolved Hide resolved
Comment on lines 519 to 540
// If this is a v1alpha1 binding
if s.V1Alpha1MetadataRef != nil {
metadataVolume := fmt.Sprintf("service-binding-metadata-%s", s.Name)
volumes = append(volumes,
corev1.Volume{
Name: metadataVolume,
VolumeSource: corev1.VolumeSource{
ConfigMap: &corev1.ConfigMapVolumeSource{
LocalObjectReference: *s.V1Alpha1MetadataRef,
},
},
},
)
volumeMounts = append(volumeMounts,
corev1.VolumeMount{
Name: metadataVolume,
MountPath: filepath.Join(platformVolume.MountPath, "bindings", s.Name, "metadata"),
ReadOnly: true,
},
)
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no "metadata" directory in the k8s service binding spec, and the secret is in the wrong place for the cnb service binding spec.

rm unless this is doing something meaningful that I don't understand.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yea I did this wrong, fixing

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be fixed now

pkg/apis/build/v1alpha2/build_pod.go Outdated Show resolved Hide resolved

for i, s := range b.Spec.Services {
if s.Kind == "Secret" && s.APIVersion == "" {
b.Spec.Services[i].APIVersion = "v1"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there precedent for defaulting the APIVersion in an object reference?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was just me speculating that this might help usability

}
serviceBindingRootEnv = corev1.EnvVar{
Name: serviceBindingRootEnvVar,
Value: filepath.Join(platformVolume.MountPath, "bindings"),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

K8s service bindings and cnb service bindings should not share the same directory.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I understand it, buildpacks will only read from one location for bindings based on this and a quick convo with @nebhale

Given that, I made build pods only project CNB bindings OR K8s bindings in which case why not use the same directory?

Curious to peoples' thoughts

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tylerphelan that makes sense to me. I always assumed it would be either/or and not both.

@tylerphelan tylerphelan linked an issue Dec 9, 2020 that may be closed by this pull request
@matthewmcnew
Copy link
Collaborator

@tylerphelan If we are holding off on this for a bit could we move it draft?

@tylerphelan tylerphelan marked this pull request as draft January 5, 2021 19:57

"github.com/pivotal/kpack/pkg/apis/build/v1alpha1"
"github.com/pivotal/kpack/pkg/apis/build/v1alpha2"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it really the best approach to mix build/v1alpha1 and build/v1alpha2? It can get very tricky which struct to take from which import and the errors can be very subtle.

Another approach would bump the api as a whole and only use build/v1alpha2. Maybe even use a import like

buildapi "github.com/pivotal/kpack/pkg/apis/build/v1alpha2"

So the code didn't have to be changed all over if a version is bumped.

@matthewmcnew
Copy link
Collaborator

Tagging this as 0.4.0 to target releasing alongside the api changes in our 0.4.0 release.

@tomkennedy513
Copy link
Collaborator

closed in favor of #823

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants