(entitySource) Use catalogd provided content for sourcing entities #182

anik120 · 2023-04-24T22:25:28Z

This PR replaces OLM v0 catalog operator with https://github.com/operator-framework/catalogd as the source of entities for deppy.

Addresses #161

controllers/operator_controller.go

internal/resolution/entitysources/catalogdsource.go

scripts/install.tpl.sh

stevekuznetsov

Looks like an OLMv0 end-to-end test was removed - is there a new one for this integration?

controllers/operator_controller.go

controllers/operator_controller_test.go

internal/resolution/entitysources/catalogdsource.go

stevekuznetsov · 2023-04-25T12:49:34Z

internal/resolution/entitysources/catalogdsource.go

+					Version string `json:"version"`
+				}
+				tmp := pkg{}
+				if err := json.Unmarshal(prop.Value, &tmp); err != nil {


What's the meaning of this marshal/unmarshal step? Do we not trust which fields are in the prop.Value? Can better validation be added to bundle.Spec.Properties? Why would it ever be valid for someone to create a bundle with an invalid property?

Mistakes happen? And we should always validate user-derived input?

So right now we just throw in whatever we're getting from the declCfg into the CR, which ends up looking something like this:

spec: catalogSource: catalogsource-sample image: quay.io/operatorhubio/argocd-operator@sha256:5f4533de114e9301e836155190dc2c66a969f55085af03a4959a2fb0af74e1f4 package: argocd-operator properties: - type: olm.gvk value: ewogICAgICAgICAgICAgICAgImdyb3VwIjogImFyZ29wcm9qLmlvIiwKICAgICAgICAgICAgICAgICJraW5kIjogIkFwcFByb2plY3QiLAogICAgICAgICAgICAgICAgInZlcnNpb24iOiAidjFhbHBoYTEiCiAgICAgICAgICAgIH0= - type: olm.gvk value: ewogICAgICAgICAgICAgICAgImdyb3VwIjogImFyZ29wcm9qLmlvIiwKICAgICAgICAgICAgICAgICJraW5kIjogIkFwcGxpY2F0aW9uIiwKICAgICAgICAgICAgICAgICJ2ZXJzaW9uIjogInYxYWxwaGExIgogICAgICAgICAgICB9 - type: olm.gvk value: ewogICAgICAgICAgICAgICAgImdyb3VwIjogImFyZ29wcm9qLmlvIiwKICAgICAgICAgICAgICAgICJraW5kIjogIkFwcGxpY2F0aW9uU2V0IiwKICAgICAgICAgICAgICAgICJ2ZXJzaW9uIjogInYxYWxwaGExIgogICAgICAgICAgICB9 - type: olm.gvk value: ewogICAgICAgICAgICAgICAgImdyb3VwIjogImFyZ29wcm9qLmlvIiwKICAgICAgICAgICAgICAgICJraW5kIjogIkFyZ29DRCIsCiAgICAgICAgICAgICAgICAidmVyc2lvbiI6ICJ2MWFscGhhMSIKICAgICAgICAgICAgfQ== - type: olm.gvk value: ewogICAgICAgICAgICAgICAgImdyb3VwIjogImFyZ29wcm9qLmlvIiwKICAgICAgICAgICAgICAgICJraW5kIjogIkFyZ29DREV4cG9ydCIsCiAgICAgICAgICAgICAgICAidmVyc2lvbiI6ICJ2MWFscGhhMSIKICAgICAgICAgICAgfQ== - type: olm.package value: ewogICAgICAgICAgICAgICAgInBhY2thZ2VOYW1lIjogImFyZ29jZC1vcGVyYXRvciIsCiAgICAgICAgICAgICAgICAidmVyc2lvbiI6ICIwLjUuMCIKICAgICAgICAgICAgfQ== relatedImages: - image: gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0 name: "" - image: quay.io/argoprojlabs/argocd-operator@sha256:2f5c0d4567607266ccacb91d8c2e3b18c2afe0edaf55855dcb1a06b02173b520 name: "" - image: quay.io/operatorhubio/argocd-operator@sha256:5f4533de114e9301e836155190dc2c66a969f55085af03a4959a2fb0af74e1f4 name: ""

We'd discussed correcting this and changing the plumbing to make sure we throw in unmarshalled structs there instead, but again, that was superseded with operator-framework/catalogd#38. Hence the tap dance with marshal/unmarshal: just a stop gap so that we're not sweating over details that are going to change soon.

@tmshort if it's required, the validation should occur at creation or mutation of the object, not downstream every time the value is used.

@anik120 is there an understanding of how long that effort will take? Leaving the software in a more stable spot while the change happens might be useful if it's a long-running effort?

It's definitely a "the very next step" for the project. We'd planned it for milestone 3 but it got pushed out in favor of us focusing our effort on the integration for m3, so I'd say milestone 4 is a pretty accurate timeline for when it's about to happen. (We can probably do a v0.2.0 release after m4 and in m5 we can update this integration with the v0.2.0 release, but don't quote me on that yet I'd like to make sure others working in the project are in agreement with "we can do these things we're promising in that timeline" too :) ). But the gist of it is, these are going to change pretty soon.

Mistakes happen? And we should always validate user-derived input?

@tmshort if it's required, the validation should occur at creation or mutation of the object, not downstream every time the value is used.

All makes sense. I've made a note of it here so that we don't miss this

I'm not sure I'm understanding the need to unmarshal/marshal. I know that deppy wants maps of properties, not lists, so I would expect some handling to do that conversion. But isn't this just a matter of collecting up the properties that have the same type into map[string][]json.Message, and then building the deppy entities from that?

stevekuznetsov · 2023-04-25T12:50:59Z

internal/resolution/entitysources/catalogdsource.go

+	return nil
+}
+
+func jsonMarshal(p interface{}) ([]byte, error) {


I've never quite seen a JSON marshal method this intricate - why is it necessary over json.Marshal? What's special about encoding HTML?

json.Marshal always escapes for HTML.

Sorry! Read right over the fact that you asked specifically about the HTML aspect. HTML encoding subs out <, >, and & for unicode escape sequences, which isn't super human-friendly. In the case of our FBC code in operator-registry (where I suspect @anik120 found this?), this is important because we expect humans to be looking at the output.

In this case, I'm not sure whether humans will ever see anything downstream of this marshaling. Theoretically, I suppose it could show up in resolution error messages?

Wouldn't we expect to HTML-escape just before putting the output into a webpage or something? I am still lost as to why we're not operating over raw values here.

This is disabling HTML escaping, which is the hardcoded only option in json.Marshal.

However, I think we could probably avoid doing any json marshaling in this entity source. I mentioned in a different comment that there is some impedance mismatch between FBC properties ([]Property) and deppy properties (map[string]string, I think?), which does seem awkward, but since we already have json.RawMessage, it seems like we could do the conversion without needing to marshal/unmarshal anything.

Huh, TIL. For whom are we disabling this? What consumer needs JSON to not be HTML-escaped?

We do something like this to disable HTML encoding in opm render because we expect humans to be looking at the output.

Here, the resolver will see this. The only place I could see a human being exposed to resolver input is in resolver error messages, and it's conceivable that property values will end up there.

I think I'm still really lost. Even in the resolver if I'm reading this code correctly a json.Unmarshal happens first so it would be back to raw values ... In user-facing output of JSON (which in and of itself is a bit of an oxymoron) this makes sense but I think unless there's some clear need, starting with a simple call to json.Marshal makes sense ...

👍 Seems reasonable to me to start with json.Marshal and re-evaluate if there's a need.

internal/resolution/entitysources/catalogdsource.go

internal/resolution/variable_sources/entity/bundle_entity.go

internal/resolution/variable_sources/entity/bundle_entity_test.go

main.go

everettraven

First round - most of my comments are around trying to understand the decision to go with a static entity source implementation rather than a dynamic one.

config/rbac/role.yaml

controllers/operator_controller.go

controllers/operator_controller_test.go

internal/resolution/entitysources/catalogdsource.go

dtfranz · 2023-04-25T17:31:03Z

test/e2e/install_test.go

@@ -63,6 +44,8 @@ var _ = Describe("Operator Install", func() {
 		err := c.Create(ctx, operator)
 		Expect(err).ToNot(HaveOccurred())

+		// TODO dfranz: This test currently relies on the hard-coded CatalogSources found in bundle_cache.go


Shouldn't this comment be removed instead of added back since the hard-coded catalog sources are gone?

Consolidating comments about e2e here.

@stevekuznetsov : "Looks like an OLMv0 end-to-end test was removed - is there a new one for this integration?"

I realized after removing the hardcoded entity source that the v0 CatalogSource integration was using the v0 OLM installation to create a CatalogSource with an index image, but then for us to include prod grade e2e tests we probably have to set up the e2e test infrastructure first. That means

Discuss if we want to install catalogd v0.0.1 as part of the operator-controller installation

Set up test infrastructure like a mock image registry, that can be used to build and post an index image into so that the tests can pull from it etc.

My first instinct is to add the hardcoded entitySource back, so that the deppy tests can go on with the hardcoded entitySource, and we don't increase the scope of this PR with "set up e2e test infrastructure for this project", but then if we feel like we must do it as a part of this PR then I'm happy to do it, with an agreement that it'll increase the scope of this PR.

cc: @joelanford

Discuss if we want to install catalogd v0.0.1 as part of the operator-controller installation

My guess for this is "yes we want this to be included in this PR, just like we install rukpak", but I'll wait for others to chime in first, to make sure we're comfortable including v0.1.0 release of catalogd as a part of the operator-contorller installation

Discuss if we want to install catalogd v0.0.1 as part of the operator-controller installation

Yes, 100%.

Set up test infrastructure like a mock image registry, that can be used to build and post an index image into so that the tests can pull from it etc.

Agree with doing this separately. There's a whole bunch wrapped up in this question:

Should we do the catalog.spec.source union type first so that we don't need all the image infrastructure everywhere we want to test it?

What tests should we put in catalogd vs operator-controller?

What's the appropriate layer for the tests? Unit or e2e? Or both?

joelanford

This isn't really what I had in mind when we talked about it before. I was anticipating the dynamic entity source that Bryce was alluding to in comments. Having said that, I'm not necessarily opposed to the "read everything into memory at init time" approach because it technically seems like it will meet the bar set out in the demo script.

I do think we should setup the entity source once and remove the if r.Resolver == nil block in the reconciler though. I know doing that may necessitate making this more dynamic though.

joelanford · 2023-04-26T15:15:41Z

.gitignore

@@ -1,3 +1,4 @@
+vendor


Is there some reason that this needs to be gitignore'd? I don't think anything in the repo generates a vendor dir, so I don't think we ever expect it to exist.

You have to go mod vendor to build the manager binary, and you either have to delete it every time you're about to push to your PR or never do git add . :) I don't think it hurts to keep it here

You have to go mod vendor to build the manager binary

I don't have to do that...

Makefile

controllers/operator_controller.go

internal/resolution/entitysources/catalogdsource.go

joelanford · 2023-04-26T15:31:05Z

internal/resolution/entitysources/catalogdsource.go

+					Version string `json:"version"`
+				}
+				tmp := pkg{}
+				if err := json.Unmarshal(prop.Value, &tmp); err != nil {


I'm not sure I'm understanding the need to unmarshal/marshal. I know that deppy wants maps of properties, not lists, so I would expect some handling to do that conversion. But isn't this just a matter of collecting up the properties that have the same type into map[string][]json.Message, and then building the deppy entities from that?

internal/resolution/entitysources/catalogdsource.go

joelanford · 2023-04-26T15:39:09Z

internal/resolution/entitysources/catalogdsource.go

+	return nil
+}
+
+func jsonMarshal(p interface{}) ([]byte, error) {


json.Marshal always escapes for HTML.

joelanford · 2023-04-26T23:44:08Z

internal/resolution/entitysources/catalogdsource.go

+	resultSet := input.EntityList{}
+	entities, err := getEntities(ctx, es.client)
+	if err != nil {
+		return nil, err
+	}
+	for _, entity := range entities {
+		if filter(&entity) {
+			resultSet = append(resultSet, entity)
+		}
+	}
+	return resultSet, nil


Nit: in Filter and GroupBy, is it possible to call Iterate with an iterate lambda function that implements the filter and groupBy logic? That way we don't have to repeat ourselves quite as much (and thus reduce the chance for drift between implementations)

joelanford · 2023-04-27T00:00:17Z

internal/resolution/entitysources/catalogdsource.go

+				type pkg struct {
+					Name    string `json:"packageName"`
+					Version string `json:"version"`
+				}
+				tmp := pkg{}
+				if err := json.Unmarshal(prop.Value, &tmp); err != nil {
+					return nil, err
+				}
+				pkgValue, err := jsonMarshal(tmp)
+				if err != nil {
+					return nil, err
+				}
+				props[property.TypePackage] = string(pkgValue)


This needs a comment explaining what's going on. To my eye, it's literally unmarshalling and then re-marshaling, which seems like a no-op. Why not consolidate this down to:

case property.TypePackage: props[property.TypePackage] = string(prop.Value)

Better yet, I'd imagine something more like this:

valsByType := map[string][]json.RawMessage{} for _, prop := range bundle.Spec.Properties { valsByType[prop.Type] = append(valsByType[prop.Type], prop.Value) } entityProps := map[string]string{} for typ, vals := range valsByType { switch typ { case property.TypePackage: // We expect exactly on "olm.package" property if len(vals) != 1 { return err } entityProps[typ] = string(vals[0]) default: // All other properties can have 0 or more values, so always use a list entityProps[typ] = fmt.Sprintf("[%s]", bytes.Join(vals, []byte(","))) } }

internal/resolution/entitysources/catalogdsource.go

joelanford

Nice update Anik! This is shaping up pretty well, I think.

controllers/operator_controller_test.go

internal/resolution/entitysources/catalogdsource.go

stevekuznetsov · 2023-04-27T12:55:29Z

internal/resolution/entitysources/catalogdsource.go

+	return nil
+}
+
+func jsonMarshal(p interface{}) ([]byte, error) {


Huh, TIL. For whom are we disabling this? What consumer needs JSON to not be HTML-escaped?

This reverts commit 2973a14. Signed-off-by: Anik <[email protected]>

perdasilva · 2023-04-27T15:54:31Z

internal/resolution/variable_sources/entity/bundle_entity.go

+	}
+	return nil
+}
+
 func loadFromEntity[T interface{}](entity *input.Entity, propertyName string, required propertyRequirement) (T, error) {


Not related to this PR, but it would be awesome if you could change this to [T any] =D

main.go

internal/resolution/entitysources/catalogdsource.go

Makefile

joelanford · 2023-04-27T21:09:33Z

test/e2e/install_test.go

+					Name: "test-catalog",
+				},
+				Spec: catalogd.CatalogSourceSpec{
+					Image: "quay.io/operatorhubio/catalog:latest",


This is a very large catalog to use in an e2e. Okay for now, but can you add a TODO comment and an issue in this repo to replace this with something we build locally/on-the-fly as part of the e2e test and make available during the e2e?

Yup I'd discussed this yesterday and cc:@theishshah I'm adding the TODO and creating the issue so that we can keep track of this

test/e2e/install_test.go

joelanford · 2023-04-27T21:13:32Z

test/e2e/install_test.go

+			Eventually(func(g Gomega) {
+				err = c.Get(ctx, types.NamespacedName{Name: operator.Name}, operator)
+				g.Expect(err).ToNot(HaveOccurred())
+				g.Expect(len(operator.Status.Conditions)).To(Equal(1))
+				g.Expect(operator.Status.Conditions[0].Message).To(Equal("install was successful"))
+			}).WithTimeout(defaultTimeout).WithPolling(defaultPoll).Should(Succeed())


It it necessary to pass g Gomega to the function? I would expect us to be able to do something like this:

Eventually(func() error { if err := doSomething(); err != nil { return err } return nil }).Should(Succeed())

You're right. The tests already had Eventually blocks that was passing in a Gomega object so I stuck to that, but it's not needed so removing from all of the other ones (I also want to paraphrase the tests with the right When->By->It tree structures, so that we take advantage of the ginkgo DAG test paths creation feature which becomes crucial when the test suite grows, but I'm going to tackle that in a different PR :) )

Turns out:

[FAILED] The function passed to Eventually had an invalid signature of func(). Functions passed to Eventually must either: (a) have return values or (b) take a Gomega interface as their first argument and use that Gomega instance to make assertions. You can learn more at https://onsi.github.io/gomega/#eventually

I know we're used to the first approach in our existing test suites, but if we want to discuss the merits of a) vs b) we can do that in a separate PR. For now I've reverted back to using b)

Oh, that function needs to return something so it can be asserted against. Updated my original comment, with a better code example.

Yea that's what I meant in my previous comment, that we're using the func signature you mentioned in other test suites but changing the current approach in the code base seems like a follow up PR

stevekuznetsov · 2023-04-27T21:15:12Z

internal/resolution/entitysources/catalogdsource.go

+	client client.Client
+}
+
+func NewCatalogdEntitySource(client client.Client) *catalogdEntitySource {


Is there a compelling reason not to return input.EntitySource?

There's a go proverb "Accept interfaces, return concrete types". So my initial argument was "let's just export this", which is fine because its internal. But since its internal, its hard to care that much because we can always change it.

everettraven · 2023-04-28T17:14:19Z

internal/resolution/variable_sources/entity/bundle_entity.go

+	b.mu.Lock()
+	defer b.mu.Unlock()
+	if b.bundlePath == "" {
+		bundlePath, err := loadFromEntity[string](b.Entity, PropertyBundlePath, required)


I'm not sure that this is necessary. From my testing, this particular line is what makes us have to do weird marshalling and unmarshalling logic here

I think using the loadFromEntity() function makes the most sense when you are attempting to load something you are expecting to follow a specific structure and gets unmarshalled into a struct. For this case, since we are expecting an unstructured string ("hello world!" as opposed to "{"test": "test"}") and the b.Entity.Properties is a map[string]string I think we are better off just doing something like:

Suggested change

bundlePath, err := loadFromEntity[string](b.Entity, PropertyBundlePath, required)

bundlePath, ok := b.Entity.Properties[PropertyBundlePath]

Using the above suggestion will allow us to change this to:

props["olm.bundle.path"] = bundle.Spec.Image

Makefile

varshaprasad96 · 2023-04-30T21:54:32Z

controllers/operator_controller.go

-//
-// For more details, check Reconcile and its Result here:
-// - https://pkg.go.dev/sigs.k8s.io/[email protected]/pkg/reconcile
+//+kubebuilder:rbac:groups=catalogd.operatorframework.io,resources=bundlemetadata,verbs=get;list;watch


Just curious, why does the operator controller need to be able to watch bundlemetadata and packages? Isn't the catalog controller doing that? Are we adding watches to these objects in the operator controller's reconciler (I don't see that change in the reconciler code, just wanted to confirm it)?

No that's a good catch, we don't actually need to watch these resources. Updated to remove the watch verb

@anik120 took another pass, I maybe wrong but do we also need get and list for those GVKs? The catalog controller is fetching bundle metadata and packages, we are getting the content through the manager's client and passing in the entities to the controller. The operator controller doesn't seem to directly interact with both the APIs (pkgs or BMD). Given that, does it need the rbac to get and list those resources?

We need list and watch if we use the caching client, right?

Edit: one way or another, the process running the entity source needs list/watch because of the caching client in the catalogsource. My understanding is that the operator controller is the thing running the resolver and the resolver is the thing using the entity source?

We can put these rbac comments in the entity source implementation and update the rbac generator invocation to find them there if we want to keep the rules nearest the place that needs them. But that could be a follow up.

tmshort · 2023-05-01T15:38:29Z

controllers/operator_controller.go

@@ -121,7 +115,6 @@ func (r *OperatorReconciler) reconcile(ctx context.Context, op *operatorsv1alpha
 		})
 		return ctrl.Result{}, nil
 	}
-


Nit: deletion of a blank line/whitepsace. This goes against the "minimizing" the diff, but I don't care enough.

tmshort · 2023-05-01T15:39:38Z

Just a note that catsrc integration was added in 2973a14, this PR deletes all the added files from that commit (at least), and removes other edits of that commit.

tmshort

LGTM, although so many other people reviewed this, I'd at least like to get one of them to give it 👍

varshaprasad96

/lgtm

joelanford · 2023-05-05T12:56:54Z

controllers/operator_controller.go

+//+kubebuilder:rbac:groups=catalogd.operatorframework.io,resources=bundlemetadata,verbs=get;list
+//+kubebuilder:rbac:groups=catalogd.operatorframework.io,resources=packages,verbs=get;list


Because we're using mgr.GetClient() when we setup the catalogd entity source, that means we're using the caching client. The caching client needs list and watch verbs. get isn't necessary because the caching client always gets from the cache and never actually issues get requests to the apiserver.

If you create the sample catalog and operator and then watch the logs based on this commit, you'll see lines like this:

E0505 12:53:49.867260 1 reflector.go:140] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:169: Failed to watch *v1beta1.Package: unknown (get packages.catalogd.operatorframework.io) E0505 12:53:50.229906 1 reflector.go:140] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:169: Failed to watch *v1beta1.BundleMetadata: unknown (get bundlemetadata.catalogd.operatorframework.io) E0505 12:53:52.993949 1 reflector.go:140] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:169: Failed to watch *v1beta1.Package: unknown (get packages.catalogd.operatorframework.io) E0505 12:53:53.228923 1 reflector.go:140] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:169: Failed to watch *v1beta1.BundleMetadata: unknown (get bundlemetadata.catalogd.operatorframework.io)

Suggested change

//+kubebuilder:rbac:groups=catalogd.operatorframework.io,resources=bundlemetadata,verbs=get;list

//+kubebuilder:rbac:groups=catalogd.operatorframework.io,resources=packages,verbs=get;list

//+kubebuilder:rbac:groups=catalogd.operatorframework.io,resources=bundlemetadata,verbs=list;watch

//+kubebuilder:rbac:groups=catalogd.operatorframework.io,resources=packages,verbs=list;watch

Yikes. Updated.

This PR replaces OLM v0 catalog operator with https://github.com/operator-framework/catalogd as the source of entities for deppy. Addresses operator-framework#161 Signed-off-by: Anik <[email protected]>

tmshort · 2023-05-08T13:19:23Z

/lgtm

anik120 force-pushed the catalogd-integration branch from 29241c3 to 0469e7f Compare April 24, 2023 22:26

anik120 commented Apr 24, 2023

View reviewed changes

controllers/operator_controller.go Outdated Show resolved Hide resolved

internal/resolution/entitysources/catalogdsource.go Outdated Show resolved Hide resolved

anik120 force-pushed the catalogd-integration branch from 0469e7f to cf3f52e Compare April 24, 2023 22:46

anik120 mentioned this pull request Apr 24, 2023

DNR: Wip: Poc/catsrc v2 #141

Closed

7 tasks

dtfranz reviewed Apr 24, 2023

View reviewed changes

scripts/install.tpl.sh Outdated Show resolved Hide resolved

stevekuznetsov reviewed Apr 25, 2023

View reviewed changes

everettraven reviewed Apr 25, 2023

View reviewed changes

dtfranz reviewed Apr 25, 2023

View reviewed changes

joelanford reviewed Apr 26, 2023

View reviewed changes

anik120 force-pushed the catalogd-integration branch from cf3f52e to 4d13185 Compare April 26, 2023 22:23

openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Apr 26, 2023

joelanford reviewed Apr 26, 2023

View reviewed changes

joelanford reviewed Apr 27, 2023

View reviewed changes

internal/resolution/entitysources/catalogdsource.go Outdated Show resolved Hide resolved

joelanford reviewed Apr 27, 2023

View reviewed changes

internal/resolution/entitysources/catalogdsource.go Outdated Show resolved Hide resolved

joelanford reviewed Apr 27, 2023

View reviewed changes

internal/resolution/entitysources/catalogdsource.go Show resolved Hide resolved

joelanford reviewed Apr 27, 2023

View reviewed changes

stevekuznetsov reviewed Apr 27, 2023

View reviewed changes

Revert "Add catalogsource entitysource (operator-framework#129)"

29a5cc9

This reverts commit 2973a14. Signed-off-by: Anik <[email protected]>

perdasilva reviewed Apr 27, 2023

View reviewed changes

main.go Outdated Show resolved Hide resolved

anik120 force-pushed the catalogd-integration branch from 4d13185 to d3a1105 Compare April 27, 2023 19:16

openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Apr 27, 2023

anik120 force-pushed the catalogd-integration branch 3 times, most recently from 61d29dc to 1d5268e Compare April 27, 2023 19:31

joelanford reviewed Apr 27, 2023

View reviewed changes

internal/resolution/entitysources/catalogdsource.go Outdated Show resolved Hide resolved

joelanford reviewed Apr 27, 2023

View reviewed changes

Makefile Show resolved Hide resolved

anik120 force-pushed the catalogd-integration branch 2 times, most recently from 088c0ae to 07e1b63 Compare April 27, 2023 20:16

joelanford reviewed Apr 27, 2023

View reviewed changes

test/e2e/install_test.go Show resolved Hide resolved

joelanford reviewed Apr 27, 2023

View reviewed changes

stevekuznetsov reviewed Apr 27, 2023

View reviewed changes

anik120 force-pushed the catalogd-integration branch 4 times, most recently from b23746e to 7041aca Compare April 28, 2023 16:02

everettraven reviewed Apr 28, 2023

View reviewed changes

Makefile Outdated Show resolved Hide resolved

anik120 force-pushed the catalogd-integration branch from 7041aca to 7b23295 Compare April 28, 2023 17:42

anik120 mentioned this pull request Apr 28, 2023

(rough sketch dumps) Follow ups from catalogd-integration #187

Closed

varshaprasad96 reviewed Apr 30, 2023

View reviewed changes

anik120 force-pushed the catalogd-integration branch from 7b23295 to 15dcd66 Compare May 1, 2023 14:43

tmshort reviewed May 1, 2023

View reviewed changes

tmshort approved these changes May 1, 2023

View reviewed changes

varshaprasad96 approved these changes May 1, 2023

View reviewed changes

openshift-ci bot assigned varshaprasad96 May 1, 2023

openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label May 1, 2023

joelanford reviewed May 5, 2023

View reviewed changes

anik120 force-pushed the catalogd-integration branch from 15dcd66 to 35af915 Compare May 8, 2023 13:07

openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label May 8, 2023

(entitySource) Use catalogd provided content for sourcing entities

724f053

This PR replaces OLM v0 catalog operator with https://github.com/operator-framework/catalogd as the source of entities for deppy. Addresses operator-framework#161 Signed-off-by: Anik <[email protected]>

anik120 force-pushed the catalogd-integration branch from 35af915 to 724f053 Compare May 8, 2023 13:18

openshift-ci bot assigned tmshort May 8, 2023

openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label May 8, 2023

tmshort merged commit 5cc5cc2 into operator-framework:main May 8, 2023

joelanford mentioned this pull request May 9, 2023

Catalogd integration foundations #175

Closed

	bundlePath, err := loadFromEntity[string](b.Entity, PropertyBundlePath, required)
	bundlePath, ok := b.Entity.Properties[PropertyBundlePath]

		//+kubebuilder:rbac:groups=catalogd.operatorframework.io,resources=bundlemetadata,verbs=get;list
		//+kubebuilder:rbac:groups=catalogd.operatorframework.io,resources=packages,verbs=get;list

(entitySource) Use catalogd provided content for sourcing entities #182

(entitySource) Use catalogd provided content for sourcing entities #182

Conversation

anik120 commented Apr 24, 2023

stevekuznetsov left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

everettraven left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joelanford left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joelanford left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joelanford Apr 27, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joelanford Apr 28, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

varshaprasad96 Apr 30, 2023 • edited Loading

Choose a reason for hiding this comment

anik120 May 1, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joelanford May 1, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tmshort commented May 1, 2023

tmshort left a comment

Choose a reason for hiding this comment

varshaprasad96 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tmshort commented May 8, 2023

joelanford Apr 27, 2023 •

edited

Loading

joelanford Apr 28, 2023 •

edited

Loading

varshaprasad96 Apr 30, 2023 •

edited

Loading

anik120 May 1, 2023 •

edited

Loading

joelanford May 1, 2023 •

edited

Loading