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

[WIP] Package Extension API Server #433

Merged
merged 31 commits into from
Sep 11, 2018
Merged

Conversation

njhale
Copy link
Member

@njhale njhale commented Aug 28, 2018

Description

Implements a package manifest extension-apiserver that uses the Kubernetes Aggregation Layer to provide parsed package manifests as top-level Kubernetes resources. Manifests are parsed from config maps pointed at by sourceType: internal catalog sources and are stored in memory instead of etcd.

Result of ALM-648

Copy link
Member

@ecordell ecordell left a comment

Choose a reason for hiding this comment

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

awesome work! it's pretty close to being something we could deploy right away.

I'll also leave this here for us to consider:
https://www.thesaurus.com/browse/package

Gopkg.toml Outdated
@@ -55,3 +55,14 @@
[[constraint]]
name = "github.com/writeas/go-strip-markdown"
version = "2.0.0"

# resolved to 1.1.3 which doesn't support flags used by apimachinary release-1.11
Copy link
Member

Choose a reason for hiding this comment

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

these were set a while ago, did you try removing them and resolving to see if it built?

name: v1alpha1.apps.coreos.com
spec:
insecureSkipTLSVerify: true
group: apps.coreos.com
Copy link
Member

Choose a reason for hiding this comment

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

for actually deploying we probably want to think about this group name

Copy link
Member Author

Choose a reason for hiding this comment

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

I was thinking something like packages.apps.redhat.com

@@ -0,0 +1,146 @@
apiVersion: apiregistration.k8s.io/v1beta1
Copy link
Member

Choose a reason for hiding this comment

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

In order for our packaging scripts to work we need each of these yamls to have its own file (threw them all in one for testing)

Alternately you could fix our packaging scripts to not require that each be in a separate file, whichever

// Install registers the API group and adds types to a scheme
func Install(scheme *runtime.Scheme) {
v1alpha1.AddToScheme(scheme)
//utilruntime.Must(v1alpha1.AddToScheme(scheme))
Copy link
Member

Choose a reason for hiding this comment

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

do we need these?

metav1.ObjectMeta `json:"metadata"`

Spec PackageManifestSpec `json:"spec"`
//TODO: status
Copy link
Member

Choose a reason for hiding this comment

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

As a super simple status, we could write what catalog a package came from?

Name: spec.PackageName,
Namespace: cm.GetNamespace(),
},
Spec: spec,
Copy link
Member

Choose a reason for hiding this comment

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

we should think about what should actually be here with @alecmerdler

the current "package spec" from the catalog configmap isn't enough to display packages in the ui. the ui is using the package spec to find the CSV in the configmap and then using that for display.

it could probably be as simple as:

spec:
  package:
    package spec
  csv: 
    - csv spec for csv in default channel

which would match what we currently do. or it could have it's own set of metadata instead.

// TODO: add check for invalid package definitions
manifests = append(manifests, manifest)
}
log.Debugf("Load ConfigMap -- Found packages: %v", manifests)
Copy link
Member

Choose a reason for hiding this comment

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

since we're copying this over anyway, could we make this structured with log.WithField etc like we do for other parts of olm?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yup, sounds good.


// check if the sourcetype is internal
switch catsrc.Spec.SourceType {
case "internal":
Copy link
Member

Choose a reason for hiding this comment

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

👍 for future proofing!


return &manifest, nil
}

Copy link
Member

Choose a reason for hiding this comment

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

So what happens if I try and create a Package in the API? do I get a reasonable error back?

Copy link
Member Author

Choose a reason for hiding this comment

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

Error from server (MethodNotAllowed): error when creating "pkg-manifest.json": the server does not allow this method on the requested resource which I think is reasonable; though it could be more descriptive.

@@ -5,11 +5,12 @@

set -e

ps x | grep -q [m]inikube || minikube start --kubernetes-version="v1.11.1" --extra-config=apiserver.v=4 || { echo 'Cannot start minikube.'; exit 1; }
ps x | grep -q [m]inikube || minikube start --extra-config=apiserver.v=4 || { echo 'Cannot start minikube.'; exit 1; }
Copy link
Member

Choose a reason for hiding this comment

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

is minikube 1.11 by default now?

@njhale njhale force-pushed the pkg-api branch 2 times, most recently from 993c8d7 to 1d588a4 Compare September 6, 2018 22:44
apiVersion: apiregistration.k8s.io/v1beta1
kind: APIService
metadata:
name: v1alpha1.packages.apps.redhat.com
spec:
insecureSkipTLSVerify: true
caBundle: {{ $ca.Cert | b64enc | quote }}
Copy link

Choose a reason for hiding this comment

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

You should be able to write this as caBundle: {{ b64enc $ca.Cert }}.

ci.kubeconfig Outdated
@@ -0,0 +1,29 @@
apiVersion: v1
Copy link
Member

Choose a reason for hiding this comment

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

🚫 don't commit secrets...

type PackageManifestSpec struct{}

// PackageManifestStatus represents the current status of the PackageManifest
type PackageManifestStatus struct {
Copy link
Member

Choose a reason for hiding this comment

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

We should pull info from the CSV into this. And actually, I think some of it should go into labels if it's not too weird (so that when you do a label query, the object you get back has labels to match)

}

// Get takes name of the packageManifest, and returns the corresponding packageManifest object, and an error if there is any.
func (c *packageManifests) Get(name string, options v1.GetOptions) (result *v1alpha1.PackageManifest, err error) {
Copy link
Member

Choose a reason for hiding this comment

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

Is there a way to tell the Client codegen to only generate get/list/watch?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes - I'm testing that out now.

"k8s.io/client-go/tools/cache"
"k8s.io/client-go/tools/clientcmd"

//"k8s.io/sample-apiserver/pkg/admission/plugin/banflunder"
Copy link
Member

Choose a reason for hiding this comment

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

these can go

go sourceProvider.Run(stopCh)

// add health checks
// server.AddHealthzChecks(healthz.NamedCheck("healthz", mgr.CheckHealth))
Copy link
Member

Choose a reason for hiding this comment

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

health checks would be nice if this helper does what it says

ecordell and others added 23 commits September 10, 2018 10:17
updates dependencies to kube 1.11

don't require etcd to start apiserver

fix(apiserver): make apiserver start

feat(package-api): make minimally functional in-mem store

fix(package-api): use correct group

refactor(package-server): change rest.Storage implementation

fix(package-server): fix package-server

feat(package-server): add better filtering

fix(types): add struct tags for metadata

chore(certs): remove local client certs

chore(bin): remove package-server binary

chore(scripts): remove second run_console script

feat(types): add package mainfest status resource

refactor(types): register different api group

Registers package manifests under the `packages.apps.redhat.com` api
group.

feat(make): add openapi gen rules

feat(install_local): add wait for package-server rollout

refactor(charts): change package apiserver deployment name

Changes package-manifest-apiserver to package-server in deployment and
dependent resources
- Enables openapi for the package-server extension-apiserver
- Removes leftover sample-apiserver fuzzer comments

fix(make): update openapi gen rule to include dependencies

fix(openapi): add openapi comment
chore(codgen): update codegen

chore(package-server): regen clients

fix(build_local): specify kube version

chore(vendor): re-vendor

chore(package-server): clean up leftover comments
Fixes unmarshalling of catalog source package manifest yaml to
PackageManifestStatus
- Changes package-server serviceaccount name
- Changes package-server service name
- Adds debug flag to package-server container commands
- Adds basic e2e test
- Adds package-server e2e helm values
Declares cobra command in main package init to make visible to test binary
- Adds debug flag
- Change default watch interval to 5 minutes
name: v1alpha1.packages.apps.redhat.com
spec:
caBundle: {{ $ca.Cert | b64enc | quote }}
group: packages.apps.redhat.com
Copy link
Member

Choose a reason for hiding this comment

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

This seems weird since the other group is operators.coreos.com

Copy link
Member Author

Choose a reason for hiding this comment

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

I was wondering whether we want to continue using *.coreos.com. Also, I added the package prefix because the package-server is only going to be responsible for package related resources. If I had just used apps.redhat.com or apps.coreos.com, the group would be unusable by any other CRDs or extension-apiservers.

Copy link
Member

@ecordell ecordell left a comment

Choose a reason for hiding this comment

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

LGTM

I think this is good to merge, but there are some things I think we'll want to circle back around on soon:

  • If we're keeping the configmap catalog source parsing, maybe it makes more sense to just run the packages server in the same binary as the catalog operator, so that we don't have to deploy two separate control loops watching catalogsources and parsing confmaps into memory
  • Not sure we want the entire contents of every channel's CSV in the package manifest.
  • We know we'll need to change a chunk of these control loops when we have the catalog api up

@njhale njhale merged commit 724b209 into operator-framework:master Sep 11, 2018
ecordell pushed a commit to ecordell/operator-lifecycle-manager that referenced this pull request Mar 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants