# Eventing 1.0 Status

###### tags: `Eventing`

For a task list, please see [Eventing to 1.0](https://github.com/knative/eventing/projects/19) project board.

## Work Week 20, 21

- [ ] Finish Broker Conformance tests.
- blocked on https://github.com/knative/specs/pull/24
- [ ] Finish Channel Conformance tests.
- blocked on https://github.com/knative/specs/pull/24

## Work Week 19

- [^] Finish Broker Conformance tests.
- blocked on https://github.com/knative/specs/pull/24
- [^] Finish Channel Conformance tests.
- blocked on https://github.com/knative/specs/pull/24

### May 19

- [n3wscott] I can now parse yaml enough to split on sentences, which allows me to do some other interesting things

      specification: https://github.com/n3wscott/mdspeclinks/blob/main/example.md
        processed: "2021-05-19T14:06:19-07:00"
    requirements:

          - id: Example-SHOULD-1.1[0]
            word: SHOULD
            lines: L8-L9
            section: "1.1"
            offset: 11
            index: 0
            text: '- Repetunt SHOULD speculo'
            link: https://github.com/n3wscott/mdspeclinks/blame/main/example.md?w=SHOULD&c=11#L8-L9
            md5: a44ee3f2605461bba62c11bfd6c7be02
          - id: Example-MAY-1.1[1]
            word: MAY
            lines: L10
            section: "1.1"
            offset: 8
            index: 1
            text: '- Latus MAY artibus'
            link: https://github.com/n3wscott/mdspeclinks/blame/main/example.md?w=MAY&c=8#L10
            md5: 59f148800732ad5630d2b820db11c72e

I can now do blame links with multi-lines and I calculate the md5 hash of the sentence with the spec word in question highlighted the md5s are different for the same sentence and it is always repeatable, until that sentence is changed.

          - id: Example-MUST-1.3[0]
            word: MUST
            lines: L27-L28
            section: "1.3"
            offset: 16
            index: 0
            text: Sorte aliquando MUST sumpsere illum rebus, [et obortis](http://quidem-expulit.com/) care MAY in.
            link: https://github.com/n3wscott/mdspeclinks/blame/main/example.md?w=MUST&c=16#L27-L28
            md5: b8065f00884bc42cdf75c389c616beca
          - id: Example-MAY-1.3[1]
            word: MAY
            lines: L27-L28
            section: "1.3"
            offset: 89
            index: 1
            text: Sorte aliquando MUST sumpsere illum rebus, [et obortis](http://quidem-expulit.com/) care MAY in.
            link: https://github.com/n3wscott/mdspeclinks/blame/main/example.md?w=MAY&c=89#L27-L28
            md5: 3b0552429821183f8926d13107d90ab8

what I am working on now is how do I talk about this entry in an easy way without using that MD5 hash, and not be fragile to break if someone adds a section to the document, causing all ids to need to be updated after the addition.

here is an example from the new eventing specs:

      - id: Data-plane-MUST-1.3.3[12]
        word: MUST
        lines: L128-L129
        section: 1.3.3
        offset: 108
        index: 12
        text: '[Brokers](./overview.md#broker) and [Channels](./overview.md#channel) MUST implement congestion control and MUST implement retries.'
        link: https://github.com/knative/specs/blame/438f242a1a96564cd1004ea80a0c08cd81978d45/specs/eventing/data-plane.md?w=MUST&c=108#L128-L129
        md5: 3897a98dd3d569873954f061ea5a357e

### May 18

- [n3wscott] Working on a PoC to convert a markdown file into a extracted list of the requirement and pointer back from the source of the line.
- Ends up looking like this maybe:

      - id: Data-planeSHOULD_NOT_L159C11
        word: SHOULD NOT
        line: 159
        column: 11
        text: The sender SHOULD NOT assume that a received reply event is directly related to the event sent in the HTTP request.
        link: https://github.com/knative/specs/blame/438f242a1a96564cd1004ea80a0c08cd81978d45/specs/eventing/data-plane.md?w=SHOULD_NOT&c=11#L159
        md5: 23cc2c2e3990b6ba05d369f18c9a7308

- PoC in progress here: https://github.com/n3wscott/mdspeclinks/tree/github-links

## Work Week 18

- [^] Finish Broker Conformance tests.
- [^] Finish Channel Conformance tests.

This week we focused around getting the release ready.

- [argent] is working on rewriting the eventing specs, which has put a pause on the conformance test authoring.
- https://github.com/knative/specs/pull/24 updates the overview, motivation, and data plane.
- https://github.com/knative/specs/pull/25 builds on 24 and adds a control-plane and event routing doc.

## Work Week 17

- [^] Finish Broker Conformance tests.
- [^] Finish Channel Conformance tests.

### May 6

- [n3wscott, bmo] Ben was writing some e2e tests and discovered that the webhooks in eventing kiinnndddaaa did not work so much anymore because of yesterdays trimming of config. This is a followup pr to [trim the rest of the conversion config off](https://github.com/knative/eventing/pull/5362).
- [n3wscott] More progress on the API validation for schema and webhooks, most of this work had already been done by others. So that is nice.
- https://github.com/knative/eventing/pull/5366
- https://github.com/knative/eventing/pull/5365
- https://github.com/knative/eventing/pull/5361
- General fixup for conversion: https://github.com/knative/eventing/pull/5362

### May 5

- [n3wscott] Was able to get a bunch of the API issues closed:
- https://github.com/knative/eventing/issues/4922
- https://github.com/knative/eventing/issues/4932
- https://github.com/knative/eventing/issues/4938
- https://github.com/knative/eventing/issues/4930
- (in progress) https://github.com/knative/eventing/issues/4926

### May 3

- [n3wscott]
- [bmo] Added [e2es for ContainerSource](https://github.com/knative/eventing/pull/5338)

## Work Week 17

- [^] Finish Broker Conformance tests.
- [^] Finish Channel Conformance tests.
- [x] Have someone else from the community author a rekt test.

### April 26

- [n3wscott] MIA, working on a presentation.

## Work Week 16

- [^] Finish Broker Conformance tests.
- [^] Finish Channel Conformance tests.
- [^] Have someone else from the community author a rekt test.

### April 23 - Day off.

### April 21,23 - idk.

### April 20

- [n3wscott] Fixing timing bugs in the channel tests. [eventing#5284](https://github.com/knative/eventing/pull/5284).
- Going to look at some way to help make this easier to remember to do...

### April 19

- [n3wscott] Need to look at some flake reports on channel ready status. We might not have polling in all the right places for asserts on the channel tests.

## Work Week 15

- [x] Have an easier way to send and receive events using eventshub. It is too hard to correlate the events at the moment.
- [^] Finish Broker Conformance tests.
- We are super close to closing this out.
- [^] Finish Channel Conformance tests.
- [^] Have someone else from the community author a rekt test.
- This is in progress for Kafka Source.

### April 16

- hack day.
- [n3wscott] Worked on look ahead for feature test runs for the wahoo viewer. [reconciler-test#178](https://github.com/knative-sandbox/reconciler-test/pull/178), pairs with [wahoo#fe7f37b](https://github.com/n3wscott/wahoo/commit/fe7f37b302b3cb8b7701aa3987c950a9929663ba)

### April 15

- [n3wscott] Filled `MTChannelBasedBroker impl ignores trigger.spec.delivery when creating subscriptions.` [eventing#5266](https://github.com/knative/eventing/issue/5266)
- Fixed by [eventing#5267](https://github.com/knative/eventing/pull/5267).
- [n3wscott] Wrap up data plane broker tests. [eventing#5268](https://github.com/knative/eventing/pull/5268)

### April 14

- [n3wscott + vaikas] We colab'ed on building a solution to estimate the expectations given delivery specs of a known broker+trigger combo and were able to test broker/trigger delivery spec combos. Found issues. [eventing#5262](https://github.com/knative/eventing/pull/5262)

### April 13

- [n3wscott] Integrate with event prober from reconcile-test in [eventing#5216](https://github.com/knative/eventing/pull/5216).

### April 12

- [n3wscott] Starting to try to land the eventprober to reconciler-test. Landed! [reconciler-test#173](https://github.com/knative-sandbox/reconciler-test/pull/173)

## Work Week 14

- [^] Have an easier way to send and receive events using eventshub. It is too hard to correlate the events at the moment.
- [^] Finish Broker Conformance tests.
- [^] Finish Channel Conformance tests.
- [^] Have someone else from the community author a rekt test.

### April 9

- hack day.

### April 8

- [n3wscott] Created [eventing#5216](https://github.com/knative/eventing/pull/5216) to land the last weeks work of this instance object to work with eventshub.

### April 7

- [n3wscott] Continue working on events from yaml. Made a file server, integrated it in eventing, and ended up with this test:

    // SourceToTwoSinksWithDLQ tests to see if a Ready Broker acts as middleware.
    //
    // source ---> broker +--[trigger<via1>]--> bad uri
    //                |   |
    //                |   +--[trigger<vai2>]--> sink2
    //                |
    //                +--[DLQ]--> sink1
    //
    func SourceToTwoSinksWithDLQ(brokerName string) *feature.Feature {
        prober := eventprober.New(broker.GVR(), brokerName, "")

        via1 := feature.MakeRandomK8sName("via")
        via2 := feature.MakeRandomK8sName("via")

        f := feature.NewFeature()

        lib := feature.MakeRandomK8sName("lib")
        f.Setup("install events", eventcache.Install(lib))
        f.Setup("use events cache", prober.EventsFromSVC(lib, "events/three.ce"))
        if err := prober.ExpectYAMLEvents(eventcache.PathFor("events/three.ce")); err != nil {
            panic(fmt.Errorf("can not find event files: %s", err))
        }

        // Setup Probes
        f.Setup("install recorder1", prober.RxInstall("sink1"))
        f.Setup("install recorder2", prober.RxInstall("sink2"))

        // Setup data plane
        f.Setup("update broker with DLQ", broker.Install(brokerName, prober.DeadLetterSinkCfg("sink1")))
        f.Setup("install trigger via1", trigger.Install(via1, brokerName, trigger.WithSubscriber(nil, "bad://uri")))
        f.Setup("install trigger via2", trigger.Install(via2, brokerName, trigger.WithSubscriber(prober.AsRef("sink2"), "")))

        // Resources ready.
        f.Setup("trigger1 goes ready", trigger.IsReady(via1))
        f.Setup("trigger2 goes ready", trigger.IsReady(via2))

        // Install events after data plane is ready.
        f.Setup("install source", prober.TxInstall("source"))

        // After we have finished sending.
        f.Requirement("sender is finished", prober.TxDone("source"))

        // Assert events ended up where we expected.
        f.Stable("broker with DLQ").
            Must("accepted all events", prober.AssertSentAll("source")).
            Must("deliver event to DLQ (via1)", prober.AssertReceivedAll("source", "sink1")).
            Must("deliver event to sink (via2)", prober.AssertReceivedAll("source", "sink2"))

        return f
    }

Which I find pretty readable.

### April 6

- [n3wscott] Eventshub can now send events from yaml configuration via a url (or file path) in [reconciler-test#165](https://github.com/knative-sandbox/reconciler-test/pull/165)

### April 5

- [n3wscott] Going to make the eventshub able to take a url to a yaml based cloudevents definition.
- [n3wscott] Discovered why we get panics in eventshub, fixed in [reconciler-test#164](https://github.com/knative-sandbox/reconciler-test/pull/164)

## Work Week 13

- [^] Have an easier way to send and receive events using eventshub. It is too hard to correlate the events at the moment.
- [^] Finish Broker Conformance tests.
- [^] Finish Channel Conformance tests.
- [^] Have someone else from the community author a rekt test.

### April 2

- Hack Day.
- [n3wscott] Was working on adding structured support to the cloudevents conformance tool: [cloudevents/conformance#20](https://github.com/cloudevents/conformance/pull/20)

### April 1

- [n3wscott] Working on what it migth look like to wrap the eventshub in an instance object to maintain state while running the test. The experiment,

The simple test case is trying to test something like this:

    // source ---> broker<Via> --[trigger]--> bad uri
    //                |
    //                +--[DLQ]--> sink
    //

And the test becomes this:

    func SourceToSinkWithDLQ(brokerName string) *feature.Feature {
        prober := eventprober.New(broker.GVR(), brokerName, "")
        prober.LoadFullEvents(1)

        via := feature.MakeRandomK8sName("via")

        f := new(feature.Feature)

        // Setup Probes
        f.Setup("install recorder", prober.RxInstall("sink"))

        // Setup data plane
        f.Setup("update broker with DLQ", broker.Install(brokerName, prober.DeadLetterSinkCfg("sink")))
        f.Setup("install trigger", trigger.Install(via, brokerName, trigger.WithSubscriber(nil, "bad://uri")))

        // Resources ready.
        f.Setup("trigger goes ready", trigger.IsReady(via))

        // Install events after data plane is ready.
        f.Setup("install source", prober.TxInstall("source"))

        // After we have finished sending.
        f.Requirement("sender is finished", prober.TxDone("source"))

        // Assert events ended up where we expected.
        f.Stable("broker with DLQ").
            Must("accepted all events", prober.AssertSentAll("source")).
            Must("deliver event to DLQ", prober.AssertReceivedAll("sink"))

        return f
    }

Some interesting things are always asking the prober for Rx and Tx objects via the prefix: prober.RxInstall(“sink”)

And letting the prober understand how to make some kinds of configuration, like: `prober.DeadLetterSinkCfg("sink")`

Full impl of the prober class:

https://github.com/knative/eventing/compare/main...n3wscott:chatty?expand=1#diff-abba9d361f2fb5e45040a191bfd2cfa47ab2c2796b7c3c43168e2c978bde0ef5

LOTS of WIP and playing in this, another experiment to make it easier to send events that are a shape using the cloudevents conformance tool is in there and not sure how it lands.

Another example with something a little more complicated:

    // [Source] ---> { Target(Broker)}--> [Sink1] --> {reply}
    //                  	|
    //   	                +-(DLQ)-> [Sink2]
    //

so in this one we have two sinks...

    func SourceToSinkWithDLQ(brokerName string) *feature.Feature {
        prober := New(broker.GVR(), brokerName, "")

        prober.LoadFullEvents(3)

        via := feature.MakeRandomK8sName("via")

        f := new(feature.Feature)

        // Setup Probes
        f.Setup("install sink", prober.RxInstall("sink1"))
        //f.Setup("install sink", prober.FxInstall("sink3"))
        f.Setup("install dlq", prober.RxInstall("dlq"))

        // Setup data plane
        f.Setup("update broker with DLQ", broker.Install(brokerName, prober.DeadLetterSinkCfg("dlq")))
        f.Setup("install trigger", trigger.Install(via, brokerName, prober.TriggerSubscriberCfg("sink"), trigger.WithFilter()))

        // Resources ready.
        f.Setup("trigger goes ready", trigger.IsReady(via))

        // Install events after data plane is ready.
        f.Setup("install source", prober.TxInstall("source"))

        // Assert events ended up +1.
        f.Stable("broker with DLQ").
            Must("deliver event to DLQ", prober.Rx("sink").)
            //OnStore(dlq).MatchEvent(HasId(event.ID())).Exact(1))

            //[]eventsByWho := prober.SentEvents()
            prober.WantEventsSeenBy("prefix", )

        f.Assert("all events were accepted", func(ctx context.Context, t feature.T) {
            prober.
        })

        return f
    }

### March 31

- [n3wscott] Refactored (minor) the cloudevent accepts test from broker to use for channel: [eventing#5187](https://github.com/knative/eventing/pull/5187)

### March 30

- [n3wscott] Finished channel control plane tests. [eventing#5182](https://github.com/knative/eventing/pull/5182)
- [n3wscott] Starting channel data plane tests. [eventing#5183](https://github.com/knative/eventing/pull/5183)

### March 29

- [n3wscott] Adding more channel control plane tests, starting to add subscription tests in prep for the data plane tests for channels. [eventing#5177](https://github.com/knative/eventing/pull/5177)

## Work Week 12

Week goals:

- [^] Have an easier way to send and receive events using eventshub. It is too hard to correlate the events at the moment.
- [^] Finish Broker Conformance tests.
- [^] Mostly finish Channel Conformance tests.

### March 26

- hack day.

### March 25

- [n3wscott] Channel CO shape tests [eventing#5152](https://github.com/knative/eventing/pull/5152)

### March 23

- [n3wscott] Working on channel control plane tests.
- [Channel CRD conformance](https://github.com/knative/eventing/pull/5138)
- [vaikas] Worked on several tests using events hub to test data plane conformance related to return codes and delivery.
- Found an issue downstream where RabbitMQ Broker does not respond with the correct http code.

### March 22

- [n3wscott] Started channel control plane tests.
- [n3wscott/vaikas] We got feedback from slinky that we are not doing a great job explaining the plan.
- We will post a discussion thread to help folks come alone on the new assumptions on the test author requirements.
- Posted [eventing/discussions#5123](https://github.com/knative/eventing/discussions/5123)

## Work Week 11

Week goals:

- [x] Land seed conformance test to eventing that can be run on other brokers in other repos with no changes.
- [x] Rework eventshub to not require the eventing namespace init methods.
- Turns out we can do this in the test.main init method, so it might be ok.

### March 19

- hack day.

### March 18

- [n3wscott] all Broker/Trigger control plane conformance tests have been finished. We are now working on the tests that involve the data plane.

### March 17

- [n3wcott] Fixed a bug with schema cli and pushed the update to discovery and eventing.
- [eventing#153](https://github.com/knative-sandbox/discovery/pull/153)
- [discovery#153](https://github.com/knative-sandbox/discovery/pull/153)
- [n3wscott] Adding a test for bad trigger filter values, [eventing#5089](https://github.com/knative/eventing/pull/5089)
- bad news: all new tests failed, the trigger webhook accepted all bad values.

### March 16

- [n3wscott] [eventing#5072](https://github.com/knative/eventing/pull/5072) merged but there are several followup items.
- We moved forward with replacing the templates for DUT type tests, but we want to enable overlays of the important bits, first crack at this is here [reconciler-test#136](https://github.com/knative-sandbox/reconciler-test/pull/136)
- [n3wscott] Filed a bug we just found `Spec says trigger.spec.broker gets defaulted, but this does not happen in the code.` [eventing#5081](https://github.com/knative/eventing/issues/5081)
- [n3wscott] Authored a fix for some of the trigger tests that were failing, [eventing#5082](https://github.com/knative/eventing/pull/5082)
- [ vaikas ] Feedback on the features, add ability to pull templates from various places. Vendor in and work on getting conformance tests to pass in rabbitmq.

### March 15

- [n3wscott / vaikas] Trying to land all of the friday work for external broker class and more spec based conf tests, [eventing#5072](https://github.com/knative/eventing/pull/5072)
-

## Work Week 10

### March 12

- [n3wscott] A followup from the ideas from yesterday, I decided to try a cucumber based configuration of the rekt tests. This looks promising.
- PoC PR [eventing#5062](https://github.com/knative/eventing/pull/5062) After chatting, we think it is interesting but cucumber might not be adding value, can we get the same thing with just config? We are working up that PoC next.
- [n3wscott / vaikas] After long discussions, we're going to dump cucumber for now and see about simplifying the assumptions and rely on conventions over a particular too. So the assumptions are as follows, and we're going to work on using RabbitMQ broker as our first "customer".
- It's ok for now to copy the main test entry point into the users code base. This is in the order of ~15 lines and currently required due to vendoring of go stuff. May be solvable, but for now will suffice.
- User who wants to validate a particular Broker implementation (same goes for channels, etc. but to simplify, we'll use Broker as it covers all the use cases) will only have to know the conventions (below) and create snippets of yaml that contain specific deets about the Broker under test.
- So, the plan of record is as follows:
- There will be a test "root" directory, where for each permutation of the creatable brokers there will be a directory. For our RabbitMQ test, there are going to be two: "with-operator" and "with-secret". For RabbitMQ broker these are the variants that we're interested in testing. Let's call this "testdata/config", therefore, we'd have two directories there: "testdata/config/with-operator" and "testdata/config/with-secret".
- In each of these directories there are two files (by convention): base.yaml and prereq.yaml. base.yaml contains the bare bones deets for creating a Broker that we're going to be testing. prereq.yaml contains any necessary pre-requisites for creating the Broker. In our base, prereq.yaml would have two flavors (in their respective directories), one that would create a RabbitMQClusterOperator and another with a Secret. These prereqs will run through a template processor and will get the namespace under test populated from the test framework. The base.yaml will contain only the necessary bits for creation of the Broker that varies for the creation. So, in our cases, there would be one that would be pointing to a Secret and one pointing to Operator. TBD if / how we determine the prereq becoming ready. One could argue that since we're dealing with k8s resources, things should become ready because the order of creation shouldn't matter. For now, if prereqs don't become ready, the Broker will not become ready -> test will fail.
- One additional piece that we probably do NOT want to come from file is the BrokerClass, current thinking is that this will be env variable. There's no reason why that can't be baked into the base.yaml, but something to keep in mind.
- So, now that we have the first level of "for" loopery, we'll then for each of these permutations run all the conformance tests by treating prereq.yaml (with Namespace populated) as our testing Prerequisite and we'll then convert the base.yaml into v1.Broker type. At this point, for things like Delivery, we can now run permutations around various configurations of the Delivery because it's a strongly typed, we define the expected behaviour in our tests and can also set up things like Trigger / Subscription, etc. around this.
- Also, this should lend itself nicely for doing mutation testing. Create a base.yaml resource, and now that it's a v1.Broker type, we can do mutations, for example, change the BrokerClass => won't go and should fail and so on. But all these mutations are defined in the specs repo test code.
- Resulting PR [n3wscott/eventing#15](https://github.com/n3wscott/eventing/pull/15)

### March 11

- [n3wscott] Based on feedback, working on upstreaming some common duck type related features from eventing into reconciler-test. Then adding timing based defaults to reconciler-test to help reduce boilerplate in downstream tests.
- [reconciler-test#127](https://github.com/knative-sandbox/reconciler-test/pull/127)
- [n3wscott] Will followup on comments on [eventing#5049](https://github.com/knative/eventing/pull/5049)
- [n3wscott] Ville and I had a long talk about the requirements for conformance and we are going to look at what a solution might look like to have much less config be baked into go, and more come from the test runner (the human or CI system).

### March 10

- [n3wscott] PR for [Smoke Tests on SinkBinding](https://github.com/knative/eventing/pull/5049)
- [n3wscott] Looking at migrating existing tests for SinkBinding to rekt
- skip until later.
- [n3wscott] Introduce rekt managed env option [Managed Lifecycle of Environment](https://github.com/knative-sandbox/reconciler-test/pull/123)
- [n3wscott] PR for [Smoke Tests on ContainerSource](https://github.com/knative/eventing/pull/5050)
- [n3wscott] PR for [Smoke Tests on Channel](https://github.com/knative/eventing/pull/5052)
- [vaikas] Trying to use the new reconciler-test for generic conformance tests. Identify shortcomings, propose fixes, work with Scottie on solutions.

### March 9

- [n3wscott] Started working up smoke tests for SinkBinding
- [n3wscott] Some fun fighting bots and upstream packages this morning with actions upgrades (looking at you golint).
- [vaikas] Kafka v1alpha1 duckery work
- [vaikas] Speed up e2e tests by ~15-20 minutes, building all the archs for e2e and we only use one. Great stuff... not

### March 8

- [n3wscott] Broke apart e2e and rekt tests in eventing that was causing flakes in prow for eventing. [eventing#5025](https://github.com/knative/eventing/pull/5025) and [test-infra#2698](https://github.com/knative/test-infra/pull/2698)
- [n3wscott] Made an example smoke tests using rekt for [PingSource](https://github.com/knative/eventing/pull/5033)
- [vaikas] moar coverage for UT

## Work Week 9

### March 5

- [n3wscott] Hack day. Worked on [metareconciler discovery#154](https://github.com/knative-sandbox/discovery/pull/154) trying to build the base of what will be the sugar controller abstractions.
- [vaikas] Refactor mtbroker -> broker for cleaner code org
- [vaikas] remove bunch of old cruft, configmappropagations
- [vaikas] more ready for v1. Change internal uses of v1beta1 to v1 wherever possible
- [vaikas] port the v1alpha1 ducks to kafka to ensure they will keep working

### March 4

- [n3wscott] Worked up a milestone event sender for milestones of the testing framework, but folks do not seem to see the benifits of doing such a thing. [reconciler-test#106](https://github.com/knative-sandbox/reconciler-test/pull/109)
- [vaikas] (or thereabouts) add moar UT, remove old v1alpha1 duckery, subscription only works with v1beta1 / v1 now.

### March 3

- [n3wscott] Adding unit tests for issue [eventing#4972](https://github.com/knative/eventing/issues/4972), pkg/reconciler/source/* items.
- [vaikas] [Removing v1alpha1 Channelable](https://github.com/knative/eventing/pull/5005).
- Supporting PR for Kafka to [move their usage local](https://github.com/knative-sandbox/eventing-kafka/pull/430).

### March 2

- [n3wscott] feature sets merged!
- [n3wscott] Moving forward with feature.T interface but holding off on wrapping testing.T for now in [refactor Feature](https://github.com/knative-sandbox/reconciler-test/pull/97)
- [n3wscott] Made more progress on the schema dump tool.
- base pr in [pkg](https://github.com/knative/pkg/pull/2039)
- in use in [discovery](https://github.com/knative-sandbox/discovery/pull/153)

### March 1

- [n3wscott] Picking back up the [kvstore PR](https://github.com/knative-sandbox/reconciler-test/pull/103) for reconciler-test, impl feedback.
- [n3wscott] Updated [feature sets](https://github.com/knative-sandbox/reconciler-test/pull/102), ready for merge.
- [n3wscott] Picking up [Code Coverage needs to be increased >=80% for pkg/adapter/v2](https://github.com/knative/eventing/issues/4960)
- Created [eventing#5000](https://github.com/knative/eventing/pull/5000)

## Work Week 8

### Feb 26

- [n3wscott] Hack day. Looking at lifting parts of the [sugar PoC](https://github.com/n3wscott/sugar) into [discovery](https://github.com/knative-sandbox/discovery).
- First PR to try to add the per duck controller creation management: [discovery#154](https://github.com/knative-sandbox/discovery/pull/154). Needs tests.

### Feb 25

- [n3wscott] While we are sorting out how to compose tests and all that, I am going to take a look at how to generate OpenAPI for CRDs without kustomize/kubebuiler. Looking at https://github.com/kubernetes/kube-openapi/tree/master/cmd/openapi-gen but it is lightly documented.
- Found this chunk of code by Harwane that does some fancy reflection based magic on types based on imports and the go files linked to those imports: [Harwayne/knative-gcp#reflective-schema](https://github.com/Harwayne/knative-gcp/tree/reflective-schema) but sadly this is fairly compile time dependent, and also needs the local files. So I am starting with this and lifed it out into knative/pkg.
- Adding this concept as a cli base to [pkg#2039](https://github.com/knative/pkg/pull/2039)
- Integrating it with [Discovery#153](https://github.com/knative-sandbox/discovery/pull/153)
### Feb 24
- [n3wscott] produced [reconciler-test#103](https://github.com/knative-sandbox/reconciler-test/pull/103) to attempt to address sharing state between steps in a feature.

### Feb 23

- [n3wscott] going to look at [FeatureSets](https://github.com/knative-sandbox/reconciler-test/issues/65) to support conforamce work.
- Produced [knative-sandbox/reconciler-test #102](https://github.com/knative-sandbox/reconciler-test/pull/102)